From Ted.Lemon@nominum.com Sun Apr 1 03:34:29 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1157521F868C for ; Sun, 1 Apr 2012 03:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BC6MlAfV-Nl for ; Sun, 1 Apr 2012 03:34:28 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A377721F868A for ; Sun, 1 Apr 2012 03:34:24 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT3gvMHxaU/eJxlrQ0c9toLOHXA88oU/X@postini.com; Sun, 01 Apr 2012 03:34:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 91FD71B82BB for ; Sun, 1 Apr 2012 03:34:23 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 00CE9190064; Sun, 1 Apr 2012 03:34:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sun, 1 Apr 2012 03:34:11 -0700 From: Ted Lemon To: Tony Hain Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gB1uXCAAAojCT4= Date: Sun, 1 Apr 2012 10:34:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com>, <075201cd0f8e$94cb8170$be628450$@tndh.net> In-Reply-To: <075201cd0f8e$94cb8170$be628450$@tndh.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 10:34:29 -0000 *sigh* This is why we keep failing to complete anything: people who want the optio= n think the use cases are obvious, and don't want to go to the trouble of c= learly articulating them. People who don't want the option then look at t= he incompletely articulated use cases, recognize that they aren't valid, an= d quite rightly ask us to stop working on something for which there is no c= lear motivating use case. If you are experiencing operational pain as a result of not having the rout= e option, I would like to hear about that operational pain. If you just t= hink there ought to be a route option because that's what we did in IPv4, I= don't agree with that argument. I think there are real uses cases that i= nvolve real operational pain. We should focus on addressing those use cas= es, hopefully in a way that fits in with the rest of the internet architect= ure, rather than trying to replicate IPv4 functionality just for the sake o= f completeness. As for whether this ought to be a DHC or MIF item, part of what happened he= re is that I pushed pretty hard to *not* have this as a DHC item, because I= don't think it's particularly a matter for the DHC working group unless we= get a mandate from some other working group to work on it. I personally a= m not experiencing any pain as a result of not having this option, and I am= not aware of anybody who is except Alexandru and BBF, who actually have tw= o very different use cases. I personally have no wish to involve DHCPv6 route options in the operation = of my home network, and I am pretty sure the ops team at Nominum doesn't ne= ed or want this option to operate their networks. It's something that mak= es sense in a few cases, not generally. So it's simply not work the DHC w= orking group would ever adopt on its own, without some clear use case or so= me clear request from another working group that has already developed the = use case. From alh-ietf@tndh.net Mon Apr 2 09:18:48 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1A821F851B for ; Mon, 2 Apr 2012 09:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0OZ-KmVWt6z for ; Mon, 2 Apr 2012 09:18:47 -0700 (PDT) Received: from tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7436D21F865B for ; Mon, 2 Apr 2012 09:18:47 -0700 (PDT) X-AuthUser: alh-ietf@tndh.net Received: from eaglet ([172.20.144.31]:40052) by tndh.net with [XMail 1.27 ESMTP Server] id for from ; Mon, 2 Apr 2012 09:18:44 -0700 From: "Tony Hain" To: "'Ted Lemon'" References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> ,<075201cd0f8e$94cb817 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com> Date: Mon, 2 Apr 2012 09:18:42 -0700 Message-ID: <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGYocXPKzopiDhicKFSNXe3ky5PRQFWcj/vAj3jZD8CE4SQEAM8EDN1Aal2DB8CuqDa4AGu3TE6AouFInYBmOpBUgHiAfgSAabbPDMCVhY93gK9RQNgAaU+fSYBVklIJAKKPEcuAtiEBeIBI67GfQHRMw/lAfaPfVACiVre65WUMZKQ Content-Language: en-us Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:18:48 -0000 Ted, I agree that you don't do something just because it was done in IPv4, but your response is exactly the same as your complaint about the public lynching. Just because your local network is not using this mechanism is no reason to deny others from having it for theirs. I didn't put more detail in the initial response because I thought it needed more time to do it justice. I still intend to do an offline set of comments about splitting the existing doc so that there is a dhcp mechanism and an RA approach, but in short; people do operate VPNs with split tunneling, and need a way to push the internal routes to the client. The operational pain will occur when there is no option 121 for those networks that use it for IPv4. The alternative is what I am doing; manually running a static route script every time the vpn goes up and another when it goes down to pull them back out. That is not operationally viable at scale, and is more than annoying even during the interim while the nonsense fighting over the "correct" operational model continues in the IETF. It really doesn't matter what your local network uses or wants, what matters is can people clearly articulate a use case and a mechanism to deal with it. As I said earlier, there are networks that want to use dhcp as their centralized point of management control. For those networks we need to document the IPv6 version of RFC 3442. At the same time there are networks that want to avoid deploying dhcp just for one mechanism, so an alternative needs to be defined. Not that it matters, but my corporate network only uses IPv6 dhcp to provision a router that requires it for 6rd testing, and that will go away at some point. I really don't want to keep dhcp just for the VPN clients, but that is better than manual scripts. In the big picture though, it really doesn't matter what my network uses any more than any other. Widespread deployment requires that people have the tools they want to use for managing their local network. Continued fighting in the IETF over why someone else's operational model is "wrong" is simply delaying deployment. MIF is supposed to be identifying all the operational issues raised by the multiple interface case, then the resolutions. People have raised use cases for why routes need to be pushed, yet MIF seems more interested in denying the operational concerns than in documenting solutions. Tony -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Sunday, April 01, 2012 3:34 AM To: Tony Hain Cc: mif@ietf.org Subject: RE: [mif] Route option for DHCPv6 - next steps? *sigh* This is why we keep failing to complete anything: people who want the option think the use cases are obvious, and don't want to go to the trouble of clearly articulating them. People who don't want the option then look at the incompletely articulated use cases, recognize that they aren't valid, and quite rightly ask us to stop working on something for which there is no clear motivating use case. If you are experiencing operational pain as a result of not having the route option, I would like to hear about that operational pain. If you just think there ought to be a route option because that's what we did in IPv4, I don't agree with that argument. I think there are real uses cases that involve real operational pain. We should focus on addressing those use cases, hopefully in a way that fits in with the rest of the internet architecture, rather than trying to replicate IPv4 functionality just for the sake of completeness. As for whether this ought to be a DHC or MIF item, part of what happened here is that I pushed pretty hard to *not* have this as a DHC item, because I don't think it's particularly a matter for the DHC working group unless we get a mandate from some other working group to work on it. I personally am not experiencing any pain as a result of not having this option, and I am not aware of anybody who is except Alexandru and BBF, who actually have two very different use cases. I personally have no wish to involve DHCPv6 route options in the operation of my home network, and I am pretty sure the ops team at Nominum doesn't need or want this option to operate their networks. It's something that makes sense in a few cases, not generally. So it's simply not work the DHC working group would ever adopt on its own, without some clear use case or some clear request from another working group that has already developed the use case. From Ted.Lemon@nominum.com Tue Apr 3 03:06:22 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE07E21F8653 for ; Tue, 3 Apr 2012 03:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.979 X-Spam-Level: X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35kW5D4SWi1C for ; Tue, 3 Apr 2012 03:06:22 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8B21F841E for ; Tue, 3 Apr 2012 03:06:20 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT3rLmjsOJ0vMjdyEteZHZ5JP0bij158m@postini.com; Tue, 03 Apr 2012 03:06:21 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F33581B82CE for ; Tue, 3 Apr 2012 03:06:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E33C5190064; Tue, 3 Apr 2012 03:06:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 3 Apr 2012 03:06:11 -0700 From: Ted Lemon To: Tony Hain Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gB1uXCAAAojCT4ATUl3AAAWVyMT Date: Tue, 3 Apr 2012 10:06:11 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> ,<075201cd0f8e$94cb817 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>, <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> In-Reply-To: <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 10:06:22 -0000 > I agree that you don't do something just because it was done in IPv4, but > your response is exactly the same as your complaint about the public > lynching. Just because your local network is not using this mechanism is = no >reason to deny others from having it for theirs. Lynching was a poor choice of words. In any case, my point is that if you= have a real need for this functionality on your network, you should be abl= e to articulate that in a convincing way, and there should be some reason w= hy DHCPv6 is a better solution than RA. It shouldn't be the case that you= 'd just rather use DHCPv6. > people do operate VPNs with split tunneling, and > need a way to push the internal routes to the client. The operational pai= n > will occur when there is no option 121 for those networks that use it for > IPv4. The alternative is what I am doing; manually running a static route > script every time the vpn goes up and another when it goes down to pull t= hem > back out. What's missing from this description is "RA doesn't work well in this situa= tion because..." > Widespread deployment requires that people have the tools they want to us= e > for managing their local network. Widespread deployment requires that people have tools that work well to man= age their local network. If the tools that we have given them thus far do = not work well, it should be easy to say why. It's not the IETF's job, nor= should it be, to give them specific tools just because those are the ones = they want, any more than the building code should allow you to use deck scr= ews in a shear wall just because you happen to prefer an impact driver to a= nail gun.= From alh-ietf@tndh.net Tue Apr 3 09:24:15 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D11811E815A for ; Tue, 3 Apr 2012 09:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjT2NrOZ+Cmk for ; Tue, 3 Apr 2012 09:24:14 -0700 (PDT) Received: from tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0DE11E8157 for ; Tue, 3 Apr 2012 09:24:13 -0700 (PDT) X-AuthUser: alh-ietf@tndh.net Received: from eaglet ([172.20.144.31]:37878) by tndh.net with [XMail 1.27 ESMTP Server] id for from ; Tue, 3 Apr 2012 09:24:11 -0700 From: "Tony Hain" To: "'Ted Lemon'" References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> ,<075201cd0f8e$94cb81 7 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>, <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> Date: Tue, 3 Apr 2012 09:24:09 -0700 Message-ID: <01a601cd11b6$34522090$9cf661b0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGYocXPKzopiDhicKFSNXe3ky5PRQFWcj/vAj3jZD8CE4SQEAM8EDN1Aal2DB8CuqDa4AGu3TE6AouFInYBmOpBUgHiAfgSAabbPDMCVhY93gK9RQNgAaU+fSYBVklIJAKKPEcuAtiEBeIBI67GfQHRMw/lAPKIJtsCiVre6wGxPjrQAeJ5bLGVgUcx8A== Content-Language: en-us Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:24:15 -0000 Ted Lemon wrote: > > I agree that you don't do something just because it was done in IPv4, > >but your response is exactly the same as your complaint about the > >public lynching. Just because your local network is not using this > >mechanism is no reason to deny others from having it for theirs. > > Lynching was a poor choice of words. In any case, my point is that if you > have a real need for this functionality on your network, you should be able to > articulate that in a convincing way, and there should be some reason why > DHCPv6 is a better solution than RA. It shouldn't be the case that you'd just > rather use DHCPv6. It appears you missed my point that my personal preference is to avoid using DHCPv6 for this single function, because I have no other ongoing need. At the same time, as I said my personal preference doesn't matter, and I will defend the right of others to have the tools they expect. Like it or not, there are people that wouldn't know what to do with their network without the centralized point of all operational knowledge in their DHCP server. In some cases this is due to internal politics, where the end system administrators operate the DHCP service, and they refuse to turn over control to the evil network ops team and whatever they might do. In other cases the network ops team operates DHCP with the explicit intent to assert some control over those evil end systems. > > > people do operate VPNs with split tunneling, and need a way to push > > the internal routes to the client. The operational pain will occur > > when there is no option 121 for those networks that use it for IPv4. > > The alternative is what I am doing; manually running a static route > > script every time the vpn goes up and another when it goes down to > > pull them back out. > > What's missing from this description is "RA doesn't work well in this situation > because..." One size does not fit all ... The reason that operations is such a mess right now is the ongoing and unnecessary war about which operational model is "right", resulting in the absurd need to do logically associated things in different places. There should be a mechanism that makes this work well via RA, but that does not mean the DHCP approach is wrong. The IETF needs to create a complete tool set for operating networks both with and without DHCP. Again, one size does not fit all ... When we started this IPv6 effort DHCP was just getting started, and going through growing pains. At this point an entire generation of network operators don't know any different and would be lost if you told them their point of control in DHCP is gone. While a well-functioning RA mechanism is needed, that is simply inadequate for people that don't know anything but DHCP. > > > Widespread deployment requires that people have the tools they want to > > use for managing their local network. > > Widespread deployment requires that people have tools that work well to > manage their local network. If the tools that we have given them thus far do > not work well, it should be easy to say why. It's not the IETF's job, nor > should it be, to give them specific tools just because those are the ones they > want, any more than the building code should allow you to use deck screws > in a shear wall just because you happen to prefer an impact driver to a nail > gun.= Following that analogy, a large percentage of the network operators out there have a hammer. It doesn't matter if you give them screws or nails, they are going to use the hammer they know. At the end of the day one of those choices is more efficient and less frustrating than the other, but both can get the job done. At the same time, leaving the screws and a screwdriver laying alongside the nails will lead many to realize there may be a better fit for their needs. When you meet people where they are mentally, you have a better chance of discussing alternatives than if you insist they leave their comfort zone and follow your 'one true way' into the vast unknown. Tony From ek@google.com Tue Apr 3 18:53:20 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5111E8072 for ; Tue, 3 Apr 2012 18:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNHN3-MdDNmu for ; Tue, 3 Apr 2012 18:53:20 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5821F85FF for ; Tue, 3 Apr 2012 18:53:20 -0700 (PDT) Received: by qcsq13 with SMTP id q13so237194qcs.31 for ; Tue, 03 Apr 2012 18:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=0wBC1oWKG2BmoivbKVAgaIgtsMtySfJTx6ya+GCm8VI=; b=aSsO4OHgI2+IqKe6dQrdC5ChP4lCBIyURepT4rlG/vMG9IKvZQXTewBxiYRwUjFuJi p/uMsABO466E0T2fW95tgYlkGa9SMdAzcOerNuFzolSpkcBB9Kh7BpHcDxhWa7Y9/e7Z 4ezEb8mpwg45UwH8jAs22oTBv8U/LZuJz/rfV3qRVA5y+20WD5iplxo0GPHggPo1X5Lz fkB/WRsSW1Lje1lrPOFmqPAU+EFV/uo+4Jtx31C2ffY3JWWxZADIK988QvoeHizNZNSp hh2gsBElj1MW0lg5M731Bw+s9bi0k7fVyIk4tOGfyBZJFHxKh9YLmYPCBP1xqU+IK4YN lycw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=0wBC1oWKG2BmoivbKVAgaIgtsMtySfJTx6ya+GCm8VI=; b=feP8qiS6IK+yzSDZ5RbRl4Gprw4r+k4qYjkD6Qp3JXp8lHs1Ya6BOTxJd4WIjHAm0h wHxfqVk67URQ4c35dz4yksO/vzMokOwVoZGqfJdoqrwhL0DrSAh7nhT5cB3oCKkoL1BB N1TV2VSzi5SBtn/BWUzYwTyHFVRBRwlLimiQs1RYqr/kZT9dtP5SIbt5KxGa7nN5T//1 FIZbonvrBTn5e5xsj7SBw4iCQsF82UUMY+cBtN8xG+VhGNGyrguZxllPSCaIgxs0MtQv aVHKDfgTx+llELDJUwFJJd82i9EEVbXExyeukrC1O8PrP+ziqhmf8nWtMAv7v5DZUVe1 KLOg== Received: by 10.224.181.69 with SMTP id bx5mr16187640qab.49.1333504399759; Tue, 03 Apr 2012 18:53:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.181.69 with SMTP id bx5mr16187630qab.49.1333504399608; Tue, 03 Apr 2012 18:53:19 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Tue, 3 Apr 2012 18:53:19 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D47A7@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D47A7@mbx-01.win.nominum.com> Date: Wed, 4 Apr 2012 10:53:19 +0900 Message-ID: From: Erik Kline To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQk3Bt2OM33wRWdiI2hr4tv265ZOon3NvfaLmgWO1LsORzuk7SvJg6ulhxdFaHjx1yxXsAiIlPQdCCThqp5c4OUILGp5goiubiQvhB2uEKD8+BgHDBidJBbnK3rx4Gi6vMQctjep Cc: "mif@ietf.org" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 01:53:21 -0000 > It's true, as Jari said, that this can be accomplished in other ways, and= maybe it would be better if it would. =C2=A0 If there were some better cen= tral management solution for populating unicast RA mappings on the router, = then unicast RA would indeed address the exact use case that I think we car= e about. =C2=A0 But without the mechanism for populating routers, we still = have a poorly-addressed use case. =C2=A0 And then the question is, do we wa= nt to develop a whole new protocol just to solve this one small problem? > > It might be worth developing the protocol just to put this issue to bed. Is RADIUS suitable for this? At one point it was the general non-client provisioning protocol of choice, I thought. I have not been following any of the evolving diameter work, but would a RADIUS option suffice? From lorenzo@google.com Tue Apr 3 19:01:49 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D326C21F849B for ; Tue, 3 Apr 2012 19:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIjzCIay+TyO for ; Tue, 3 Apr 2012 19:01:49 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4732821F8470 for ; Tue, 3 Apr 2012 19:01:42 -0700 (PDT) Received: by yhkk25 with SMTP id k25so192556yhk.31 for ; Tue, 03 Apr 2012 19:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=fPsZc6Wf796WW3RHX2pxgL6y+mi53Wl78J5yYdW8JWM=; b=e1W79Shwy+ZENit91Tq7e4wZLARcHap9kJKV6aC1UBy6Uvq1IK1ssJ9mWrUVmo8y2j 912fR7bNcq2Z4M4Zdsc+Zee8Tgzagr2+pq+0L/WRzk2BIB2Ck4MTZGd2C4qyZR0PMQi2 vWMmdYSrDSkvP/02h2jckQIMJuKOrqlToFhcS2o3A7N90rWWenH6BWJaiPQy+LnTHSSz MWr5/Atq0unBUmAE9TjC962y5WIm1Hot84T2UYUYqG2sykJjc45mBz1tGgjJ/PlB42E6 DSf0YZ8N5efRvDLG8Ej74pLkslS8TW1s4dUrVq4Y06lnnatCr08j3ggFeJ+UeFvQkhpo qUYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=fPsZc6Wf796WW3RHX2pxgL6y+mi53Wl78J5yYdW8JWM=; b=a3QSbec8BYJofBTAUQfhZwi6Pveq/JCim9aAU4DRZgb9ffm4klzBvhUROnXLYvKKRN jyhVPCO4I8NCa4vtA1uH1FdY3ZJf8o7XMYkmAtDLRky6CQ1SF4Ag2X4dP5lNWtd4K6LS lyp+Su8QnJhNa3buG7ii6IhjOIDbJYG6MrUobI1L40xHUonz8mGsTRmapDajZ6yP/48J 52HQ8sBFoYE0zn7vPZXinz8RV8BJmd3MUPrpeuDnajJLNuV+yRe2AL+y5R1qJaCjt23S gDiQLz8oFpq8LcRbMFCVg9Na5G30VC+M9oFPZzcKYdyUo0sBoUwrkV8K+gis8BTTIsrV GKcw== Received: by 10.60.0.226 with SMTP id 2mr22038768oeh.18.1333504901849; Tue, 03 Apr 2012 19:01:41 -0700 (PDT) Received: by 10.60.0.226 with SMTP id 2mr22038752oeh.18.1333504901699; Tue, 03 Apr 2012 19:01:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.63.231 with HTTP; Tue, 3 Apr 2012 19:01:21 -0700 (PDT) In-Reply-To: <01a601cd11b6$34522090$9cf661b0$@tndh.net> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com> <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> <01a601cd11b6$34522090$9cf661b0$@tndh.net> From: Lorenzo Colitti Date: Wed, 4 Apr 2012 11:01:21 +0900 Message-ID: To: Tony Hain Content-Type: multipart/alternative; boundary=e89a8fb1fbc6f8d95204bcd0cd57 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnn80yMcJyH1ulThKHcQflSo5xRBq1CvwdWWCM4A5f/Eo8PpG1cheVC6oU0VVj3JaQo0yvCtYoSy7mN2W1cWmk5RGs0c+48ViYB2UiaPSUy3nbd6cl37fhR6W6NL7QW3A8yY2qW Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 02:01:50 -0000 --e89a8fb1fbc6f8d95204bcd0cd57 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 4, 2012 at 01:24, Tony Hain wrote: > Following that analogy, a large percentage of the network operators out > there have a hammer. It doesn't matter if you give them screws or nails, > they are going to use the hammer they know. But that's a problem. If we standardize a hammer, there is a risk that those people will use it in the wrong scenarios - they might use the the hammer to drive screws into the walls instead of using the screwdriver, because they don't know how to use the screwdriver, even though they have it. That's not a problem per se. The concern is that over time, "use what you know", network effects, "security", and economics will lead to general adoption of the hammer because it becomes the lowest common denominator. If that happens, we as a community might not use the screwdriver any more, and we will have replaced a sophisticated tool with a less sophisticated one. --e89a8fb1fbc6f8d95204bcd0cd57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 4, 2012 at 01:24, Tony Hain <alh-ietf@tndh.net>= ; wrote:
Following that analogy, a large percentage of the network= operators out
there have a hammer. It doesn't matter if you give them screws or nails= ,
they are going to =A0use the hammer they know.

<= div>But that's a problem.

If we standardize a = hammer, there is a risk that those people will use it in the wrong scenario= s - they might use the the hammer to drive screws into the walls instead of= using the screwdriver, because they don't know how to use the screwdri= ver, even though they have it.

That's not a problem per se. The concern is that ov= er time, "use what you know", network effects, "security&quo= t;, and economics will lead to general adoption of the hammer because it be= comes the lowest common denominator. If that happens, we as a community mig= ht not use the screwdriver any more, and we will have replaced a sophistica= ted tool with a less sophisticated one.
--e89a8fb1fbc6f8d95204bcd0cd57-- From ek@google.com Tue Apr 3 19:07:08 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F53C21F8541 for ; Tue, 3 Apr 2012 19:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8Q3wx9ARnZr for ; Tue, 3 Apr 2012 19:07:07 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C853121F853A for ; Tue, 3 Apr 2012 19:07:07 -0700 (PDT) Received: by qcsq13 with SMTP id q13so243084qcs.31 for ; Tue, 03 Apr 2012 19:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=OA7zDPd8bvtiLh014C2ab/0MxZCpx1c30M/BCQJ8qvA=; b=IUFpKpW90AE76tI36dZm0yCsMMO+8/h1gj1DpJvoJ1N05WKTROlVUcC4J+4ND5Gyvo Ih7bkB6xKQokfx+kaoJpd7M1DY6JqrutQQsBA4g2L79xXvMTpf1omX3hXCgoSdIkijAM Xh4Cf62393n3L6DL+CToS1U0LcakpuXe+gbny8Uc4bwHRckWb01KjLI8lhsritQvfr5D HyZ8gaWNd/fmRhWPql9JtNqKBZGl/B7tnKqHHvE+1SkMqn6RNRoWqyanOAuxjAmltxC3 XX5EbngK/8F/p7t43MRsmQIkZqej+fjRYkZQCtL/axaQVSKFyr8nC7rqVk4vkWzc8lH3 yvYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=OA7zDPd8bvtiLh014C2ab/0MxZCpx1c30M/BCQJ8qvA=; b=e8t2QsMCfIRH2TYjdolPmkcnKNuyRGF6MCP3+U73e4MxZDyOYvuQuV/nGAAE0tW8Iz sOdJIqTVLHvkiCqWVde14aqThiVI0wTJn928pVX2wvMkZykRpdsm9qOX54YFzbpsaZ6m 6hVztA3eI/Jr9grICWs9Fkc6d/q+Zxb3A/7sQEeVjO+Vp8RT6BkjjzZlOpshQMoE4SAa wBw3jkhKInDlPY8qZpzqUQW1TTy6DPpAeo4AUZenIF4WPgQHAHtIYVM69RXSuwJML+2+ DrwiHpvRdB5exrtjKPmsqhZgK6l9opRKJas0d4mG1evuE+d33xsgMgl6PRczqAbDFBQq wnUQ== Received: by 10.229.115.21 with SMTP id g21mr5988575qcq.77.1333505227328; Tue, 03 Apr 2012 19:07:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.115.21 with SMTP id g21mr5988566qcq.77.1333505227206; Tue, 03 Apr 2012 19:07:07 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Tue, 3 Apr 2012 19:07:07 -0700 (PDT) In-Reply-To: <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com> <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> Date: Wed, 4 Apr 2012 11:07:07 +0900 Message-ID: From: Erik Kline To: Tony Hain Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkMATrOSTsqm/jk8+vRiGThPYdO/YiH4vqf5R5BFCMwuh7iyGvrlIDjxoRyQgLOomGuCNgAqAEpa3+PD4stp7kAuHsgJ92AS3Z7lj0vS6bSOEExWWcrlexTaG1L6CDVur3B6HhR Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 02:07:08 -0000 > Widespread deployment requires that people have the tools they want to use > for managing their local network. Continued fighting in the IETF over why > someone else's operational model is "wrong" is simply delaying deployment. In the short time that I've been working on IPv6 I don't think I have seen this as an actual blocker to deployment. I've seen it claimed to be a blocker, though, just as I've seen many other claimed blockers as well. When each of those claimed blockers were cleared it didn't actually result in deployment, just identification of the next blocker du jour. For this reason I think I completely agree with Ted's earlier comments about "just because it's in IPv4" and use cases. From Ted.Lemon@nominum.com Wed Apr 4 08:52:17 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1121F8862 for ; Wed, 4 Apr 2012 08:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.134 X-Spam-Level: X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sfUvk5PurCN for ; Wed, 4 Apr 2012 08:52:15 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id B221D21F86B2 for ; Wed, 4 Apr 2012 08:52:14 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT3xuKQ/t8oZhwoC8X/uDkM/DslkzDJLX@postini.com; Wed, 04 Apr 2012 08:52:14 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D34011B8225 for ; Wed, 4 Apr 2012 08:52:08 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9F828190064; Wed, 4 Apr 2012 08:52:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 4 Apr 2012 08:52:08 -0700 From: Ted Lemon To: Erik Kline Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gAjg1aA//+udoeAB9F/gIAA6lyA Date: Wed, 4 Apr 2012 15:52:07 +0000 Message-ID: <905A7517-B173-48FE-9E7A-DEDC709E7B83@nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D47A7@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_905A7517B17348FE9E7ADEDC709E7B83nominumcom_" MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:52:17 -0000 --_000_905A7517B17348FE9E7ADEDC709E7B83nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 3, 2012, at 9:53 PM, Erik Kline = > wrote: Is RADIUS suitable for this? At one point it was the general non-client provisioning protocol of choice, I thought. I have not been following any of the evolving diameter work, but would a RADIUS option suffice? RADIUS could potentially be used for configuring unicast RAs on routers. = But since we don't have a clear description of the use cases we're trying t= o address, it's hard to evaluate. --_000_905A7517B17348FE9E7ADEDC709E7B83nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 3, 2012, at 9:53 PM, Erik Kline <ek@google.com> wrote:
I= s RADIUS suitable for this?  At one point it was the general
non-client provisioning protocol of choice, I thought.  I have not
been following any of the evolving diameter work, but would a RADIUS
option suffice?

