From carlsonj@workingcode.com Tue Mar 8 07:29:31 2011 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 279243A67B7 for ; Tue, 8 Mar 2011 07:29:31 -0800 (PST) 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 PWbgGBZPl3+m for ; Tue, 8 Mar 2011 07:29:30 -0800 (PST) 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 CD2383A67A8 for ; Tue, 8 Mar 2011 07:29:29 -0800 (PST) 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 p28FUYaw021371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Mar 2011 10:30:35 -0500 (EST) Message-ID: <4D764B99.7030501@workingcode.com> Date: Tue, 08 Mar 2011 10:30:33 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: PPP Extensions Content-Type: multipart/mixed; boundary="------------030107080103080202030006" X-DCC-x.dcc-servers-Metrics: carlson; whitelist Subject: [Pppext] [Fwd: I-D ACTION:draft-fleischhauer-ipv4-addr-saving-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: Tue, 08 Mar 2011 15:29:31 -0000 This is a multi-part message in MIME format. --------------030107080103080202030006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I see nothing particularly new here -- just a rehash of the existing ability to negotiate NCPs when and where desired -- but since it describes PPP mechanisms directly, I'm forwarding it along to the list. -- James Carlson 42.703N 71.076W --------------030107080103080202030006 Content-Type: message/rfc822; name="I-D ACTION:draft-fleischhauer-ipv4-addr-saving-00.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D ACTION:draft-fleischhauer-ipv4-addr-saving-00.txt.eml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on carlson.workingcode.com X-Spam-Level: X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,RDNS_NONE autolearn=ham version=3.2.4 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p2822VHs010044 for ; Mon, 7 Mar 2011 21:02:31 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11B728C165; Mon, 7 Mar 2011 18:00:14 -0800 (PST) X-Original-To: i-d-announce@core3.amsl.com Delivered-To: i-d-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71F53A68D0 for ; Mon, 7 Mar 2011 18:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 WTSHDmdgkRzX for ; Mon, 7 Mar 2011 18:00:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0503328C0FB for ; Mon, 7 Mar 2011 18:00:04 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-fleischhauer-ipv4-addr-saving-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110308020004.17578.25763.idtracker@localhost> Date: Mon, 07 Mar 2011 18:00:04 -0800 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-DCC-x.dcc-servers-Metrics: carlson; whitelist --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. Title : On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios Author(s) : O. Bonness, et al Filename : draft-fleischhauer-ipv4-addr-saving-00.txt Pages : 10 Date : 2011-03-07 Today the Dual-Stack approach is the most straightforward and most common way for introducing IPv6 into existing systems and networks. However a typical drawback of implementing Dual-Stack is that each node will still require at least one IPv4 address. Hence, solely deploying Dual-Stack does not provide a sufficient solution to the IPv4 address exhaustion problem. Assuming a situation where most of the IP communication (e.g. always-on, VoIP etc.) can be provided via IPv6, the usage of IPv4 addresses can significantly be reduced and the unused IPv4 addresses can under certain circumstances be returned to the IPv4 address pool of the service provider. New Dual-Stack enabled services can be introduced without increasing the IPv4 address demand, when IPv6 will be the preferred network layer protocol. This document describes such a solution in a Dual-Stack PPP session network scenario and explains the protocol mechanisms which are used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fleischhauer-ipv4-addr-saving-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-fleischhauer-ipv4-addr-saving-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07174946.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------030107080103080202030006-- From carlsonj@workingcode.com Mon Mar 14 14:30:19 2011 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 7B6BE3A6F8F for ; Mon, 14 Mar 2011 14:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 vEuC88swQf3v for ; Mon, 14 Mar 2011 14:30:18 -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 DAB333A6F8B for ; Mon, 14 Mar 2011 14:30:16 -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 p2ELVT5E028995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Mar 2011 17:31:30 -0400 (EDT) Message-ID: <4D7E8931.9050408@workingcode.com> Date: Mon, 14 Mar 2011 17:31:29 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: PPP Extensions Content-Type: multipart/mixed; boundary="------------050502080106060807020603" X-DCC-SIHOPE-DCC-3-Metrics: carlson; whitelist Subject: [Pppext] new drafts posted for IPv6CP extensions 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, 14 Mar 2011 21:30:19 -0000 This is a multi-part message in MIME format. --------------050502080106060807020603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Two new drafts were posted for IPv6CP extensions. The announcements are attached. You can see diffs from the previous version by looking here: http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-requirements-01 http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-extensions-01 -- James Carlson 42.703N 71.076W --------------050502080106060807020603 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on carlson.workingcode.com X-Spam-Level: X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,RDNS_NONE autolearn=ham version=3.2.4 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p2EF5522022757 for ; Mon, 14 Mar 2011 11:05:05 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C933A6DE8; Mon, 14 Mar 2011 08:00:20 -0700 (PDT) X-Original-To: i-d-announce@core3.amsl.com Delivered-To: i-d-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8BB3A6DAF for ; Mon, 14 Mar 2011 08:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 WT4BqTkJF5D3 for ; Mon, 14 Mar 2011 08:00:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0326C3A6DCB for ; Mon, 14 Mar 2011 08:00:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-hu-pppext-ipv6cp-extensions-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314150004.18047.19036.idtracker@localhost> Date: Mon, 14 Mar 2011 08:00:04 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-DCC-x.dcc-servers-Metrics: carlson; whitelist --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PPP IPv6 Control Protocol Extensions Author(s) : J. Hu, et al. Filename : draft-hu-pppext-ipv6cp-extensions-01.txt Pages : 12 Date : 2011-03-14 The IPv6 Control Protocol (IPv6CP) is one of Network Control Protocols(NCPs) that are defined by the Point-to-Point Protocol(PPP) for establishing and configuring different network protocols. This document extends the IPv6CP for negotiating and configuring IPv6 network parameters over PPP links, including IPv6 address, IPv6 prefix, primary and alternative DNS server addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hu-pppext-ipv6cp-extensions-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-hu-pppext-ipv6cp-extensions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14075316.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------050502080106060807020603 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on carlson.workingcode.com X-Spam-Level: X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,RDNS_NONE autolearn=ham version=3.2.4 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p2EF66R3022762 for ; Mon, 14 Mar 2011 11:06:07 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A393A6DED; Mon, 14 Mar 2011 08:00:22 -0700 (PDT) X-Original-To: i-d-announce@core3.amsl.com Delivered-To: i-d-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C823A6DD8 for ; Mon, 14 Mar 2011 08:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 27kWf2qjzUBr for ; Mon, 14 Mar 2011 08:00:09 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4CC3A6905 for ; Mon, 14 Mar 2011 08:00:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-hu-pppext-ipv6cp-requirements-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314150004.18047.13743.idtracker@localhost> Date: Mon, 14 Mar 2011 08:00:04 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-DCC-x.dcc-servers-Metrics: carlson; whitelist --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PPPv6 Problem statement and requirements Author(s) : J. Hu, et al. Filename : draft-hu-pppext-ipv6cp-requirements-01.txt Pages : 7 Date : 2011-03-14 As in IPv4 network, PPP (PPPoE) will still be an important mechanism to provide access services to broadband subscribers of IPv6 or dual- stack. This document describes problems the ISPs faced when deploying IPv6 in broadband access network over PPP, particularly, the capabilities lacked in IPv6CP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hu-pppext-ipv6cp-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-hu-pppext-ipv6cp-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14075348.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------050502080106060807020603-- From bernard_aboba@hotmail.com Mon Mar 14 17:12:00 2011 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 C43993A6D2E for ; Mon, 14 Mar 2011 17:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 Fsw9wQDMLEDh for ; Mon, 14 Mar 2011 17:11:59 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by core3.amsl.com (Postfix) with ESMTP id A03B53A6B90 for ; Mon, 14 Mar 2011 17:11:59 -0700 (PDT) Received: from BLU152-DS15 ([65.55.116.72]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 17:13:23 -0700 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'James Carlson'" , "'PPP Extensions'" References: <4D7E8931.9050408@workingcode.com> In-Reply-To: <4D7E8931.9050408@workingcode.com> Date: Mon, 14 Mar 2011 17:13:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWlLReTu2RMA24ZphMfHS/KpmaYZQYIdjA Content-Language: en-us X-OriginalArrivalTime: 15 Mar 2011 00:13:23.0674 (UTC) FILETIME=[CC636BA0:01CBE2A5] Subject: Re: [Pppext] new drafts posted for IPv6CP extensions 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: Tue, 15 Mar 2011 00:12:00 -0000 A related draft was also posted to the RADEXT list: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-04 -----Original Message----- From: pppext-bounces@ietf.org [mailto:pppext-bounces@ietf.org] On Behalf Of James Carlson Sent: Monday, March 14, 2011 2:31 PM To: PPP Extensions Subject: [Pppext] new drafts posted for IPv6CP extensions Two new drafts were posted for IPv6CP extensions. The announcements are attached. You can see diffs from the previous version by looking here: http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-requirements-01 http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-extensions-01 -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Thu Mar 17 12:22:54 2011 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 32E813A694D for ; Thu, 17 Mar 2011 12:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FR6YWdt448ED for ; Thu, 17 Mar 2011 12:22:52 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 948A73A69A7 for ; Thu, 17 Mar 2011 12:22:52 -0700 (PDT) Received: by iwl42 with SMTP id 42so3739084iwl.31 for ; Thu, 17 Mar 2011 12:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=7jI0BLmVRcFr4zoeFMd6/WUMsTPRYa4q/IpCRlGXTt8=; b=iFB5DKXi0hXbz5Cf5Sc0QWzs0y8dUydfLQtrGj78rDqqtK43hByNbfE25dSw8zT2Zn mlZy9RWxXZCUySWSUPo9BGryg5vpsxcNKMn6LyE8+SPmNgC96sAsSH3KWRbwSohMo3dC Xlp0ojWpOPtgNZ549ey9a9sTykOWkOLs5kIps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=pcIGLgiPOUcl0Dex1p4gKkj/yWhdxUwG6NWwDuB0e/AmgmR0Rcp+gL2ewn6/Q1qN/L gB5ObrKu2/lUyG3Vk36mS1OohZkNYqswcD/+2oVqn0EYlbENuaHRdMddUcUvyCZUqAz5 ibQRIyS14n509aABtbcKZvmzelHIt+SBGbEb8= Received: by 10.42.161.2 with SMTP id r2mr165056icx.330.1300389860523; Thu, 17 Mar 2011 12:24:20 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id u9sm792814ibe.36.2011.03.17.12.24.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2011 12:24:19 -0700 (PDT) Message-ID: <4D825FE1.2030801@gmail.com> Date: Thu, 17 Mar 2011 15:24:17 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF PPP Extensions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Pppext] draft-simpson-isis-ppp-unique-00b 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: Thu, 17 Mar 2011 19:22:54 -0000 Sadly, I wasn't paying attention, and didn't notice there was another IETF meeting coming up. So, they won't let me post this draft today. Here it is anyway for your perusal, just in case anybody is interested! === INTERNET-DRAFT W A Simpson DayDreamer Intended status: Standards Track 17 March 2011 Generation of Unique IS-IS System Identifiers draft-simpson-isis-ppp-unique-00b Abstract The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires unique System Identifiers at the link layer. A common practice has been to use an existing IEEE 802 MAC link-layer address. When no unique MAC address is available, this document specifies automatic generation of identifiers. It is fully interoperable with systems that do not support this extension. Additionally, the extension automatically resolves conflicts between System Identifiers. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months Simpson expires August 17, 2011 [Page i] DRAFT ISIS Unique 17 March 2011 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Terminology . . . . . . . . . . . . . . . . . . . 1 2. Random Generation . . . . . . . . . . . . . . . . . . . 1 2.1 PPP Links . . . . . . . . . . . . . . . . . . . . 2 3. Resolving Conflicts . . . . . . . . . . . . . . . . . . 2 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 3 IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 3 OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 3 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 3 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 4 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 4 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Simpson expires August 17, 2011 [Page ii] DRAFT ISIS Unique 17 March 2011 1. Introduction The System Identifier is 6 octets for OSI end systems, and 7 octets for IS-IS routers or pseudonodes. This identifier is not required to be the Destination or Source of any packet. (See [ISO10589], [RFC1195], and [RFC5342] for further details.) Typically, IS-IS implementations base the identifier on an existing 6 octet Media Access Control (MAC) identifier defined for one of its link-layer interfaces. The 48-bit MAC is composed of a 24-bit Organizationally Unique Identifier (OUI) followed by a 24-bit Network Interface Controller (NIC) specific number. Other systems have a configured identifier that is independent of the interfaces. 1.1. Terminology The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC2119]. 2. Random Generation Some systems have only point-to-point links without any conveniently available MAC, and do not have a configured identifier. This status might change dynamically, as hot swap interfaces are added or removed. In this case, a 48-bit System Identifier MUST be randomly generated. (See [RFC4086] for requirements.) To mitigate against potential assignment conflicts, this System Identifier (considered as a pseudo-MAC) MUST have both the "locally- assigned" and "broadcast/multicast" (group) bits set; that is, the least significant two bits of the most significant octet are equal to 0x3. The probability of conflict is reduced to a birthday attack of the order N/2**23; where N is the number of systems in the same IS-IS area. This is considerably less likely than a duplicate MAC (see below), or operating facility destruction by meteor, or an operator's death by lightning strike. [Schneier] Simpson expires August 17, 2011 [Page 1] DRAFT ISIS Unique 17 March 2011 2.1. PPP Links PPP [RFC1661] links (such as [RFC1377]) already specify negotiation of a 32-bit Magic Number. As currently used in [RFC1663] and [RFC1990], every link in a single system MUST have different Magic Numbers, and each end of every link between two peers SHOULD have Magic Numbers which are unique to those peers. This protects against patch-panel errors in addition to looped-back links. An implementation conforming with this specification MUST ensure this Magic Number is unique for all local interfaces, and also MUST be unique for all negotiated peer interfaces. Whenever a Magic Number has been successfully negotiated, only the most significant 2 octets of a pseudo-OUI are randomly generated. The selected Magic Number is appended after the pseudo-OUI. To mitigate against potential assignment conflicts, this System Identifier (considered as a pseudo-OUI) MUST have both the "locally- assigned" and "broadcast/multicast" (group) bits set; that is, the least significant two bits of the most significant octet are equal to 0x3. The probability of conflict is considerably less than the wholly generated pseudo-MAC (above), as the Magic Number has already been determined to be locally unique. The pseudo-OUI differentiates among such PPP-only systems. 3. Resolving Conflicts Field experience has shown that IEEE 802 MAC addresses are frequently not unique. Companies that manufacture more than 16,777,214 devices will often reuse the same MAC. Also, many companies reuse the same MAC for different product lines, or different speeds or types of media. Some implementations failed to correctly convert the MAC to canonical form [RFC2469], resulting unintentional conflicts through multi-media bridges. If a duplicated MAC is used as a System Identifier within an IS-IS area, this leads to the condition colloquially called "LSR War". Currently, IS-IS has no method to detect or resolve such conflicts. After detecting a conflicting System Identifier in a neighbor, or receiving 3 or more IS-IS Hellos and failing to resolve participation in an area within 30 seconds, an implementation conforming with this specification MUST generate a replacement System Identifier using one of the techniques specified above. Simpson expires August 17, 2011 [Page 2] DRAFT ISIS Unique 17 March 2011 Acknowledgments This document parallels text originally in [RFC2153]. James Carlson, Donald Eastlake, and Dave Katz provided background information and helpful comments. IANA Considerations This document has no IANA actions. [RFC Editor: please remove this section prior to publication.] Operational Considerations Although the probability of conflict with another System Identifier is minuscule, some implementations might not have a sufficient source of randomness, and could repeatedly select conflicting values. An implementation conforming with this specification MUST have an option to statically configure the System Identifier. Default 0 (off). To mitigate against potential assignment conflicts, this System Identifier (considered as a pseudo-MAC) MUST have the "locally- assigned" bit set and "broadcast/multicast" (group) bit clear; that is, the least significant two bits of the most significant octet are equal to 0x2. Security Considerations These mechanisms provide protection against compromised, malfunctioning, or misconfigured systems [RFC4593]; spoofing attacks are thwarted by quickly renegotiating a replacement System Identifier. Never-the-less, [RFC5304] increases protection against maliciously configured conflicting System Identifiers. Simpson expires August 17, 2011 [Page 3] DRAFT ISIS Unique 17 March 2011 Normative References [ISO10589] ISO/IEC 10589:2002, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)" [RFC1195] [RFC1377] [RFC1661] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC4086] Eastlake, D. (3rd), Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, June 2005. Informative References [RFC1663] [RFC1990] [RFC2153] [RFC2469] [RFC4593] [RFC5304] [RFC5342] [Schneier] Simpson expires August 17, 2011 [Page 4] DRAFT ISIS Unique 17 March 2011 Author's Address Questions about this document can be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 William.Allen.Simpson@Gmail.com Simpson expires August 17, 2011 [Page 5] From william.allen.simpson@gmail.com Thu Mar 17 12:29:47 2011 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 E63843A69E0 for ; Thu, 17 Mar 2011 12:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 t5brC+mMjYlR for ; Thu, 17 Mar 2011 12:29:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 029423A6A03 for ; Thu, 17 Mar 2011 12:29:44 -0700 (PDT) Received: by iyi12 with SMTP id 12so3703942iyi.31 for ; Thu, 17 Mar 2011 12:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PKRwGO5RflrZyb96qSu5gfHxm0EYTxV3/z8gn+4ug8M=; b=EwDGD49tkGgXJwiuh7U610jNmj5rWI9MPeRqm57uCmTVzR5iCgW9FPyjQY7BGOkgwC Uq7zEX2oT0PsyCEC5+R6iBeHTx3ObUvC9pg4KcG9+g+sYxsZFPwo1OAgOA6nCzpVdkAZ KM8dn/HRNLPV1R6DTQ7uoSK7J/7foa5DGCMYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=NmRzaIG2uquxNb4r0Cp1jsnfevVldZYkbJ6uTnJ4iS9o6qBfEp+f5O+wp/DRqmN0Jf 2kX919dh3p+4C+yM2GMdTKeazWUoj5nmIM1kb9ust6JoojC6Dth2yosAuT33nVlpHBSi Q5mmruSGMViC6ix/u8tfQDRfQdNm/5rgxMdac= Received: by 10.42.108.9 with SMTP id f9mr214201icp.233.1300390273173; Thu, 17 Mar 2011 12:31:13 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id c4sm1373641ict.7.2011.03.17.12.31.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2011 12:31:09 -0700 (PDT) Message-ID: <4D82617C.6040700@gmail.com> Date: Thu, 17 Mar 2011 15:31:08 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pppext@ietf.org, rbridge@postel.org References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> <4D41D6DC.2040406@workingcode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] [rbridge] proposed TRILL IS-IS System ID text 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: Thu, 17 Mar 2011 19:29:47 -0000 On 2/4/11 8:01 PM, Anoop Ghanwani wrote: > On Thu, Jan 27, 2011 at 12:34 PM, James Carlson > wrote: > >> At a minimum, I want to hear from IS-IS and TRILL experts before I go >> ahead with proposing any new random-number-based System ID mechanism. >> If they sign on, then I'll go ahead with it. >> >> But my off-the-cuff guess is that they'll have objections, and more >> objections probably aren't helpful in getting to consensus. > > Coming from the TRILL part of the world, I don't think this is a problem > that needs to be addressed in this draft. Generating a unique System ID > for IS-IS is an IS-IS problem, and as such should be addressed in the IS-IS > working group. > > Anoop > After some local difficulty, I've posted to the pppext list a separate draft. If somebody points me at another WG list, I'll post it there too. I'd be reasonably content to have the TRILL PPP draft reference my draft for resolution of the issue. Then, it can be discussed as many places as needed. As it is very simple and builds on existing standard's track protocols, I doubt that it's contentious. From william.allen.simpson@gmail.com Sat Mar 26 09:15:33 2011 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 648D03A6783 for ; Sat, 26 Mar 2011 09:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599] 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 Mw4vmN5SM8WT for ; Sat, 26 Mar 2011 09:15:32 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 7B19B3A6405 for ; Sat, 26 Mar 2011 09:15:32 -0700 (PDT) Received: by vxg33 with SMTP id 33so1649165vxg.31 for ; Sat, 26 Mar 2011 09:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2p6Da1KeQZ1Ru4PWRg/4FbD6lcwtMIzVT8ol3vb+jOs=; b=frAQTEjuUcSd2Sw92x0n021qli112yqNdSyouSZfqPxfJzapgKwA+wGHlkg/6438Nh VrspBmws5TgrzvR3QPucBRqBNpD5Ix/3dERcaWHpZvMsgtpL9gNfd7IUhjBQeypBX8pV mQw8Vmdth24V+tD/UcvT3cp4Cuy4uN0NOLr1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KnvzEKvAoGNmTJMn0Of0mEYFpFtiK9qMOFlAPoVj56iWEyuzfl3mnUmcwmgoA/Fw7q Nf5Rt+H9aXX4cKBOvlHqvbZRBineUYXHzB9mzN0zNUHdx1eLSsnf39aAfu/pdDfJ4JO1 eBNDcgcUi6QugW709VssCDcBHhObPz+rj6u5I= Received: by 10.52.94.211 with SMTP id de19mr2743366vdb.59.1301156228146; Sat, 26 Mar 2011 09:17:08 -0700 (PDT) Received: from Wastrel-3.local (d199-74-177-50.col.wideopenwest.com [74.199.50.177]) by mx.google.com with ESMTPS id h18sm1116090vbj.11.2011.03.26.09.17.04 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Mar 2011 09:17:05 -0700 (PDT) Message-ID: <4D8E117F.5060001@gmail.com> Date: Sat, 26 Mar 2011 12:17:03 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: rbridge@postel.org References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> <4D41D6DC.2040406@workingcode.com> <4D82617C.6040700@gmail.com> In-Reply-To: <4D82617C.6040700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org Subject: Re: [Pppext] [rbridge] proposed TRILL IS-IS System ID text 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: Sat, 26 Mar 2011 16:15:33 -0000 On 3/17/11 3:31 PM, William Allen Simpson wrote: > After some local difficulty, I've posted to the pppext list a separate > draft. If somebody points me at another WG list, I'll post it there too. > > I'd be reasonably content to have the TRILL PPP draft reference my draft > for resolution of the issue. Then, it can be discussed as many places > as needed. As it is very simple and builds on existing standard's track > protocols, I doubt that it's contentious. http://www.ietf.org/mail-archive/web/pppext/current/msg00516.html Since the IETF meeting starts tomorrow in Prague, and both TRILL and ISIS meet on Monday, is anybody likely to be there and ask somebody over in the ISIS WG whether they have any interest? I'm planning on taking this directly to RFC via Independent Submission. So far, I've only received 2 private comments. 1) about one reference in the PPP section. I've checked, and that was deprecated in [RFC1990]. So, I'll re-write to reference the earlier decisions and language on the PPP list. Nearly identical language remains in [RFC1663]. 2) the 30 second timeout is too long. That's easy to shorten, and should probably have a random dither to avoid simultaneous changes. How about 9-12 seconds inclusive? It's pretty simple and uncontroversial. But I'd still welcome any word-smithing review! From d3e3e3@gmail.com Sun Mar 27 05:45:50 2011 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 5351C3A67E3 for ; Sun, 27 Mar 2011 05:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.138 X-Spam-Level: X-Spam-Status: No, score=-104.138 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 5kEIRyoVSt8t for ; Sun, 27 Mar 2011 05:45:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 317EF3A67CC for ; Sun, 27 Mar 2011 05:45:49 -0700 (PDT) Received: by wwa36 with SMTP id 36so2095782wwa.13 for ; Sun, 27 Mar 2011 05:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Udo8UXr4er4xQ7SXF5JN9jyqH8LqQcFwormVEYkczYE=; b=XosHAcnBLX1YhFsxICSmkApRvyIzRRbN73fwJFgqVjf9Z0cW9aD3L7Gk9ruoEvwvpK uzRR5+Gx5TwAh3cdCjw9Xnn7FEIB6DBG3aUeoDbLQb07IgPCu+9cqnYL3yKYylcNPdOM b3x1g2jgY9nn0pg8ZiqMa1y/uy2ObQqHdNiBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=JYfkDs/7bHbmzuPhkTbxn1ltyPb0Kk4dKtVl6cfL99eYgos6wMe4dk+qBtHoYhB6n3 vNuYLM5TMQ+52t8W2WBddVQ3IpdID6OsRCdaWJSv5pPzYLfT28ta1X5qlrHqQ8j1CJhv wbsg+BCc749mJrCjny9YkcC1lXJ+yYHrUeI50= Received: by 10.227.197.148 with SMTP id ek20mr2904480wbb.203.1301230045338; Sun, 27 Mar 2011 05:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.55.146 with HTTP; Sun, 27 Mar 2011 05:47:05 -0700 (PDT) In-Reply-To: <4D8E117F.5060001@gmail.com> References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> <4D41D6DC.2040406@workingcode.com> <4D82617C.6040700@gmail.com> <4D8E117F.5060001@gmail.com> From: Donald Eastlake Date: Sun, 27 Mar 2011 08:47:05 -0400 Message-ID: To: William Allen Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rbridge@postel.org, pppext@ietf.org Subject: Re: [Pppext] [rbridge] proposed TRILL IS-IS System ID text 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: Sun, 27 Mar 2011 12:45:50 -0000 Hi Bill, On Sat, Mar 26, 2011 at 12:17 PM, William Allen Simpson wrote: > On 3/17/11 3:31 PM, William Allen Simpson wrote: >> >> After some local difficulty, I've posted to the pppext list a separate >> draft. If somebody points me at another WG list, I'll post it there too. >> >> I'd be reasonably content to have the TRILL PPP draft reference my draft >> for resolution of the issue. Then, it can be discussed as many places >> as needed. As it is very simple and builds on existing standard's track >> protocols, I doubt that it's contentious. > > http://www.ietf.org/mail-archive/web/pppext/current/msg00516.html Well, the ISIS WG mailing list is isis-wg@ietf.org. I suppose, if you want, I could post it there. I am also planning to attend and could probably say something about it. > Since the IETF meeting starts tomorrow in Prague, and both TRILL and ISIS > meet on Monday, is anybody likely to be there and ask somebody over in th= e > ISIS WG whether they have any interest? =A0I'm planning on taking this > directly to RFC via Independent Submission. There will be a brief mention of the draft-ietf-pppext-trill-protocol-02.txt draft, along with other TRILL relevant drafts, during the initial presentation by the chairs. > So far, I've only received 2 private comments. > > =A01) about one reference in the PPP section. =A0I've checked, and that w= as > deprecated in [RFC1990]. =A0So, I'll re-write to reference the earlier > decisions and language on the PPP list. =A0Nearly identical language > remains in [RFC1663]. > > =A02) the 30 second timeout is too long. =A0That's easy to shorten, and > should probably have a random dither to avoid simultaneous changes. > How about 9-12 seconds inclusive? > > It's pretty simple and uncontroversial. =A0But I'd still welcome any > word-smithing review! Thanks, Donald From d3e3e3@gmail.com Tue Mar 29 05:29:55 2011 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 A66A23A6784 for ; Tue, 29 Mar 2011 05:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.17 X-Spam-Level: X-Spam-Status: No, score=-104.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 kmToBwbs-JDk for ; Tue, 29 Mar 2011 05:29:54 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BFC103A6783 for ; Tue, 29 Mar 2011 05:29:53 -0700 (PDT) Received: by wyb29 with SMTP id 29so107893wyb.31 for ; Tue, 29 Mar 2011 05:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=n6/WuIESmzCGvB9jS26sNx54lhGtzj5/lI07OGflOUA=; b=rWKA0JOgrI4Jb90Wtn1r+/1bFc/GAB/SDnld62fUIQSGa1JKHDobCvx3/iBYHqvJ4j RaMuOj4kdgavYn3QxFnswTmxe3lWGNxi29XzBP9mcxRg7ai4A4LnC0WGcN7ziMCbcJuj pBAhBeu35yUVdS25ed2NOTOGayY54Qyf3T9RA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=YmAqfzYoBq6SsUYrQfY9F36OC5EH+Xs+hb0vxPaNHtCsr54L6I4Fahl/bhFlWEN1pr monTHHCADMTCi+LIHkKedNyWSjDMoE/wIQeJn/swkg6miwlp06P35oIs39JScPetBeBG E0v1mIbuDyjRrctgH8DYtQk7mgLl30ANgpn2s= Received: by 10.227.13.135 with SMTP id c7mr4934966wba.111.1301401891254; Tue, 29 Mar 2011 05:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.197.19 with HTTP; Tue, 29 Mar 2011 05:31:11 -0700 (PDT) In-Reply-To: <4D825FE1.2030801@gmail.com> References: <4D825FE1.2030801@gmail.com> From: Donald Eastlake Date: Tue, 29 Mar 2011 14:31:11 +0200 Message-ID: To: William Allen Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PPP Extensions Subject: Re: [Pppext] draft-simpson-isis-ppp-unique-00b 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: Tue, 29 Mar 2011 12:29:55 -0000 Hi, Just a couple little quick comments from my point of view. I mentioned yesterday at the ISIS Working Group meeting that this draft was coming. Thanks, Donald On Thu, Mar 17, 2011 at 8:24 PM, William Allen Simpson wrote: >... > > INTERNET-DRAFT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 W A Simpson > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DayDreamer > Intended status: Standards Track =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 17 March 2011 > > > =A0 =A0 =A0 =A0 =A0 =A0 Generation of Unique IS-IS System Identifiers > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-simpson-isis-ppp-unique-00b > > > Abstract > > =A0 The IS-IS routing protocol (Intermediate System to Intermediate > =A0 System, ISO 10589) requires unique System Identifiers at the link > =A0 layer. =A0A common practice has been to use an existing IEEE 802 MAC > =A0 link-layer address. =A0When no unique MAC address is available, this > =A0 document specifies automatic generation of identifiers. =A0It is full= y > =A0 interoperable with systems that do not support this extension. > > =A0 Additionally, the extension automatically resolves conflicts between > =A0 System Identifiers. > > Copyright Notice > > =A0 Copyright (c) 2011 IETF Trust and the persons identified as the > =A0 document authors. All rights reserved. > > =A0 This document is subject to BCP 78 and the IETF Trust's Legal > =A0 Provisions Relating to IETF Documents > =A0 (http://trustee.ietf.org/license-info) in effect on the date of > =A0 publication of this document. Please review these documents > =A0 carefully, as they describe your rights and restrictions with respect > =A0 to this document. > > =A0 This document may not be modified, and derivative works of it may not > =A0 be created, except to format it for publication as an RFC or to > =A0 translate it into languages other than English. > > Status of this Memo > > =A0 This Internet-Draft is submitted in full conformance with the > =A0 provisions of BCP 78 and BCP 79. > > =A0 Internet-Drafts are working documents of the Internet Engineering > =A0 Task Force (IETF). Note that other groups may also distribute working > =A0 documents as Internet-Drafts. The list of current Internet-Drafts is > =A0 at http://datatracker.ietf.org/drafts/current. > > =A0 Internet-Drafts are draft documents valid for a maximum of six months > > > > Simpson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0expires August 17, 2011 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page i] > DRAFT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ISIS Unique =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 17 March 2011 > > > =A0 and may be updated, replaced, or obsoleted by other documents at any > =A0 time. It is inappropriate to use Internet-Drafts as reference > =A0 material or to cite them other than as "work in progress." > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Table of Contents > > > =A0 =A0 1. =A0 =A0 Introduction . . . . . . . . . . . . . . . . . . . . .= . =A0 1 > =A0 =A0 =A0 =A01.1 =A0 =A0 =A0 Terminology =A0. . . . . . . . . . . . . .= . . . . . =A0 1 > =A0 =A0 2. =A0 =A0 Random Generation =A0. . . . . . . . . . . . . . . . .= . . =A0 1 > =A0 =A0 =A0 =A02.1 =A0 =A0 =A0 PPP Links =A0. . . . . . . . . . . . . . .= . . . . . =A0 2 > =A0 =A0 3. =A0 =A0 Resolving Conflicts =A0. . . . . . . . . . . . . . . .= . . =A0 2 > =A0 =A0 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . = =A0 3 > =A0 =A0 IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . = =A0 3 > =A0 =A0 OPERATIONAL CONSIDERATIONS =A0. . . . . . . . . . . . . . . . . .= =A0 3 > =A0 =A0 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . = =A0 3 > =A0 =A0 NORMATIVE REFERENCES =A0. . . . . . . . . . . . . . . . . . . . .= =A0 4 > =A0 =A0 INFORMATIVE REFERENCES =A0. . . . . . . . . . . . . . . . . . . .= =A0 4 > =A0 =A0 CONTACTS =A0. . . . . . . . . . . . . . . . . . . . . . . . . . .= =A0 5 > >... > > Simpson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0expires August 17, 2011 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 [Page ii] > DRAFT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ISIS Unique =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 17 March 2011 > > > 1. =A0Introduction > > =A0 The System Identifier is 6 octets for OSI end systems, and 7 octets > =A0 for IS-IS routers or pseudonodes. =A0This identifier is not required = to > =A0 be the Destination or Source of any packet. =A0(See [ISO10589], > =A0 [RFC1195], and [RFC5342] for further details.) > > =A0 Typically, IS-IS implementations base the identifier on an existing 6 > =A0 octet Media Access Control (MAC) identifier defined for one of its > =A0 link-layer interfaces. =A0The 48-bit MAC is composed of a 24-bit "... is *usually* composed ..." Also add a reference to [RFC3452]. These days you can get an 36 bit prefix, called an Individual Address Block, which is cheaper than a 24 bit OUI pre-fix. > =A0 Organizationally Unique Identifier (OUI) followed by a 24-bit Network > =A0 Interface Controller (NIC) specific number. > > =A0 Other systems have a configured identifier that is independent of the > =A0 interfaces. > > > 1.1. =A0Terminology > > =A0 The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", > =A0 "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be > =A0 interpreted as described in [RFC2119]. > > > > 2. =A0Random Generation > > =A0 Some systems have only point-to-point links without any conveniently > =A0 available MAC, and do not have a configured identifier. =A0This statu= s > =A0 might change dynamically, as hot swap interfaces are added or > =A0 removed. Suggest "only point-to-point links without any conveniently available MAC" -> "only point-to-point or other links that do not have an associated MAC address" There could be some exotic link that isn't p2p but doesn't use MAC addresse= s. > =A0 In this case, a 48-bit System Identifier MUST be randomly generated. > =A0 (See [RFC4086] for requirements.) > > =A0 To mitigate against potential assignment conflicts, this System > =A0 Identifier (considered as a pseudo-MAC) MUST have both the "locally- > =A0 assigned" and "broadcast/multicast" (group) bits set; that is, the > =A0 least significant two bits of the most significant octet are equal to > =A0 0x3. > > =A0 The probability of conflict is reduced to a birthday attack of the > =A0 order N/2**23; where N is the number of systems in the same IS-IS > =A0 area. =A0This is considerably less likely than a duplicate MAC (see > =A0 below), or operating facility destruction by meteor, or an operator's > =A0 death by lightning strike. =A0[Schneier] > > > > > > Simpson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0expires August 17, 2011 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 1] > DRAFT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ISIS Unique =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 17 March 2011 > > > 2.1. =A0PPP Links > > =A0 PPP [RFC1661] links (such as [RFC1377]) already specify negotiation > =A0 of a 32-bit Magic Number. =A0As currently used in [RFC1663] and > =A0 [RFC1990], every link in a single system MUST have different Magic > =A0 Numbers, and each end of every link between two peers SHOULD have > =A0 Magic Numbers which are unique to those peers. =A0This protects again= st > =A0 patch-panel errors in addition to looped-back links. > > =A0 An implementation conforming with this specification MUST ensure this > =A0 Magic Number is unique for all local interfaces, and also MUST be > =A0 unique for all negotiated peer interfaces. =A0Whenever a Magic Number > =A0 has been successfully negotiated, only the most significant 2 octets > =A0 of a pseudo-OUI are randomly generated. =A0The selected Magic Number = is > =A0 appended after the pseudo-OUI. > > =A0 To mitigate against potential assignment conflicts, this System > =A0 Identifier (considered as a pseudo-OUI) MUST have both the "locally- > =A0 assigned" and "broadcast/multicast" (group) bits set; that is, the > =A0 least significant two bits of the most significant octet are equal to > =A0 0x3. > > =A0 The probability of conflict is considerably less than the wholly > =A0 generated pseudo-MAC (above), as the Magic Number has already been > =A0 determined to be locally unique. =A0The pseudo-OUI differentiates amo= ng > =A0 such PPP-only systems. > > > 3. =A0Resolving Conflicts > > =A0 Field experience has shown that IEEE 802 MAC addresses are frequently > =A0 not unique. =A0Companies that manufacture more than 16,777,214 device= s > =A0 will often reuse the same MAC. > > =A0 Also, many companies reuse the same MAC for different product lines, > =A0 or different speeds or types of media. =A0Some implementations failed > =A0 to correctly convert the MAC to canonical form [RFC2469], resulting > =A0 unintentional conflicts through multi-media bridges. > > =A0 If a duplicated MAC is used as a System Identifier within an IS-IS > =A0 area, this leads to the condition colloquially called "LSR War". > =A0 Currently, IS-IS has no method to detect or resolve such conflicts. > > =A0 After detecting a conflicting System Identifier in a neighbor, or > =A0 receiving 3 or more IS-IS Hellos and failing to resolve participation > =A0 in an area within 30 seconds, an implementation conforming with this > =A0 specification MUST generate a replacement System Identifier using one > =A0 of the techniques specified above. > > > > Simpson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0expires August 17, 2011 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 2] > DRAFT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ISIS Unique =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 17 March 2011 > > > Acknowledgments > > =A0 This document parallels text originally in [RFC2153]. > > =A0 James Carlson, Donald Eastlake, and Dave Katz provided background > =A0 information and helpful comments. > > > IANA Considerations > > =A0 This document has no IANA actions. > > =A0 [RFC Editor: please remove this section prior to publication.] > > > Operational Considerations > > =A0 Although the probability of conflict with another System Identifier > =A0 is minuscule, some implementations might not have a sufficient source > =A0 of randomness, and could repeatedly select conflicting values. =A0An > =A0 implementation conforming with this specification MUST have an option > =A0 to statically configure the System Identifier. =A0Default 0 (off). > > =A0 To mitigate against potential assignment conflicts, this System > =A0 Identifier (considered as a pseudo-MAC) MUST have the "locally- > =A0 assigned" bit set and "broadcast/multicast" (group) bit clear; that > =A0 is, the least significant two bits of the most significant octet are > =A0 equal to 0x2. > > > Security Considerations > > =A0 These mechanisms provide protection against compromised, > =A0 malfunctioning, or misconfigured systems [RFC4593]; spoofing attacks > =A0 are thwarted by quickly renegotiating a replacement System > =A0 Identifier. > > =A0 Never-the-less, [RFC5304] increases protection against maliciously > =A0 configured conflicting System Identifiers. > >... > > Simpson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0expires August 17, 2011 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 3] > DRAFT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ISIS Unique =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 17 March 2011 > > > Normative References > > =A0 [ISO10589] =A0ISO/IEC 10589:2002, "Intermediate system to Intermediat= e > =A0 =A0 =A0 =A0 =A0 =A0 =A0 system routeing information exchange protocol= for use in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 conjunction with the Protocol for providing t= he > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Connectionless-mode Network Service (ISO 8473= )" > > =A0 [RFC1195] > > =A0 [RFC1377] > > =A0 [RFC1661] > > =A0 [RFC2119] =A0 Bradner, S., "Key words for use in RFCs to Indicate > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Requirement Levels", BCP 14, March 1997. > > =A0 [RFC4086] =A0 Eastlake, D. (3rd), Schiller, J., and S. Crocker, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Randomness Requirements for Security", BCP 1= 06, June > =A0 =A0 =A0 =A0 =A0 =A0 =A0 2005. > > > > Informative References > > =A0 [RFC1663] > > =A0 [RFC1990] > > =A0 [RFC2153] > > =A0 [RFC2469] > > =A0 [RFC4593] > > =A0 [RFC5304] > > =A0 [RFC5342] > > =A0 [Schneier] > >... > > Simpson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0expires August 17, 2011 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 4] > DRAFT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ISIS Unique =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 17 March 2011 > > > Author's Address > > =A0 Questions about this document can be directed to: > > =A0 =A0 =A0William Allen Simpson > =A0 =A0 =A0DayDreamer > =A0 =A0 =A0Computer Systems Consulting Services > =A0 =A0 =A01384 Fontaine > =A0 =A0 =A0Madison Heights, Michigan =A048071 > > =A0 =A0 =A0 =A0 =A0William.Allen.Simpson@Gmail.com > >... > > > Simpson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0expires August 17, 2011 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 5] From william.allen.simpson@gmail.com Tue Mar 29 10:46:04 2011 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 DEFE53A6986 for ; Tue, 29 Mar 2011 10:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 RFa5WmmP6gMP for ; Tue, 29 Mar 2011 10:46:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 1816D3A6943 for ; Tue, 29 Mar 2011 10:46:04 -0700 (PDT) Received: by iye19 with SMTP id 19so443421iye.31 for ; Tue, 29 Mar 2011 10:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VaFHCSBgBx6AwSEnjLC6a1EIY2D2b1rz7u7fRZPvYFA=; b=TMRdTJzNBbGM5+EcbMqopfkoyVxjiPb87f/EpTYRxGieOJhPh5zJBA1kaftxcKCK3/ U1uOhQIq3Bn6i6LKCJTfIXVLHre4v6VkyzSqL96Z67g/W9wSxM3zpo6cHOjCoz6RZzYe b9r/4WYk/5Uo9ALTIQIUSaMYRx2uo9NnXKN/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=glRQTHUINENYFxYfYlOFyg6Dh+0tlUlKWzBRX/JoOCNd3U6JOYopQpRH4teZkB2GVG UfVr5+0naERNVLlxPMFvCy7DENKnH51sEomTfD/oZ3bnMRkgNjW7RaQ+SOsgnYlkt1EF OitJjuq5kYoaxrLgwgl9E6X4D6nbk5wkSkHUk= Received: by 10.231.65.68 with SMTP id h4mr154932ibi.36.1301420861227; Tue, 29 Mar 2011 10:47:41 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id c1sm3788180ibe.32.2011.03.29.10.47.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 10:47:39 -0700 (PDT) Message-ID: <4D921B39.2090706@gmail.com> Date: Tue, 29 Mar 2011 13:47:37 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF PPP Extensions References: <4D825FE1.2030801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] draft-simpson-isis-ppp-unique-00b 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: Tue, 29 Mar 2011 17:46:05 -0000 On 3/29/11 8:31 AM, Donald Eastlake wrote: > I mentioned yesterday at the ISIS Working Group meeting that this > draft was coming. > Tried listening, but missed the first 40 minutes as I'd thought it was UTC+1 -- it was UTC+2. >> Typically, IS-IS implementations base the identifier on an existing 6 >> octet Media Access Control (MAC) identifier defined for one of its >> link-layer interfaces. The 48-bit MAC is composed of a 24-bit > > "... is *usually* composed ..." > Also add a reference to [RFC3452]. > "FEC Building Block"? Obsoleted by: 5052, 5445? > These days you can get an 36 bit prefix, called an Individual Address > Block, which is cheaper than a 24 bit OUI pre-fix. > OK. >> Some systems have only point-to-point links without any conveniently >> available MAC, and do not have a configured identifier. This status >> might change dynamically, as hot swap interfaces are added or >> removed. > > Suggest "only point-to-point links without any conveniently available > MAC" -> "only point-to-point or other links that do not have an > associated MAC address" > > There could be some exotic link that isn't p2p but doesn't use MAC addresses. > OK. From d3e3e3@gmail.com Tue Mar 29 15:05:13 2011 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 B9B973A6ACC for ; Tue, 29 Mar 2011 15:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.157 X-Spam-Level: X-Spam-Status: No, score=-104.157 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 aJV51fv9b4yf for ; Tue, 29 Mar 2011 15:05:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 949713A6825 for ; Tue, 29 Mar 2011 15:05:12 -0700 (PDT) Received: by wyb29 with SMTP id 29so626482wyb.31 for ; Tue, 29 Mar 2011 15:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=xKdk0MTyGzWxApifua+DlempRpuPiiFyqLpVmkEFlPk=; b=tLiEfPGrSHpr+3pebo5BMMIIC8/q05xQ6mKcmsy4YbQfZ7g/xhG4pTeOgIw4wCYYbF tAQ2LKTjf0C7pX0Of5FbxUpnnyS9wHOVw25dWl9MnTrTvt6X+lufrK8W11J6LQjcKX3x wl7qntw6wIAQQ/bQj4kyoyfvtvDRA7jI/UYL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=IJbEjbH+0CdnV/EA6AWAPr3sNEDMwURvrxqDeZr4PQs3b9GjTXom/udURKmJMtVJGh 4m7xBhVYqcgd/PDehkB+0/jdsbgaq4igpVJVdGm8xO6HYY0RBk8IZClorELd2NP5+ivT tuXGXtdUQ5x4R5QBvIt6woF4TU3zRYK5u9qvs= Received: by 10.227.131.23 with SMTP id v23mr388473wbs.53.1301436410140; Tue, 29 Mar 2011 15:06:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.197.19 with HTTP; Tue, 29 Mar 2011 15:06:30 -0700 (PDT) In-Reply-To: <4D921B39.2090706@gmail.com> References: <4D825FE1.2030801@gmail.com> <4D921B39.2090706@gmail.com> From: Donald Eastlake Date: Wed, 30 Mar 2011 00:06:30 +0200 Message-ID: To: William Allen Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PPP Extensions Subject: Re: [Pppext] draft-simpson-isis-ppp-unique-00b 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: Tue, 29 Mar 2011 22:05:13 -0000 Hi, On Tue, Mar 29, 2011 at 7:47 PM, William Allen Simpson wrote: > On 3/29/11 8:31 AM, Donald Eastlake wrote: >> >> I mentioned yesterday at the ISIS Working Group meeting that this >> draft was coming. >> > Tried listening, but missed the first 40 minutes as I'd thought it was > UTC+1 -- it was UTC+2. It wasn't that exciting. I just told people to keep an eye out for our draft and explained in about four sentences what its goal was. >>> =A0 Typically, IS-IS implementations base the identifier on an existing= 6 >>> =A0 octet Media Access Control (MAC) identifier defined for one of its >>> =A0 link-layer interfaces. =A0The 48-bit MAC is composed of a 24-bit >> >> "... is *usually* composed ..." >> Also add a reference to [RFC3452]. >> > "FEC Building Block"? =A0Obsoleted by: 5052, 5445? :-) Sorry, that's 5342. I got the right digits, just in a random order.... It has a definition of Individual Address Blocks. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com >> These days you can get an 36 bit prefix, called an Individual Address >> Block, which is cheaper than a 24 bit OUI pre-fix. >> > OK. > > >>> =A0 Some systems have only point-to-point links without any convenientl= y >>> =A0 available MAC, and do not have a configured identifier. =A0This sta= tus >>> =A0 might change dynamically, as hot swap interfaces are added or >>> =A0 removed. >> >> Suggest "only point-to-point links without any conveniently available >> MAC" -> =A0"only point-to-point or other links that do not have an >> associated MAC address" >> >> There could be some exotic link that isn't p2p but doesn't use MAC >> addresses. >> > OK. > > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext > From william.allen.simpson@gmail.com Tue Mar 29 19:29:43 2011 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 D0DA43A6834 for ; Tue, 29 Mar 2011 19:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gFOfr8Y9rEnm for ; Tue, 29 Mar 2011 19:29:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E86013A6765 for ; Tue, 29 Mar 2011 19:29:42 -0700 (PDT) Received: by iye19 with SMTP id 19so864587iye.31 for ; Tue, 29 Mar 2011 19:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dkzQ7eq+ugZovWzwaC80sJOcY6H7/uYmzTVsUBRgBNc=; b=QXgSZ506bfNN+W2d+8m5NuGNajAzMzKfHobojLrjSvJ1v13Oum03yBK0040xpKiKmh U+Ui11clWL2ZNUbpL9hQfrFSWrfj+iWxo4wyZOVQl9DENf838kDqaRAAR0Cefm2qDtDY Ka+iyBr0QOIz6LyvqxrkWh56SweNp3KTt5n0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=O6L92LIM+P0CbFldn/x8qDlNF1euJgGeXFVY8TFOCHlNkJ5h4xqf5cXfEjMXPVqkS/ Ctw/hebDtiMkMKt4JZ+OHW1uyiexL37/SSJOBBDbMIpYZ7y9PmmrFxzKMBXyOWROQ7YV /iuXZncufEoduTMlX96rtjwu2gwZxFNpOq/jc= Received: by 10.43.70.2 with SMTP id ye2mr447572icb.345.1301452281264; Tue, 29 Mar 2011 19:31:21 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id wo15sm3719835icb.4.2011.03.29.19.31.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 19:31:20 -0700 (PDT) Message-ID: <4D9295F6.5040401@gmail.com> Date: Tue, 29 Mar 2011 22:31:18 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF PPP Extensions References: <4D825FE1.2030801@gmail.com> <4D921B39.2090706@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] draft-simpson-isis-ppp-unique-00b 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: Wed, 30 Mar 2011 02:29:44 -0000 On 3/29/11 6:06 PM, Donald Eastlake wrote: > On Tue, Mar 29, 2011 at 7:47 PM, William Allen Simpson > wrote: >>>> Typically, IS-IS implementations base the identifier on an existing 6 >>>> octet Media Access Control (MAC) identifier defined for one of its >>>> link-layer interfaces. The 48-bit MAC is composed of a 24-bit >>> >>> "... is *usually* composed ..." >>> Also add a reference to [RFC3452]. >>> >> "FEC Building Block"? Obsoleted by: 5052, 5445? > > :-) Sorry, that's 5342. I got the right digits, just in a random > order.... It has a definition of Individual Address Blocks. > That was already referenced. I've noticed a serious error in it, but that will be the topic of another message someday. From william.allen.simpson@gmail.com Tue Mar 29 19:47:41 2011 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 A11233A6840 for ; Tue, 29 Mar 2011 19:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 GmAAEpiYza04 for ; Tue, 29 Mar 2011 19:47:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 952053A6834 for ; Tue, 29 Mar 2011 19:47:39 -0700 (PDT) Received: by iwn39 with SMTP id 39so882297iwn.31 for ; Tue, 29 Mar 2011 19:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=495qL7jgUGks2tPVm11PtWzPnP9PNF85YdrutRmeFGQ=; b=oHo6OTsIp+JNvWbJo1U4xlCe3rKmKbh2NcozgwgCa+meRu66y9fconZAMP/g5iWppV zOSjuX7OtwDlk61Hvab/qyQga2NbUKjljfIW8WuNcY2yiEhtbP74ZjBUxkqL4Cp2LvGP Yanrje4NVuuMz3BpshGkoWJVOwf2nJW14t2jQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=dIBWj9ggyLhIEm8dDGCixDcY4rPgxEJQfqzqtsRfJfbGJqpZtz5Adc//VM+rvzZyP8 FbvH8yi0QUd89563Lr+NWHvQJ8V/dovm4cuanis/7HuOSSZLZhRngliPoZLsHlCj8uE0 wFneRlBckr3foM57Ij+AQ9WmtP2SHWXaTBNbA= Received: by 10.42.131.72 with SMTP id y8mr403606ics.283.1301453356466; Tue, 29 Mar 2011 19:49:16 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id uk4sm3727826icb.9.2011.03.29.19.49.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 19:49:15 -0700 (PDT) Message-ID: <4D929A29.5040903@gmail.com> Date: Tue, 29 Mar 2011 22:49:13 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF PPP Extensions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Pppext] draft-simpson-isis-ppp-unique-00c 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: Wed, 30 Mar 2011 02:47:41 -0000 Includes changes discussed, with changebars. The internet-draft (sans c) does not include the changebars. === INTERNET-DRAFT W A Simpson DayDreamer Intended status: Standards Track 29 March 2011 Generation of Unique IS-IS System Identifiers | draft-simpson-isis-ppp-unique-00c | Abstract The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires unique System Identifiers at the link layer. A common practice has been to use an existing IEEE 802 MAC | link-layer interface identifier. When no unique MAC is available, this document specifies automatic generation of identifiers. It is fully interoperable with systems that do not support this extension. Additionally, the extension automatically resolves conflicts between System Identifiers. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months Simpson expires August 29, 2011 [Page i] DRAFT ISIS Unique 29 March 2011 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Terminology . . . . . . . . . . . . . . . . . . . 1 2. Random Generation . . . . . . . . . . . . . . . . . . . 1 2.1 PPP Links . . . . . . . . . . . . . . . . . . . . 2 3. Resolving Conflicts . . . . . . . . . . . . . . . . . . 2 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 3 IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 3 OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 4 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 4 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 5 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 5 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Simpson expires August 29, 2011 [Page ii] DRAFT ISIS Unique 29 March 2011 1. Introduction The System Identifier is 6 octets for OSI end systems, and 7 octets for IS-IS routers or pseudonodes. This identifier is not required to be the Destination or Source of any packet. (See [ISO10589], [RFC1195], and [RFC5342] for further details.) Typically, IS-IS implementations base the identifier on an existing | Media Access Control (MAC) link-layer interface identifier. The | 48-bit MAC is usually composed of a 24-bit Organizationally Unique | Identifier (OUI) followed by a 24-bit Network Interface Controller | (NIC) specific number. Other systems have a configured identifier that is independent of the interfaces. 1.1. Terminology The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC2119]. 2. Random Generation Some systems have only point-to-point or other links without any | conveniently available MAC, and do not have a configured identifier. This status might change dynamically, as hot swap interfaces are added or removed. In this case, a 48-bit System Identifier MUST be randomly generated. (See [RFC4086] for requirements.) To mitigate against potential assignment conflicts, this System Identifier (considered as a pseudo-MAC) MUST have both the "locally- assigned" and "broadcast/multicast" (group) bits set; that is, the least significant two bits of the most significant octet are equal to 0x3. The probability of conflict is reduced to a birthday attack of the order N/2**23; where N is the number of systems in the same IS-IS area. This is considerably less likely than a duplicate MAC (see below), or operating facility destruction by meteor, or an operator's death by lightning strike. [Schneier] Simpson expires August 29, 2011 [Page 1] DRAFT ISIS Unique 29 March 2011 2.1. PPP Links PPP [RFC1661] links (such as [RFC1377]) already specify negotiation | of a unique 32-bit Magic Number. Although only a single interface | negotiation is described in the base document, it has long been | understood [RFC1220] [Simpson1992] [Baker1992] that the term "unique" | applies across all local system interfaces. This protects against | patch-panel errors in addition to looped-back modems, to detect | unexpected loopbacks of a link from an endpoint to itself. | [Simpson1993] [RFC1663] [RFC1717] An implementation conforming with this specification MUST have | different Magic Numbers for every link in a single system, and each | end of every link between two peers MUST have Magic Numbers which are | unique to those peers. That is, the Magic Number MUST be unique for | all visible interfaces. | Whenever such a Magic Number has been successfully negotiated, only the most significant 2 octets of a pseudo-OUI are randomly generated. The selected Magic Number is appended after the pseudo-OUI. To mitigate against potential assignment conflicts, this System Identifier (considered as a pseudo-OUI) MUST have both the "locally- assigned" and "broadcast/multicast" (group) bits set; that is, the least significant two bits of the most significant octet are equal to 0x3. The probability of conflict is considerably less than the wholly generated pseudo-MAC (above), as the Magic Number has already been determined to be locally unique. The pseudo-OUI differentiates among such PPP-only systems. 3. Resolving Conflicts Field experience has shown that IEEE 802 MAC identifiers are | frequently not unique. Companies that manufacture more than 16,777,214 devices will often reuse the same MAC. Also, many companies reuse the same MAC for different product lines, or different speeds or types of media. Some implementations failed to correctly convert the MAC to canonical form [RFC2469], resulting unintentional conflicts through multi-media bridges. If a duplicated MAC is used as a System Identifier within an IS-IS area, this leads to the condition colloquially called "LSR War". Currently, IS-IS has no method to detect or resolve such conflicts. Simpson expires August 29, 2011 [Page 2] DRAFT ISIS Unique 29 March 2011 After detecting a conflicting System Identifier in a neighbor, or receiving 3 or more IS-IS Hellos and failing to resolve participation | in an area within 10 seconds, an implementation conforming with this specification MUST generate a replacement System Identifier using one of the techniques specified above. + The system SHOULD delay generation and transmission of this + replacement System Identifier for a random amount of time between 0 + and MAX_GENERATION_DELAY. Although the randomization range is + specified in units of seconds, the actual randomly-chosen value + SHOULD NOT be in units of whole seconds, but rather in units of the + highest available timer resolution. + This reduces the probability of synchronization with advertisements + from other systems in the same IS-IS area. If a message is received + during the delay indicating the conflict was resolved by another + system, the existing local System Identifier remains unchanged. Acknowledgments This document parallels text originally in [RFC2153] and various | other drafts. James Carlson, Donald Eastlake, and Dave Katz provided background information and helpful comments. IANA Considerations This document has no IANA actions. [RFC Editor: please remove this section prior to publication.] Simpson expires August 29, 2011 [Page 3] DRAFT ISIS Unique 29 March 2011 Operational Considerations MAX_GENERATION_DELAY + Default: 1 second. This is based on an anticipated IS-IS Hello + interval of no more than 4 seconds. + When Hellos are sent at a greater time interval, this MUST NOT be + greater than interval/2, and SHOULD NOT be greater than + interval/4. + Configurable System Identifier + Default 0 (off). Although the probability of conflict with another System Identifier is minuscule, some implementations might not have a sufficient source of randomness, and could repeatedly select conflicting values. An implementation conforming with this specification MUST have an option to statically configure the System Identifier. To mitigate against potential assignment conflicts, this System Identifier (considered as a pseudo-MAC) MUST have the "locally- assigned" bit set and "broadcast/multicast" (group) bit clear; that is, the least significant two bits of the most significant octet are equal to 0x2. + Security Considerations These mechanisms provide protection against compromised, malfunctioning, or misconfigured systems [RFC4593]; spoofing attacks are thwarted by quickly renegotiating a replacement System Identifier. Never-the-less, [RFC5304] increases protection against maliciously configured conflicting System Identifiers. Simpson expires August 29, 2011 [Page 4] DRAFT ISIS Unique 29 March 2011 Normative References [ISO10589] ISO/IEC 10589:2002, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)" [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and + dual environments", December 1990. [RFC1377] Katz, D., "The PPP OSI Network Layer Control Protocol + (OSINLCP)", November 1992. [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", + STD 51, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC4086] Eastlake, D. (3rd), Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, June 2005. Informative References [Baker1992] Baker, F., "PPP Reliable and Multi-Link Transmission", + Message to PPP Compression List, June 29, 1992. Message- + Id: <9206292135.AA00620@saffron.acc.com> + [RFC1220] Baker, F., "Point-to-Point Protocol extensions for + bridging", April 1991. [RFC1663] Rand, D., "PPP Reliable Transmission", July 1994. | [RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The | PPP Multilink Protocol (MP)", November 1994. [RFC2153] Simpson, W., "PPP Vendor Extensions", May 1997. + [RFC2469] Narten, T., and C. Burton, "A Caution On The Canonical + Ordering Of Link-Layer Addresses", December 1998. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to + Routing Protocols", October 2006. Simpson expires August 29, 2011 [Page 5] DRAFT ISIS Unique 29 March 2011 [RFC5304] Li, T., and R. Atkinson, "IS-IS Cryptographic + Authentication", October 2008. [RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol + Usage for IEEE 802 Parameters", BCP 141, September 2008. [Schneier] Schneier, B., "Applied Cryptography", John Wiley & Sons, + 1996. ISBN 0-471-11709-9. + [Simpson1992] + Simpson, W., "where are we?", Message to IESG and others, + April 17, 1992. Message-Id: + <269.bsimpson@vela.acs.oakland.edu> + [Simpson1993] + Simpson, W., "Re: Simple Multilink Proceedure for PPP - + the document", Message to ietf-ppp and iplpdn mailing + lists, February 21, 1993. Message-Id: + <988.bill.simpson@um.cc.umich.edu> Author's Address Questions about this document can be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 William.Allen.Simpson@Gmail.com Simpson expires August 29, 2011 [Page 6] From william.allen.simpson@gmail.com Tue Mar 29 20:37:54 2011 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 970DA3A6996 for ; Tue, 29 Mar 2011 20:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6iUp2bjSSMRm for ; Tue, 29 Mar 2011 20:37:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id BA9063A6994 for ; Tue, 29 Mar 2011 20:37:53 -0700 (PDT) Received: by iye19 with SMTP id 19so914241iye.31 for ; Tue, 29 Mar 2011 20:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=C5BF7fU/PbdNBCiSy3rq0wiyZWyfSvhEhYLnKVRA7Yw=; b=BOxt8dv3V+QGT/3n9ldkUzJlEcZIiRqHvoh0QyCTIM2HC/svfHRa1HcONAHGjjnQvY 5tMRSEBG8Y45LDsL4B6tS5WF7qvICiPJXTTsNFsT5Oz05dSGIjgL86fhlUbXQY0cKq1K R+GjnoJTlF5k/I5JIb9AJDrfBpbeqYB2cutvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=mzk+/s4qcNBRc4sMKMGbtlip/gWP/S4Dz1d10K+wLn9UG4lMY0pyvFbLZf/a/XUN1t zRbtPBOhkyZ8vcZFGXG7abxS45600MGMwXLxaAZdEdrstjLGWV1QAQjUxeNc9eoOir+P MAbRXNfkLowwzsQ3OmwvTGO+F126BMwTld0NE= Received: by 10.231.193.68 with SMTP id dt4mr703754ibb.123.1301456371045; Tue, 29 Mar 2011 20:39:31 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id 19sm4064313ibx.18.2011.03.29.20.39.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 20:39:30 -0700 (PDT) Message-ID: <4D92A5F0.4070108@gmail.com> Date: Tue, 29 Mar 2011 23:39:28 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF PPP Extensions References: <4D929A29.5040903@gmail.com> In-Reply-To: <4D929A29.5040903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] draft-simpson-isis-ppp-unique-00c 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: Wed, 30 Mar 2011 03:37:54 -0000 On 3/29/11 10:49 PM, William Allen Simpson wrote: > Includes changes discussed, with changebars. The internet-draft (sans c) > does not include the changebars. > http://tools.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-00.txt The draft has been officially announced, and my request sent to the RFC-Editor for Independent Submissions to publish as a Proposed Standard. From d3e3e3@gmail.com Tue Mar 29 22:53:35 2011 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 B68C33A680E for ; Tue, 29 Mar 2011 22:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.145 X-Spam-Level: X-Spam-Status: No, score=-104.145 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 M5yC421GCwxc for ; Tue, 29 Mar 2011 22:53:31 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3C5753A6ADA for ; Tue, 29 Mar 2011 22:53:28 -0700 (PDT) Received: by wwa36 with SMTP id 36so753253wwa.13 for ; Tue, 29 Mar 2011 22:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=nx/IFCMI1MwdGeSET1h2SUP0GfpbHgaFaf6qM8GHM9Q=; b=uDQAaf79L6NAI4UK8Myu1e+6k2lFKwHNGhJd61H8PbXOl5mcCmRieqhJKYTwpEg5A0 DrIhVAViYwapA7NZcTpX1wfHu3MsBeu09tOeb64fNK2ckbuaZMMHIXGkuPzKewn2EgfX +DRmmBglM7JW88z6exY0j2M/IlxpteVU5kHqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=QjX4ubAlA3sYSIgrT/y+twGwqeiDPbZcwQf+75lOYvcWoBtmStwGXJR65L4pWYUEwY olc68OvxDpRTZDLIYBKEuJZN2yXb1uKJ/14o0eyNZoPXJeDy1c5UZSRJXeCCQgxs/ND5 MpSbSn0lgI6ENI3Fk6WnHoNa6TfpphkzUIQS8= Received: by 10.227.202.139 with SMTP id fe11mr729486wbb.169.1301464498130; Tue, 29 Mar 2011 22:54:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.197.19 with HTTP; Tue, 29 Mar 2011 22:54:38 -0700 (PDT) In-Reply-To: <4D9295F6.5040401@gmail.com> References: <4D825FE1.2030801@gmail.com> <4D921B39.2090706@gmail.com> <4D9295F6.5040401@gmail.com> From: Donald Eastlake Date: Wed, 30 Mar 2011 07:54:38 +0200 Message-ID: To: William Allen Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PPP Extensions Subject: Re: [Pppext] draft-simpson-isis-ppp-unique-00b 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: Wed, 30 Mar 2011 05:53:35 -0000 Hi Bill, On Wed, Mar 30, 2011 at 4:31 AM, William Allen Simpson wrote: > On 3/29/11 6:06 PM, Donald Eastlake wrote: >> >> On Tue, Mar 29, 2011 at 7:47 PM, William Allen Simpson >> =A0wrote: >>>>> >>>>> =A0 Typically, IS-IS implementations base the identifier on an existi= ng 6 >>>>> =A0 octet Media Access Control (MAC) identifier defined for one of it= s >>>>> =A0 link-layer interfaces. =A0The 48-bit MAC is composed of a 24-bit >>>> >>>> "... is *usually* composed ..." >>>> Also add a reference to [RFC3452]. >>>> >>> "FEC Building Block"? =A0Obsoleted by: 5052, 5445? >> >> :-) =A0Sorry, that's 5342. I got the right digits, just in a random >> order.... It has a definition of Individual Address Blocks. >> > That was already referenced. =A0I've noticed a serious error in it, but t= hat > will be the topic of another message someday. Well, it isn't a big deal whether there is a reference to RFC 5342 here but I also don't see it as a problem for something to be referenced at more than one place in a draft. Up to you. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From william.allen.simpson@gmail.com Wed Mar 30 05:22:34 2011 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 A58553A6947 for ; Wed, 30 Mar 2011 05:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Qc3l5aLMP23D for ; Wed, 30 Mar 2011 05:22:32 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id B0A3728C165 for ; Wed, 30 Mar 2011 05:22:28 -0700 (PDT) Received: by iye19 with SMTP id 19so1391040iye.31 for ; Wed, 30 Mar 2011 05:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HH1UL8aJnm81Ar0nSAjguaA2dZXDV3kW7tddUXuFC38=; b=H6MsG7fOj1y3AOmTpOvrJgbsOeK2HFy5bMF6BCBu9lCWGmq1m0C/XabNqCnxVjBP86 Sx7Auhy5+MIuPrVUU2xHw5RmJCX/UBZS1/MJznxecg9+ba3eiNpeqrIsJ+Va60YV11US HQtkUXKbJs8pT/lnPzGxYfb5Iz4JM4JrxZfVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=U2M753P9oQlDXiy/BPo1qLzZ+JtoT9txBfas6XtfNI8hwvzVvCGE63d0TiSA142qRH N1Xcd0JXZ3F7nB/s6Cls/Db2WLsFmei2dMRKdZmKNt4EJU+EpKCERYinP1A9bSa6TNcy e/6vpR9iJ1lqu3NyzEO1knqz0JiGhVHzNODrI= Received: by 10.43.53.134 with SMTP id vq6mr1114263icb.263.1301487840442; Wed, 30 Mar 2011 05:24:00 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id wo11sm18246icb.8.2011.03.30.05.23.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 05:23:59 -0700 (PDT) Message-ID: <4D9320DD.9010507@gmail.com> Date: Wed, 30 Mar 2011 08:23:57 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF PPP Extensions References: <4D825FE1.2030801@gmail.com> <4D921B39.2090706@gmail.com> <4D9295F6.5040401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] draft-simpson-isis-ppp-unique-00b 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: Wed, 30 Mar 2011 12:22:34 -0000 On 3/30/11 1:54 AM, Donald Eastlake wrote: > On Wed, Mar 30, 2011 at 4:31 AM, William Allen Simpson > wrote: >> On 3/29/11 6:06 PM, Donald Eastlake wrote: >>> :-) Sorry, that's 5342. I got the right digits, just in a random >>> order.... It has a definition of Individual Address Blocks. >>> >> That was already referenced. I've noticed a serious error in it, but that >> will be the topic of another message someday. > > Well, it isn't a big deal whether there is a reference to RFC 5342 > here but I also don't see it as a problem for something to be > referenced at more than one place in a draft. Up to you. > Chuckle. The existing reference is in the final sentence of the preceding paragraph. That's a bit closer than one would use a second reference. You may have missed it because you accidentally remembered the wrong number: ... (See [ISO10589], [RFC1195], and [RFC5342] for further details.) Typically, IS-IS implementations base the identifier on an existing | Media Access Control (MAC) link-layer interface identifier. The | 48-bit MAC is usually composed of a 24-bit Organizationally Unique | Identifier (OUI) followed by a 24-bit Network Interface Controller | (NIC) specific number. From Internet-Drafts@ietf.org Wed Mar 30 12:45:04 2011 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 45A573A6BBE; Wed, 30 Mar 2011 12:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 76Hi0xftjeNv; Wed, 30 Mar 2011 12:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510393A6A7F; Wed, 30 Mar 2011 12:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110330194502.10758.85300.idtracker@localhost> Date: Wed, 30 Mar 2011 12:45:02 -0700 Cc: pppext@ietf.org Subject: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-03.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: Wed, 30 Mar 2011 19:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : J. Carlson Filename : draft-ietf-pppext-trill-protocol-03.txt Pages : 6 Date : 2011-03-30 The Point-to-Point Protocol (PPP) [1] defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pppext-trill-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-30123316.I-D@ietf.org> --NextPart-- From carlsonj@workingcode.com Wed Mar 30 13:16:28 2011 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 C14923A6BC5 for ; Wed, 30 Mar 2011 13:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Mx8HRZL+2h7q for ; Wed, 30 Mar 2011 13:16:28 -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 C97A73A69AB for ; Wed, 30 Mar 2011 13:16:26 -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 p2UKI1SN002109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Mar 2011 16:18:02 -0400 (EDT) Message-ID: <4D938FF9.7060607@workingcode.com> Date: Wed, 30 Mar 2011 16:18:01 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: PPP Extensions References: <20110330194502.10758.85300.idtracker@localhost> In-Reply-To: <20110330194502.10758.85300.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Subject: Re: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-03.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: Wed, 30 Mar 2011 20:16:28 -0000 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > > Title : PPP TRILL Protocol Control Protocol > Author(s) : J. Carlson > Filename : draft-ietf-pppext-trill-protocol-03.txt > Pages : 6 > Date : 2011-03-30 For reference, here are the substantive changes made in the document since the -02 draft: 245,249c245,247 < can form an IS-IS System ID. Resolving that issue is an < implementation-dependent matter, but it is expected that, if at < all possible, some means of minimizing the need for < administrative configuration SHOULD be considered in order to < accomplish the RBridge goal of zero configuration. --- > can form an IS-IS System ID. Resolving that issue is outside the > scope of this document, but see [8] for one mechanism that should > be considered in this situation. > INTERNET-DRAFT The PPP TRILL Protocol Control Protocol March 2011 314a315,316 > [8] W. Simpson, "Generation of Unique IS-IS System Identifiers," > work in progress, March 2011 318,319c321,322 < The author thanks Donald Eastlake, Linda Dunbar, and Radia Perlman < and for their comments and help. --- > The author thanks Linda Dunbar, Donald Eastlake, Radia Perlman and > William A. Simpson for their comments and help. -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Thu Mar 31 07:45:30 2011 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 11D623A6B10 for ; Thu, 31 Mar 2011 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 aPZqaD+4P5wG for ; Thu, 31 Mar 2011 07:45:29 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4E6D33A6B38 for ; Thu, 31 Mar 2011 07:45:29 -0700 (PDT) Received: by iwn39 with SMTP id 39so2857218iwn.31 for ; Thu, 31 Mar 2011 07:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fq/e3TDjJqcCGY/Xp8TstADRZDmPMlUMsBAltowBWBk=; b=pCbRLVXEeP+w8vaLKLj/yhtAQHXHOLzrka+oEy6Ko5yBJQZKqfYfaDzqxKz+WkpaWg ufAky9bcuMw+nNi2tycM7jsdxNx9Q+V3MOZ4C7ikXh74vSSWL5J6U+vkXwa5MjoSL2VJ EugXsG2SeU3RUHMeiguHEEByDAMTHaIle731o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ML6KjcSP1tbVTDp9OIxL/bSgDynCpxVX7V6Mq+iK06J7BR0qwu3yol1psVZxOZUJf8 UMEHC3nr0uj8ShiGdCVxG/IxxFDgM7hEnbTfyP7At4XMYtJDzuqhD3eH/FIfEt34YzTL cq6P/XQ/EALIsaPMRoJ13mCU/IKgcaGqQB518= Received: by 10.42.132.67 with SMTP id c3mr3060084ict.520.1301582828954; Thu, 31 Mar 2011 07:47:08 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id jv9sm677656icb.1.2011.03.31.07.47.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 07:47:07 -0700 (PDT) Message-ID: <4D9493E9.9050903@gmail.com> Date: Thu, 31 Mar 2011 10:47:05 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pppext@ietf.org References: <20110330194502.10758.85300.idtracker@localhost> <4D938FF9.7060607@workingcode.com> In-Reply-To: <4D938FF9.7060607@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-03.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: Thu, 31 Mar 2011 14:45:30 -0000 Seems better to me! Although, I'd thought my draft would be normative, rather than informative. And there should probably be references to the appropriate RFCs in the security section, too. But those can be added by the RFC Editor. From carlsonj@workingcode.com Thu Mar 31 08:36:28 2011 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 3106A3A694C for ; Thu, 31 Mar 2011 08:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 mtyC-t69LVb0 for ; Thu, 31 Mar 2011 08:36:24 -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 1478B3A6844 for ; Thu, 31 Mar 2011 08:36:23 -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 p2VFbxDh018270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2011 11:38:00 -0400 (EDT) Message-ID: <4D949FD7.7000203@workingcode.com> Date: Thu, 31 Mar 2011 11:37:59 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: William Allen Simpson References: <20110330194502.10758.85300.idtracker@localhost> <4D938FF9.7060607@workingcode.com> <4D9493E9.9050903@gmail.com> In-Reply-To: <4D9493E9.9050903@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-03.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: Thu, 31 Mar 2011 15:36:28 -0000 William Allen Simpson wrote: > Seems better to me! Although, I'd thought my draft would be normative, > rather than informative. I don't believe it is, for the same reason that I don't believe that the original issue raised was actually in scope of the draft I'd written. The issue you've raised and that you're dealing with in your draft is an overall system design issue, and particularly a _potential_ problem with IS-IS -- depending entirely on the system environment. It's not something that someone working on a PPP link for TRILL needs to worry about. It's not related to negotiation or carriage of data; nothing about a PPP TRILL link. It *is* something that someone designing the IS-IS part of the system should worry about, because he has to get that System ID value. So I believe that an informative reference is _more_ than sufficient. Frankly, I would prefer to say nothing at all about the issue, because it's really outside the scope of this draft to explain or otherwise account for IS-IS implementation details. Particularly ones that may well change over time. > And there should probably be references to the > appropriate RFCs in the security section, too. But those can be added by > the RFC Editor. Adding a new NCP normally adds no additional security issues beyond the usual "authenticate your links and/or encrypt traffic if the situation warrants." Is that what you're referring to? If not, then please provide more detailed references for what is "appropriate" here, and I'll add them if they're reasonably in scope. (In other words, there's no way I'm going to add any documentation about IS-IS security issues. That's *way* out of scope, and I'm simply guaranteed to get it wrong. If not now, then certainly over time. But references to RFC 1994 or 1968 or some such would be OK, though I think it might be bordering on pedantic to force each new PPP RFC to direct implementors to these documents. Real implementors -- or at least modestly competent ones -- know that they've got to look through more than one RFC to do the job, depending on circumstances.) -- James Carlson 42.703N 71.076W