From carlsonj@workingcode.com Fri Aug 13 11:59:09 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2F33A68D5 for ; Fri, 13 Aug 2010 11:59:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTU7U6yKd2V6 for ; Fri, 13 Aug 2010 11:59:08 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 538273A6944 for ; Fri, 13 Aug 2010 11:59:08 -0700 (PDT) Received: from [192.168.254.211] (dhcp-211 [192.168.254.211]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o7DIxeuo020989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Aug 2010 14:59:40 -0400 (EDT) Message-ID: <4C659616.3070304@workingcode.com> Date: Fri, 13 Aug 2010 14:59:34 -0400 From: James Carlson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: pppext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-INFN-TO-Metrics: carlson; whitelist Subject: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:59:09 -0000 Subject: I-D Action:draft-vautrin-6man-ipv6-mlppp-id-00.txt Date: Thu, 12 Aug 2010 16:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi link PPP Support for an ipv6 address class identifier Author(s) : O. Vautrin, B. Lourdelet Filename : draft-vautrin-6man-ipv6-mlppp-id-00.txt Pages : 5 Date : 2010-08-12 This document specifies a new multi link protocol address class identifier. This new class will be able to contain an ipv6 address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vautrin-6man-ipv6-mlppp-id-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -- James Carlson 42.703N 71.076W From carlsonj@workingcode.com Fri Aug 13 12:36:02 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71683A6919 for ; Fri, 13 Aug 2010 12:36: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FCxa70kCWYj for ; Fri, 13 Aug 2010 12:36:01 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 5426F3A6836 for ; Fri, 13 Aug 2010 12:36:01 -0700 (PDT) Received: from [192.168.254.211] (dhcp-211 [192.168.254.211]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o7DJaW2J022060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 15:36:32 -0400 (EDT) Message-ID: <4C659EB9.4050405@workingcode.com> Date: Fri, 13 Aug 2010 15:36:25 -0400 From: James Carlson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Olivier@juniper.net, blourdel@cisco.com References: <4C659616.3070304@workingcode.com> In-Reply-To: <4C659616.3070304@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:36:02 -0000 > Title : Multi link PPP Support for an ipv6 address class > identifier > Author(s) : O. Vautrin, B. Lourdelet > Filename : draft-vautrin-6man-ipv6-mlppp-id-00.txt In general, I like the idea, but I'd like to suggest a few amendments (or at least points for consideration): - Some IPv6 addresses are probably not as suitable for use as others. In particular, using a link local is unlikely to be a good idea because of the greater risk of duplication. We glossed over this issue with IPv4 in RFC 1990, mostly because link-locals are so 'rare' there, but it seems more important to call out in the context of IPv6. - A "privacy" address, or any other "changes frequently" address, may be a problem operationally. If a PPP system establishes one link, and then later (perhaps on demand) establishes another link that's intended as part of a bundle, that second link will need to use the same endpoint discriminator. If the address has changed, the bundle will fail. Implementations likely need to "sample" a locally-available IPv6 address, and then keep using that address for all future links until the bundle itself is terminated -- regardless of the current status of that address on the system. That is, I believe the document should explicitly _encourage_ the use of IPv6 addresses in this one context past the point where the system is otherwise still "allowed" to use the address. If that can't be done (e.g., if the IPv6 folks believe that this usage is somehow a problem), then addresses that are expected to change need to be avoided. (Personally, I don't see how it could be a problem, unless you're prepared to tear down the whole bundle when the address becomes invalid, but I guess I'm unsure here.) - As a nit, I don't think it's wise to duplicate the existing RFC 1990 values for Class in this document. Instead, just the new value and semantics should be included. - I think this ought to be a standards-track document that updates RFC 1990, and (with your agreement, of course) should be a wg document. (See RFC 3818; the Class numbers are "IETF Consensus.") - Wow. The new boilerplate makes a visual mess of otherwise nice, simple proposals like this. :-< -- James Carlson 42.703N 71.076W From esriniva@juniper.net Sun Aug 15 22:53:29 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40173A6958 for ; Sun, 15 Aug 2010 22:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSYrZDWDRX5Y for ; Sun, 15 Aug 2010 22:53:26 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 8612A3A694A for ; Sun, 15 Aug 2010 22:53:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTGjScSdlij+yG7pXNjYFPJVYlqX7C8Iu@postini.com; Sun, 15 Aug 2010 22:54:02 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 15 Aug 2010 22:42:24 -0700 Received: from svl-junos-pool81.juniper.net (svl-junos-pool81.juniper.net [172.17.30.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o7G5gOU69086; Sun, 15 Aug 2010 22:42:24 -0700 (PDT) (envelope-from esriniva@juniper.net) Received: from svl-junos-pool81.juniper.net (localhost.juniper.net [127.0.0.1]) by svl-junos-pool81.juniper.net (8.14.3/8.12.3) with ESMTP id o7G5gOsx067280; Sun, 15 Aug 2010 22:42:24 -0700 (PDT) (envelope-from esriniva@svl-junos-pool81.juniper.net) Received: (from esriniva@localhost) by svl-junos-pool81.juniper.net (8.14.3/8.12.3/Submit) id o7G5gOt3067273; Sun, 15 Aug 2010 22:42:24 -0700 (PDT) Date: Sun, 15 Aug 2010 22:42:24 -0700 From: Eswaran Srinivasan To: James Carlson Message-ID: <20100816054224.GP43721@juniper.net> References: <4C659616.3070304@workingcode.com> <4C659EB9.4050405@workingcode.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4C659EB9.4050405@workingcode.com> User-Agent: Mutt/1.4.2.3i Cc: "pppext@ietf.org" , "Olivier@juniper.net" , "blourdel@cisco.com" Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 05:53:29 -0000 Hi Olivier, The draft looks great to me in general. However, I have a question to you. The section 1 says that the IPv6 class is introduced since the class 1 (Locally Assigned Address) is deprecated. I am thinking that having a IPv6 class is useful even if class 1 is not deprecated. Should we rephrase the sentence (if you agree)? Hi Jim, I can still see the usefulness of class 1 and I have heard about a lot of deployment scenarios with this. So, what does 'deprecated' mean here? Is there any time limit? Basically, I am inclined towards making it 'non-deprecated' and I am trying to understand the logistics behind doing it. Thanks -Eswaran On Fri Aug 13, 2010 at 12:36:25PM -0700, James Carlson wrote: > > Title : Multi link PPP Support for an ipv6 address class > > identifier > > Author(s) : O. Vautrin, B. Lourdelet > > Filename : draft-vautrin-6man-ipv6-mlppp-id-00.txt > > In general, I like the idea, but I'd like to suggest a few amendments > (or at least points for consideration): > > - Some IPv6 addresses are probably not as suitable for use as others. > In particular, using a link local is unlikely to be a good idea because > of the greater risk of duplication. We glossed over this issue with > IPv4 in RFC 1990, mostly because link-locals are so 'rare' there, but it > seems more important to call out in the context of IPv6. > > - A "privacy" address, or any other "changes frequently" address, may be > a problem operationally. If a PPP system establishes one link, and then > later (perhaps on demand) establishes another link that's intended as > part of a bundle, that second link will need to use the same endpoint > discriminator. If the address has changed, the bundle will fail. > Implementations likely need to "sample" a locally-available IPv6 > address, and then keep using that address for all future links until the > bundle itself is terminated -- regardless of the current status of that > address on the system. > > That is, I believe the document should explicitly _encourage_ the use of > IPv6 addresses in this one context past the point where the system is > otherwise still "allowed" to use the address. If that can't be done > (e.g., if the IPv6 folks believe that this usage is somehow a problem), > then addresses that are expected to change need to be avoided. > (Personally, I don't see how it could be a problem, unless you're > prepared to tear down the whole bundle when the address becomes invalid, > but I guess I'm unsure here.) > > - As a nit, I don't think it's wise to duplicate the existing RFC 1990 > values for Class in this document. Instead, just the new value and > semantics should be included. > > - I think this ought to be a standards-track document that updates RFC > 1990, and (with your agreement, of course) should be a wg document. > (See RFC 3818; the Class numbers are "IETF Consensus.") > > - Wow. The new boilerplate makes a visual mess of otherwise nice, > simple proposals like this. :-< > > -- > James Carlson 42.703N 71.076W > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext From carlsonj@workingcode.com Mon Aug 16 04:41:39 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268D43A68A0 for ; Mon, 16 Aug 2010 04:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skMYSIDCzer9 for ; Mon, 16 Aug 2010 04:41:38 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id D9CBC3A680E for ; Mon, 16 Aug 2010 04:41:37 -0700 (PDT) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o7GBg5UD005905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 07:42:05 -0400 (EDT) Message-ID: <4C69240D.3090801@workingcode.com> Date: Mon, 16 Aug 2010 07:42:05 -0400 From: James Carlson User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Eswaran Srinivasan References: <4C659616.3070304@workingcode.com> <4C659EB9.4050405@workingcode.com> <20100816054224.GP43721@juniper.net> In-Reply-To: <20100816054224.GP43721@juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: "pppext@ietf.org" , "Olivier@juniper.net" , "blourdel@cisco.com" Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 11:41:39 -0000 On 08/16/10 01:42, Eswaran Srinivasan wrote: > Hi Olivier, > > The draft looks great to me in general. However, I have a question to > you. > > The section 1 says that the IPv6 class is introduced since the > class 1 (Locally Assigned Address) is deprecated. I am thinking > that having a IPv6 class is useful even if class 1 is not deprecated. > > Should we rephrase the sentence (if you agree)? It's RFC 1717 that deprecates Class 1 ... before even RFC 1990. It was born deprecated. The proposed draft is not changing this, so I think this discussion might be a bit off-topic for the draft itself. > Hi Jim, > > I can still see the usefulness of class 1 and I have heard about a lot > of deployment scenarios with this. So, what does 'deprecated' mean here? > Is there any time limit? > > Basically, I am inclined towards making it 'non-deprecated' and I am > trying to understand the logistics behind doing it. There's no specific time limit nor prohibition against using it. I think the original fear with Class 1 was that since there's no defined way to ensure uniqueness among bundle heads, there could possibly be duplication of values -- which would cause (at least) link failures. As I read it, and perhaps someone else here remembers more about it, the force of the "deprecation" is that it's not the recommended practice for new systems, because the other defined mechanisms are believed to be better and just as easy to use, and that there's the possible threat that it may be removed entirely from future specifications. However, if it is indeed in common use, then that'd be a good reason to document those usages and perhaps create a new document that removes the "deprecated" status rather than removing the feature. Do you have pointers to any additional information? -- James Carlson 42.703N 71.076W From ovautrin@juniper.net Mon Aug 16 11:22:49 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724153A682D for ; Mon, 16 Aug 2010 11:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GolV5tEHLlkm for ; Mon, 16 Aug 2010 11:22:48 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 025EF3A67AF for ; Mon, 16 Aug 2010 11:22:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTGmCGqk/vj9X6C305IhC3o6eLACSZ46n@postini.com; Mon, 16 Aug 2010 11:23:24 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 16 Aug 2010 11:22:39 -0700 From: Olivier Vautrin To: James Carlson , "Olivier@juniper.net" , "blourdel@cisco.com" Date: Mon, 16 Aug 2010 11:22:36 -0700 Thread-Topic: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt Thread-Index: Acs7HtpmzamimqLrSvivQKaH9naIWQCS4yzA Message-ID: <84600D05C20FF943918238042D7670FD36D7087F7A@EMBX01-HQ.jnpr.net> References: <4C659616.3070304@workingcode.com> <4C659EB9.4050405@workingcode.com> In-Reply-To: <4C659EB9.4050405@workingcode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 16 Aug 2010 11:38:52 -0700 Cc: "pppext@ietf.org" Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 18:22:49 -0000 Hello James, thanks for your feedback please see below. Yes, I think this document should be a WG document. I thought 6man WG would= be the right place, but I guess PPPext WG makes more sense. /Olivier > -----Original Message----- > From: James Carlson [mailto:carlsonj@workingcode.com] > Sent: Friday, August 13, 2010 12:36 PM > To: Olivier@juniper.net; blourdel@cisco.com > Cc: pppext@ietf.org > Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6- > mlppp-id-00.txt >=20 > > Title : Multi link PPP Support for an ipv6 address > class > > identifier > > Author(s) : O. Vautrin, B. Lourdelet > > Filename : draft-vautrin-6man-ipv6-mlppp-id-00.txt >=20 > In general, I like the idea, but I'd like to suggest a few amendments > (or at least points for consideration): >=20 > - Some IPv6 addresses are probably not as suitable for use as others. > In particular, using a link local is unlikely to be a good idea because > of the greater risk of duplication. We glossed over this issue with > IPv4 in RFC 1990, mostly because link-locals are so 'rare' there, but > it > seems more important to call out in the context of IPv6. [Olivier - ] Yes, a unique Ipv6 address should be used. But in the IPv6 cas= e, the link-local is very rarely non-unique as it is supposed to use the In= terface-ID which is usually a unique ID. Perhaps we could just say that it = would be the responsibility of the operator to use unique Ipv6 address with= out more details? > - A "privacy" address, or any other "changes frequently" address, may > be > a problem operationally. If a PPP system establishes one link, and > then > later (perhaps on demand) establishes another link that's intended as > part of a bundle, that second link will need to use the same endpoint > discriminator. If the address has changed, the bundle will fail. > Implementations likely need to "sample" a locally-available IPv6 > address, and then keep using that address for all future links until > the > bundle itself is terminated -- regardless of the current status of that > address on the system. [Olivier - ] - I guess this issue exist also on IPv4. Do you think this dra= ft is the right vehicle to clarify this for both IPv4 and IPv6? > - As a nit, I don't think it's wise to duplicate the existing RFC 1990 > values for Class in this document. Instead, just the new value and > semantics should be included. > - Wow. The new boilerplate makes a visual mess of otherwise nice, > simple proposals like this. :-< [Olivier - ] This was a way to clarify the document especially because of t= he boilerplate ;) But, yes, I will remove the duplicate part of RFC1990. From ovautrin@juniper.net Mon Aug 16 11:24:20 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AE73A6A30 for ; Mon, 16 Aug 2010 11:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSFkVxaBNCHZ for ; Mon, 16 Aug 2010 11:24:19 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 5BA543A682D for ; Mon, 16 Aug 2010 11:24:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTGmCcyfeCpQbtQW6TdKN9k/cb6T09LwX@postini.com; Mon, 16 Aug 2010 11:24:55 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 16 Aug 2010 11:24:32 -0700 From: Olivier Vautrin To: Eswaran Srinivasan , James Carlson Date: Mon, 16 Aug 2010 11:24:30 -0700 Thread-Topic: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt Thread-Index: Acs9BeMehvza/1BaTkSKvTZ7bvmDPQAaj9oA Message-ID: <84600D05C20FF943918238042D7670FD36D7087F85@EMBX01-HQ.jnpr.net> References: <4C659616.3070304@workingcode.com> <4C659EB9.4050405@workingcode.com> <20100816054224.GP43721@juniper.net> In-Reply-To: <20100816054224.GP43721@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 16 Aug 2010 11:38:52 -0700 Cc: "pppext@ietf.org" , "Olivier@juniper.net" , "blourdel@cisco.com" Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 18:24:20 -0000 Thanks Eswaran for your comment, I will rephrase the sentence about Class 1= . /Olivier > -----Original Message----- > From: Eswaran Srinivasan [mailto:esriniva@juniper.net] > Sent: Sunday, August 15, 2010 10:42 PM > To: James Carlson > Cc: Olivier@juniper.net; blourdel@cisco.com; pppext@ietf.org > Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6- > mlppp-id-00.txt >=20 > Hi Olivier, >=20 > The draft looks great to me in general. However, I have a question to > you. >=20 > The section 1 says that the IPv6 class is introduced since the > class 1 (Locally Assigned Address) is deprecated. I am thinking > that having a IPv6 class is useful even if class 1 is not > deprecated. >=20 > Should we rephrase the sentence (if you agree)? >=20 > Hi Jim, >=20 > I can still see the usefulness of class 1 and I have heard about a lot > of deployment scenarios with this. So, what does 'deprecated' mean > here? > Is there any time limit? >=20 > Basically, I am inclined towards making it 'non-deprecated' and I am > trying to understand the logistics behind doing it. >=20 > Thanks > -Eswaran >=20 > On Fri Aug 13, 2010 at 12:36:25PM -0700, James Carlson wrote: > > > Title : Multi link PPP Support for an ipv6 address > class > > > identifier > > > Author(s) : O. Vautrin, B. Lourdelet > > > Filename : draft-vautrin-6man-ipv6-mlppp-id-00.txt > > > > In general, I like the idea, but I'd like to suggest a few amendments > > (or at least points for consideration): > > > > - Some IPv6 addresses are probably not as suitable for use as others. > > In particular, using a link local is unlikely to be a good idea > because > > of the greater risk of duplication. We glossed over this issue with > > IPv4 in RFC 1990, mostly because link-locals are so 'rare' there, but > it > > seems more important to call out in the context of IPv6. > > > > - A "privacy" address, or any other "changes frequently" address, may > be > > a problem operationally. If a PPP system establishes one link, and > then > > later (perhaps on demand) establishes another link that's intended as > > part of a bundle, that second link will need to use the same endpoint > > discriminator. If the address has changed, the bundle will fail. > > Implementations likely need to "sample" a locally-available IPv6 > > address, and then keep using that address for all future links until > the > > bundle itself is terminated -- regardless of the current status of > that > > address on the system. > > > > That is, I believe the document should explicitly _encourage_ the use > of > > IPv6 addresses in this one context past the point where the system is > > otherwise still "allowed" to use the address. If that can't be done > > (e.g., if the IPv6 folks believe that this usage is somehow a > problem), > > then addresses that are expected to change need to be avoided. > > (Personally, I don't see how it could be a problem, unless you're > > prepared to tear down the whole bundle when the address becomes > invalid, > > but I guess I'm unsure here.) > > > > - As a nit, I don't think it's wise to duplicate the existing RFC > 1990 > > values for Class in this document. Instead, just the new value and > > semantics should be included. > > > > - I think this ought to be a standards-track document that updates > RFC > > 1990, and (with your agreement, of course) should be a wg document. > > (See RFC 3818; the Class numbers are "IETF Consensus.") > > > > - Wow. The new boilerplate makes a visual mess of otherwise nice, > > simple proposals like this. :-< > > > > -- > > James Carlson 42.703N 71.076W > > > _______________________________________________ > > Pppext mailing list > > Pppext@ietf.org > > https://www.ietf.org/mailman/listinfo/pppext From carlsonj@workingcode.com Mon Aug 16 12:59:15 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837E83A6A81 for ; Mon, 16 Aug 2010 12:59:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIlc7wOUuUF5 for ; Mon, 16 Aug 2010 12:59:14 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 4D2823A6A93 for ; Mon, 16 Aug 2010 12:59:14 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o7GJxkP9015598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 15:59:46 -0400 (EDT) Message-ID: <4C6998B1.5060908@workingcode.com> Date: Mon, 16 Aug 2010 15:59:45 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Olivier Vautrin References: <4C659616.3070304@workingcode.com> <4C659EB9.4050405@workingcode.com> <84600D05C20FF943918238042D7670FD36D7087F7A@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36D7087F7A@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: carlson; whitelist Cc: "pppext@ietf.org" , "blourdel@cisco.com" Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 19:59:15 -0000 Olivier Vautrin wrote: > Hello James, thanks for your feedback please see below. > > Yes, I think this document should be a WG document. I thought 6man WG would be the right place, but I guess PPPext WG makes more sense. OK; thanks. Consider it done. You'd need our group's approval anyway to modify the IANA registry for the new E-D Class value. >> - Some IPv6 addresses are probably not as suitable for use as others. >> In particular, using a link local is unlikely to be a good idea because >> of the greater risk of duplication. We glossed over this issue with >> IPv4 in RFC 1990, mostly because link-locals are so 'rare' there, but >> it >> seems more important to call out in the context of IPv6. > > [Olivier - ] Yes, a unique Ipv6 address should be used. But in the IPv6 case, the link-local is very rarely non-unique as it is supposed to use the Interface-ID which is usually a unique ID. Perhaps we could just say that it would be the responsibility of the operator to use unique Ipv6 address without more details? For IPv6, the only operational uniqueness requirement is that the address is unique on a given subnetwork. Since one of the main things we're trying to do here is distinguish unrelated remote systems -- ones that may well be on completely different networks -- there's not as much that guarantees it. Yes, I agree that "most" link-locals are created using EUI64 values and are thus guaranteed to be unique. However, I do know of at least one virtual server solution that conjures up link-locals out of thin air (and that thus relies on DAD to do the rest). Anyway, what I was suggesting here was text of the form: "Using a statically-assigned global IPv6 address to form this identifier is RECOMMENDED." >> - A "privacy" address, or any other "changes frequently" address, may >> be >> a problem operationally. If a PPP system establishes one link, and >> then >> later (perhaps on demand) establishes another link that's intended as >> part of a bundle, that second link will need to use the same endpoint >> discriminator. If the address has changed, the bundle will fail. >> Implementations likely need to "sample" a locally-available IPv6 >> address, and then keep using that address for all future links until >> the >> bundle itself is terminated -- regardless of the current status of that >> address on the system. > > [Olivier - ] - I guess this issue exist also on IPv4. Do you think this draft is the right vehicle to clarify this for both IPv4 and IPv6? The privacy extensions (RFC 4941) are a bit different, and don't appear to apply to v4. In the implementation I've used (Solaris), the v6 addresses with privacy enabled change fairly frequently, and would represent a significant challenge to use with this mechanism. There are two underlying suggestions here: 1. If the address is known (for whatever reason) to be one that might vary over time, then it'd be less preferred for use here than one that doesn't (or isn't expected to) vary. (This is the same issue as above; static global would be best.) That's not to say "can't use" autoconf or some other address, but if you have something more stable, and you know the difference, it'd be good to choose that. 2. Implementations that may see addresses come and go should consider choosing an address to be used when the bundle head is created, and continuing to use that same address until the bundle head is torn down. They should do so regardless of the state of the address itself on the machine; if the address is deprecated and removed, that should not affect the bundle head using it for identity. The same issue, more or less, could apply with IPv4, but in practice does not. The systems that use an IPv4 identifier are typically ones that have a static IPv4 address. There are just more viable options with IPv6. For others, where the address may end up wandering between systems (e.g., DHCP), it would probably be unwise to use either feature, and the existing magic number block or even opaque identifier might well be better. As a deployment note, this draft relies for interoperability with existing implementations on the idea that a well-designed RFC 1990 system will treat all classes (and associated data) as effectively opaque and will not attempt to "validate" the peer's reported class number, except in comparison to other E-D data during bundle formation. One benefit of adding and deploying this feature is that it may end up identifying implementations that are not that robust. Bottom line, though, is that I was asking you to consider adding some advice for implementors, not insisting that you do. If you feel it's truly unnecessary to do that, I'll just shrug and go along, because I don't think these are substantial issues. -- James Carlson 42.703N 71.076W