RADIUS could potentially be used for configuring unicast RAs on router= s.   But since we don't have a clear description of the use cases we'r= e trying to address, it's hard to evaluate.

--_000_905A7517B17348FE9E7ADEDC709E7B83nominumcom_-- From Ted.Lemon@nominum.com Wed Apr 4 09:02:11 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600F821F8491 for ; Wed, 4 Apr 2012 09:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bX7zotTHlvCC for ; Wed, 4 Apr 2012 09:02:10 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 5457321F848E for ; Wed, 4 Apr 2012 09:02:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT3xwgTDU5PzLDNwlC5GUGWea6kHyriD/@postini.com; Wed, 04 Apr 2012 09:02:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 793BF1B819B for ; Wed, 4 Apr 2012 09:02:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 71216190064; Wed, 4 Apr 2012 09:02:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 4 Apr 2012 09:02:03 -0700 From: Ted Lemon To: Tony Hain Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gB1uXCAAAojCT4ATUl3AAAWVyMTABwkMoAAMYTdAA== Date: Wed, 4 Apr 2012 16:02:03 +0000 Message-ID: <3B8389FE-8FE4-4AC8-B1F2-D2FD924EAC8A@nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> ,<075201cd0f8e$94cb81 7 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>, <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> <01a601cd11b6$34522090$9cf661b0$@tndh.net> In-Reply-To: <01a601cd11b6$34522090$9cf661b0$@tndh.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_3B8389FE8FE44AC8B1F2D2FD924EAC8Anominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:02:11 -0000 --_000_3B8389FE8FE44AC8B1F2D2FD924EAC8Anominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 3, 2012, at 12:24 PM, Tony Hain > wrote: It appears you missed my point that my personal preference is to avoid usin= g DHCPv6 for this single function, because I have no other ongoing need. At the same time, as I said my personal preference doesn't matter, and I will defend the right of others to have the tools they expect. This argument would be a good justification for perpetuating the use of Net= BIOS. What I mean is that if we are trying to replicate functionality, that doesn= 't motivate us to choose DHCP over RA, or vice versa: we can just replicate= the functionality in whatever way is most architecturally appropriate, and= be happy that we have provided people with the tools they need to do their= job. If, on the other hand, what we need to do is to produce functionality that = matches someone's mental model of how networks work, then that's a very dif= ferent problem. But we do not want to do that; if we did, we would have a= dopted NetBIOS. Nobody's saying that people can't use NetBIOS if they want, and nobody's sa= ying people can't use IPv4 behind a NAT if they want. But your argument d= oesn't really address the question, which is, is there a *need* for the DHC= Pv6 route option? Is there a use case that RA doesn't address, or address= es poorly, but that DHCPv6 route does address. Tony, when I asked you to specifically say why RA didn't address your use c= ase, you didn't answer my question. Instead you said, effectively "no, pe= ople want NetBIOS." That's orthogonal to the question. *Is* there somet= hing RA can't do well that DHCPv6+Route can? If so, can you clearly state= what that is? If not, then you haven't articulated a use case. "Somebo= dy wants to use a hammer" is not a use case. --_000_3B8389FE8FE44AC8B1F2D2FD924EAC8Anominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9EBBD6E8B6FDDA439056DFAEDA0C4E4A@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 3, 2012, at 12:24 PM, Tony Hain <alh-ietf@tndh.net> wrote:
I= t appears you missed my point that my personal preference is to avoid using<= /span>
DHCPv6 for this single function, because I have no other ongoing need. At<= br style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal= ; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h= eight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text= -transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webki= t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium= ; "> the same time, as I said my personal preference doesn't matter, and I will
defend the right of others to have the tools they expect.

This argument would be a good justification for perpetuating the use o= f NetBIOS.

What I mean is that if we are trying to replicate functionality, that = doesn't motivate us to choose DHCP over RA, or vice versa: we can just repl= icate the functionality in whatever way is most architecturally appropriate= , and be happy that we have provided people with the tools they need to do their job.

If, on the other hand, what we need to do is to produce functionality = that matches someone's mental model of how networks work, then that's a ver= y different problem.   But we do not want to do that; if we did, we wo= uld have adopted NetBIOS.

Nobody's saying that people can't use NetBIOS if they want, and nobody= 's saying people can't use IPv4 behind a NAT if they want.   But your = argument doesn't really address the question, which is, is there a *need* f= or the DHCPv6 route option?   Is there a use case that RA doesn't address, or addresses poorly, but that DHCPv6 r= oute does address.

Tony, when I asked you to specifically say why RA didn't address your = use case, you didn't answer my question.   Instead you said, effective= ly "no, people want NetBIOS."   That's orthogonal to the que= stion.   *Is* there something RA can't do well that DHCPv6+Route can?   If so, can you clearly state what that is? &n= bsp; If not, then you haven't articulated a use case.   "Somebody= wants to use a hammer" is not a use case.

--_000_3B8389FE8FE44AC8B1F2D2FD924EAC8Anominumcom_-- From alexandru.petrescu@gmail.com Wed Apr 4 09:28:51 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E2B21F8722 for ; Wed, 4 Apr 2012 09:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ddx3UVv2-+pr for ; Wed, 4 Apr 2012 09:28:50 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C221F8720 for ; Wed, 4 Apr 2012 09:28:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q34GSmRv016265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 4 Apr 2012 18:28:48 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q34GSmvF018396 for ; Wed, 4 Apr 2012 18:28:48 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q34GSjdQ023724 for ; Wed, 4 Apr 2012 18:28:48 +0200 Message-ID: <4F7C76BD.1020003@gmail.com> Date: Wed, 04 Apr 2012 18:28:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D47A7@mbx-01.win.nominum.com> <905A7517-B173-48FE-9E7A-DEDC709E7B83@nominum.com> In-Reply-To: <905A7517-B173-48FE-9E7A-DEDC709E7B83@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:28:51 -0000 Le 04/04/2012 17:52, Ted Lemon a écrit : > On Apr 3, 2012, at 9:53 PM, Erik Kline > wrote: >> Is RADIUS suitable for this? At one point it was the general >> non-client provisioning protocol of choice, I thought. I have not >> been following any of the evolving diameter work, but would a RADIUS >> option suffice? > > RADIUS could potentially be used for configuring unicast RAs on routers. > But since we don't have a clear description of the use cases we're > trying to address, it's hard to evaluate. I am not sure I understand between which entities would RADIUS be used and to configure what in particular? In the case of connecting a mobile router (a router that moves) to an LTE infrastructure, I am not sure where would RADIUS fit? Alex > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From alh-ietf@tndh.net Wed Apr 4 12:39:50 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A5111E80BE for ; Wed, 4 Apr 2012 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNRHiBZia9zh for ; Wed, 4 Apr 2012 12:39:49 -0700 (PDT) Received: from tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id 239BB11E80B7 for ; Wed, 4 Apr 2012 12:39:40 -0700 (PDT) X-AuthUser: alh-ietf@tndh.net Received: from eaglet ([172.20.144.31]:44300) by tndh.net with [XMail 1.27 ESMTP Server] id for from ; Wed, 4 Apr 2012 12:39:39 -0700 From: "Tony Hain" To: "'Ted Lemon'" References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> ,<075201cd0f8e$94cb81 7 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>, <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> <01a601cd11b6$34522090$9cf661b0$@tndh.net> <3B8389FE-8FE4-4AC8-B1F2-D2FD924EAC8A@nominum.com> In-Reply-To: <3B8389FE-8FE4-4AC8-B1F2-D2FD924EAC8A@nominum.com> Date: Wed, 4 Apr 2012 12:39:37 -0700 Message-ID: <00a501cd129a$ace0f560$06a2e020$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGYocXPKzopiDhicKFSNXe3ky5PRQFWcj/vAj3jZD8CE4SQEAM8EDN1Aal2DB8CuqDa4AGu3TE6AouFInYBmOpBUgHiAfgSAabbPDMCVhY93gK9RQNgAaU+fSYBVklIJAKKPEcuAtiEBeIBI67GfQHRMw/lAVePDlICiVre6wGxPjrQAeJ5bLEClisipgIfvbl0lVo145A= Content-Language: en-us Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 19:39:50 -0000 Ted Lemon wrote: > On Apr 3, 2012, at 12:24 PM, Tony Hain wrote: > It appears you missed my point that my personal preference is to avoid using > DHCPv6 for this single function, because I have no other ongoing need. At > the same time, as I said my personal preference doesn't matter, and I will > defend the right of others to have the tools they expect. > > This argument would be a good justification for perpetuating the use of NetBIOS. > > What I mean is that if we are trying to replicate functionality, that doesn't motivate > us to choose DHCP over RA, or vice versa: we can just replicate the functionality in > whatever way is most architecturally appropriate, and be happy that we have provided > people with the tools they need to do their job. If enough people wanted the IETF to work on standardizing issues related to NetBIOS, it would be wrong to ignore that. > If, on the other hand, what we need to do is to produce functionality that > matches someone's mental model of how networks work, then that's a very different > problem. But we do not want to do that; if we did, we would have adopted NetBIOS. It is not the IETF's place to tell people what protocols to run. The role here is to tell implementers to be consistent so the operators have a chance of doing something that works. > Nobody's saying that people can't use NetBIOS if they want, and nobody's saying > people can't use IPv4 behind a NAT if they want. But your argument doesn't really > address the question, which is, is there a *need* for the DHCPv6 route option? > Is there a use case that RA doesn't address, or addresses poorly, but that DHCPv6 route > does address. And you keep refusing to hear the use case that "an RA option does not work for people that want to manage related functionality in their existing DHCP server". Requiring some things in an RA and others in DHCP is just broken; both operationally and architecturally. > Tony, when I asked you to specifically say why RA didn't address your use case, > you didn't answer my question. Instead you said, effectively "no, people want NetBIOS." > That's orthogonal to the question. *Is* there something RA can't do well that >DHCPv6+Route can? If so, can you clearly state what that is? If not, then you haven't >articulated a use case. "Somebody wants to use a hammer" is not a use case. See above about the brokenness of requiring both RA and DHCP to make a network work ... Let's try a different analogy ... We need to deliver Champaign to clients. The RA approach is the equivalent of a custom developed stemmed and fluted crystal glass, while DHCPv6 is equivalent to a generic ceramic coffee mug. We are NOT discussing delivering different types of Champaign, it is coming from the same bottle. The only discussion point is the delivery mechanism. My point is both need to exist and be viable because they serve different operational models and efficiency needs. Your argument against allowing the DHCP option to exist amounts to an irrational fear that somehow allowing people to choose to consume from their existing generic ceramic mug will be detrimental to your ability to consume from the crystal glass. While I do understand some degree of that fear being derived from the insanity of the ongoing IESG stance that the IETF's role is to restrict everything to one-size-fits-all, then force everyone to adopt that even when it doesn't work efficiently for them; that still doesn't justify fighting against someone else's approach. If MIF is doing its job right, it will present both the RA and the DHCP drafts at the same time and tell the IESG to get over itself. What we have though is the ongoing infighting between DHCP and RA that has done nothing but hamper progress for 15 years. If we don't define both in parallel, there is a very real chance that the IESG will kill off efforts to define the second one, further bolstering the claims that the IETF ignores the operations community. That said, if we know they are going to kill one off anyway we should give them the RA one; because any vendor can define an option in DHCP then bypass the IESG stupidity by going straight to the RFC editor with an Informational draft that explains to the community how to interpret that option number. If we get 15 years down the road and one of the operational models has so significantly dominated the other that the lesser one becomes operationally irrelevant (re: your NetBIOS comments), then the right thing to do is define the lesser one as Historic and move on. Again, the IETF is not here to tell people how to run their networks, it is here to make sure the products they attempt to use will work consistently with each other. The operator gets to choose which approach is most efficient for their local needs. Tony From Ted.Lemon@nominum.com Wed Apr 4 14:38:29 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0624E11E80EC for ; Wed, 4 Apr 2012 14:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.033 X-Spam-Level: X-Spam-Status: No, score=-106.033 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYzo9-LCCcts for ; Wed, 4 Apr 2012 14:38:28 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id B0FEB11E80D9 for ; Wed, 4 Apr 2012 14:38:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT3y/U7sgVs5ouugXur11+GxkuIg8zpcv@postini.com; Wed, 04 Apr 2012 14:38:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DBF051B8294 for ; Wed, 4 Apr 2012 14:38:26 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D376B190064; Wed, 4 Apr 2012 14:38:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 4 Apr 2012 14:38:21 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gAjg1aA//+udoeAB9F/gIAA6lyAgAAKPICAAFZ9AA== Date: Wed, 4 Apr 2012 21:38:20 +0000 Message-ID: References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D47A7@mbx-01.win.nominum.com> <905A7517-B173-48FE-9E7A-DEDC709E7B83@nominum.com> <4F7C76BD.1020003@gmail.com> In-Reply-To: <4F7C76BD.1020003@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_A6487A0FE05B42AB8196A4F41A6D2CCCnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 21:38:29 -0000 --_000_A6487A0FE05B42AB8196A4F41A6D2CCCnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 4, 2012, at 12:28 PM, Alexandru Petrescu > wrote: I am not sure I understand between which entities would RADIUS be used and = to configure what in particular? In the case of connecting a mobile router (a router that moves) to an LTE i= nfrastructure, I am not sure where would RADIUS fit? Radius is good at getting per-user attributes to devices that are doing RAD= IUS anyway, typically for network access control. I don't think it addres= ses every use case, and indeed it may not address *any* use case. It prett= y clearly *doesn't* address your use case. So all I'm saying is that there may be some motivating use cases for the DH= CPv6 route option that could be addressed equally well by RADIUS+RA. Whet= her or not any such use cases exist, I do not know. This is why we need p= eople to clearly document their use cases and avoid hand-waving. I think = we're pretty clear now on your use case, so this comment is not directed at= you. --_000_A6487A0FE05B42AB8196A4F41A6D2CCCnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <99FBA44383ED9241B8AD9AEA45FC1E53@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 4, 2012, at 12:28 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
I am not sure I understand between which entities would RADIUS be used and t= o configure what in particular?

In the case of connecting a mobile router (a router that moves) to an LTE inf= rastructure, I am not sure where would RADIUS fit?

Radius is good at getting per-user attributes to devices that are doin= g RADIUS anyway, typically for network access control.   I don't think= it addresses every use case, and indeed it may not address *any* use case.=  It pretty clearly *doesn't* address your use case.

So all I'm saying is that there may be some motivating use cases for t= he DHCPv6 route option that could be addressed equally well by RADIUS+R= A.   Whether or not any such use cases exist, I do not know.   Th= is is why we need people to clearly document their use cases and avoid hand-waving.   I think we're pretty clear now on = your use case, so this comment is not directed at you.

--_000_A6487A0FE05B42AB8196A4F41A6D2CCCnominumcom_-- From Ted.Lemon@nominum.com Wed Apr 4 14:42:13 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B855D11E810E for ; Wed, 4 Apr 2012 14:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.329 X-Spam-Level: X-Spam-Status: No, score=-106.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOOc1lO+gzfn for ; Wed, 4 Apr 2012 14:42:13 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id E996D11E80D9 for ; Wed, 4 Apr 2012 14:42:08 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT3zAMHmfg3NBKGvokKHdLoOVf+tYeYlO@postini.com; Wed, 04 Apr 2012 14:42:09 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2AF161B80D2 for ; Wed, 4 Apr 2012 14:42:08 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 24B21190064; Wed, 4 Apr 2012 14:42:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 4 Apr 2012 14:42:08 -0700 From: Ted Lemon To: Tony Hain Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gB1uXCAAAojCT4ATUl3AAAWVyMTABwkMoAAMYTdAAAHmVmAAARG8IA= Date: Wed, 4 Apr 2012 21:42:07 +0000 Message-ID: References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> ,<075201cd0f8e$94cb81 7 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>, <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> <01a601cd11b6$34522090$9cf661b0$@tndh.net> <3B8389FE-8FE4-4AC8-B1F2-D2FD924EAC8A@nominum.com> <00a501cd129a$ace0f560$06a2e020$@tndh.net> In-Reply-To: <00a501cd129a$ace0f560$06a2e020$@tndh.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E249735A140084586EA00872EC074BD@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 21:42:13 -0000 Instead of using a lot of analogies and guilt trips, why don't you just tel= l us what your use case is, Tony? I'm sorry if you feel like you're not b= eing heard here, but I really do hear you. I just don't agree. Maybe ot= hers here do, but even if they do, it's not going to help us to make forwar= d progress. From brian.e.carpenter@gmail.com Thu Apr 5 00:14:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9998911E8079 for ; Thu, 5 Apr 2012 00:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.541 X-Spam-Level: X-Spam-Status: No, score=-101.541 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e4LIZ9MM7IJ for ; Thu, 5 Apr 2012 00:14:35 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2BE721F85EF for ; Thu, 5 Apr 2012 00:14:34 -0700 (PDT) Received: by werb10 with SMTP id b10so779564wer.31 for ; Thu, 05 Apr 2012 00:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5BXjkxdLKuJ08cKEEkiuVqJoudDxCfQkAIJPfYbyUoY=; b=K1vggZbKvYTZcrMqrbm9WOaXCoefc2h8iKReh6MMjDDJVliZyJPa4jBFHGHXk69ldI Wtgq73rnOlyUvdiv6G4t4+SWiFT2yAJVbUx5kZGulXI6AfNrbJVFOb2Hq0pZaWwKk80a e0nhpQqs7jTUieTrBOcuslFsl3/AgWCLEeeflb5EWtiPOj9oIYMjABsxbH2mkzyeI9pU FnFvJ4oR5pjFI2a8StfVHjGzEVP7EspdACC6+UxAx3IYwZp7OEVRmhBkuRY7ZWPJJ20C AvqnHbneEIh/6WNkcRX6TmBqeRdO16uuxg0stj+IWIaK5JUJjZS7qoHKOcGnM5JqIwAW N7ow== Received: by 10.180.107.162 with SMTP id hd2mr10199628wib.8.1333610074128; Thu, 05 Apr 2012 00:14:34 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-217-51.as13285.net. [2.102.217.51]) by mx.google.com with ESMTPS id l5sm11319276wia.11.2012.04.05.00.14.31 (version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 00:14:32 -0700 (PDT) Message-ID: <4F7D4650.7040108@gmail.com> Date: Thu, 05 Apr 2012 08:14:24 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> , <075201cd0f8e$94cb81 7 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>, <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> <01a601cd11b6$34522090$9cf661b0$@tndh.net> <3B8389FE-8FE4-4AC8-B1F2-D2FD924EAC8A@nominum.com> <00a501cd129a$ace0f560$06a2e020$@tndh.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 07:14:35 -0000 On 2012-04-04 22:42, Ted Lemon wrote: > Instead of using a lot of analogies and guilt trips, why don't you just tell us what your use case is, Tony? I'm sorry if you feel like you're not being heard here, but I really do hear you. I just don't agree. Maybe others here do, but even if they do, it's not going to help us to make forward progress. My understanding is that IT departments who currently manage layer 3 aspects of hosts via whatever database tool configures their DHCP[v6] servers wish to continue doing so, rather than having to use a different (or updated) tool to configure their RAs. The reason of course is to reduce operational complexity and expense. Access providers who already use RADIUS to configure users might prefer that approach, for exactly the same reason. This has felt for a long time like a case where we *cannot* reasonably apply the principle advocated in RFC 1958: "If there are several ways of doing the same thing, choose one." Brian (editor of RFC 1958) From denghui02@gmail.com Thu Apr 5 01:43:45 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EC521F87BF for ; Thu, 5 Apr 2012 01:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60369mYmTV8a for ; Thu, 5 Apr 2012 01:43:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 984DD21F87BE for ; Thu, 5 Apr 2012 01:43:44 -0700 (PDT) Received: by ggmi1 with SMTP id i1so657833ggm.31 for ; Thu, 05 Apr 2012 01:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=515iq6Oo2F2em40IYmp8fAgUPC1WWCUUihNeOfqpebk=; b=KQcKBqrnFi38+ycDkqv/CLU827F+J/Pt1iM3pVVrDR3X0QbIPfYtEu8L3zuYJoZ6pR v+NqMwzXRgNZHjmoe0C2tfWg9YMCa5O1QFParmJQK//iVmX7rWmZyDQBrG2aBJQoGjOt h3wteXPu/HAtIyKECTKrG5gy3sXs9Q+Ol1sONaRvN5r2L1N6dTvtpSvAbf/lK+FwBkL6 3VwW06TrmKRtfnU6w/THEsDJDq0Q5vuJKq1wv6tf4qG6tgzAmMwA6IEa7fo+/5QBCovx U9XhuiWUkBnHJ2byJ8Uczrk9iFXAH+D3BhR/dWP+P2b7H4MqwpN38+yFIaz8EYsX4231 OuKQ== MIME-Version: 1.0 Received: by 10.236.183.201 with SMTP id q49mr1251625yhm.114.1333615424154; Thu, 05 Apr 2012 01:43:44 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Thu, 5 Apr 2012 01:43:44 -0700 (PDT) Date: Thu, 5 Apr 2012 16:43:44 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=14dae9d70e889faa6504bcea890a Subject: [mif] MIF IETF 83 Notes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:43:45 -0000 --14dae9d70e889faa6504bcea890a Content-Type: text/plain; charset=ISO-8859-1 Hello all Please help to takea look at the below notes,feel free to correct http://www.ietf.org/proceedings/83/minutes/minutes-83-mif.txt thanks a lot co-chairs --14dae9d70e889faa6504bcea890a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Please help to takea look at the below notes,feel free to correct
=A0
thanks a lot
=A0
co-chairs
=A0
--14dae9d70e889faa6504bcea890a-- From denghui02@gmail.com Thu Apr 5 01:48:07 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2818B21F86CF for ; Thu, 5 Apr 2012 01:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oITlGKwzeulm for ; Thu, 5 Apr 2012 01:48:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D28021F86C7 for ; Thu, 5 Apr 2012 01:48:06 -0700 (PDT) Received: by ghbg16 with SMTP id g16so660818ghb.31 for ; Thu, 05 Apr 2012 01:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yoCixJW0I2EvuyoE3ktUmDYOtgf16JQ27tDpuBxUGcA=; b=Z1rMmpcOocyno2Lcmh4h062KqRlb42yZgi3zFA7dpUO0Ww8oXYJP67ySvQa3WAy0IU AjxO0EygrXcbqJ0RnjYTrEUsPgJLjnFsfYI8ZlOsZBuhVmK06fj51AWOW10p4hjcMNPc b/eHTw6eIvXenPEKmO2TGEWC8nAEnJ70wVPcsQXxUo0Kh3UYa3tSL8W7f91MM5amu2Pn 91f2r/s+sFuB8DDKwsxazV6tgjLZjsBEvwoaP1qxKFphv75/sFCF5FWyc5xPCsftFtXl IREpPWVKGki1CLGeSPwZcVgBZ/08B4ZJ4/rOq6sOyrvckqsdWCnZLmMCBRCrySvyTo+c JZFQ== MIME-Version: 1.0 Received: by 10.236.138.197 with SMTP id a45mr1283761yhj.97.1333615686215; Thu, 05 Apr 2012 01:48:06 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Thu, 5 Apr 2012 01:48:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 16:48:05 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=20cf303bf9ae3e66e504bcea99eb Subject: Re: [mif] MIF IETF 83 Notes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:48:07 -0000 --20cf303bf9ae3e66e504bcea99eb Content-Type: text/plain; charset=ISO-8859-1 Especially thanks Stuart Cheshire and Peter McCann for their kind help and Behcet for jabber Best, co-chairs 2012/4/5 Hui Deng > Hello all > > Please help to takea look at the below notes,feel free to correct > http://www.ietf.org/proceedings/83/minutes/minutes-83-mif.txt > > thanks a lot > > co-chairs > > --20cf303bf9ae3e66e504bcea99eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Especially thanks Stuart Cheshire=A0and Peter McCann for their kind he= lp
and Behcet for jabber
=A0
Best,
=A0
co-chairs

2012/4/5 Hui Deng <denghui02@gmail.com>
Hello all
=A0
Please help to takea look at the below notes,feel free to correct
=A0
thanks a lot
=A0
co-chairs
=A0

--20cf303bf9ae3e66e504bcea99eb-- From Ted.Lemon@nominum.com Thu Apr 5 03:42:14 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83B621F86C7 for ; Thu, 5 Apr 2012 03:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.383 X-Spam-Level: X-Spam-Status: No, score=-106.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYRdjRQhWGjS for ; Thu, 5 Apr 2012 03:42:14 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 8339721F86AF for ; Thu, 5 Apr 2012 03:42:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT313BOGgvMW464rVT5nrhA7cr0kV2Rol@postini.com; Thu, 05 Apr 2012 03:42:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DB68F1B8263 for ; Thu, 5 Apr 2012 03:42:11 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CB9A1190064; Thu, 5 Apr 2012 03:42:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 5 Apr 2012 03:42:05 -0700 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gB1uXCAAAojCT4ATUl3AAAWVyMTABwkMoAAMYTdAAAHmVmAAARG8IAAE/zpAAAHQK8A Date: Thu, 5 Apr 2012 10:42:05 +0000 Message-ID: References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> ,<075201cd0f8e$94cb81 7 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>, <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> <01a601cd11b6$34522090$9cf661b0$@tndh.net> <3B8389FE-8FE4-4AC8-B1F2-D2FD924EAC8A@nominum.com> <00a501cd129a$ace0f560$06a2e020$@tndh.net> <4F7D4650.7040108@gmail.com> In-Reply-To: <4F7D4650.7040108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <515EECDDD34F744BA7A51C5C1ED233EC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 10:42:14 -0000 On Apr 5, 2012, at 3:14 AM, Brian E Carpenter wrote: > My understanding is that IT departments who currently manage layer 3 > aspects of hosts via whatever database tool configures their DHCP[v6] > servers wish to continue doing so, rather than having to use a > different (or updated) tool to configure their RAs. The reason of > course is to reduce operational complexity and expense. But *why*? Please stop talking about feelings. Please say why.=20 For example, if using DHCPv6 instead of RA reduces operational complexity a= nd expense, you should be able to say *why* it does so. From brian.e.carpenter@gmail.com Thu Apr 5 04:18:43 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9D21F86DC for ; Thu, 5 Apr 2012 04:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.591 X-Spam-Level: X-Spam-Status: No, score=-101.591 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEzKJ0AO5vRC for ; Thu, 5 Apr 2012 04:18:43 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEF9421F8668 for ; Thu, 5 Apr 2012 04:18:36 -0700 (PDT) Received: by werb10 with SMTP id b10so940377wer.31 for ; Thu, 05 Apr 2012 04:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R8xPx0b0iwOR4O419ms/74SAz5wJUA8FYpqqzdIpJpE=; b=twORhMmQuRWCAfGWeKr75cIIkBCEmZBc/ao6SmZ9aaVrZwTgzdHHWEDnc3Jcb5UohU 7rjAaxJeA+lGLY0mdMa0EQU+gGvRFW0VvysStFblxgfkmaV5pDPzdjjDJ0ZHoXBP7KwQ aUaG0nVlrIRNTjyU4s3d2nPWDGBClgd4RnRKN5ptfzXZ8p6X9UaqXLSAvVkr03yxj2Ic ZlwwzstIKQ2cVB9/ZGklbIOokrKrbQvh0wjJ7pt7gaYA87VEctgP9mtm5yQ/4qwuZW7z SdV6t8oDlwRh19jpYHnATQ9HYIbSm//XbVi/61rEdzyKxEKZNI2MtfN1PFK2sss0kQRK xCVQ== Received: by 10.180.89.130 with SMTP id bo2mr3951395wib.17.1333624715902; Thu, 05 Apr 2012 04:18:35 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-217-51.as13285.net. [2.102.217.51]) by mx.google.com with ESMTPS id ea6sm12827780wib.5.2012.04.05.04.18.33 (version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 04:18:34 -0700 (PDT) Message-ID: <4F7D7F82.9050405@gmail.com> Date: Thu, 05 Apr 2012 12:18:26 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> , <075201cd0f8e$94cb81 7 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>, <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D608D@mbx-01.win.nominum.com> <01a601cd11b6$34522090$9cf661b0$@tndh.net> <3B8389FE-8FE4-4AC8-B1F2-D2FD924EAC8A@nominum.com> <00a501cd129a$ace0f560$06a2e020$@tndh.net> <4F7D4650.7040108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:18:43 -0000 On 2012-04-05 11:42, Ted Lemon wrote: > On Apr 5, 2012, at 3:14 AM, Brian E Carpenter > wrote: >> My understanding is that IT departments who currently manage layer 3 >> aspects of hosts via whatever database tool configures their DHCP[v6] >> servers wish to continue doing so, rather than having to use a >> different (or updated) tool to configure their RAs. The reason of >> course is to reduce operational complexity and expense. > > But *why*? Please stop talking about feelings. Please say why. > > For example, if using DHCPv6 instead of RA reduces operational complexity and expense, you should be able to say *why* it does so. Because using one method of configuring hosts is less complex and therefore cheaper than using two. It's clear that small simple networks (the dentist's office scenario in the terminology we used around 1995) can get by with RA alone, and it's clear that more complex networks need much more flexibility. MIF and homenet are both considering complex scenarios by this standard. I now think that detailing use cases is beside the point. It's simply a fact that above a certain level of complexity, operators need the flexibility of DHCPv6 or RADIUS, and in that case, it is less complex if everything configurable can be configured with the same tool. Brian From georg.hampel@alcatel-lucent.com Thu Apr 5 07:04:04 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBEF21F86D6 for ; Thu, 5 Apr 2012 07:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.548 X-Spam-Level: X-Spam-Status: No, score=-7.548 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB0Y0Ybuby33 for ; Thu, 5 Apr 2012 07:04:04 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 73EBF21F8680 for ; Thu, 5 Apr 2012 07:04:04 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q35E43r3025918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Apr 2012 09:04:03 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q35E43dV015055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 5 Apr 2012 09:04:03 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 5 Apr 2012 09:04:03 -0500 From: "Hampel, K Georg (K Georg)" To: "mif@ietf.org" Date: Thu, 5 Apr 2012 09:04:01 -0500 Thread-Topic: draft-mglt-mif-security-requirements-01 Thread-Index: Ac0TNPQZQ0CpnUoGT6K1U2zAyTFnUA== Message-ID: <154773479ED2314980CB638A48FC4434893D3BCA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC4434893D3BCAUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [mif] draft-mglt-mif-security-requirements-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:04:05 -0000 --_000_154773479ED2314980CB638A48FC4434893D3BCAUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daniel, all, I read draft-mglt-mif-security-requirements-01. Just to make sure I got the essence: The draft proposes to extend IPsec/Mob= IKE so that a multihomed host can simultaneously sustain multiple paths to = the same security gateway or app server using the *same* SA. MobIKE would h= ave to be upgraded to dynamically add/delete such paths. Purpose: Such an extension would avoid the need to establish separate SAs f= or each path. Is that correct? Regards, Georg --_000_154773479ED2314980CB638A48FC4434893D3BCAUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daniel, all,

 

I read draft-mglt-mif-security-requirements-01.

 

Just to make sure I got the essence: The draft proposes = to extend IPsec/MobIKE so that a multihomed host can simultaneously sustain mu= ltiple paths to the same security gateway or app server using the *same* SA. MobIK= E would have to be upgraded to dynamically add/delete such paths.<= /span>

 

Purpose: Such an extension would avoid the need to estab= lish separate SAs for each path.

 

Is that correct?

 

 

Regards,

Georg

 

 

--_000_154773479ED2314980CB638A48FC4434893D3BCAUSNAVSXCHMBSA2n_-- From mglt.ietf@gmail.com Thu Apr 5 07:29:12 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216FC21F8568 for ; Thu, 5 Apr 2012 07:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB395-RVpHe0 for ; Thu, 5 Apr 2012 07:29:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1CD21F8535 for ; Thu, 5 Apr 2012 07:29:11 -0700 (PDT) Received: by iazz13 with SMTP id z13so2251930iaz.31 for ; Thu, 05 Apr 2012 07:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oqlbVsw5+nrsiq83m/Q68hhQWV1kM+ehAD02Vjd+XUQ=; b=1D4jLKyI4H0Fibec9nLcvcgOtcKrTbS6jz4n/wsr9iPxLl8Of3HSTdPB0/rCUW5ew+ JDRPkWb9h1ZjnBHeu+p2JrN9/FC5kjtHU2nIRfH1a4+6G6H//dzZDhikoCFp68LDTahO h8V0s8d67OJeftABH7kHf0llLjvp0DJ3ljE13JUUI9FBdkW92putJzU3z2quT4ErV3Un f+pZuuEugdgC08ikzD6W2YoL4MuyNm7/qzEyCBABHiJCk+24XNEs5eNfkFcVNoYZdZtN y/gukFQStUBaJzYN0Qc45QUjKdu0HxVZIyfYKYm6LwBiKBR7nIHT/R8HBwbeKEdJM2Lf cezw== MIME-Version: 1.0 Received: by 10.42.157.65 with SMTP id c1mr1762330icx.6.1333636150660; Thu, 05 Apr 2012 07:29:10 -0700 (PDT) Received: by 10.231.170.138 with HTTP; Thu, 5 Apr 2012 07:29:10 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC4434893D3BCA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC4434893D3BCA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Thu, 5 Apr 2012 16:29:10 +0200 Message-ID: From: Daniel Migault To: "Hampel, K Georg (K Georg)" Content-Type: multipart/alternative; boundary=90e6ba6e8d3a050cf904bcef5daa Cc: "mif@ietf.org" Subject: Re: [mif] draft-mglt-mif-security-requirements-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:29:12 -0000 --90e6ba6e8d3a050cf904bcef5daa Content-Type: text/plain; charset=ISO-8859-1 That's correct. It provides IPsec the Multiple Interfaces features of SCTP or MPTCP. The goal is that MIF Nodes can deal with IPsec protected communications. BR Daniel On Thu, Apr 5, 2012 at 4:04 PM, Hampel, K Georg (K Georg) < georg.hampel@alcatel-lucent.com> wrote: > Daniel, all,**** > > ** ** > > I read draft-mglt-mif-security-requirements-01. **** > > ** ** > > Just to make sure I got the essence: The draft proposes to extend > IPsec/MobIKE so that a multihomed host can simultaneously sustain multiple > paths to the same security gateway or app server using the *same* SA. > MobIKE would have to be upgraded to dynamically add/delete such paths.**** > > ** ** > > Purpose: Such an extension would avoid the need to establish separate SAs > for each path.**** > > ** ** > > Is that correct?**** > > ** ** > > ** ** > > Regards,**** > > Georg**** > > ** ** > > ** ** > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --90e6ba6e8d3a050cf904bcef5daa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's correct. It provides IPsec the Multiple Interfaces features of= =20 SCTP or MPTCP.=A0 The goal is that MIF Nodes can deal with IPsec protected communications.


BR
Daniel

= On Thu, Apr 5, 2012 at 4:04 PM, Hampel, K Georg (K Georg) <georg.hampel@alcate= l-lucent.com> wrote:

Daniel, all,

=A0

I read draft-mglt-mif-security-requirements-01. =

=A0

Just to make sure I got the essence: The draft proposes= to extend IPsec/MobIKE so that a multihomed host can simultaneously sustain mu= ltiple paths to the same security gateway or app server using the *same* SA. MobIK= E would have to be upgraded to dynamically add/delete such paths.

=A0

Purpose: Such an extension would avoid the need to esta= blish separate SAs for each path.

=A0

Is that correct?

=A0

=A0

Regards,

Georg

=A0

=A0


_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif




--
Daniel Migault
O= range Labs -- Security
+33 6 70 72 69 58
--90e6ba6e8d3a050cf904bcef5daa-- From georg.hampel@alcatel-lucent.com Thu Apr 5 07:47:03 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B89621F86C2 for ; Thu, 5 Apr 2012 07:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.39 X-Spam-Level: X-Spam-Status: No, score=-7.39 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41BiBxDA60VF for ; Thu, 5 Apr 2012 07:47:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1057421F86BD for ; Thu, 5 Apr 2012 07:47:01 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q35Ekwba002538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Apr 2012 09:46:58 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q35Ekwog005480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Apr 2012 09:46:58 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 5 Apr 2012 09:46:58 -0500 From: "Hampel, K Georg (K Georg)" To: Daniel Migault Date: Thu, 5 Apr 2012 09:46:56 -0500 Thread-Topic: [mif] draft-mglt-mif-security-requirements-01 Thread-Index: Ac0TOHgI019Bwf5eQqG+XboM6bwMNgAAirGw Message-ID: <154773479ED2314980CB638A48FC4434893D3C1A@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC4434893D3BCA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC4434893D3C1AUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "mif@ietf.org" Subject: Re: [mif] draft-mglt-mif-security-requirements-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:47:03 -0000 --_000_154773479ED2314980CB638A48FC4434893D3C1AUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daniel, In principle, the same could be accomplished via separate SA on each path, = even if the paths pertain to the same SCTP or MPTCP connection. Correct? Th= is obviously adds cost to SA establishment. Georg ________________________________ From: Daniel Migault [mailto:mglt.ietf@gmail.com] Sent: Thursday, April 05, 2012 10:29 AM To: Hampel, K Georg (K Georg) Cc: mif@ietf.org Subject: Re: [mif] draft-mglt-mif-security-requirements-01 That's correct. It provides IPsec the Multiple Interfaces features of SCTP = or MPTCP. The goal is that MIF Nodes can deal with IPsec protected communi= cations. BR Daniel On Thu, Apr 5, 2012 at 4:04 PM, Hampel, K Georg (K Georg) > wrote: Daniel, all, I read draft-mglt-mif-security-requirements-01. Just to make sure I got the essence: The draft proposes to extend IPsec/Mob= IKE so that a multihomed host can simultaneously sustain multiple paths to = the same security gateway or app server using the *same* SA. MobIKE would h= ave to be upgraded to dynamically add/delete such paths. Purpose: Such an extension would avoid the need to establish separate SAs f= or each path. Is that correct? Regards, Georg _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --_000_154773479ED2314980CB638A48FC4434893D3C1AUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daniel,

 

In principle, the same could be accomp= lished via separate SA on each path, even if the paths pertain to the same SCTP or MPTCP connection. Correct? This obviously adds cost to SA establishment.

 

Georg

 

From: Daniel M= igault [mailto:mglt.ietf@gmail.com]
Sent: Thursday, April 05, 20= 12 10:29 AM
To: Hampel, K Georg (K Georg= )
Cc: mif@ietf.org
Subject: Re: [mif] draft-mglt-mif-security-requirements-01

 

That's correct. I= t provides IPsec the Multiple Interfaces features of SCTP or MPTCP.  The goal is that MIF Nodes can deal with IPsec protected communications.


BR
Daniel

On Thu, Apr 5, 2012 at 4:04 PM, Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent= .com> wrote:

Da= niel, all,

&n= bsp;

I = read draft-mglt-mif-security-requirements-01.

&n= bsp;

Ju= st to make sure I got the essence: The draft proposes to extend IPsec/MobIKE so that a multihomed host can simultaneously sustain multiple paths to the same secur= ity gateway or app server using the *same* SA. MobIKE would have to be upgraded= to dynamically add/delete such paths.

&n= bsp;

Pu= rpose: Such an extension would avoid the need to establish separate SAs for each p= ath.

&n= bsp;

Is= that correct?

&n= bsp;

&n= bsp;

Re= gards,

Ge= org

&n= bsp;

&n= bsp;


_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif




--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

--_000_154773479ED2314980CB638A48FC4434893D3C1AUSNAVSXCHMBSA2n_-- From mglt.ietf@gmail.com Thu Apr 5 11:02:17 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBDF21F85DA for ; Thu, 5 Apr 2012 11:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w14Rx3g14sjZ for ; Thu, 5 Apr 2012 11:02:17 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDF5521F85D8 for ; Thu, 5 Apr 2012 11:02:16 -0700 (PDT) Received: by iazz13 with SMTP id z13so2510916iaz.31 for ; Thu, 05 Apr 2012 11:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yn8YmjKX98yd0+PA6184bur5BVk+8MvKorRN55BNEK8=; b=WJ33AgBaQgk1/4SzUXHrVzi46Kxu7a/QHjlawbE2kA2zx9opy1x5btd+tRYUrycx9S 5DxgoYtvdC0yzvaERjovcXjGAiR68jpUVbHV5La9K2We8cKLa36hNUxjcZDfLgJ+6ONJ h+tWLDE2Ua9Yv6NPV1/uiuIPdFEDcGEOOXotBus50Yi9lxfEZEFZGDEH63FqR3DTRu6T Ajhcie434njBDcEItFGsLlJ9ifbFo0Dgoqlgi4i83+mNH+uq2GXyladeCj+efmQ9Ey6b B1f5Cm84kcNFOLo341iJx5tBV0aZoilG2tFHzWe/kawPdzUsGHlaKi2i6w2Vmn9WHCAu LJnQ== MIME-Version: 1.0 Received: by 10.50.45.228 with SMTP id q4mr3351009igm.58.1333648936257; Thu, 05 Apr 2012 11:02:16 -0700 (PDT) Received: by 10.231.170.138 with HTTP; Thu, 5 Apr 2012 11:02:16 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC4434893D3C1A@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC4434893D3BCA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC4434893D3C1A@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Thu, 5 Apr 2012 20:02:16 +0200 Message-ID: From: Daniel Migault To: "Hampel, K Georg (K Georg)" Content-Type: multipart/alternative; boundary=14dae934064519c8d204bcf25742 Cc: "mif@ietf.org" Subject: Re: [mif] draft-mglt-mif-security-requirements-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:02:18 -0000 --14dae934064519c8d204bcf25742 Content-Type: text/plain; charset=ISO-8859-1 Exactly. There are actually two possible scenarios: - Scenario 1 where the MIF-Node initiates for each Interface an IKEv2 exchange to establish an IKEv2 channel and then configure the SA. - Scenario 2 where the MIF-Node re-use the already IKEv2 channel to create the new SAs for each Interface with a CREATE_CHILD_SA exchange. The proposed solution takes advantage of previously existing SA and SP. When an update is required, we only update the required field, and when a new SA or SP needs to be created, we take advantage of the existing context. Note that when a new SP need to be created, we have to check first they match the general Security Policies of the System. I will clarify this in the next version of the draft thanks for the comment. Here are some more details about the mentioned scenarios: Note that Scenario1 MUST be considered since IKEv2 [RFC5996] mentions in section1.3 an implementation MAY refuse all CREATE_CHILD_SA request within an IKE_SA" A) Scenario 1: For each Interface the MIF-Node performs an IKEv2 exchange to negotiate the SA. This requires at least a four message exchange which includes an authentication. For example, using EAP-SIM [RFC4186] adds 7 exchanges and using EAP-AKA [RFC4187] adds 5 exchanges. This method is not convenient because it adds latencies, it results in creatings SA + IKE_SA for each interface, add computations by generating the keys and DH exchange for each Interface. B) Scenario 2: For each Interface the MIF-Node performs an CREATE_CHILD_SA This requires a two message exchange described in [RFC5996] section 1.3.1. This exchange requires multiple Notify Payloads like SA (SA Proposal), Ni (the Nonce) and Tsi Tr, (the Traffic Selectors). This is still better than scenario 1, but (1) it does not take advantage of the previously negotiated SA and its keying material, (2) Payloads are quite large which adds latencies, slows the IPsec configuration. This affects the SCTP/ MPTCP connectivity because packets are DISCARDed during this time. In additon, the IPsec Anti-replay Windows is quite small and may increase the number of rejected IP packets. On Thu, Apr 5, 2012 at 4:46 PM, Hampel, K Georg (K Georg) < georg.hampel@alcatel-lucent.com> wrote: > Daniel,**** > > ** ** > > In principle, the same could be accomplished via separate SA on each path, > even if the paths pertain to the same SCTP or MPTCP connection. Correct? > This obviously adds cost to SA establishment.**** > > ** ** > > Georg**** > > ** ** > ------------------------------ > > *From:* Daniel Migault [mailto:mglt.ietf@gmail.com] > *Sent:* Thursday, April 05, 2012 10:29 AM > *To:* Hampel, K Georg (K Georg) > *Cc:* mif@ietf.org > *Subject:* Re: [mif] draft-mglt-mif-security-requirements-01**** > > ** ** > > That's correct. It provides IPsec the Multiple Interfaces features of SCTP > or MPTCP. The goal is that MIF Nodes can deal with IPsec protected > communications. > > > BR > Daniel**** > > On Thu, Apr 5, 2012 at 4:04 PM, Hampel, K Georg (K Georg) < > georg.hampel@alcatel-lucent.com> wrote:**** > > Daniel, all,**** > > **** > > I read draft-mglt-mif-security-requirements-01. **** > > **** > > Just to make sure I got the essence: The draft proposes to extend > IPsec/MobIKE so that a multihomed host can simultaneously sustain multiple > paths to the same security gateway or app server using the *same* SA. > MobIKE would have to be upgraded to dynamically add/delete such paths.**** > > **** > > Purpose: Such an extension would avoid the need to establish separate SAs > for each path.**** > > **** > > Is that correct?**** > > **** > > **** > > Regards,**** > > Georg**** > > **** > > **** > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif**** > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58**** > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --14dae934064519c8d204bcf25742 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Exactly. There are actually two possible scenarios:
=A0=A0=A0=A0=A0=A0= =A0 - Scenario 1 where the MIF-Node initiates for each Interface an IKEv2 e= xchange to establish an IKEv2 channel and then configure the SA.
=A0=A0= =A0=A0=A0=A0=A0 - Scenario 2 where the MIF-Node re-use the already IKEv2 ch= annel to create the new SAs for each Interface with a CREATE_CHILD_SA excha= nge.

The proposed solution takes advantage of previously existing SA and SP.= When an update is required, we only update the required field, and when a=20 new SA or SP needs to be created, we take advantage of the existing=20 context. Note that when a new SP need to be created, we have to check first= they match the general Security Policies of the System.

I will clarify this in the next version of the draft thanks for the comment= .

Here are some more details about the mentioned scenarios:

N= ote that Scenario1 MUST be considered since IKEv2=20 [RFC5996] mentions in section1.3 an implementation MAY refuse all CREATE_CH= ILD_SA request within an IKE_SA"

A) Scenario 1: For each Interface the MIF-Node performs an IKEv2 exchan= ge to negotiate the SA.

This requires at least a four message exchan= ge which includes an authentication. For example, using EAP-SIM [RFC4186] a= dds 7 exchanges and using EAP-AKA [RFC4187] adds 5 exchanges. This method i= s not convenient because it adds latencies, it results in creatings SA + IK= E_SA for each interface, add computations by generating the keys and DH exc= hange for each Interface.

B) Scenario 2: For each Interface the MIF-Node performs an CREATE_CHILD= _SA

This requires a two message exchange described in [RFC5996] sect= ion 1.3.1. This exchange requires multiple Notify Payloads like SA (SA Prop= osal), Ni (the Nonce) and Tsi Tr, (the Traffic Selectors). This is still be= tter than scenario 1, but (1) it does not take advantage of the previously = negotiated SA and its keying material, (2) Payloads are quite large which a= dds latencies, slows the IPsec configuration. This affects the SCTP/ MPTCP = connectivity because packets are DISCARDed during this time. In additon, th= e IPsec Anti-replay Windows is quite small and may increase the number of r= ejected IP packets.


On Thu, Apr 5, 2012 at 4:46 PM, Hampel, = K Georg (K Georg) <georg.hampel@alcatel-lucent.com> wrote:

Daniel,<= /font>

=A0

In principle, the same could = be accomplished via separate SA on each path, even if the paths pertain to the same SCTP or MPTCP connection. Correct? This obviously adds cost to SA establishment.=

=A0

Georg

=A0

From: Daniel Mig= ault [mailto:mglt.ietf@= gmail.com]
Sent: Thursday, April 05, 20= 12 10:29 AM
To: Hampel, K Georg (K Georg= )
Cc: mif@ietf.org
Subject: Re: [mif] draft-mglt-mif-security-requirements-01

=A0

That's correct. I= t provides IPsec the Multiple Interfaces features of SCTP or MPTCP.=A0 The goal is that MIF Nodes can deal with IPsec protected communications.


BR
Daniel

On Thu, Apr 5, 2012 at 4:04 PM, Hampel, K Georg (K G= eorg) <georg.hampel@alcatel-lucent.com> wrote:

Daniel, all,

=A0

I read draft-mglt-mif-security-requirements-01.

=A0

Just to make sure I got the essence: The draft proposes to extend IPsec/MobIKE so that a multihomed host can simultaneously sustain multiple paths to the same secur= ity gateway or app server using the *same* SA. MobIKE would have to be upgraded= to dynamically add/delete such paths.

=A0

Purpose: Such an extension would avoid the need to establish separate SAs for each p= ath.

=A0

Is that correct?

=A0

=A0

Regards,

Georg

=A0

=A0


_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif




--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58




--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--14dae934064519c8d204bcf25742-- From jouni.nospam@gmail.com Thu Apr 5 13:28:03 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E50821F865D for ; Thu, 5 Apr 2012 13:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAqbtnJAN3If for ; Thu, 5 Apr 2012 13:28:02 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1D59A21F8659 for ; Thu, 5 Apr 2012 13:28:01 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so106299wgb.1 for ; Thu, 05 Apr 2012 13:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Qs3555YNSGj1cpsT8YZRsddHCV4eRsMaakIsgUhpn2M=; b=lj3YqWka/sd5YfG4aoRv1Po/t4ZKFilvVrqph7DwxK6Wz6ol/FuHWXBDA6gpCQJuMD QkHkHjr3uHv9Qpqu67jeLE5/SBYARRMskahVh7p9TI1HBxOOzuvyfuLMh9zWMRrwqej/ 6Lm8zBlLwoxL1Jw6f/5dSx/XugnC2fK/vtEHjZlLHIXn2yLtW0zxuboatS3tQcKJeySd gchlUJ9MzyElf5ZoxbWhX/C2+aap1nMHlpuHgDOCH6w7hcc5hhLXbS6/hHpBMz9G9aLb VdvbzUUmu8y6RIkmis/r5chhUUyeoKSF24QC2XBz7sHfmu5bXa/nws+F6y8J5XxZNL86 GdFw== Received: by 10.216.133.93 with SMTP id p71mr2618655wei.10.1333657681165; Thu, 05 Apr 2012 13:28:01 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id ff2sm255288wib.9.2012.04.05.13.27.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 13:27:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 5 Apr 2012 23:27:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <8D23D4052ABE 7A4490E77B1A012B6307472D47A7@mbx-01.win.nominum.com> To: Erik Kline X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 20:28:03 -0000 RADEXT is working on = http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06 which adds attributes for RFC4191 use, for example. That is then also = implicitly available for Diameter. Assuming unicast RA would be doable using just RFC6085, then there = should not be much, if anything, to do protocol wise. The router that gets = provisioned per host via AAA knows the l2-l3 mapping already.. and the AAA server also = learns it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 = addresses for a session identification when it sends a change of authorization.. The assumption here is that each host gets separately authorized when = they attach the network, which might be an issue on some links & deployments. = However, some network architectures with multiple routers/gateways (can) already use = AAA for centralized address management at per host granularity. - Jouni On Apr 4, 2012, at 4:53 AM, Erik Kline wrote: >> It's true, as Jari said, that this can be accomplished in other ways, = and maybe it would be better if it would. If there were some better = central management solution for populating unicast RA mappings on the = router, then unicast RA would indeed address the exact use case that I = think we care about. But without the mechanism for populating routers, = we still have a poorly-addressed use case. And then the question is, = do we want to develop a whole new protocol just to solve this one small = problem? >>=20 >> It might be worth developing the protocol just to put this issue to = bed. >=20 > Is RADIUS suitable for this? At one point it was the general > non-client provisioning protocol of choice, I thought. I have not > been following any of the evolving diameter work, but would a RADIUS > option suffice? > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From sarikaya2012@gmail.com Thu Apr 5 13:46:56 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E993A21F85CF for ; Thu, 5 Apr 2012 13:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHfQv3yD-uM9 for ; Thu, 5 Apr 2012 13:46:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8D521F85C3 for ; Thu, 5 Apr 2012 13:46:56 -0700 (PDT) Received: by iazz13 with SMTP id z13so2705940iaz.31 for ; Thu, 05 Apr 2012 13:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=wiv9/9MsLieAqRal53Y2S6Uzxy7pABk6hYE7STOacEg=; b=kRPHEdPfp2j0/fqDSeQNubUMZu72+gCApXEpIS2L/Ns4pp+fgxOvI1P7XJUCFzXqOC 9yc/T7ovYhbxTM/3MCdysmrsNBiS5gVo+eyFu+HXLyOSu6QXtHko9r6TyBpRA6ttT6tV Ea+r3Sg5yxsEE4MR3S7DdulIUtFm8qxGREczXGgFuDi96e248uOZpkgHT1D3QkE+FX63 q+3j3FPL5iSxStDQnEAW8UgRv9AhUJnuNdA1xvMe7ov2XdvT+meB7GvKBn3LyaUMTNYK ZuXCM+EwRlxEqyj52kYrfsPw/R+srMF9a7w9b9mWPvMzFdwLlCXPax1RMJW1MKPioNJk lI+g== MIME-Version: 1.0 Received: by 10.43.52.74 with SMTP id vl10mr2661500icb.55.1333658811371; Thu, 05 Apr 2012 13:46:51 -0700 (PDT) Received: by 10.231.141.146 with HTTP; Thu, 5 Apr 2012 13:46:50 -0700 (PDT) In-Reply-To: <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> Date: Thu, 5 Apr 2012 15:46:50 -0500 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mif@ietf.org" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 20:46:57 -0000 On Thu, Apr 5, 2012 at 3:27 PM, jouni korhonen wro= te: > > RADEXT is working on http://tools.ietf.org/html/draft-ietf-radext-ipv6-ac= cess-06 > which adds attributes for RFC4191 use, for example. That is then also imp= licitly > available for Diameter. > > Assuming unicast RA would be doable using just RFC6085, I don't understand what RFC 6085 has to do with this discussion? > then there should not > be much, if anything, to do protocol wise. The router that gets provision= ed per > host via AAA knows the l2-l3 mapping already.. and the AAA server also le= arns > it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 addre= sses > for a session identification when it sends a change of authorization.. > > The assumption here is that each host gets separately authorized when the= y attach > the network, which might be an issue on some links & deployments. However= , some > network architectures with multiple routers/gateways (can) already use AA= A for > centralized address management at per host granularity. > > - Jouni > > > On Apr 4, 2012, at 4:53 AM, Erik Kline wrote: > >>> It's true, as Jari said, that this can be accomplished in other ways, a= nd maybe it would be better if it would. =A0 If there were some better cent= ral management solution for populating unicast RA mappings on the router, t= hen unicast RA would indeed address the exact use case that I think we care= about. =A0 But without the mechanism for populating routers, we still have= a poorly-addressed use case. =A0 And then the question is, do we want to d= evelop a whole new protocol just to solve this one small problem? >>> >>> It might be worth developing the protocol just to put this issue to bed= . >> >> Is RADIUS suitable for this? =A0At one point it was the general >> non-client provisioning protocol of choice, I thought. =A0I have not >> been following any of the evolving diameter work, but would a RADIUS >> option suffice? >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From sgundave@cisco.com Mon Apr 9 16:01:06 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7B921F87F3 for ; Mon, 9 Apr 2012 16:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV2CYuQ6773w for ; Mon, 9 Apr 2012 16:01:06 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9E021F87CD for ; Mon, 9 Apr 2012 16:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1204; q=dns/txt; s=iport; t=1334012466; x=1335222066; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=M38i5aA7dHajpan0CVEdVheJUHRNWHJizD0WholMCbY=; b=Bk/JEPjPg47Ol66TP0cq+tC6mEmYQODtp4xGxTQnKGzyLR5EQafnxpjD JjftWnq8r1pYuzF5daVQeDefh924ORhxlXjQpe0naoaItW25wrOmZuFKh 13v5UqLkIdJcgDgc+MnH6UrMo8o4C/oWNRhTIYtBlHgtSxv20L122kpj1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD5pg0+rRDoI/2dsb2JhbABCuWCBB4IJAQEBAwESAScCATwSAQhnNgEBBAENBSKHXgMGBAyeWJZGDYFrii2GPgSIWo0SgRGKKIMUgWmDBw X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="36651867" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 09 Apr 2012 23:01:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q39N167S029393; Mon, 9 Apr 2012 23:01:06 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 16:01:06 -0700 Received: from 10.32.246.210 ([10.32.246.210]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 Apr 2012 23:01:05 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 09 Apr 2012 16:01:01 -0700 From: Sri Gundavelli To: jouni korhonen , Erik Kline Message-ID: Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: Ac0WpKHh8x61NiRYyEuiEWaGtqPJMA== In-Reply-To: <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Apr 2012 23:01:06.0088 (UTC) FILETIME=[A4EA5280:01CD16A4] Cc: "mif@ietf.org" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 23:01:07 -0000 Response to one specific comment; ignoring/not taking any stand on the rest of the DHCP/RA discussion... On 4/5/12 1:27 PM, "jouni korhonen" wrote: > > RADEXT is working on > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06 > which adds attributes for RFC4191 use, for example. That is then also > implicitly > available for Diameter. > > Assuming unicast RA would be doable using just RFC6085, then there should not > be much, if anything, to do protocol wise. The router that gets provisioned > per > host via AAA knows the l2-l3 mapping already.. and the AAA server also learns > it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 addresses > for a session identification when it sends a change of authorization.. > Yes. The router can learn the L2 to L3 mapping based on the Router Solicitations/Attach Triggers of the host. It can also learn this mapping by being in the Authentication path (supporting Proxy RADIUS), or by means of handling RADIUS triggers. Now, with respect to unicast RA transmission, the clarified L3 multicast/L2 unicast semantic defined in 6085 does allow unicast RA transmission. Sri From lorenzo@google.com Mon Apr 9 20:23:02 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFF621F854F for ; Mon, 9 Apr 2012 20:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d3Ghm0afwfm for ; Mon, 9 Apr 2012 20:23:01 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5858C21F854E for ; Mon, 9 Apr 2012 20:23:01 -0700 (PDT) Received: by iazz13 with SMTP id z13so8131429iaz.31 for ; Mon, 09 Apr 2012 20:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=AhRedeiXg+ShA1yBGfB3iy95jZrtltUnoKpuZpmLdso=; b=kPSBvRdlLu1o07k1SpJB4M03E787Dw9B1R8knQHWAPpgMjd2BX2IU2JdQaAs0eQdjs saZo9xZUTOBjrWQlwBxTE9llj8ZLCrF8RDKbjRlCIkOae2uYW1F6Od1wOpFNHO+uzzTI 2C8stS/khbipColg43tqZkA8z1g6MzdAsPkWr24Q41iIE6qu7HE4pmbh0gOqx5bj+9Ss KOiK3g6BCv9ZM7ZF4vNlVPSTa9Imx5wdHuIAlYXIwOg7YGDHJeEyGyCuDNtae7zfDKCJ ogVinA+R7HETnFAJrwawg5rpnRom4s+Z9kyxDN3nyExRxqL9QDsmLePtrsWSvGgfJK0b 2xpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=AhRedeiXg+ShA1yBGfB3iy95jZrtltUnoKpuZpmLdso=; b=CWVD/8+F2z2oykJ+62BPwyXkwkM1S1RpG6cxVHIs+V/n93JhJpAe0IgC0ty/dAibV6 KMP4CqkRncZBQ8yAfUCykcmm8v00/bPmU9E7i3bSKYqFs5eYFFFcA2Yk4NH+SmWJRwqT iNTdyvuJbk2eV9ZDl66om5Vdz2UMResqR4qDl8Qgen5R4A7oxS0h0fTKf5cOp/a3x8se yiALr7WBXuktA0Fu0aXTES2TOE/0agvvoymirXfyVXRwV/ESQPxQEnxTU8wrIbSLmQ5L 5UhfM14xRaH0DfaNoGgb8qH0K6PPtEF8kC7RLBbNhBSfWavcXu27Zc0RIpUfN82zLTef NF8g== Received: by 10.50.155.168 with SMTP id vx8mr924687igb.11.1334028181043; Mon, 09 Apr 2012 20:23:01 -0700 (PDT) Received: by 10.50.155.168 with SMTP id vx8mr924675igb.11.1334028180757; Mon, 09 Apr 2012 20:23:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.187.169 with HTTP; Mon, 9 Apr 2012 20:22:40 -0700 (PDT) In-Reply-To: <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> From: Lorenzo Colitti Date: Tue, 10 Apr 2012 12:22:40 +0900 Message-ID: To: jouni korhonen Content-Type: multipart/alternative; boundary=e89a8f2349c1d59e6704bd4aa3ac X-System-Of-Record: true X-Gm-Message-State: ALoCoQn5nbmHDEUfTdEodrdsSYWlnd41+1+Ga1nkSECJOZF+m0uRn+YbsFlqzapV1dEpuGxabLSXmeuvQBq3ixs79SYQh/5udM0F/OY/f1o3ak6SpAV3oi9nivxTPYVUzBiz1JEP1l8v Cc: "mif@ietf.org" Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 03:23:02 -0000 --e89a8f2349c1d59e6704bd4aa3ac Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 6, 2012 at 05:27, jouni korhonen wrote: > > RADEXT is working on > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06 which adds > attributes for RFC4191 use, for example. That is then also > implicitly available for Diameter. > That seems like it would meet the desired use case, right? > Assuming unicast RA would be doable using just RFC6085, then there should > not be much, if anything, to do protocol wise. You mean the text that allows "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"? So, in effect, the router would say that "this RA is only relevant to one host, so I'm going to unicast it to that one host"? --e89a8f2349c1d59e6704bd4aa3ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 6, 2012 at 05:27, jouni korhonen <jouni.nospam@g= mail.com> wrote:

RADEXT is working on http://tools.ietf.org/html/draft-ietf-r= adext-ipv6-access-06=A0which adds attributes for RFC4191 use, for examp= le. That is then also implicitly=A0available for Diameter.

That seems like it would meet the desired = use case, right?
=A0
Assuming= unicast RA would be doable using just RFC6085, then there should not=A0be = much, if anything, to do protocol wise.

You mean the text that allows "mapping of=A0an IPv= 6=A0packet with a multicast destination address into an Ethernet link-layer= unicast address, when it is clear that only one address is=A0relevant"= ;?

So, in effect, the router would say that "this RA = is only relevant to one host, so I'm going to unicast it to that one ho= st"?
--e89a8f2349c1d59e6704bd4aa3ac-- From wdec.ietf@gmail.com Tue Apr 10 08:09:52 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4020F11E80EF for ; Tue, 10 Apr 2012 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7KMdfdLWjwi for ; Tue, 10 Apr 2012 08:09:51 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEC321F84D6 for ; Tue, 10 Apr 2012 08:09:51 -0700 (PDT) Received: by qafi31 with SMTP id i31so2716826qaf.15 for ; Tue, 10 Apr 2012 08:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uc/jW2LJsXry78IvCHFJFnZFbpANQplGm/0JCmCy6xU=; b=M4uIbOQrG6yoJALl73iPh5DNZDBknhuCJkCMh5N+G8034QAdpxSB7Nf6gPqedSvKMV e0/8gP3sVbe8UPBCMsi7zAUAKFGWXK5MyR05w65XpfLdMpDLTeMD7fHdffRMC34atnka LkrXrRG7/veZ2NRTMdk3qlwSUXkqPKjZag0UFXRH2yStsoRkBgNWWH7TS8FEEvyK+CA1 7uBYa4HSdiLiPaJ4omJTlUwXO+O9mV7MqUnS3FJYmID7ygrMw99L8WiU1LlFRv0+3hdX D3VHNp6Wv0REEmo45jwFEKOFOgokajPQRqRodQlFsNhMoePqOqYqeCgZ8pocb49As5us ZlfA== MIME-Version: 1.0 Received: by 10.229.75.215 with SMTP id z23mr4602033qcj.111.1334070590729; Tue, 10 Apr 2012 08:09:50 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Tue, 10 Apr 2012 08:09:50 -0700 (PDT) In-Reply-To: <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> Date: Tue, 10 Apr 2012 17:09:50 +0200 Message-ID: From: Wojciech Dec To: "mif@ietf.org" Content-Type: multipart/alternative; boundary=002354470c5caa6fef04bd548325 Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:09:52 -0000 --002354470c5caa6fef04bd548325 Content-Type: text/plain; charset=ISO-8859-1 Folks, before we get carried away on the "let's use Radius to provision the edge router" solution, allow me to say that: a) this is already standardized if not actually practised today b) it does not solve the problem of the operators who do not directly control the access edge router (eg think wholesale) c) it requires not only a specific type of Radius infrastructure, that some operators choose not to have, but also a specific type of stateful NAS router (eg a BRAS) that others still also do not want to have. Beyond the above, and in much the same way as has been argued previously, a Radius client on the end device solution variant could also be used to provision the route on the client (or SNMP, or a script, etc). In theory thus, all of the Radius variants, are all perfectly good solutions, and standards based too. The practicality of them is a different matter, and this problem is all about per host configuration and operational practicality. At least personally, I humbly think that there is no one size fits all solution in this domain, and "perfectly good theoretical solutions" are not necessarily practical ones; operators would much rather have a choice of tools and an understanding of their tradeoffs, rather than an SDO diktat in terms of how to operate their networks. My 2c, -Woj. On 5 April 2012 22:27, jouni korhonen wrote: > > RADEXT is working on > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06 > which adds attributes for RFC4191 use, for example. That is then also > implicitly > available for Diameter. > > Assuming unicast RA would be doable using just RFC6085, then there should > not > be much, if anything, to do protocol wise. The router that gets > provisioned per > host via AAA knows the l2-l3 mapping already.. and the AAA server also > learns > it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 > addresses > for a session identification when it sends a change of authorization.. > > The assumption here is that each host gets separately authorized when they > attach > the network, which might be an issue on some links & deployments. However, > some > network architectures with multiple routers/gateways (can) already use AAA > for > centralized address management at per host granularity. > > - Jouni > > > On Apr 4, 2012, at 4:53 AM, Erik Kline wrote: > > >> It's true, as Jari said, that this can be accomplished in other ways, > and maybe it would be better if it would. If there were some better > central management solution for populating unicast RA mappings on the > router, then unicast RA would indeed address the exact use case that I > think we care about. But without the mechanism for populating routers, we > still have a poorly-addressed use case. And then the question is, do we > want to develop a whole new protocol just to solve this one small problem? > >> > >> It might be worth developing the protocol just to put this issue to bed. > > > > Is RADIUS suitable for this? At one point it was the general > > non-client provisioning protocol of choice, I thought. I have not > > been following any of the evolving diameter work, but would a RADIUS > > option suffice? > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --002354470c5caa6fef04bd548325 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,

before we get carried away on the "let's use Radius = to provision the edge router" solution, allow me to say that:
a) th= is is already standardized if not actually practised today
b) it does n= ot solve the problem of the operators who do not directly control the acces= s edge router (eg think wholesale)
c) it requires not only a specific type of Radius infrastructure, that some= operators choose not to have, but also a specific type of stateful NAS rou= ter (eg a BRAS) that others still also do not want to have.

Beyond t= he above, and in much the same way as has been argued previously, a Radius = client on the end device solution variant could also be used to provision t= he route on the client (or SNMP, or a script, etc).

In theory thus, all of the Radius variants, are all perfectly good solu= tions, and standards based too. The practicality of them is a different mat= ter, and this problem is all about per host configuration and operational p= racticality. At least personally, I humbly think that there is no one size = fits all solution in this domain, and "perfectly good theoretical solu= tions" are not necessarily practical ones; operators would much rather= have a choice of tools and an understanding of their tradeoffs, rather tha= n an SDO diktat in terms of how to operate their networks.

My 2c,
-Woj.


On 5 April 2012 2= 2:27, jouni korhonen <jouni.nospam@gmail.com> wrote:

RADEXT is working on http://tools.ietf.org/html/draft-ietf-r= adext-ipv6-access-06
which adds attributes for RFC4191 use, for example. That is then also impli= citly
available for Diameter.

Assuming unicast RA would be doable using just RFC6085, then there should n= ot
be much, if anything, to do protocol wise. The router that gets provisioned= per
host via AAA knows the l2-l3 mapping already.. and the AAA server also lear= ns
it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 address= es
for a session identification when it sends a change of authorization..

The assumption here is that each host gets separately authorized when they = attach
the network, which might be an issue on some links & deployments. Howev= er, some
network architectures with multiple routers/gateways (can) already use AAA = for
centralized address management at per host granularity.

- Jouni


On Apr 4, 2012, at 4:53 AM, Erik Kline wrote:

>> It's true, as Jari said, that this can be accomplished in othe= r ways, and maybe it would be better if it would. =A0 If there were some be= tter central management solution for populating unicast RA mappings on the = router, then unicast RA would indeed address the exact use case that I thin= k we care about. =A0 But without the mechanism for populating routers, we s= till have a poorly-addressed use case. =A0 And then the question is, do we = want to develop a whole new protocol just to solve this one small problem?<= br> >>
>> It might be worth developing the protocol just to put this issue t= o bed.
>
> Is RADIUS suitable for this? =A0At one point it was the general
> non-client provisioning protocol of choice, I thought. =A0I have not > been following any of the evolving diameter work, but would a RADIUS > option suffice?
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif

_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--002354470c5caa6fef04bd548325-- From hisuntao@gmail.com Wed Apr 11 05:10:20 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C532921F85BB for ; Wed, 11 Apr 2012 05:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sgDko-xv0UZ for ; Wed, 11 Apr 2012 05:10:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55AA721F85B7 for ; Wed, 11 Apr 2012 05:10:19 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so645748vcb.31 for ; Wed, 11 Apr 2012 05:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=X9T8jvluf6P4nDhRomlxIICmKyuNsh25BqfvGZ2AblM=; b=DiBkONYxnX+LFqR2dxb8pLsMeyYWkcMHxxe77v3lxOc7Czl7mQBd8Tfvxq7vJk0Z8I qlfsyMXyYo94sYhW70iFmQ2lq662R6HbIIcQP+r/2xqa9rEVSJAwqeoxczh62xCWHh+M ZrfoDfonW73pb862fMcd4CY70S+O1grT0Qm0CuA4fLSlYVmWkxpwfyaVfOYcJ+Y897QN SvCJCQvzjsD9J5dEBgtsrNHVK5hKzDpQHDoEL1oc/1aWX8DVGm5TIMVpBibHmy7uY4g/ GsaZNTLYt/eCk1nPeI1IYLQ6p9D2qK9FY6wmQMwKGytGW5fNwCzshl9n89ZgDtsHBDnW nXaw== MIME-Version: 1.0 Received: by 10.52.179.168 with SMTP id dh8mr6088815vdc.120.1334146218810; Wed, 11 Apr 2012 05:10:18 -0700 (PDT) Received: by 10.220.198.133 with HTTP; Wed, 11 Apr 2012 05:10:18 -0700 (PDT) In-Reply-To: References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> Date: Wed, 11 Apr 2012 20:10:18 +0800 Message-ID: From: Tao Sun To: Wojciech Dec , "mif@ietf.org" Content-Type: multipart/alternative; boundary=bcaec51a7c08735e9604bd661f8a Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:10:20 -0000 --bcaec51a7c08735e9604bd661f8a Content-Type: text/plain; charset=ISO-8859-1 People argued quite a lot that RS/RA can be used for the problem. It can be seen that only rely on the RA based solution, the RA, Radius or even protocols such as PMIP need to do enhancement or extension. DHCPv6 option provides more easy way to implement in practice. This makes the route configuration for multiple interface more easily adopted. Only put all the hope to the RA related enhancement may prevent operators adopt this functionality. In the end, neither RA nor DHCPv6 option may be used, which may delay or even prevent the feature that a host can simultaneous access through multiple interfaces. Tao Sun On Tue, Apr 10, 2012 at 11:09 PM, Wojciech Dec wrote: > Folks, > > before we get carried away on the "let's use Radius to provision the edge > router" solution, allow me to say that: > a) this is already standardized if not actually practised today > b) it does not solve the problem of the operators who do not directly > control the access edge router (eg think wholesale) > c) it requires not only a specific type of Radius infrastructure, that > some operators choose not to have, but also a specific type of stateful NAS > router (eg a BRAS) that others still also do not want to have. > > Beyond the above, and in much the same way as has been argued previously, > a Radius client on the end device solution variant could also be used to > provision the route on the client (or SNMP, or a script, etc). > > In theory thus, all of the Radius variants, are all perfectly good > solutions, and standards based too. The practicality of them is a different > matter, and this problem is all about per host configuration and > operational practicality. At least personally, I humbly think that there is > no one size fits all solution in this domain, and "perfectly good > theoretical solutions" are not necessarily practical ones; operators would > much rather have a choice of tools and an understanding of their tradeoffs, > rather than an SDO diktat in terms of how to operate their networks. > > My 2c, > -Woj. > > > > On 5 April 2012 22:27, jouni korhonen wrote: > >> >> RADEXT is working on >> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06 >> which adds attributes for RFC4191 use, for example. That is then also >> implicitly >> available for Diameter. >> >> Assuming unicast RA would be doable using just RFC6085, then there should >> not >> be much, if anything, to do protocol wise. The router that gets >> provisioned per >> host via AAA knows the l2-l3 mapping already.. and the AAA server also >> learns >> it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 >> addresses >> for a session identification when it sends a change of authorization.. >> >> The assumption here is that each host gets separately authorized when >> they attach >> the network, which might be an issue on some links & deployments. >> However, some >> network architectures with multiple routers/gateways (can) already use >> AAA for >> centralized address management at per host granularity. >> >> - Jouni >> >> >> On Apr 4, 2012, at 4:53 AM, Erik Kline wrote: >> >> >> It's true, as Jari said, that this can be accomplished in other ways, >> and maybe it would be better if it would. If there were some better >> central management solution for populating unicast RA mappings on the >> router, then unicast RA would indeed address the exact use case that I >> think we care about. But without the mechanism for populating routers, we >> still have a poorly-addressed use case. And then the question is, do we >> want to develop a whole new protocol just to solve this one small problem? >> >> >> >> It might be worth developing the protocol just to put this issue to >> bed. >> > >> > Is RADIUS suitable for this? At one point it was the general >> > non-client provisioning protocol of choice, I thought. I have not >> > been following any of the evolving diameter work, but would a RADIUS >> > option suffice? >> > _______________________________________________ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --bcaec51a7c08735e9604bd661f8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

People argued quite a lot that RS/RA = can be used for the problem. It can be seen that only rely on the RA based = solution, the RA, Radius or even protocols such as PMIP need to do enhancem= ent or extension.

=A0

DHCPv6 option provides more easy way to imp= lement in practice. This makes the route configuration for multiple interfa= ce more easily adopted. Only put all the hope to the RA=A0related enhanceme= nt=A0may prevent operators adopt this functionality. In the end, neither RA= nor DHCPv6 option may be used, which may delay or even prevent the feature= that a host can simultaneous access through multiple interfaces.

=A0
Tao Sun

On Tue, Apr 10, 2012 at 11:09 PM, Wojciech Dec <= span dir=3D"ltr"><wdec.ietf@gmail= .com> wrote:
Folks,

before we get carried a= way on the "let's use Radius to provision the edge router" so= lution, allow me to say that:
a) this is already standardized if not actually practised today
b) it d= oes not solve the problem of the operators who do not directly control the = access edge router (eg think wholesale)
c) it requires not only a specif= ic type of Radius infrastructure, that some operators choose not to have, b= ut also a specific type of stateful NAS router (eg a BRAS) that others stil= l also do not want to have.

Beyond the above, and in much the same way as has been argued previousl= y, a Radius client on the end device solution variant could also be used to= provision the route on the client (or SNMP, or a script, etc).

In theory thus, all of the Radius variants, are all perfectly good solution= s, and standards based too. The practicality of them is a different matter,= and this problem is all about per host configuration and operational pract= icality. At least personally, I humbly think that there is no one size fits= all solution in this domain, and "perfectly good theoretical solution= s" are not necessarily practical ones; operators would much rather hav= e a choice of tools and an understanding of their tradeoffs, rather than an= SDO diktat in terms of how to operate their networks.

My 2c,
-Woj.=20



On 5 April 2012 22:27, jouni korhonen <jo= uni.nospam@gmail.com> wrote:

RADEXT is working on http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06
which adds attributes for RFC4191 use, for example. That is then also impli= citly
available for Diameter.

Assuming unicast RA would be doable= using just RFC6085, then there should not
be much, if anything, to do p= rotocol wise. The router that gets provisioned per
host via AAA knows the l2-l3 mapping already.. and the AAA server also lear= ns
it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 a= ddresses
for a session identification when it sends a change of authoriz= ation..

The assumption here is that each host gets separately authorized when t= hey attach
the network, which might be an issue on some links & depl= oyments. However, some
network architectures with multiple routers/gatew= ays (can) already use AAA for
centralized address management at per host granularity.

- Jouni


On Apr 4, 2012, at 4:53 AM, Erik Kline wrote:

>> = It's true, as Jari said, that this can be accomplished in other ways, a= nd maybe it would be better if it would. =A0 If there were some better cent= ral management solution for populating unicast RA mappings on the router, t= hen unicast RA would indeed address the exact use case that I think we care= about. =A0 But without the mechanism for populating routers, we still have= a poorly-addressed use case. =A0 And then the question is, do we want to d= evelop a whole new protocol just to solve this one small problem?
>>
>> It might be worth developing the protocol just to put = this issue to bed.
>
> Is RADIUS suitable for this? =A0At one p= oint it was the general
> non-client provisioning protocol of choice,= I thought. =A0I have not
> been following any of the evolving diameter work, but would a RADIUS> option suffice?
> ____________________________________________= ___
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif

____________________= ___________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif


_______________________________________________
mi= f mailing list
mif@ietf.org
https://www.ietf.org/mailm= an/listinfo/mif


--bcaec51a7c08735e9604bd661f8a-- From arifumi@nttv6.net Fri Apr 13 02:08:02 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EE521F8731 for ; Fri, 13 Apr 2012 02:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHKIuGb8jUDH for ; Fri, 13 Apr 2012 02:08:01 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5549121F847D for ; Fri, 13 Apr 2012 02:08:01 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q3D98bh5080880; Fri, 13 Apr 2012 18:08:37 +0900 (JST) (envelope-from arifumi@nttv6.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Arifumi Matsumoto In-Reply-To: Date: Fri, 13 Apr 2012 18:06:40 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> To: MIF List Mailing X-Mailer: Apple Mail (2.1257) Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 09:08:02 -0000 Hi, Besides multi-interface cases, DHCP relay functionality is widely = deployed and really helpful function to implement a new way of = information distribution. Replacing or upgrading all the provider edge routers should be real = headaches to access network providers, because the amount of edge = routers tend to be large, and they are more and more overloaded with = various features, and so not cheap. The provider edge routers are the = place where control plane and data plane reside together. And DHCP = servers and RADIUS servers are those entities separated from the data = plane, so they are relatively cheaper and easier to get upgraded. =46rom the access network provider perspective, RADIUS based approach needs standardization, implementation at the = routing equipments, and upgrade of RADIUS servers. DHCP based approach needs upgrade of just the DHCP servers. How can we say this is not the show stopper ? Best regards, On 2012/04/11, at 21:10, Tao Sun wrote: > People argued quite a lot that RS/RA can be used for the problem. It = can be seen that only rely on the RA based solution, the RA, Radius or = even protocols such as PMIP need to do enhancement or extension. > =20 > DHCPv6 option provides more easy way to implement in practice. This = makes the route configuration for multiple interface more easily = adopted. Only put all the hope to the RA related enhancement may prevent = operators adopt this functionality. In the end, neither RA nor DHCPv6 = option may be used, which may delay or even prevent the feature that a = host can simultaneous access through multiple interfaces. > =20 > Tao Sun >=20 > On Tue, Apr 10, 2012 at 11:09 PM, Wojciech Dec = wrote: > Folks, >=20 > before we get carried away on the "let's use Radius to provision the = edge router" solution, allow me to say that: > a) this is already standardized if not actually practised today=20 > b) it does not solve the problem of the operators who do not directly = control the access edge router (eg think wholesale) > c) it requires not only a specific type of Radius infrastructure, that = some operators choose not to have, but also a specific type of stateful = NAS router (eg a BRAS) that others still also do not want to have. >=20 > Beyond the above, and in much the same way as has been argued = previously, a Radius client on the end device solution variant could = also be used to provision the route on the client (or SNMP, or a script, = etc).=20 >=20 > In theory thus, all of the Radius variants, are all perfectly good = solutions, and standards based too. The practicality of them is a = different matter, and this problem is all about per host configuration = and operational practicality. At least personally, I humbly think that = there is no one size fits all solution in this domain, and "perfectly = good theoretical solutions" are not necessarily practical ones; = operators would much rather have a choice of tools and an understanding = of their tradeoffs, rather than an SDO diktat in terms of how to operate = their networks. >=20 > My 2c, > -Woj. >=20 >=20 >=20 > On 5 April 2012 22:27, jouni korhonen wrote: >=20 > RADEXT is working on = http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06 > which adds attributes for RFC4191 use, for example. That is then also = implicitly > available for Diameter. >=20 > Assuming unicast RA would be doable using just RFC6085, then there = should not > be much, if anything, to do protocol wise. The router that gets = provisioned per > host via AAA knows the l2-l3 mapping already.. and the AAA server also = learns > it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 = addresses > for a session identification when it sends a change of authorization.. >=20 > The assumption here is that each host gets separately authorized when = they attach > the network, which might be an issue on some links & deployments. = However, some > network architectures with multiple routers/gateways (can) already use = AAA for > centralized address management at per host granularity. >=20 > - Jouni >=20 >=20 > On Apr 4, 2012, at 4:53 AM, Erik Kline wrote: >=20 > >> It's true, as Jari said, that this can be accomplished in other = ways, and maybe it would be better if it would. If there were some = better central management solution for populating unicast RA mappings on = the router, then unicast RA would indeed address the exact use case that = I think we care about. But without the mechanism for populating = routers, we still have a poorly-addressed use case. And then the = question is, do we want to develop a whole new protocol just to solve = this one small problem? > >> > >> It might be worth developing the protocol just to put this issue to = bed. > > > > Is RADIUS suitable for this? At one point it was the general > > non-client provisioning protocol of choice, I thought. I have not > > been following any of the evolving diameter work, but would a RADIUS > > option suffice? > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From lorenzo@google.com Sun Apr 15 19:03:30 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB32821F8849 for ; Sun, 15 Apr 2012 19:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3jlNHAfjSHq for ; Sun, 15 Apr 2012 19:03:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16A2B21F85F6 for ; Sun, 15 Apr 2012 19:03:29 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so1814400obb.31 for ; Sun, 15 Apr 2012 19:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=sgj4wTAhapJYk9+6RJ8o6SCrM87Jdf5RS20d2+YZHVA=; b=jKf5KyRZVLt6llAfsJehMbcq3zXQtkgGXhKPp5dmzmC1VIBx4JXfFfMDLFHGqTcsXe TTk4uIXxUrvRptiaKyJcAN/LykRcsbhkWSLcAD8KyjJP0GVoVMZViI2qRgrEcRUx5EPA O+aJDTKmcg7ZAycLQZuoEMd8oMH4uVwTxexBsXJN54vP4aCXYKAxhu1QNspqlSAzOkUI /qVv3JJfM5hBgnJaDHCQ5ObqdZN6nHTKRjczgb3yNkvLBkkHcM6/V/Hyrwl7q6IwVUSp YDYRdjA88vTYtX59TcsmdUhfW/UAOEs7iVFaLX7JVF3h2tAEsXnOE9X0QTbnxkymndqY TI4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=sgj4wTAhapJYk9+6RJ8o6SCrM87Jdf5RS20d2+YZHVA=; b=Ae2g9qv/sam6uRAXSCcNUEpPoEDFiomO0wGZWeLIGK4HV0rIL66xnuriPcckmrA+Cu J6IK9bLW0QkjHjNci1gdfXPpVeWCh/S1H99udE1fWBJ4FMR2c8sFgDjuJxK7WpJulwxE QETD7Wb9XgUbCJ/VO9mLT2l/Qip2fn8e0VriaCxG5Svt/+eL+kvGRxFDyzi/6lkB5Xqx rENjCJl3uiWw8/DBISZvQkhzm1dvQ2Dw787z/pzPBep8p3t5Op3lTlVjFwH1PYKJDx2C gu5AlR93aJ2UZWcZIqP6askf8GPRYmg2KyGdP/lC+bDirT5PfjDCDQQQ687FNhuQOFq+ tcUw== Received: by 10.182.177.101 with SMTP id cp5mr13687345obc.38.1334541809219; Sun, 15 Apr 2012 19:03:29 -0700 (PDT) Received: by 10.182.177.101 with SMTP id cp5mr13687327obc.38.1334541808993; Sun, 15 Apr 2012 19:03:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Sun, 15 Apr 2012 19:03:08 -0700 (PDT) In-Reply-To: <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> From: Lorenzo Colitti Date: Mon, 16 Apr 2012 11:03:08 +0900 Message-ID: To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=e89a8f83a51376855504bdc23a81 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmmlKJ0xAoJtDkUh21HgFTfQiL5R3wHFhCEnhl2zd+yVQfUxaGjA472TfWSiBfTxPLAl8eDiCpYh3IIzAS1d+yDnrcIJWaL9q0B5Sgdu83h46k4w/NcsFD7yCwXc8fKAL/1tWH+ Cc: MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 02:03:30 -0000 --e89a8f83a51376855504bdc23a81 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 18:06, Arifumi Matsumoto wrote: > RADIUS based approach needs standardization, implementation at the routing > equipments, and upgrade of RADIUS servers. > DHCP based approach needs upgrade of just the DHCP servers. > > How can we say this is not the show stopper ? > I don't think that's a valid argument. You could say exactly the same about RAs: "DHCPv6 based approach needs standardization, implementation at the host and CPE, and upgrade of DHCPv6 servers. RA based approach needs upgrade of just the edge routers. How can we say this is not a showstopper?" (Yes - my paragraph omits the fact that the RADIUS servers need to be updated. But your paragraph omits the fact that the hosts / CPEs need to be updated, too.) Basically, using DHCPv6 is pushing the state out of the network and on to the CPE or the host. I'm sure this is desirable if you're a network operator. However, it's not so desirable if you're a host or CPE developer. In general, I think pushing complexity and state to the host is fine, because hosts are the smartest entities in the network. However, I think that DHCPv6 is the wrong tool for the job, because its semantics (essentially, static configuration information that will not change for the duration of the lease, and cannot be invalidated if the DHCPv6 server goes away) are not rich enough to communicate routing information. --e89a8f83a51376855504bdc23a81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 13, 2012 at 18:06, Arifumi Matsumoto= <arifumi@nttv6.n= et> wrote:
RADIUS based approach needs standardization, implementation at the routing = equipments, and upgrade of RADIUS servers.
DHCP based approach needs upgrade of just the DHCP servers.

How can we say this is not the show stopper ?

I don't think that's a valid argument. You could say exactly= the same about RAs:

"DHCPv6 based=A0approach= needs standardization, implementation at the host and CPE, and upgrade of = DHCPv6 servers.
RA based approach needs upgrade of just the edge routers.
How can we say this is not a showstopper?"

=
(Yes - my paragraph omits the fact that the RADIUS servers need = to be updated. But your paragraph omits the fact that the hosts / CPEs need= to be updated, too.)

Basically, using DHCPv6 is pushing the state out of the= network and on to the CPE or the host. I'm sure this is desirable if y= ou're a network operator. However, it's not so desirable if you'= ;re a host or CPE developer.

In general, I think pushing complexity and state to the= host is fine, because hosts are the smartest entities in the network. Howe= ver, I think that DHCPv6 is the wrong tool for the job, because its semanti= cs (essentially, static configuration information that will not change for = the duration of the lease, and cannot be invalidated if the DHCPv6 server g= oes away) are not rich enough to communicate routing information.
--e89a8f83a51376855504bdc23a81-- From denghui02@gmail.com Fri Apr 20 06:22:00 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719F521F84DD for ; Fri, 20 Apr 2012 06:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEYOpFkL4299 for ; Fri, 20 Apr 2012 06:21:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D18E321F86E1 for ; Fri, 20 Apr 2012 06:21:54 -0700 (PDT) Received: by yhkk25 with SMTP id k25so5858366yhk.31 for ; Fri, 20 Apr 2012 06:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BLQV3j4Gj5UiBsISKOAvwsLabgT88vlgHJkftrMatqc=; b=FD0ya9wpMdE380cN4ciQ5NiT+PnQui+c0DmoKNGtgwKcywcaR1ghKT6wfD5eDf3GS9 DkO/iI0O1sDy+fuX36ktbX3hUIKi5yOAoAaJGmAWh/trGS2jfbWMSN+NWQfie0x2L+/r qh5IPVwlt9Yh3ULGNmiRAis4NgDe8pv3y7f82XltoAe9c9eGj3sSo3LhAepX1s3js7y7 NKpc6HvjBEyByrI5UswI8WuuclV6w/p11wdMtbYQsyFOADoItcxDPAMuVYlVZcaEMVIo g93BFF9BmlxKV7NHC1wPc06vO7TsbfjIZ4jbu6dtodWDBJFijRcsNTGV/B5mTqss9d3s yJYw== MIME-Version: 1.0 Received: by 10.236.125.168 with SMTP id z28mr5899111yhh.120.1334928114467; Fri, 20 Apr 2012 06:21:54 -0700 (PDT) Received: by 10.147.115.6 with HTTP; Fri, 20 Apr 2012 06:21:54 -0700 (PDT) Date: Fri, 20 Apr 2012 21:21:54 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=20cf3036388b10445304be1c2c72 Subject: [mif] Shepherd on draft-ietf-mif-dns-server-selection-08 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 13:22:00 -0000 --20cf3036388b10445304be1c2c72 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hello all Belo are document writeup for draft-ietf-mif-dns-server-selection-08 Chair will submit if there is no any issue on this. thanks -co-chairs (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? =3D=3D> Proposed Standard, this document is a normaltive work and request I= ANA to assign two new option codes, in the title page header states "Standards Track" (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary =3D=3D>A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? =3D=3D> There is no controversy about this document, but There were fears that this document is actually =A1=B0promoting use of split-brain DNS=A1=B1. After discussions the concern was tackled in Section 7 =A1=B0Considerations for network administrators=A1=B1 with text: =A1=B1Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoiding caching related issues and destination selection problems (see Section 2.3).=A1=B1 Another major area that caused lots of discussion was security implications caused by risks related to attacker redirecting some DNS queries to bad places. This is addressed in Section 4.4. =A1=B0Limitations on use=A1=B1 and in Section 4.1, especially with help of DNSSEC. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? =3D=3D> There are two implementations of the protocol, one from Nokia, the other from NTT. Microsoft also has Name Resolution Policy Table implementation. There are thorough review, but not lead to important changes, there is no substntive issues. There are no MID and Media type definition which need expert review. Personnel Hui Deng is the Document Shepherd, Ralph Drom is the Responsible Area Director (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. =3D=3D=A1=B7 The document has been discussed in the working group which has= won the concenuss to move forward this document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? =3D=3D> The document has had extensive reviews within the IETF, not just MIF working group, but also DNSOP, DNSEXT and DHCWG. I do not have any concerns about the depth or breadth of reviews received. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. =3D=3D> The document has already got review from DNSEXT,DNSOP and DHCWG, others are not needed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. =3D=3D> There is no concern or issue on this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. =3D=3D> There are 3 authors in this document, Teemu has conformed Nokia's IPR claimed. Ted has conformed he is not aware of any IPR. J. Kato from NTT didn't reply anything on this. Need IESG's advice on how to handle this. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. =3D=3D> Yes, it has an IPR disclosure before it has been adopted as the working group document, but there isn't one filed in the datatracker. working group feel that the terms in that IPR filing is acceptable. https://datatracker.ietf.org/ipr/1103/ (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =3D=3D> WG as a whole understand and agree with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) =3D=3D> No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. =3D=3D> the document has passed the ID nits check, no error and warning. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. =3D=3D> This document meets the required criteria, and it doesn't define a new MIF, media type, and URL type. (13) Have all references within this document been identified as either normative or informative? =3D=3D> Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? =3D=3D> No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. =3D=3D> No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. =3D=3D> No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). =3D=3D> Shepherd confirms that the document does request no new registries and pointers to existing registries (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. =3D=3D> the document doesn't request new registeries to existing registrie= s (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. =3D=3D> Shepherd think the document is well written in the formal language --20cf3036388b10445304be1c2c72 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hello all

Belo are document writeup for draft-ietf-mif-dns-server-selection-08
Chair will submit if there is no any issue on this.
 
thanks
 
-co-chairs

(1) What type of RFC is being requested (BCP, Proposed Standard,
Inte= rnet Standard, Informational, Experimental, or Historic)?  Why
is t= his the proper type of RFC?  Is this type of RFC indicated in the
t= itle page header?

=3D=3D> Proposed Standard, this document is a normaltive work and req= uest IANA
to assign two new option codes, in the title page header stat= es "Standards Track"

(2) The IESG approval announcement includes a Document Announcement
W= rite-Up. Please provide such a Document Announcement Write-Up. Recent
ex= amples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

=3D=3D>A multi-interfaced node is connected to multiple networks, som= e of
   which may be utilizing private DNS namespaces.  A= node commonly
   receives DNS server configuration informatio= n from all connected
   networks.  Some of the DNS servers may have information a= bout
   namespaces other servers do not have.  When a mul= ti-interfaced node
   needs to utilize DNS, the node has to ch= oose which of the servers to
   contact to.  This documen= t describes DHCPv4 and DHCPv6 options that
   can be used to configure nodes with information required to pe= rform
   informed DNS server selection decisions.

Working Group Summary

  Was there anything in WG process that is worth noting? For
&n= bsp; example, was there controversy about particular points or
  w= ere there decisions where the consensus was particularly
  rough?<= /p>

=3D=3D> There is no controversy about this document, but There were f= ears
    that this document is actually “promoting = use of split-brain
    DNS”. After discussions the= concern was tackled in Section 7
    “Considerati= ons for network administrators” with text:
    ”Private namespaces MUST be globally unique in ord= er to keep DNS
    unambiguous and henceforth avoiding ca= ching related issues and
    destination selection probl= ems (see Section 2.3).”

    Another major area that caused lots of discussion was= security
    implications caused by risks related to at= tacker redirecting some
    DNS queries to bad places. Th= is is addressed in Section 4.4.
    “Limitations o= n use” and in Section 4.1, especially with help
    of DNSSEC.

Document Quality

  Are there existing implementations of the protocol? Have a
&n= bsp; significant number of vendors indicated their plan to
  imple= ment the specification? Are there any reviewers that
  merit speci= al mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclus= ion that the document had no substantive issues? If
  there was a = MIB Doctor, Media Type or other expert review,
  what was its cour= se (briefly)? In the case of a Media Type
  review, on what date was the request posted?

=3D=3D> There are two implementations of the protocol, one from
No= kia, the other from NTT. Microsoft also has Name Resolution
Policy Table= implementation. There are thorough review, but not
lead to important ch= anges, there is no substntive issues.
There are no MID and Media type definition which need expert review.

Personnel

 
  Hui Deng is the Document Shepherd, Ralph Drom is the R= esponsible Area
  Director


(3) Briefly describe the review of this document that was performed = by
the Document Shepherd.  If this version of the document is not r= eady
for publication, please explain why the document is being forwarded= to
the IESG.
=3D=3D=A1=B7 The document has been discussed in the working gr= oup which has won
the concenuss to move forward this document.


(4) Does the document Shepherd have any concerns about the depth or<= br>breadth of the reviews that have been performed? 
 =3D=3D&= gt; The document has had extensive reviews within the IETF, not just
&n= bsp;  MIF working group, but also DNSOP, DNSEXT and DHCWG. I do not ha= ve
   any concerns about the depth or breadth of reviews received.


(5) Do portions of the document need review from a particular or fro= m
broader perspective, e.g., security, operational complexity, AAA, DNS,=
DHCP, XML, or internationalization? If so, describe the review that
took place.
 =3D=3D> The document has already got review from DN= SEXT,DNSOP and DHCWG,
  others are not needed.


(6) Describe any specific concerns or issues that the Document Sheph= erd
has with this document that the Responsible Area Director and/or the=
IESG should be aware of? For example, perhaps he or she is uncomfortabl= e
with certain parts of the document, or has concerns whether there reallyis a need for it. In any event, if the WG has discussed those issues andhas indicated that it still wishes to advance the document, detail those<= br> concerns here.
 =3D=3D> There is no concern or issue on this doc= ument.


(7) Has each author confirmed that any and all appropriate IPR
di= sclosures required for full conformance with the provisions of BCP 78
an= d BCP 79 have already been filed. If not, explain why.
 =3D=3D> = There are 3 authors in this document,
 Teemu has conformed Nokia's IPR claimed.
 Ted has conform= ed he is not aware of any IPR.
 J. Kato from NTT didn't reply a= nything on this. Need IESG's advice
 on how to handle this. 

(8) Has an IPR disclosure been filed that references this document?
I= f so, summarize any WG discussion and conclusion regarding the IPR
discl= osures.
 =3D=3D> Yes, it has an IPR disclosure before it has bee= n adopted as the
 working group document, but there isn't one filed in the datatrac= ker.
 working group feel that the terms in that IPR filing is accep= table.
https://datatr= acker.ietf.org/ipr/1103/


(9) How solid is the WG consensus behind this document? Does it
= represent the strong concurrence of a few individuals, with others
being= silent, or does the WG as a whole understand and agree with it?  = ;
 =3D=3D> WG as a whole understand and agree with it.
 
(= 10) Has anyone threatened an appeal or otherwise indicated extreme
disc= ontent? If so, please summarise the areas of conflict in separate
email = messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
 = ;=3D=3D> No.
 
(11) Identify any ID nits the Document Shepher= d has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
th= orough.
 =3D=3D> the document has passed the ID nits check, no e= rror and warning.
 
(12) Describe how the document meets any req= uired formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
&nbs= p;=3D=3D> This document meets the required criteria, and it doesn't = define
 a new MIF, media type, and URL type.
 
(13) Have= all references within this document been identified as
either normative or informative?
 =3D=3D> Yes.
 
(14)= Are there normative references to documents that are not ready for
adva= ncement or are otherwise in an unclear state? If such normative
referenc= es exist, what is the plan for their completion?
 =3D=3D> No.
 
(15) Are there downward normative referen= ces references (see RFC 3967)?
If so, list these downward references to = support the Area Director in the
Last Call procedure.
 =3D=3D&g= t; No.
 
(16) Will publication of this document change the statu= s of any
existing RFCs? Are those RFCs listed on the title page header, listed
in= the abstract, and discussed in the introduction? If the RFCs are not
li= sted in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
othe= r RFCs is discussed. If this information is not in the document,
explain= why the WG considers it unnecessary.
 =3D=3D> No.
 
= (17) Describe the Document Shepherd's review of the IANA considerations=
section, especially with regard to its consistency with the body of the
= document. Confirm that all protocol extensions that the document makes
a= re associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified= . Confirm that newly created IANA registries include a
detailed specific= ation of the initial contents for the registry, that
allocations procedu= res for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
=  =3D=3D> Shepherd confirms that the document does request no new re= gistries
  and pointers to existing registries
 
(18) L= ist any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful= in selecting the IANA Experts for these new registries.
 =3D=3D>= ; the document doesn't request new registeries to existing registries 
(19) Describe reviews and automated checks performed by the Document
She= pherd to validate sections of the document written in a formal
language,= such as XML code, BNF rules, MIB definitions, etc.
 =3D=3D> She= pherd think the document is well written in the formal language

--20cf3036388b10445304be1c2c72-- From mrw@lilacglade.org Fri Apr 20 06:29:16 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF9621F86DD for ; Fri, 20 Apr 2012 06:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7hW2ZFhqcrc for ; Fri, 20 Apr 2012 06:29:15 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13021F86DB for ; Fri, 20 Apr 2012 06:29:15 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 2578A20244; Fri, 20 Apr 2012 09:24:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-114-139067973 From: Margaret Wasserman In-Reply-To: Date: Fri, 20 Apr 2012 09:29:13 -0400 Message-Id: <31B088F1-9F92-4602-B8EE-EBA91FF3F0CF@lilacglade.org> References: To: Hui Deng X-Mailer: Apple Mail (2.1084) Cc: MIF Mailing List Subject: Re: [mif] Shepherd on draft-ietf-mif-dns-server-selection-08 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 13:29:17 -0000 --Apple-Mail-114-139067973 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Your write-up looks good to me, Hui. Thank you for doing it! Margaret On Apr 20, 2012, at 9:21 AM, Hui Deng wrote: > Hello all >=20 > Belo are document writeup for draft-ietf-mif-dns-server-selection-08 > Chair will submit if there is no any issue on this. > =20 > thanks > =20 > -co-chairs > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in the > title page header? >=20 > =3D=3D> Proposed Standard, this document is a normaltive work and = request IANA=20 > to assign two new option codes, in the title page header states = "Standards Track" >=20 > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: >=20 > Technical Summary >=20 > =3D=3D>A multi-interfaced node is connected to multiple networks, some = of > which may be utilizing private DNS namespaces. A node commonly > receives DNS server configuration information from all connected > networks. Some of the DNS servers may have information about > namespaces other servers do not have. When a multi-interfaced node > needs to utilize DNS, the node has to choose which of the servers = to > contact to. This document describes DHCPv4 and DHCPv6 options that > can be used to configure nodes with information required to perform > informed DNS server selection decisions. >=20 > Working Group Summary >=20 > Was there anything in WG process that is worth noting? For=20 > example, was there controversy about particular points or=20 > were there decisions where the consensus was particularly=20 > rough? >=20 > =3D=3D> There is no controversy about this document, but There were = fears > that this document is actually =E2=80=9Cpromoting use of = split-brain=20 > DNS=E2=80=9D. After discussions the concern was tackled in Section = 7=20 > =E2=80=9CConsiderations for network administrators=E2=80=9D with = text: > =E2=80=9DPrivate namespaces MUST be globally unique in order to = keep DNS > unambiguous and henceforth avoiding caching related issues and=20 > destination selection problems (see Section 2.3).=E2=80=9D >=20 > Another major area that caused lots of discussion was security=20 > implications caused by risks related to attacker redirecting some > DNS queries to bad places. This is addressed in Section 4.4.=20 > =E2=80=9CLimitations on use=E2=80=9D and in Section 4.1, = especially with help=20 > of DNSSEC. >=20 > Document Quality >=20 > Are there existing implementations of the protocol? Have a=20 > significant number of vendors indicated their plan to=20 > implement the specification? Are there any reviewers that=20 > merit special mention as having done a thorough review,=20 > e.g., one that resulted in important changes or a=20 > conclusion that the document had no substantive issues? If=20 > there was a MIB Doctor, Media Type or other expert review,=20 > what was its course (briefly)? In the case of a Media Type=20 > review, on what date was the request posted? >=20 > =3D=3D> There are two implementations of the protocol, one from > Nokia, the other from NTT. Microsoft also has Name Resolution > Policy Table implementation. There are thorough review, but not > lead to important changes, there is no substntive issues. > There are no MID and Media type definition which need expert review. >=20 > Personnel >=20 > =20 > Hui Deng is the Document Shepherd, Ralph Drom is the Responsible = Area > Director >=20 >=20 > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. > =3D=3D=E3=80=8B The document has been discussed in the working group = which has won > the concenuss to move forward this document. >=20 >=20 > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? =20 > =3D=3D> The document has had extensive reviews within the IETF, not = just=20 > MIF working group, but also DNSOP, DNSEXT and DHCWG. I do not have > any concerns about the depth or breadth of reviews received. >=20 >=20 > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. > =3D=3D> The document has already got review from DNSEXT,DNSOP and = DHCWG,=20 > others are not needed. >=20 >=20 > (6) Describe any specific concerns or issues that the Document = Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? For example, perhaps he or she is = uncomfortable > with certain parts of the document, or has concerns whether there = really > is a need for it. In any event, if the WG has discussed those issues = and > has indicated that it still wishes to advance the document, detail = those > concerns here. > =3D=3D> There is no concern or issue on this document. >=20 >=20 > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP = 78 > and BCP 79 have already been filed. If not, explain why. > =3D=3D> There are 3 authors in this document,=20 > Teemu has conformed Nokia's IPR claimed. > Ted has conformed he is not aware of any IPR. > J. Kato from NTT didn't reply anything on this. Need IESG's advice=20 > on how to handle this. > =20 >=20 > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. > =3D=3D> Yes, it has an IPR disclosure before it has been adopted as = the=20 > working group document, but there isn't one filed in the datatracker. > working group feel that the terms in that IPR filing is acceptable. > https://datatracker.ietf.org/ipr/1103/ >=20 >=20 > (9) How solid is the WG consensus behind this document? Does it=20 > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? = =20 > =3D=3D> WG as a whole understand and agree with it. > =20 > (10) Has anyone threatened an appeal or otherwise indicated extreme=20 > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.)=20 > =3D=3D> No. > =20 > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the = Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. > =3D=3D> the document has passed the ID nits check, no error and = warning. > =20 > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. > =3D=3D> This document meets the required criteria, and it doesn't = define > a new MIF, media type, and URL type. > =20 > (13) Have all references within this document been identified as > either normative or informative? > =3D=3D> Yes. > =20 > (14) Are there normative references to documents that are not ready = for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? > =3D=3D> No. > =20 > (15) Are there downward normative references references (see RFC = 3967)? > If so, list these downward references to support the Area Director in = the > Last Call procedure.=20 > =3D=3D> No. > =20 > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are = not > listed in the Abstract and Introduction, explain why, and point to the > part of the document where the relationship of this document to the > other RFCs is discussed. If this information is not in the document, > explain why the WG considers it unnecessary. > =3D=3D> No. > =20 > (17) Describe the Document Shepherd's review of the IANA = considerations > section, especially with regard to its consistency with the body of = the > document. Confirm that all protocol extensions that the document makes > are associated with the appropriate reservations in IANA registries. > Confirm that any referenced IANA registries have been clearly > identified. Confirm that newly created IANA registries include a > detailed specification of the initial contents for the registry, that > allocations procedures for future registrations are defined, and a > reasonable name for the new registry has been suggested (see RFC = 5226). > =3D=3D> Shepherd confirms that the document does request no new = registries > and pointers to existing registries=20 > =20 > (18) List any new IANA registries that require Expert Review for = future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. > =3D=3D> the document doesn't request new registeries to existing = registries > =20 > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. > =3D=3D> Shepherd think the document is well written in the formal = language --Apple-Mail-114-139067973 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hello = all

Belo are document writeup for = draft-ietf-mif-dns-server-selection-08
Chair will submit if there is no any issue on this.
 
thanks
 
-co-chairs

(1) What type of RFC is being requested (BCP, = Proposed Standard,
Internet Standard, Informational, Experimental, or = Historic)?  Why
is this the proper type of RFC?  Is this = type of RFC indicated in the
title page header?

=3D=3D> = Proposed Standard, this document is a normaltive work and request IANA =
to assign two new option codes, in the title page header states = "Standards Track"

(2) The IESG approval announcement includes a = Document Announcement
Write-Up. Please provide such a Document = Announcement Write-Up. Recent
examples can be found in the "Action" = announcements for approved
documents. The approval announcement contains the following = sections:

Technical Summary

=3D=3D>A multi-interfaced = node is connected to multiple networks, some of
   which = may be utilizing private DNS namespaces.  A node = commonly
   receives DNS server configuration information = from all connected
   networks.  Some of the DNS servers may have = information about
   namespaces other servers do not = have.  When a multi-interfaced node
   needs to = utilize DNS, the node has to choose which of the servers = to
   contact to.  This document describes DHCPv4 and = DHCPv6 options that
   can be used to configure nodes with information required to = perform
   informed DNS server selection = decisions.

Working Group Summary

  Was there anything = in WG process that is worth noting? For
  example, was there = controversy about particular points or
  were there decisions = where the consensus was particularly
  rough?

=3D=3D> = There is no controversy about this document, but There were = fears
    that this document is actually =E2=80=9Cpromot= ing use of split-brain
    DNS=E2=80=9D. After = discussions the concern was tackled in Section 7
    = =E2=80=9CConsiderations for network administrators=E2=80=9D with = text:
    =E2=80=9DPrivate namespaces MUST be globally unique = in order to keep DNS
    unambiguous and henceforth = avoiding caching related issues and
    destination = selection problems (see Section 2.3).=E2=80=9D

    = Another major area that caused lots of discussion was security =
    implications caused by risks related to attacker = redirecting some
    DNS queries to bad places. This = is addressed in Section 4.4.
    =E2=80=9CLimitations = on use=E2=80=9D and in Section 4.1, especially with help
    of DNSSEC.

Document Quality

  Are = there existing implementations of the protocol? Have a
  = significant number of vendors indicated their plan to
  = implement the specification? Are there any reviewers that
  = merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  = conclusion that the document had no substantive issues? If
  = there was a MIB Doctor, Media Type or other expert review,
  = what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

=3D=3D> = There are two implementations of the protocol, one from
Nokia, the = other from NTT. Microsoft also has Name Resolution
Policy Table = implementation. There are thorough review, but not
lead to important = changes, there is no substntive issues.
There are no MID and Media type definition which need expert = review.

Personnel

 
  Hui Deng is the Document = Shepherd, Ralph Drom is the Responsible Area
  = Director


(3) Briefly describe the review of this document that = was performed by
the Document Shepherd.  If this version of the = document is not ready
for publication, please explain why the = document is being forwarded to
the IESG.
=3D=3D=E3=80=8B The document has been discussed in the = working group which has won
the concenuss to move forward this = document.


(4) Does the document Shepherd have any concerns = about the depth or
breadth of the reviews that have been = performed? 
 =3D=3D> The document has had extensive = reviews within the IETF, not just
   MIF working group, = but also DNSOP, DNSEXT and DHCWG. I do not have
   any concerns about the depth or breadth of reviews = received.


(5) Do portions of the document need review from a = particular or from
broader perspective, e.g., security, operational = complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, = describe the review that
took place.
 =3D=3D> The document has already got review from = DNSEXT,DNSOP and DHCWG,
  others are not needed.


(6) = Describe any specific concerns or issues that the Document = Shepherd
has with this document that the Responsible Area Director = and/or the
IESG should be aware of? For example, perhaps he or she is = uncomfortable
with certain parts of the document, or has concerns whether there = really
is a need for it. In any event, if the WG has discussed those = issues and
has indicated that it still wishes to advance the = document, detail those
concerns here.
 =3D=3D> There is no concern or issue on this = document.


(7) Has each author confirmed that any and all = appropriate IPR
disclosures required for full conformance with the = provisions of BCP 78
and BCP 79 have already been filed. If not, = explain why.
 =3D=3D> There are 3 authors in this document, =
 Teemu has conformed Nokia's IPR claimed.
 Ted has = conformed he is not aware of any IPR.
 J. Kato from NTT didn't = reply anything on this. Need IESG's advice
 on how to handle = this.
 

(8) Has an IPR disclosure been filed that = references this document?
If so, summarize any WG discussion and = conclusion regarding the IPR
disclosures.
 =3D=3D> Yes, it = has an IPR disclosure before it has been adopted as the
 working group document, but there isn't one filed in the = datatracker.
 working group feel that the terms in that IPR = filing is acceptable.
https://datatracker.ietf.o= rg/ipr/1103/


(9) How solid is the WG consensus behind = this document? Does it
represent the strong concurrence of a few = individuals, with others
being silent, or does the WG as a whole = understand and agree with it?  
 =3D=3D> WG as a whole understand and agree with = it.
 
(10) Has anyone threatened an appeal or otherwise = indicated extreme
discontent? If so, please summarise the areas of = conflict in separate
email messages to the Responsible Area Director. = (It should be in a
separate email because this questionnaire is publicly available.) =
 =3D=3D> No.
 
(11) Identify any ID nits the = Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnit= s/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to = be
thorough.
 =3D=3D> the document has passed the ID nits = check, no error and warning.
 
(12) Describe how the document = meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type = reviews.
 =3D=3D> This document meets the required criteria, = and it doesn't define
 a new MIF, media type, and URL = type.
 
(13) Have all references within this document been = identified as
either normative or informative?
 =3D=3D> = Yes.
 
(14) Are there normative references to documents that = are not ready for
advancement or are otherwise in an unclear state? = If such normative
references exist, what is the plan for their = completion?
 =3D=3D> No.
 
(15) Are there downward normative = references references (see RFC 3967)?
If so, list these downward = references to support the Area Director in the
Last Call procedure. =
 =3D=3D> No.
 
(16) Will publication of this = document change the status of any
existing RFCs? Are those RFCs listed on the title page header, = listed
in the abstract, and discussed in the introduction? If the = RFCs are not
listed in the Abstract and Introduction, explain why, = and point to the
part of the document where the relationship of this document to = the
other RFCs is discussed. If this information is not in the = document,
explain why the WG considers it = unnecessary.
 =3D=3D> No.
 
(17) Describe the = Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of = the
document. Confirm that all protocol extensions that the document = makes
are associated with the appropriate reservations in IANA = registries.
Confirm that any referenced IANA registries have been = clearly
identified. Confirm that newly created IANA registries = include a
detailed specification of the initial contents for the = registry, that
allocations procedures for future registrations are = defined, and a
reasonable name for the new registry has been suggested (see RFC = 5226).
 =3D=3D> Shepherd confirms that the document does = request no new registries
  and pointers to existing registries =
 
(18) List any new IANA registries that require Expert = Review for future
allocations. Provide any public guidance that the IESG would = find
useful in selecting the IANA Experts for these new = registries.
 =3D=3D> the document doesn't request new = registeries to existing registries
 
(19) Describe reviews and automated checks performed by the = Document
Shepherd to validate sections of the document written in a = formal
language, such as XML code, BNF rules, MIB definitions, = etc.
 =3D=3D> Shepherd think the document is well written in = the formal language


= --Apple-Mail-114-139067973-- From arifumi@nttv6.net Mon Apr 23 02:32:43 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C275621F864B for ; Mon, 23 Apr 2012 02:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzmg8JsubmtL for ; Mon, 23 Apr 2012 02:32:43 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id F1E9421F8559 for ; Mon, 23 Apr 2012 02:32:42 -0700 (PDT) Received: from [127.0.0.1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q3N9XHBJ079879; Mon, 23 Apr 2012 18:33:17 +0900 (JST) (envelope-from arifumi@nttv6.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Arifumi Matsumoto In-Reply-To: Date: Mon, 23 Apr 2012 18:31:21 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-63! 21-403F-9097-F7B48601DCD5@gmail.com> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1257) Cc: MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 09:32:43 -0000 Hi, sorry for late response. On 2012/04/16, at 11:03, Lorenzo Colitti wrote: > On Fri, Apr 13, 2012 at 18:06, Arifumi Matsumoto = wrote: > RADIUS based approach needs standardization, implementation at the = routing equipments, and upgrade of RADIUS servers. > DHCP based approach needs upgrade of just the DHCP servers. >=20 > How can we say this is not the show stopper ? >=20 > I don't think that's a valid argument. You could say exactly the same = about RAs: I said, "=46rom the access network provider perspective". It is the cost they have to pay that matters to them. >=20 > "DHCPv6 based approach needs standardization, implementation at the = host and CPE, and upgrade of DHCPv6 servers. > RA based approach needs upgrade of just the edge routers. AFAIK, only Windows Vista and above supports RFC 4191 by default, = though. Best regards, >=20 > How can we say this is not a showstopper?" >=20 > (Yes - my paragraph omits the fact that the RADIUS servers need to be = updated. But your paragraph omits the fact that the hosts / CPEs need to = be updated, too.) >=20 > Basically, using DHCPv6 is pushing the state out of the network and on = to the CPE or the host. I'm sure this is desirable if you're a network = operator. However, it's not so desirable if you're a host or CPE = developer. >=20 > In general, I think pushing complexity and state to the host is fine, = because hosts are the smartest entities in the network. However, I think = that DHCPv6 is the wrong tool for the job, because its semantics = (essentially, static configuration information that will not change for = the duration of the lease, and cannot be invalidated if the DHCPv6 = server goes away) are not rich enough to communicate routing = information. -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From Ted.Lemon@nominum.com Mon Apr 23 06:38:18 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6E21F8666 for ; Mon, 23 Apr 2012 06:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxhp6yl7Xm-b for ; Mon, 23 Apr 2012 06:38:18 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9598A21F8652 for ; Mon, 23 Apr 2012 06:38:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT5VbSGm4dbNQyz17Ax722GOKMmoSjzEQ@postini.com; Mon, 23 Apr 2012 06:38:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 795261B8204 for ; Mon, 23 Apr 2012 06:38:16 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6845319005D; Mon, 23 Apr 2012 06:38:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 06:38:16 -0700 From: Ted Lemon To: Arifumi Matsumoto Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gAjg1aA//+udoeAB9F/gIACyb4AgAeCygCAAWAsAIAC8VsAgARAqQCAC32NgIAARPoA Date: Mon, 23 Apr 2012 13:38:15 +0000 Message-ID: <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-63! 21-403F-9097-F7B48601DCD5@gmail.com> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <92EAB3D1FC80FE42A3F765284A06E724@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 13:38:18 -0000 On Apr 23, 2012, at 5:31 AM, Arifumi Matsumoto wrote: > I said, "From the access network provider perspective". > It is the cost they have to pay that matters to them. It would help to complete this argument if you unpacked the details here. = Why is RA so much more expensive than DHCP in this case? I get the sense= that this is obvious to the people who are promoting various DHCP route op= tions, but it clearly isn't obvious to people who aren't network operators,= so more detail is needed. > AFAIK, only Windows Vista and above supports RFC 4191 by default, though. This is not a good argument. Windows Vista is ancient. We can't define = IPv6 in terms of the functionality present in Windows XP. From roberta.maglione@telecomitalia.it Tue Apr 24 00:06:42 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CF211E808D for ; Tue, 24 Apr 2012 00:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY6eSs1diSqK for ; Tue, 24 Apr 2012 00:06:41 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id F0B5921F8551 for ; Tue, 24 Apr 2012 00:06:40 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 24 Apr 2012 09:06:31 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 24 Apr 2012 09:06:31 +0200 From: Maglione Roberta To: 'Ted Lemon' , Arifumi Matsumoto Date: Tue, 24 Apr 2012 09:06:31 +0200 Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gAjg1aA//+udoeAB9F/gIACyb4AgAeCygCAAWAsAIAC8VsAgARAqQCAC32NgIAARPoAgABWhvA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE51370AD04A@GRFMBX704BA020.griffon.local> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-63! 21-403F-9097-F7B48601DCD5@gmail.com> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> In-Reply-To: <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:06:42 -0000 > It would help to complete this argument if you unpacked the details here.= > Why is RA so much more expensive than DHCP in this case? I get the s= ense > that this is obvious to the people who are promoting various DHCP ro= ute > options, but it clearly isn't obvious to people who aren't network > operators, so more detail is needed. Because in order to be able to use RA's you would need to somehow provision= each single BNG (the router that is supposed to send the RA) with the rout= e information to be sent into RA's for all the subscribers and if, for any = reason, you need to move a subscriber from one BNG to another you would nee= d to re-provision the same information on the other BNG. While with DHCPv6 you can have a single centralized provision point and no = additional configuration required on the BNG. This is an operational diffe= rence for an operator. Best regards, Roberta -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Ted L= emon Sent: luned=EC 23 aprile 2012 15.38 To: Arifumi Matsumoto Cc: MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? On Apr 23, 2012, at 5:31 AM, Arifumi Matsumoto wrote: > I said, "From the access network provider perspective". > It is the cost they have to pay that matters to them. It would help to complete this argument if you unpacked the details here. = Why is RA so much more expensive than DHCP in this case? I get the sense= that this is obvious to the people who are promoting various DHCP route op= tions, but it clearly isn't obvious to people who aren't network operators,= so more detail is needed. > AFAIK, only Windows Vista and above supports RFC 4191 by default, though. This is not a good argument. Windows Vista is ancient. We can't define = IPv6 in terms of the functionality present in Windows XP. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From lorenzo@google.com Tue Apr 24 00:18:42 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969DC11E80B0 for ; Tue, 24 Apr 2012 00:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC5HmirozpBs for ; Tue, 24 Apr 2012 00:18:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2F11E80AC for ; Tue, 24 Apr 2012 00:18:41 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so666393obb.31 for ; Tue, 24 Apr 2012 00:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=5xR2lTDftROwRFXKAfJy8rMX6YHqJ9lDZp59oamMW2Y=; b=mCGzUSzWkzB+VKKpgouOQnOsHSiVYYns+Vpnk6hZmMLfUdOuCCUCWKqwyD/KB1S018 FrC1QrGD7558TM421hjTQFKuw6QRUTUbOMlv782zx/iCM+LFZ02X6W3KPzyEwnCVK6FW VmzGGAUlW1+JuDT/ofksosGCRvAIkSDHpvrhaA2ghb0Nbh6pw8COFXw1yplWepN9ETgE 4v3zukZBQgZ8m18YI9pCcNg9Py7y3y4YbDUWoN0C3JH1BcV9jGGXm0TpRnQzjOXg5pWI MZbhU2FyEDU6doXvdgE5k+GH4gezpVf5AFLrIL7cRkzswBiLU2Ao2+2LhVS7e6WpXuCq Jspg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=5xR2lTDftROwRFXKAfJy8rMX6YHqJ9lDZp59oamMW2Y=; b=es63yU0pbkiR4cmcl8cCDFOFpSW+kr+Kz1vtyB5ThnBXOcpGKJKYIfqzVKvHdrDQvh aN4dSZLH3ZmuI9L3X/qUW4D4K5fldJZiAPA1dum/PEZFm4y60uF8jc6JUOWYeMXRqUFl 7V4qt+NH3s9eU2+etcXmgcua8FxKr0F9YVWDW8VOoDnHN7gUC5pAx6Cnv6wSiCofGqc+ wZt6NeeM8IRocYSKdBqBXnHIN/5D/BAMyowmpudP042VzdvIxNoBBMk0xtwUSkxxqVLt S6QKGY9iiWxN03iMCmzaIuddniXUmcCCUaoMCVn9QbKZSIQuDxWoBwAyVDDgm2uk0OQa Tf6A== Received: by 10.60.8.129 with SMTP id r1mr21717489oea.28.1335251921109; Tue, 24 Apr 2012 00:18:41 -0700 (PDT) Received: by 10.60.8.129 with SMTP id r1mr21717469oea.28.1335251920886; Tue, 24 Apr 2012 00:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Tue, 24 Apr 2012 00:18:20 -0700 (PDT) In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE51370AD04A@GRFMBX704BA020.griffon.local> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE51370AD04A@GRFMBX704BA020.griffon.local> From: Lorenzo Colitti Date: Tue, 24 Apr 2012 16:18:20 +0900 Message-ID: To: Maglione Roberta Content-Type: multipart/alternative; boundary=e89a8f839cbd6e1a3304be679095 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkTwuZtzsMNcRHWV5vz+CXxEL4TviDek9L1XzVLum49fTnAwPtyX3DuzPOETPOS5xyozwSBBwCUt02FoNUSn/+fPl44/oXRLlTzoAXFdHBiw0JnqgOwKN8N8COpxsEt2luc+WgE Cc: MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:18:42 -0000 --e89a8f839cbd6e1a3304be679095 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 24, 2012 at 16:06, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > Because in order to be able to use RA's you would need to somehow > provision each single BNG (the router that is supposed to send the RA) with > the route information to be sent into RA's for all the subscribers and if, > for any reason, you need to move a subscriber from one BNG to another you > would need to re-provision the same information on the other BNG. > Right. That's why RADIUS was mentioned earlier in this thread. > While with DHCPv6 you can have a single centralized provision point and no > additional configuration required on the BNG. This is an operational > difference for an operator. > But you have to update all the clients. --e89a8f839cbd6e1a3304be679095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 24, 2012 = at 16:06, Maglione Roberta <roberta.maglione@telecomitalia= .it> wrote:
Because in order to be abl= e to use RA's you would need to somehow provision each single BNG (the = router that is supposed to send the RA) with the route information to be se= nt into RA's for all the subscribers and if, for any reason, you need t= o move a subscriber from one BNG to another you would need to re-provision = the same information on the other BNG.

Right. That's why RADIUS was mentioned= earlier in this thread.
=A0
= While with DHCPv6 you can have a single centralized provision point and no = additional configuration required on the BNG. =A0This is an operational dif= ference for an operator.

But you have to update all the clients.
--e89a8f839cbd6e1a3304be679095-- From brian.e.carpenter@gmail.com Tue Apr 24 00:22:53 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861B221F85A3 for ; Tue, 24 Apr 2012 00:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.57 X-Spam-Level: X-Spam-Status: No, score=-101.57 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUrtAA7RT01o for ; Tue, 24 Apr 2012 00:22:53 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6AB021F85A1 for ; Tue, 24 Apr 2012 00:22:52 -0700 (PDT) Received: by eeke51 with SMTP id e51so69583eek.31 for ; Tue, 24 Apr 2012 00:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pDm+3BQlG1OrOdwLdb7362SZ1TuZYoOZqtOQlN/LaFA=; b=yJj0YPWM7YawS4TtrvU4kxfXljRnu1iux1fhd46HUckEePXdFksDlsWwaIeZNZZ98W cTFEKkJwwCOB5R5jBtzqsmInrvtOyXhkWY0kHpDliQRQLNR/R7Sd2vp4s9/4eHiinx1I USpUCQD8g6Tl/LSO82OzUizgr1i01IFxwHvJaZJHkchQCdvK14LrU1unuh5TUvi84DBM +zbjPkHIM7+Ks4jXCrLzTXEZ0WDgD25YIuVQAykKdZDZrBV6W+c99ACkLFGhHAn0BXO3 /hXLzVfacw7kBANxrWeKQ4myo2sUDQ3xWuYC7XKrf4SUtMHH5/mSrcYl1Ip31cpYal8X GE7A== Received: by 10.14.127.5 with SMTP id c5mr3118302eei.120.1335252171977; Tue, 24 Apr 2012 00:22:51 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-216-233.as13285.net. [2.102.216.233]) by mx.google.com with ESMTPS id m55sm83266895eei.1.2012.04.24.00.22.49 (version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 00:22:51 -0700 (PDT) Message-ID: <4F9654C7.3010305@gmail.com> Date: Tue, 24 Apr 2012 08:22:47 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Maglione Roberta References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-63! 21-403F-9097-F7B48601DCD5@gmail.com> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE51370AD04A@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE51370AD04A@GRFMBX704BA020.griffon.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:22:53 -0000 On 2012-04-24 08:06, Maglione Roberta wrote: >> It would help to complete this argument if you unpacked the details here. > Why is RA so much more expensive than DHCP in this case? I get the sense > that this is obvious to the people who are promoting various DHCP route >> options, but it clearly isn't obvious to people who aren't network >> operators, so more detail is needed. > > Because in order to be able to use RA's you would need to somehow provision each single BNG (the router that is supposed to send the RA) with the route information to be sent into RA's for all the subscribers and if, for any reason, you need to move a subscriber from one BNG to another you would need to re-provision the same information on the other BNG. > > While with DHCPv6 you can have a single centralized provision point and no additional configuration required on the BNG. This is an operational difference for an operator. Unfortunately, people with zero experience of running a reasonably large network seem unable to understand this elementary point. This is much bigger than a MIF issue. Brian From alexandru.petrescu@gmail.com Tue Apr 24 00:24:03 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B91321F85A1 for ; Tue, 24 Apr 2012 00:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHqBtRe-73ZS for ; Tue, 24 Apr 2012 00:24:02 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 41B7C21F85A0 for ; Tue, 24 Apr 2012 00:24:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q3O7O0pv008478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Apr 2012 09:24:00 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q3O7O0HQ029669 for ; Tue, 24 Apr 2012 09:24:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q3O7NvpW022403 for ; Tue, 24 Apr 2012 09:24:00 +0200 Message-ID: <4F96550E.6020709@gmail.com> Date: Tue, 24 Apr 2012 09:23:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <97D4F82A-63! 21-403F-9097-F7B48601DCD5@gmail.com> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> In-Reply-To: <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:24:03 -0000 Le 23/04/2012 15:38, Ted Lemon a écrit : > On Apr 23, 2012, at 5:31 AM, Arifumi Matsumoto > wrote: >> I said, "From the access network provider perspective". It is the >> cost they have to pay that matters to them. > > It would help to complete this argument if you unpacked the details > here. Why is RA so much more expensive than DHCP in this case? I > get the sense that this is obvious to the people who are promoting > various DHCP route options, but it clearly isn't obvious to people > who aren't network operators, so more detail is needed. Let me add a comment here. One part of the higher expense of RA vs DHCP is the burden of administrative management. An operator using RA to configure RFC4191/4861 default and specific routes needs to put various configuration data (the contents of radvd.conf) in _each_ access router on which end user connect. For an ADSL-type ISP this means to remotely configure, and maintain, each first-hop router (CPE+1) with different sets of specific routes, and each such router with a different default route. It means there are risks of collision (two specific routes valid at two different points, upon wrong updates), risks of wrong default routes upon network card replacement, and so on. It would be easier to have all the default/specific routes written centralized on a single (load-balanced?) server and push this data to the first-hop routers upon request from clients - more coeherence, less collision risks, higher reusability of specific routes. It's what DHCP does: the CPE+1 router is a Relay and the config file is in a unique DHCP Server. >> AFAIK, only Windows Vista and above supports RFC 4191 by default, >> though. > > This is not a good argument. Windows Vista is ancient. We can't > define IPv6 in terms of the functionality present in Windows XP. I have a comment about this, in the ADSL-type ISP case. The CPE box wouldn't be a Windows machine. It would be unix, and it would be a router. Thus, receiving RFC4191 specific routes from an RA from CPE+1 would leave it shrugging shoulders. If one wants to deliver specific routes to a CPE box one would't use RAs, because routers ignore much of info in them. Alex > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From lorenzo@google.com Tue Apr 24 00:29:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C136321F85D3 for ; Tue, 24 Apr 2012 00:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIqPRbLccTY3 for ; Tue, 24 Apr 2012 00:29:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2E521F85D2 for ; Tue, 24 Apr 2012 00:29:34 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so681402obb.31 for ; Tue, 24 Apr 2012 00:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=TXoB8rKEfg3UmVB/3j1/9OLpZ5BhLX1tgEfwWkI+adA=; b=WToG+7K1uzFCusvio9Y93K1q0UbhpGe4vP1PR8WppWhF8liaqarDLsHczHlTYW6GtW xtGV9QAPTEyUiJW3ZcCQVZQUgS5uqJXKfTZkcBv+JZ/pNpk7XIPihv3vEvdVxkNreLRF Sg8WTXkCSgJ4AyO5cV8/e3VObUou+hpSoLZne+mXZGH+5Wo0nlTqCkU4KkIbQPLMRI3k MwpmbOzq2YKoF3SJhlNqtXtZnq82OqUNErtKzsIV9h2gUfgkXI3/a0FezH/F5KTNnmgg y8/E4RehEjA/+IUR2dfMFDtharBe8CvQcw7rNrcXsRzvFmpMTC1eKdrbQ2l9FPIyQtbp xT4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=TXoB8rKEfg3UmVB/3j1/9OLpZ5BhLX1tgEfwWkI+adA=; b=h5GUj9ZUV9QKKzZlimke91qNLg49GxNwI/b/6guzlW/yamA+9qm/0tnt6/oxAQAJr7 ULK2G2atQNJVmf17zVEJBkbQn0jQ3Vsa89KDaXbmjdB/cG/oL+9T7gJr3winZmGWMgVf L6SnJzfqgJPE0EkzDKkhQAwAodyskdm4FH/ZjHBMIf+t6nuGwVxfCQ0/rInXemwnTSuW xYff9PDSObZXJrKeYBlcLwcvef3oqRWM/XSvD4sYQMNohs3uX71KUMPArSqK/xMefJwf yczf9qfAE/YN8zHxdRfj3oIszFgJQK16YPXd7vvlNpMotNWiT6EdQRcbJDyOAW0LxgxY C3qg== Received: by 10.60.0.226 with SMTP id 2mr26218564oeh.18.1335252574649; Tue, 24 Apr 2012 00:29:34 -0700 (PDT) Received: by 10.60.0.226 with SMTP id 2mr26218545oeh.18.1335252574543; Tue, 24 Apr 2012 00:29:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Tue, 24 Apr 2012 00:29:14 -0700 (PDT) In-Reply-To: <4F96550E.6020709@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> From: Lorenzo Colitti Date: Tue, 24 Apr 2012 16:29:14 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=e89a8fb1fbc664207404be67b7be X-System-Of-Record: true X-Gm-Message-State: ALoCoQkbtrbEP3JmrEnoVbUBRQpQ/cwzzIULpvYKLA0d2FLf5RlOvFPpPuoic4OtY46EUd5p9TNDHKOzZ9uF3qQSNIKANX016UtAtoDkwOmAesOUjLKcuCM71worLAJ7V3EMK5RT+8/4 Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:29:35 -0000 --e89a8fb1fbc664207404be67b7be Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 24, 2012 at 16:23, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > I have a comment about this, in the ADSL-type ISP case. > > The CPE box wouldn't be a Windows machine. It would be unix, and it > would be a router. Thus, receiving RFC4191 specific routes from an RA > from CPE+1 would leave it shrugging shoulders. > Why? The Linux Kernel supports RFC 4191, for example. > If one wants to deliver specific routes to a CPE box one would't use > RAs, because routers ignore much of info in them. > RFC 6204 specifies how IPv6 CPEs should listen to default routes in router advertisements. The CPEs could listen to more-specific routes as well. --e89a8fb1fbc664207404be67b7be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 24, 2012 = at 16:23, Alexandru Petrescu <alexandru.petrescu@gmail.com&= gt; wrote:
I have a comment about this, in the ADSL-typ= e ISP case.

The CPE box wouldn't be a Windows machine. =A0It would be unix, and it<= br> would be a router. =A0Thus, receiving RFC4191 specific routes from an RA from CPE+1 would leave it shrugging shoulders.

Why? The Linux Kernel supports=A0RFC 4191, for example.
= =A0
If one wants to deliver specific routes to a CPE box one would't use RAs, because routers ignore much of info in them.

=
RFC 6204 specifies how IPv6 CPEs should listen to default routes= in router advertisements. The CPEs could listen to more-specific routes as= well.
--e89a8fb1fbc664207404be67b7be-- From roberta.maglione@telecomitalia.it Tue Apr 24 00:29:41 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8839521F85D4 for ; Tue, 24 Apr 2012 00:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L9755K2w-TP for ; Tue, 24 Apr 2012 00:29:41 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF7921F85D8 for ; Tue, 24 Apr 2012 00:29:40 -0700 (PDT) Content-Type: multipart/mixed; boundary="_1cc6e115-433b-48cb-bd60-d8ac57a00c91_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 24 Apr 2012 09:29:38 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 24 Apr 2012 09:29:38 +0200 From: Maglione Roberta To: 'Lorenzo Colitti' Date: Tue, 24 Apr 2012 09:29:38 +0200 Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: Ac0h6oH5P/QJOAj4TVy3443lQtw9UAAARd2w Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE51370AD04C@GRFMBX704BA020.griffon.local> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE51370AD04A@GRFMBX704BA020.griffon.local> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:29:41 -0000 --_1cc6e115-433b-48cb-bd60-d8ac57a00c91_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE51370AD04CGRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE51370AD04CGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Right. That's why RADIUS was mentioned earlier in this thread. and it was already clarified in this thread that RADIUS cannot be applicabl= e in all scenarios. http://www.ietf.org/mail-archive/web/mif/current/msg01757.html Roberta ________________________________ From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: marted=EC 24 aprile 2012 9.18 To: Maglione Roberta Cc: Ted Lemon; Arifumi Matsumoto; MIF List Mailing Subject: Re: [mif] Route option for DHCPv6 - next steps? On Tue, Apr 24, 2012 at 16:06, Maglione Roberta > wrote: Because in order to be able to use RA's you would need to somehow provision= each single BNG (the router that is supposed to send the RA) with the rout= e information to be sent into RA's for all the subscribers and if, for any = reason, you need to move a subscriber from one BNG to another you would nee= d to re-provision the same information on the other BNG. Right. That's why RADIUS was mentioned earlier in this thread. While with DHCPv6 you can have a single centralized provision point and no = additional configuration required on the BNG. This is an operational diffe= rence for an operator. But you have to update all the clients. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE51370AD04CGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> Right. That's why RADIUS was mentioned earlier in this thread.=

 

and it was already clarified in this t= hread that RADIUS cannot be applicable in all scenarios.<= /font>

http://www.ietf.org/mail-archive/web/m= if/current/msg01757.html

 

Roberta

 

From: Lore= nzo Colitti [mailto:lorenzo@google.com]
Sent: marted=EC 24 aprile 20= 12 9.18
To: Maglione Roberta
Cc: Ted Lemon; Arifumi Matsu= moto; MIF List Mailing
Subject: Re: [mif] Route opt= ion for DHCPv6 - next steps?

 

On Tue, Apr 24, 2012 at 16:06, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:

Because in order to be able to use RA's you would need to somehow p= rovision each single BNG (the router that is supposed to send the RA) with = the route information to be sent into RA's for all the subscribers and if, for any reason, you need= to move a subscriber from one BNG to another you would need to re-provisio= n the same information on the other BNG.

 

Right. That's why RADIUS was mentioned earlier in this thread.=

 

While with DHCPv6 you can have a single centralized provision point= and no additional configuration required on the BNG.  This is an oper= ational difference for an operator.

 

But you have to update all the clients.

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE51370AD04CGRFMBX704BA02_-- --_1cc6e115-433b-48cb-bd60-d8ac57a00c91_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_1cc6e115-433b-48cb-bd60-d8ac57a00c91_-- From alexandru.petrescu@gmail.com Tue Apr 24 00:52:54 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE54E21F869D for ; Tue, 24 Apr 2012 00:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.149 X-Spam-Level: X-Spam-Status: No, score=-7.149 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp5oJTBzzPSi for ; Tue, 24 Apr 2012 00:52:54 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id E6C4621F861C for ; Tue, 24 Apr 2012 00:52:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q3O7qqGR022307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Apr 2012 09:52:52 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q3O7qqRJ011889; Tue, 24 Apr 2012 09:52:52 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q3O7qmOo010636; Tue, 24 Apr 2012 09:52:52 +0200 Message-ID: <4F965BD2.1080906@gmail.com> Date: Tue, 24 Apr 2012 09:52:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:52:55 -0000 Le 24/04/2012 09:29, Lorenzo Colitti a écrit : > On Tue, Apr 24, 2012 at 16:23, Alexandru Petrescu > > wrote: >> >> I have a comment about this, in the ADSL-type ISP case. >> >> The CPE box wouldn't be a Windows machine. It would be unix, and it >> would be a router. Thus, receiving RFC4191 specific routes from an RA >> from CPE+1 would leave it shrugging shoulders. > > > Why? The Linux Kernel supports RFC 4191, for example. Yes, linux kernel would support it, as a Host. The CPE is not a Host. (yes, a flag may exist to force it be a Router _and_ listen to RA - but is that flag standard). >> If one wants to deliver specific routes to a CPE box one would't use >> RAs, because routers ignore much of info in them. >> > > RFC 6204 specifies how IPv6 CPEs should listen to default routes in > router advertisements. The CPEs could listen to more-specific routes as > well. This may mean one may need to: (1) modify RFC6204 to cover specific routes as well, (2) modify RFC4191 to cover Routers as well, (3) modify RFC6204 to do cellular base stations as well, in addition to CPE of ADSL-type. Alex From lorenzo@google.com Tue Apr 24 01:04:51 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE5D21F86B0 for ; Tue, 24 Apr 2012 01:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.913 X-Spam-Level: X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL0d7EkvnDAT for ; Tue, 24 Apr 2012 01:04:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBEBA21F869D for ; Tue, 24 Apr 2012 01:04:50 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so729041obb.31 for ; Tue, 24 Apr 2012 01:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Sa14dDtFKg6WvdMk3ffT0ePkLbIKMXCIlmIU5GtyunI=; b=KMdIJtFKHxzuuPt2nueKnK0KZoBn0h9VjHetiE6Qa7bXBtWdEiCh0ptf/vKtnIroBG nhCXDEBrtXe+Rc01TueDJgCNnm5RjZwmVKWG8Kzu/r77Bf55lwLFYUWwwEuqRwIuGhh9 BBUQMrebcYbk+bKRcIc6NNYXrPlYW8p+QQ4wgNW8zcMxF6KCBVJwGNDZu1gILwgBoil0 COrfe73/ucSva/aWQCaowm1wQk5Iwi/ElHvR1Cw/6EvsDUIMXIt4p4jybYLMmCAPcBka dOEbbXb4JkudcJJlMWvlrWRFWAvk77e44eOBlP8UKeo5vo0dxA0xLgw8yMDDnxNgCQLw GsvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Sa14dDtFKg6WvdMk3ffT0ePkLbIKMXCIlmIU5GtyunI=; b=hoZKXwJwnxe+CWukeBIW+2ykKiVp02Lfgc7AWLUBCepiYzV8hgg0lurMnsWipIClij OmBlAY7GHVSCI1Ngm5zYQVbihkd3JH6ITvSLBsGM4edKNaXPFGk2i7Jzvcs37yCkIYZZ Zl/m8oYbYq+SCCUDUn/7AMcm3ledUQyRHplD3jbWXoRAd7pG/AugqzpgagzKsnJkM+Hq Ryvih5Cboxozd+xZEMKM+d153UCYfu8sTrZOSX9DDl+nNcMlu4YQizGFocBr5zoUk6dd JVVWwjzkXJRzVeY8+SLeoD6pG+3IwbgsXQBp5HPK8rJFaXmbmhPSDXkIM9Dr1WQC1FwO TFnQ== Received: by 10.60.8.129 with SMTP id r1mr21920097oea.28.1335254690393; Tue, 24 Apr 2012 01:04:50 -0700 (PDT) Received: by 10.60.8.129 with SMTP id r1mr21920087oea.28.1335254690256; Tue, 24 Apr 2012 01:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Tue, 24 Apr 2012 01:04:29 -0700 (PDT) In-Reply-To: <4F965BD2.1080906@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F72CD22.3080604@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <4F965BD2.1080906@gmail.com> From: Lorenzo Colitti Date: Tue, 24 Apr 2012 17:04:29 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=e89a8f839cbd7f57bc04be683568 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnSkrRyU5cARadVFTqynXDG/qqKQW6MpfRjFUAqFUn7s6gKtkaM23bqloiMqz8CpritiLc6QQk1Q92psWA1xNOFGgBzUA2A/5dFdBxlxPmrgX+s+Oy31Atfh+ThuxTJb4N7G70k Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 08:04:51 -0000 --e89a8f839cbd7f57bc04be683568 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 24, 2012 at 16:52, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Why? The Linux Kernel supports RFC 4191, for example. >> > > Yes, linux kernel would support it, as a Host. The CPE is not a Host. > (yes, a flag may exist to force it be a Router _and_ listen to RA - but > is that flag standard). For the kernel, I believe all you need to do is enable forwarding separately on the upstream and downstream interfaces instead of enabling forwarding globally (but I'm not 100% sure so feel free to correct me if that's wrong). That said, regardless of how it needs to be implemented, Linux-based CPEs have to do it already if they implement RFC 6204. > If one wants to deliver specific routes to a CPE box one would't use >>> RAs, because routers ignore much of info in them. >>> >>> >> RFC 6204 specifies how IPv6 CPEs should listen to default routes in >> router advertisements. The CPEs could listen to more-specific routes as >> well. >> > > This may mean one may need to: (1) modify RFC6204 to cover specific routes > as well, (2) modify RFC4191 to cover Routers as well, (3) modify RFC6204 to > do cellular base stations as well, in addition to CPE of ADSL-type. > As for #1 and #2, RFC 6024 doesn't explicitly specify what CPEs should listen to in RAs. I mentioned the default route earlier, but it mentions lots of other things too (e.g., the prefix information option to do SLAAC on the ISP-side interface, the L bit, and so on). If the CPE doesn't already support RFC 4191 (which is possible, if it's just using the standard Linux code), then it needs a code change regardless of whether you want to use DHCPv6 or RFC 4194. As for #3: RFC 6204 doesn't specify any specific technology, and it's certainly not limited to ADSL. Much of the behaviour it specifies is equally applicable to CPEs whose uplink is a cellular link. --e89a8f839cbd7f57bc04be683568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 24, 2012 = at 16:52, Alexandru Petrescu <alexandru.petrescu@gmail.com&= gt; wrote:
Why? The Linux Kernel supports RFC 4191, for example.

Yes, linux kernel would support it, as a Host. =A0The CPE is not a Host. (yes, a flag may exist to force it be a Router _and_ listen to RA - but
=A0is that flag standard).

For the kernel, = I believe all you need to do is enable forwarding separately on the upstrea= m and downstream interfaces instead of enabling forwarding globally (but I&= #39;m not 100% sure so feel free to correct me if that's wrong). That s= aid, regardless of how it needs to be implemented, Linux-based CPEs have to= do it already if they implement RFC 6204.
=A0
=A0 =A0If one wants to deliver specific rout= es to a CPE box one would't use
=A0 =A0RAs, because routers ignore much of info in them.


RFC 6204 specifies how IPv6 CPEs should listen to default routes in
router advertisements. The CPEs could listen to more-specific routes as
well.

This may mean one may need to: (1) modify RFC6204 to cover specific routes = as well, (2) modify RFC4191 to cover Routers as well, (3) modify RFC6204 to= do cellular base stations as well, in addition to CPE of ADSL-type.

As for #1 and #2, RFC 6024 doesn't exp= licitly specify what CPEs should listen to in RAs. I mentioned the default = route earlier, but it mentions lots of other things too (e.g., the prefix i= nformation option to do SLAAC on the ISP-side interface, the L bit, and so = on). If the CPE doesn't already support RFC 4191 (which is possible, if= it's just using the standard Linux code), then it needs a code change = regardless of whether you want to use DHCPv6 or RFC 4194.

As for #3: RFC 6204 doesn't specify any specific te= chnology, and it's certainly not limited to ADSL. Much of the behaviour= it specifies is equally applicable to CPEs whose uplink is a cellular link= .
--e89a8f839cbd7f57bc04be683568-- From alexandru.petrescu@gmail.com Tue Apr 24 05:20:02 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3911121F87A3 for ; Tue, 24 Apr 2012 05:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.924 X-Spam-Level: X-Spam-Status: No, score=-6.924 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0JV6NSsuNU0 for ; Tue, 24 Apr 2012 05:20:01 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 4654221F87A2 for ; Tue, 24 Apr 2012 05:20:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q3OCJxYY032152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Apr 2012 14:19:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q3OCJx9o014052; Tue, 24 Apr 2012 14:19:59 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q3OCJw5v019478; Tue, 24 Apr 2012 14:19:58 +0200 Message-ID: <4F969A70.5090506@gmail.com> Date: Tue, 24 Apr 2012 14:20:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <4F965BD2.1080906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:20:02 -0000 Le 24/04/2012 10:04, Lorenzo Colitti a écrit : > On Tue, Apr 24, 2012 at 16:52, Alexandru Petrescu > > wrote: > > Why? The Linux Kernel supports RFC 4191, for example. > > > Yes, linux kernel would support it, as a Host. The CPE is not a Host. > (yes, a flag may exist to force it be a Router _and_ listen to RA - but > is that flag standard). > > > For the kernel, I believe all you need to do is enable forwarding > separately on the upstream and downstream interfaces instead of enabling > forwarding globally (but I'm not 100% sure so feel free to correct me if > that's wrong). That said, regardless of how it needs to be implemented, > Linux-based CPEs have to do it already if they implement RFC 6204. > > If one wants to deliver specific routes to a CPE box one > would't use > RAs, because routers ignore much of info in them. > > > RFC 6204 specifies how IPv6 CPEs should listen to default routes in > router advertisements. The CPEs could listen to more-specific > routes as > well. > > > This may mean one may need to: (1) modify RFC6204 to cover specific > routes as well, (2) modify RFC4191 to cover Routers as well, (3) > modify RFC6204 to do cellular base stations as well, in addition to > CPE of ADSL-type. > > > As for #1 and #2, RFC 6024 doesn't explicitly specify what CPEs should > listen to in RAs. I mentioned the default route earlier, but it mentions > lots of other things too (e.g., the prefix information option to do > SLAAC on the ISP-side interface, the L bit, and so on). For example, RFC6204 says: > W-1: When the router is attached to the WAN interface link, it MUST > act as an IPv6 host for the purposes of stateless [RFC4862] or > stateful [RFC3315] interface address assignment. That is not enough for specific routes. Ok it covers the default routes, but not specific routes such as rfc4191. > If the CPE > doesn't already support RFC 4191 (which is possible, if it's just using > the standard Linux code), then it needs a code change regardless of > whether you want to use DHCPv6 or RFC 4194. > > As for #3: RFC 6204 doesn't specify any specific technology, and it's > certainly not limited to ADSL. Much of the behaviour it specifies is > equally applicable to CPEs whose uplink is a cellular link. ? 'CPE' is not a term used for the cellular links, I think. RFC6204 says 'residential or small-office router'. I think it is a stretch to claim that RFC6204 applies to cellular links. E.g. few if any cellular terminals use DHCP as of today, whereas RFC6204 would require them all to. Also, RFC6204 requires all cellular terminals to use Ethernet encapsulation on their WAN interface whereas none actually does. There is another RFC - 3316 - "IPv6 for some 2G and 3G Cellular Hosts" which relates more to cellular. Alex From jouni.nospam@gmail.com Wed Apr 25 01:33:58 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B515B21F879A for ; Wed, 25 Apr 2012 01:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWZJ0kkD9qxU for ; Wed, 25 Apr 2012 01:33:57 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 085F121F8799 for ; Wed, 25 Apr 2012 01:33:56 -0700 (PDT) Received: by lbgc1 with SMTP id c1so1304158lbg.31 for ; Wed, 25 Apr 2012 01:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=b+dm0r0VuTYBHZ5LjGZTuIFO03d1RPdSuL4+Bgh9rgI=; b=rik/FUqzxnmBaN0uPF6O7t2C67stY4fwshWoxPL4/hiSpI+O/kxWMwb6jNNk3k8Jnj iMeQVj0uJ738GOr9mewF28c1ETzSJRN256krC2YB3B992RILWUqpYwCFDqfSAs0DMVuR yQdAXE9pP/gfDoXO9eE2hVQ3wAjYgpEQ1iHzjewzgPfERSbOBma32QdLT0yUS+3EzEO1 Q95e7R0LYtp5yibN86xGO7wF3/NphEVLbu1sNnkdLxFgYDYN90P+JdXaNyTdGmASxSem nlQ6+fjC+FlOJG/m5dWUzSWYK8U0h93eyoCf6N8nhxos3Q/8jjDujLegsN3Sv4AbzZkS YO4w== Received: by 10.112.24.197 with SMTP id w5mr830404lbf.83.1335342835929; Wed, 25 Apr 2012 01:33:55 -0700 (PDT) Received: from a88-114-173-83.elisa-laajakaista.fi (a88-114-173-83.elisa-laajakaista.fi. [88.114.173.83]) by mx.google.com with ESMTPS id q5sm27472458lbd.13.2012.04.25.01.33.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 01:33:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F969A70.5090506@gmail.com> Date: Wed, 25 Apr 2012 11:33:38 +0300 Content-Transfer-Encoding: 7bit Message-Id: <6B411362-339E-47E4-B54E-EE02666D65A8@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <4F965BD2.1080906@gmail.com> <4F969A 70.5090506@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 08:33:58 -0000 On Apr 24, 2012, at 3:20 PM, Alexandru Petrescu wrote: [snip] >> As for #3: RFC 6204 doesn't specify any specific technology, and it's >> certainly not limited to ADSL. Much of the behaviour it specifies is >> equally applicable to CPEs whose uplink is a cellular link. > > ? > > 'CPE' is not a term used for the cellular links, I think. RFC6204 says > 'residential or small-office router'. I think it is a stretch to claim > that RFC6204 applies to cellular links. E.g. few if any cellular RFC6204 is not necessarily the best fit for cellular (6204bis does it better) but it definitely does not preclude one making a compliant CE device with a cellular WAN link. > terminals use DHCP as of today, whereas RFC6204 would require them all > to. Also, RFC6204 requires all cellular terminals to use Ethernet So? You would most likely use your cellular just as a modem to connect to network and the rest of the system & stack would be in the host side of the CE. This is sometimes referred as the "split-UE" in 3GPP circles. > encapsulation on their WAN interface whereas none actually does. All WLL-* requirements start with "If the WAN interface supports.." effectively making the following MUST conditional. Those MUSTs, like for ethernet, apply only when the WAN implements the said technology. > There is another RFC - 3316 - "IPv6 for some 2G and 3G Cellular Hosts" > which relates more to cellular. Or a bit more recent RFC6459.. - Jouni > > Alex > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From lorenzo@google.com Wed Apr 25 02:03:54 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EC721F874F for ; Wed, 25 Apr 2012 02:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOy6sYlptl6Z for ; Wed, 25 Apr 2012 02:03:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA4821F8742 for ; Wed, 25 Apr 2012 02:03:53 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so2528910obb.31 for ; Wed, 25 Apr 2012 02:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=JRTTk6v43uhlxh/Y6MK0NrKOXrCaWH+fnwmgufNlY/o=; b=Q5P6yIUOnPq0X7qKePgCiQ6lvVqM8t84QmP/uBhXgh/bSP3v0L4ZQ2OfI6bfaNj3HW oQZTi/66Lv4RL7gjik4n1RwHbRrxI1tR9oDQzEIOfkScLA+cq46hCMUYyvNatE2Mp+2O VreBG94x/myrvhcC6C4NmxeHsKWxYEO87Y9ek2D6qMIvd01dCNgKRnskzw4Dgu9TBDXa VRDLFOeIxiR4s2cfkJYSqTQcdIx5TSIuEUDVCRCCsLhri8evpE+WBJij1KEu+9MZwxO9 uLN3bW0SFObmYGfVEH6T7u3EPnPMt6+5p595GbakVXFbS1fmjzucwOcG6ktogBrf9Nwf nMzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=JRTTk6v43uhlxh/Y6MK0NrKOXrCaWH+fnwmgufNlY/o=; b=eeBb8CEyG+0lPK9m/1q+joAXX792UzkD8qB/CiSzhj+C66Ek4X7E70RqFR3xXfz8d1 SaV10CacF8lo24gqAYBeP0Qt0ZKBRmYND4Slf5rijcrDbRg7CqpD2ErLE7vo4NZwYfFv qku4f4pY5/qIJxI2kJYTW47oC0Ev2nYSqx0VOxXaRzDwh8QtFkv3rpOQoO7y839lKbB+ WrKNuOvHWYj0CdsQaKqCdP44VDykZPwN9MNoT2QKJBuY0w1X7SWWFAS3w6PI+knoj/Z1 f2V6om3zIiv6IZTsSxIlD9wkU7WByrlqDQdbY4552gHiQMwgCe2s7y5kL4OrQlpmHSbw 5COQ== Received: by 10.182.113.42 with SMTP id iv10mr2416430obb.18.1335344632878; Wed, 25 Apr 2012 02:03:52 -0700 (PDT) Received: by 10.182.113.42 with SMTP id iv10mr2416423obb.18.1335344632730; Wed, 25 Apr 2012 02:03:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Wed, 25 Apr 2012 02:03:31 -0700 (PDT) In-Reply-To: <4F969A70.5090506@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <4F965BD2.1080906@gmail.com> <4F969A70.5090506@gmail.com> From: Lorenzo Colitti Date: Wed, 25 Apr 2012 18:03:31 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=f46d04479f977c95a904be7d2600 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlGGb83RDE5amMU1KIwJt9bjfcCbwrlxaUVL4FFsZo16NoVdDDVNc7vZgWe+VrsJhimJNMP/WLdOodNBontFLbuI2JsJOYggytP/J9jnI51aWk8Nlgmj5M4Mwr2Ya8tVpZ5a+G+ Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 09:03:55 -0000 --f46d04479f977c95a904be7d2600 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 24, 2012 at 21:20, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > W-1: When the router is attached to the WAN interface link, it MUST >> act as an IPv6 host for the purposes of stateless [RFC4862] or >> stateful [RFC3315] interface address assignment. >> > > That is not enough for specific routes. Ok it covers the default routes, > but not specific routes such as rfc4191. Sure. But RFC 6204 also doesn't say "must implement a DHCPv6 route option". So if you want to ensure that the CE router can configure more-specific routes, you have to modify RFC 6204 either way. In one case, you need to modify it to say "must implement a DHCPv6 route option". In the other, you need to modify it to say "must implement RFC 4191". Note that the RFC already says that "nodes that will be deployed in SOHO environments SHOULD implement RFC 4191", so RFC 4191 is likely already implemented. --f46d04479f977c95a904be7d2600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 24, 2012 = at 21:20, Alexandru Petrescu <alexandru.petrescu@gmail.com&= gt; wrote:
=A0 W-1: =A0W= hen the router is attached to the WAN interface link, it MUST
=A0 =A0 =A0 =A0 act as an IPv6 host for the purposes of stateless [RFC4862= ] or
=A0 =A0 =A0 =A0 stateful [RFC3315] interface address assignment.

That is not enough for specific routes. =A0Ok it covers the default routes,= but not specific routes such as rfc4191.

S= ure. But RFC 6204 also doesn't say "must implement a DHCPv6 route = option". So if you want to ensure that the CE router can configure mor= e-specific routes, you have to modify RFC 6204 either way.

In one case, you need to modify it to say "must im= plement a DHCPv6 route option". In the other, you need to modify it to= say "must implement RFC 4191". Note that the RFC already says th= at "nodes that will be deployed in=A0SOHO environments SHOULD implemen= t RFC 4191", so RFC 4191 is likely already implemented.
--f46d04479f977c95a904be7d2600-- From sarikaya2012@gmail.com Wed Apr 25 09:20:51 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEDB21F8649 for ; Wed, 25 Apr 2012 09:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8v9FMCChrZ6 for ; Wed, 25 Apr 2012 09:20:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C02921F85E6 for ; Wed, 25 Apr 2012 09:20:48 -0700 (PDT) Received: by iazz13 with SMTP id z13so317794iaz.31 for ; Wed, 25 Apr 2012 09:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=kn+WvWxO3ulPTrWv3OgjAhG+30HTzb0GhlNCmFbNb1c=; b=pMZrqjZ1wL8L9hGIYhWMpW8gDtnKxunsnuDhnThroAWTjSGkCAQDYlpAuOqC5NaXRT nG6hNlzUZKd9IQEQGRoO2NEHKQDD2HhQ4pnuN891tH3sjrEiYRupfOIPqQupI5cF0UA8 1U9j4mI91AC9cDYGifRsHL7ms/Kmtq/PTrXUzCTgynHu+7gsxnr27kDFG5HlKv7dU8z2 MLb+0w9gadqKQKbxrUWCA7NCDT6JuNTLrPFnXADTVKogsgXbB2zHQjUGtsRr1phW9h6M jausZc0sRidM3HAlHlVuizsb6iXVOWnMmTGdLABmMdovVFIzH9BOQv9ZXIHbqaI43GFA mpOw== MIME-Version: 1.0 Received: by 10.50.159.202 with SMTP id xe10mr3285698igb.66.1335370848662; Wed, 25 Apr 2012 09:20:48 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Wed, 25 Apr 2012 09:20:48 -0700 (PDT) In-Reply-To: References: <20120424215837.16501.71842.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 11:20:48 -0500 Message-ID: From: Behcet Sarikaya To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [mif] Fwd: New Version Notification for draft-sarikaya-mif-6man-ra-route-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:20:51 -0000 I have submitted RA version of the route option draft. I know that this issue has been discussed a lot but for the RA version there was no draft. So now, we have a draft. I think that the consensus from IETF 83 was to go for RA options. Regards, Behcet ---------- Forwarded message ---------- From: Behcet Sarikaya Date: Tue, Apr 24, 2012 at 5:01 PM Subject: Fwd: New Version Notification for draft-sarikaya-mif-6man-ra-route-00.txt To: Wojciech Dec , Tomasz Mrugalski , suntao@chinamobile.com Hi all, If you wish to be coauthor, please let me know. I'll be happy to make -01 with you. Regards, Behcet ---------- Forwarded message ---------- From: =A0 Date: Tue, Apr 24, 2012 at 4:58 PM Subject: New Version Notification for draft-sarikaya-mif-6man-ra-route-00.t= xt To: sarikaya@ieee.org A new version of I-D, draft-sarikaya-mif-6man-ra-route-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-sarikaya-mif-6man-ra-route Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 IPv6 RA Options for Multiple Interface Next Hop = Routes Creation date: =A0 2012-04-24 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 9 Abstract: =A0 This draft defines new Router Advertisement options for configuring =A0 next hop routes on the mobile or fixed nodes. =A0Using these options, =A0 an operator can easily configure nodes with multiple interfaces (or =A0 otherwise multi-homed) to enable them to select the routes to a =A0 destination. =A0Each option is defined together with definitions of =A0 host and router behaviors. The IETF Secretariat From alexandru.petrescu@gmail.com Wed Apr 25 13:43:58 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB6121F88B2 for ; Wed, 25 Apr 2012 13:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpySWaC1ol59 for ; Wed, 25 Apr 2012 13:43:58 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id D10AE21F8894 for ; Wed, 25 Apr 2012 13:43:56 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id BD6CD940106; Wed, 25 Apr 2012 22:43:50 +0200 (CEST) Message-ID: <4F986205.9080605@gmail.com> Date: Wed, 25 Apr 2012 22:43:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <4F965BD2.1080906@gmail.com> <4F969A70.5090506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120425-0, 25/04/2012), Outbound message X-Antivirus-Status: Clean Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:43:58 -0000 Le 25/04/2012 11:03, Lorenzo Colitti a écrit : > On Tue, Apr 24, 2012 at 21:20, Alexandru Petrescu > > wrote: > > W-1: When the router is attached to the WAN interface link, > it MUST > act as an IPv6 host for the purposes of stateless > [RFC4862] or > stateful [RFC3315] interface address assignment. > > > That is not enough for specific routes. Ok it covers the default > routes, but not specific routes such as rfc4191. > > > Sure. But RFC 6204 also doesn't say "must implement a DHCPv6 route > option". So if you want to ensure that the CE router can configure > more-specific routes, you have to modify RFC 6204 either way. Right, so either way RFC 6204 wouldn't be enough when one wants to achieve DHCP route-options neither DHCP default routes. > In one case, you need to modify it to say "must implement a DHCPv6 route > option". In the other, you need to modify it to say "must implement RFC > 4191". Note that the RFC already says that "nodes that will be deployed > in SOHO environments SHOULD implement RFC 4191", so RFC 4191 is likely > already implemented. What does that "nodes" mean? In that RFC 6204 context I guess it means all entities in the SOHO except the CPE. At most, I think it means that the CPE sends 4191 RAs to SOHO Hosts which neead to read 4191 RAs. I don't think it means a CPE router to read 4191 RAs sent by CPE+1 ISP routers. A router to read 4191-specific-route does not exist today. In this case, what would one prefer to specify - a 4191 router to read specific routes from 4191? Or a DHCP Client already doing Prefix Delegation (a Requesting Router) to read DHCP route options and default route options? Alex From alexandru.petrescu@gmail.com Wed Apr 25 13:55:32 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77D321E800F for ; Wed, 25 Apr 2012 13:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g48sHLXJiaSx for ; Wed, 25 Apr 2012 13:55:32 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id AF2F211E8089 for ; Wed, 25 Apr 2012 13:55:30 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4A5C49400E3; Wed, 25 Apr 2012 22:55:23 +0200 (CEST) Message-ID: <4F9864BB.10907@gmail.com> Date: Wed, 25 Apr 2012 22:55:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: jouni korhonen References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <4F965BD2.1080906@gmail.com> <4F969A 70.5090506@gmail.com> <6B411362-339E-47E4-B54E-EE02666D65A8@gmail.com> In-Reply-To: <6B411362-339E-47E4-B54E-EE02666D65A8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120425-0, 25/04/2012), Outbound message X-Antivirus-Status: Clean Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:55:32 -0000 Le 25/04/2012 10:33, jouni korhonen a écrit : > > On Apr 24, 2012, at 3:20 PM, Alexandru Petrescu wrote: > > [snip] > > >>> As for #3: RFC 6204 doesn't specify any specific technology, and it's >>> certainly not limited to ADSL. Much of the behaviour it specifies is >>> equally applicable to CPEs whose uplink is a cellular link. >> >> ? >> >> 'CPE' is not a term used for the cellular links, I think. RFC6204 says >> 'residential or small-office router'. I think it is a stretch to claim >> that RFC6204 applies to cellular links. E.g. few if any cellular > > RFC6204 is not necessarily the best fit for cellular (6204bis does it > better) Do you mean http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08 ? > but it definitely does not preclude one making a compliant CE > device with a cellular WAN link. > >> terminals use DHCP as of today, whereas RFC6204 would require them all >> to. Also, RFC6204 requires all cellular terminals to use Ethernet > > So? You would most likely use your cellular just as a modem to connect > to network and the rest of the system& stack would be in the host side > of the CE. This is sometimes referred as the "split-UE" in 3GPP circles. > >> encapsulation on their WAN interface whereas none actually does. > > All WLL-* requirements start with "If the WAN interface supports.." > effectively making the following MUST conditional. Those MUSTs, like > for ethernet, apply only when the WAN implements the said technology. No cellular air interface to the terminal technology implements Ethernet encapsulation, so I don't understand the presence of that precluding If qualifier. (802.16 is not cellular). >> There is another RFC - 3316 - "IPv6 for some 2G and 3G Cellular Hosts" >> which relates more to cellular. > > Or a bit more recent RFC6459. Thanks for the pointer to RFC6459 "IPv6 in 3GPP EPS". I checked its Prefix Delegation section and I have comments on it, but I guess it's not here to be discussed about. BAsically that section does not tell what a UE router receving a /64 can do with its Ethernet-compatible attached devices doing SLAAC. In practice that means to either forbid SLAAC for the devices (use DHCP) or impossibility to use the /64 coming from the network. This section together with 3GPP documents I looked at recently are pure forms of speculation with no implementation couterpart. (in other document we propose a solution for it, which, if given way, makes further the case for using default routes also in DHCP). Alex > > - Jouni > > >> >> Alex >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > From lorenzo@google.com Wed Apr 25 20:42:07 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7400D21E801E for ; Wed, 25 Apr 2012 20:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVXvVWDO+xmj for ; Wed, 25 Apr 2012 20:42:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF97111E8093 for ; Wed, 25 Apr 2012 20:42:06 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so1085759obb.31 for ; Wed, 25 Apr 2012 20:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=O6ZDK1jqsuP0/laReErfLOeBiXAkYPT8uMVmvwi5arY=; b=CzXzTvh13rvpeleGl2cT1CoPmgy3VZ+unBHy70zuHbxJ/ZtJD0fuLgvTOAoki7Tg3X Z5RmwL4JbwhLCIogpDVpax8rMQc8xTXh17sFViooFAsD5CQesnjbUYRrCTsHckeQ27pd NljU+E0VutEusemYg+wc7Nt/Hoh5a32IuFWMyLw60CX+WtC/DoFwNZ0uCqkEM5pwIrW2 V5utd5qZ1+TL74HO+MMjs2wjBdILUABjGSbkcvjDY/SkpTEJjy2VGIAGwdWBWewf8EoT 5yokQInBwANk3Qg+qkqd70LuaDsQ+tPuzAGmKvcbmZ37B0ObRB8PHNip2V3uhl1ei9hs Udfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=O6ZDK1jqsuP0/laReErfLOeBiXAkYPT8uMVmvwi5arY=; b=akgMuOK7+4PdmiNP8Y4MNoF3lQFBE3uFh/IRbROVugMGmW/oSt0yzAxytrzxMpne3Y nQXT0DRxI5Ah33sRjObSXxoOOeGXiF6LYGQCWcEuT4nFQmKXtPQKJQytKe+NTbPkiWdw nAglaSFQKM+R/FTfWpk2W1cNPanyl1BKzd2/fKGQfhcq4pwOcE4g4KkTdFRBJ5lB7ko3 PX7wJuNnI4K8wM5vvacQg8gCL//FQWMQEMJ7mZF/qoqWl+HzS86IA3EQTO3g8HbCiqcH ZRM9vM11LZxv8DpCHK33VNyXJlpOZ7eXg5ZkRe2WtnEAyk3DPOZUo9TZuTHGfjJ4PQbq p7Yg== Received: by 10.182.221.100 with SMTP id qd4mr6878495obc.8.1335411726191; Wed, 25 Apr 2012 20:42:06 -0700 (PDT) Received: by 10.182.221.100 with SMTP id qd4mr6878486obc.8.1335411726037; Wed, 25 Apr 2012 20:42:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Wed, 25 Apr 2012 20:41:45 -0700 (PDT) In-Reply-To: <4F986205.9080605@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <4F965BD2.1080906@gmail.com> <4F969A70.5090506@gmail.com> <4F986205.9080605@gmail.com> From: Lorenzo Colitti Date: Thu, 26 Apr 2012 12:41:45 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=f46d044784d58f33d104be8cc5c1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnibuN7mr+ZLv4SIdbYrJEZpg+l6dNrzPFYqhVk1jh48wMwwhJAWZc0pL5JnmMdzn7AjymX+tc0LURjy4GaUrxxPZA7n0sbE8GGl7vs0eVLdA2KyEhv+rlA2p/uTz8z7OAAzOjy Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 03:42:07 -0000 --f46d044784d58f33d104be8cc5c1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 26, 2012 at 05:43, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > In one case, you need to modify it to say "must implement a DHCPv6 >> route option". In the other, you need to modify it to say "must implement >> RFC 4191". Note that the RFC already says that "nodes that will be >> deployed in SOHO environments SHOULD implement RFC 4191", so RFC 4191 is >> likely already implemented. >> > > What does that "nodes" mean? In that RFC 6204 context I guess it means > all entities in the SOHO except the CPE. > "Node" is defined by RFC 2460 as "a device that implements IPv6" > At most, I think it means that the CPE sends 4191 RAs to SOHO Hosts which > neead to read 4191 RAs. I don't think it means a CPE router to read 4191 > RAs sent by CPE+1 ISP routers. > Nope. The CPE is a node, and thus per RFC 6434 (IPv6 node requirements) it SHOULD implement RFC 4191 if it's deployed in a SOHO environment. > A router to read 4191-specific-route does not exist today. > The linux kernel supports it, I believe. > In this case, what would one prefer to specify - a 4191 router to read > specific routes from 4191? Or a DHCP Client already doing Prefix > Delegation (a Requesting Router) to read DHCP route options and default > route options? > I think RFC 4191 has much richer semantics (multiple sources of information, early deprecation, deprecation when the router originally crashes). So I would prefer RFC 4191. As we know from this thread, others disagree. :-) --f46d044784d58f33d104be8cc5c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 26, 2012 = at 05:43, Alexandru Petrescu <alexandru.petrescu@gmail.com&= gt; wrote:
In one case, you need to modify it to say "must implement a DHCPv6 rou= te=A0option". In the other, you need to modify it to say "must im= plement RFC=A04191". Note that the RFC already says that "nodes t= hat will be deployed=A0in SOHO environments SHOULD implement RFC 4191"= , so RFC 4191 is likely=A0already implemented.

What does that "nodes" mean? =A0In that RFC 6204 context I guess = it means all entities in the SOHO except the CPE.

=
"Node" is defined by RFC 2460 as "a device that i= mplements IPv6"
=A0
At most, I think it means that= the CPE sends 4191 RAs to SOHO Hosts which neead to read 4191 RAs. =A0I do= n't think it means a CPE router to read 4191 RAs sent by CPE+1 ISP rout= ers.

Nope. The CPE is a node, and thus per RFC = 6434 (IPv6 node requirements) it SHOULD implement RFC 4191 if it's depl= oyed in a SOHO environment.
=A0
A router to read 4191-specific-route does not exist today.
=

The linux kernel supports it, I believe.
=A0<= /div>
In this case, what would one prefer to specify - a 4191 router to read spec= ific routes from 4191? =A0Or a DHCP Client already doing Prefix Delegation = (a Requesting Router) to read DHCP route options and default route options?=

I think RFC 4191 has much richer semantics= (multiple sources of information, early deprecation, deprecation when the = router originally crashes). So I would prefer RFC 4191. As we know from thi= s thread, others disagree. :-)
--f46d044784d58f33d104be8cc5c1-- From sarikaya2012@gmail.com Thu Apr 26 08:47:15 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2D21E803F for ; Thu, 26 Apr 2012 08:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUNAsi4RbHx5 for ; Thu, 26 Apr 2012 08:47:14 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9483821E80A3 for ; Thu, 26 Apr 2012 08:47:13 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1187774yhk.31 for ; Thu, 26 Apr 2012 08:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ZFygb+1/VJbmeBmshkc1Ppb3dgZfqaHWQD6UuO2kT3I=; b=AL+W2L6UeAXWDVqakaeu2kCyXbFmBAdsIoApP6KyBm+o7XdTe6A9SOjLJlAQUmVFMb SdeVRMGCIoGVRwKg7eHIfEtmVzZJk4ItxALYhC/qEI2sg+TxhGpdaaT6C9PgH1NRHZlI iE/aKCt8k66G9nFM8uUNvy2cOgp0HRCsBxyHeqATBzwWNI/eAG+9mdrcPyDrP2qXJsxO 22++8mHlLDOMPE9gwlMWahcOPqb7yrXoB4RcPcGoYnEztrIDV8LwruLByDkCa6CwaB+U /3c/d6YWX2mqhb8J2U5gfrzDx7P1N5gveBiHaxYugrZUwok08xMfeYVGQCKrsX+Z5gNW BW/g== MIME-Version: 1.0 Received: by 10.50.47.135 with SMTP id d7mr19111841ign.66.1335455232894; Thu, 26 Apr 2012 08:47:12 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Thu, 26 Apr 2012 08:47:12 -0700 (PDT) In-Reply-To: References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <4F965BD2.1080906@gmail.com> <4F969A70.5090506@gmail.com> <4F986205.9080605@gmail.com> Date: Thu, 26 Apr 2012 10:47:12 -0500 Message-ID: From: Behcet Sarikaya To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:47:15 -0000 Hi Lorenzo, On Wed, Apr 25, 2012 at 10:41 PM, Lorenzo Colitti wrot= e: > On Thu, Apr 26, 2012 at 05:43, Alexandru Petrescu > wrote: >>> >>> In one case, you need to modify it to say "must implement a DHCPv6 >>> route=A0option". In the other, you need to modify it to say "must imple= ment >>> RFC=A04191". Note that the RFC already says that "nodes that will be >>> deployed=A0in SOHO environments SHOULD implement RFC 4191", so RFC 4191= is >>> likely=A0already implemented. >> >> >> What does that "nodes" mean? =A0In that RFC 6204 context I guess it mean= s >> all entities in the SOHO except the CPE. > > > "Node" is defined by RFC 2460 as "a device that implements IPv6" > >> >> At most, I think it means that the CPE sends 4191 RAs to SOHO Hosts whic= h >> neead to read 4191 RAs. =A0I don't think it means a CPE router to read 4= 191 >> RAs sent by CPE+1 ISP routers. > > > Nope. The CPE is a node, and thus per RFC 6434 (IPv6 node requirements) i= t > SHOULD implement RFC 4191 if it's deployed in a SOHO environment. > >> >> A router to read 4191-specific-route does not exist today. > > > The linux kernel supports it, I believe. > >> >> In this case, what would one prefer to specify - a 4191 router to read >> specific routes from 4191? =A0Or a DHCP Client already doing Prefix Dele= gation >> (a Requesting Router) to read DHCP route options and default route optio= ns? > > > I think RFC 4191 has much richer semantics (multiple sources of informati= on, > early deprecation, deprecation when the router originally crashes). So I > would prefer RFC 4191. As we know from this thread, others disagree. :-) RFC 4191 needs to be extended in view of route option work in MIF, I think. This is what we have done in http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-00 Take a look. Behcet