From owner-v6ops@ops.ietf.org Mon May 9 16:17:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04473 for ; Mon, 9 May 2005 16:17:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVEe6-0004ug-2e for v6ops-data@psg.com; Mon, 09 May 2005 20:14:30 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVEe4-0004uS-Ej for v6ops@ops.ietf.org; Mon, 09 May 2005 20:14:28 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 09 May 2005 13:14:28 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j49KEPER006605; Mon, 9 May 2005 13:14:26 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j49K4Hlt026956; Mon, 9 May 2005 13:04:17 -0700 In-Reply-To: <63974c9beaee21fd9150183ac4e388f6@cisco.com> References: <63974c9beaee21fd9150183ac4e388f6@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <595419910bbe300d90c5497c82cd8db4@cisco.com> Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt Date: Mon, 9 May 2005 13:14:22 -0700 To: Tim Chown X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115669057.530577"; x:"432200"; a:"rsa-sha1"; b:"nofws:409"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"iXX2E+d3rnnVuUuHvHGnhSEtWQrNDVPbctY0MiXCw62MsJhcaBBIEatDghHjDD8q4er0nmXc" "bbRxHBHrKedlBtrEsK7/yQ5MQRsgC767C7TfyR1ryoNDWZPGxAlmswCp7Fskt8bpLsb5kMXw+tY" "58cqkUeCvWWRAglg95DLJZ3Y="; c:"From: Fred Baker "; c:"Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt"; c:"Date: Mon, 9 May 2005 13:14:22 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 18, 2005, at 3:10 PM, fred@cisco.com wrote: > I believe that we are ready for a working group last call on > draft-chown-v6ops-vlan-usage-02.txt. The proposed status is > Informational. This call will end on May 6. Please finalize your > comments on this draft or declare it ready for submission as-is. I have seen no comments on the draft, positive or negative. I guess I assume it passed last call... However, it also expired a couple of days ago. Tim, could I prevail on you to repost it? From owner-v6ops@ops.ietf.org Mon May 9 16:21:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05949 for ; Mon, 9 May 2005 16:21:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVEkk-0005QC-ME for v6ops-data@psg.com; Mon, 09 May 2005 20:21:22 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVEkj-0005Ph-4h for v6ops@ops.ietf.org; Mon, 09 May 2005 20:21:21 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 May 2005 13:21:20 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j49KLIER011374 for ; Mon, 9 May 2005 13:21:18 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j49KBA5g027037 for ; Mon, 9 May 2005 13:11:10 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <54277784f4166d4c478940341d31a534@cisco.com> References: <54277784f4166d4c478940341d31a534@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3b19a9cc29c540ba27fa08ca32940890@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt Date: Mon, 9 May 2005 13:21:15 -0700 To: "'v6ops@ops.ietf.org '" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115669470.591038"; x:"432200"; a:"rsa-sha1"; b:"nofws:253"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Vb4bPRajnBCXbqStW7hfu1pI6k8ykELZf8yZKrH8VsGWOICzX6j81u9eEYsT+shMrBffSwdN" "o6/8v0SH+0NcJ13xojZqjydPJQCwYdgA5//d5b2tgxCzwvAMTmmU4i1FLfs84JMPIyNBlBhZC8l" "5SjWj5CpVKnC7HQ5uHYr6oYA="; c:"From: Fred Baker "; c:"Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt"; c:"Date: Mon, 9 May 2005 13:21:15 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 18, 2005, at 3:11 PM, fred@cisco.com wrote: > I believe that we are ready for a working group last call on > draft-ietf-v6ops-natpt-to-exprmntl-00.txt. The proposed status is BCP. > This call will end on May 6. Please finalize your comments on this > draft or declare it ready for submission as-is. From owner-v6ops@ops.ietf.org Mon May 9 16:54:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10351 for ; Mon, 9 May 2005 16:54:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVFFP-00085Q-1f for v6ops-data@psg.com; Mon, 09 May 2005 20:53:03 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVFFO-000859-7B for v6ops@ops.ietf.org; Mon, 09 May 2005 20:53:02 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26159; Mon, 9 May 2005 15:54:17 -0400 (EDT) Message-Id: <200505091954.PAA26159@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-onlinkassumption-03.txt Date: Mon, 09 May 2005 15:54:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Neighbor Discovery On-Link Assumption Considered Harmful Author(s) : S. Roy, et al. Filename : draft-ietf-v6ops-onlinkassumption-03.txt Pages : 9 Date : 2005-5-9 This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-onlinkassumption-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-onlinkassumption-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-9160005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-onlinkassumption-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-onlinkassumption-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-9160005.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon May 9 17:10:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11792 for ; Mon, 9 May 2005 17:10:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVFW0-0009nx-He for v6ops-data@psg.com; Mon, 09 May 2005 21:10:12 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVFVy-0009nb-TB for v6ops@ops.ietf.org; Mon, 09 May 2005 21:10:11 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id 4B43033; Mon, 9 May 2005 14:10:15 -0700 (PDT) In-Reply-To: <3b19a9cc29c540ba27fa08ca32940890@cisco.com> References: <54277784f4166d4c478940341d31a534@cisco.com> <3b19a9cc29c540ba27fa08ca32940890@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" From: Alain Durand Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt Date: Mon, 9 May 2005 14:10:09 -0700 To: Fred Baker X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On May 9, 2005, at 1:21 PM, Fred Baker wrote: > On Apr 18, 2005, at 3:11 PM, fred@cisco.com wrote: >> I believe that we are ready for a working group last call on >> draft-ietf-v6ops-natpt-to-exprmntl-00.txt. The proposed status is >> BCP. This call will end on May 6. Please finalize your comments on >> this draft or declare it ready for submission as-is. > > My only comment on this draft is the way the issues are classified: Issues raised with NAT-PT can be categorized as follows: o Issues which are independent of the use of a DNS-ALG: o Issues which are exacerbated by the use of a DNS-ALG: o Issues which result from the use of a DNS-ALG: It would be useful to _also_ identified the issues that are merely the same as any v4/v4 NAT by opposition as new issues that are v6 specific. This would help any NAT-PT replacement candidate. - Alain. From owner-v6ops@ops.ietf.org Mon May 9 18:40:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20880 for ; Mon, 9 May 2005 18:40:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVGte-000GLe-OO for v6ops-data@psg.com; Mon, 09 May 2005 22:38:42 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVGtd-000GLK-5H for v6ops@ops.ietf.org; Mon, 09 May 2005 22:38:41 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 May 2005 15:38:41 -0700 X-IronPort-AV: i="3.92,170,1112598000"; d="scan'208"; a="262652751:sNHT28893412" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j49McbPo011559; Mon, 9 May 2005 15:38:38 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j49MSTYF028068; Mon, 9 May 2005 15:28:29 -0700 In-Reply-To: <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> References: <54277784f4166d4c478940341d31a534@cisco.com> <3b19a9cc29c540ba27fa08ca32940890@cisco.com> <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt Date: Mon, 9 May 2005 15:38:35 -0700 To: Alain Durand X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115677709.497632"; x:"432200"; a:"rsa-sha1"; b:"nofws:840"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"fnf3/viyoHNfl3gpTX2chCbZ/LYqUj+X0BRA+l7ghGgQEgX0SGZl8BGiMYxa7MvlkNrxsRZy" "MHkoslY68oJgfvp6EowlUmLvtVaAo7elQCDsaZWjbBQIQnvJ4HijeNeLfApzDAd4hvm2yxr3gEy" "8CReneIB+JbtuyY1cgKUe6os="; c:"From: Fred Baker "; c:"Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt"; c:"Date: Mon, 9 May 2005 15:38:35 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It would have been nice if you said this two weeks ago.. OK, what specifically do you want the authors to do? On May 9, 2005, at 2:10 PM, Alain Durand wrote: > > On May 9, 2005, at 1:21 PM, Fred Baker wrote: > >> On Apr 18, 2005, at 3:11 PM, fred@cisco.com wrote: >>> I believe that we are ready for a working group last call on >>> draft-ietf-v6ops-natpt-to-exprmntl-00.txt. The proposed status is >>> BCP. This call will end on May 6. Please finalize your comments on >>> this draft or declare it ready for submission as-is. > > My only comment on this draft is the way the issues are classified: > Issues raised with NAT-PT can be categorized as follows: > o Issues which are independent of the use of a DNS-ALG: > o Issues which are exacerbated by the use of a DNS-ALG: > o Issues which result from the use of a DNS-ALG: > > It would be useful to _also_ identified the issues that are merely the > same as > any v4/v4 NAT by opposition as new issues that are v6 specific. > This would help any NAT-PT replacement candidate. > > - Alain. > From owner-v6ops@ops.ietf.org Mon May 9 20:19:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01062 for ; Mon, 9 May 2005 20:19:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVITN-000PDG-8g for v6ops-data@psg.com; Tue, 10 May 2005 00:19:41 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVITM-000PD2-JP for v6ops@ops.ietf.org; Tue, 10 May 2005 00:19:40 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id 2ED33191; Mon, 9 May 2005 17:19:45 -0700 (PDT) In-Reply-To: <4461296A.2080308@dial.pipex.com> References: <54277784f4166d4c478940341d31a534@cisco.com> <3b19a9cc29c540ba27fa08ca32940890@cisco.com> <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> <4461296A.2080308@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Fred Baker , "'v6ops@ops.ietf.org '" From: Alain Durand Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt Date: Mon, 9 May 2005 17:19:39 -0700 To: Elwyn Davies X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On May 9, 2006, at 4:44 PM, Elwyn Davies wrote: > I beleive that the items inherited from IPv4 NAT are basically at the > 'section' level in this document. Alain's point could be covered by > adding a paragraph to the introduction which lists the section numbers > which are common to any NAT-like solution. I think the list is ss > 2.1, 2.2, 2.3, 2.5, 2.6, plus the basic underlying issues in ss > 3.2-3.4. That works too. - Alain. From owner-v6ops@ops.ietf.org Mon May 9 20:19:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01086 for ; Mon, 9 May 2005 20:19:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVISQ-000PA6-3r for v6ops-data@psg.com; Tue, 10 May 2005 00:18:42 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVISP-000P8w-DP for v6ops@ops.ietf.org; Tue, 10 May 2005 00:18:41 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id CDDCD190; Mon, 9 May 2005 17:18:45 -0700 (PDT) In-Reply-To: References: <54277784f4166d4c478940341d31a534@cisco.com> <3b19a9cc29c540ba27fa08ca32940890@cisco.com> <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6cc699d95c61a5e7c67ad12499cf50cb@tycool.net> Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" From: Alain Durand Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt Date: Mon, 9 May 2005 17:18:39 -0700 To: Fred Baker X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On May 9, 2005, at 3:38 PM, Fred Baker wrote: > > OK, what specifically do you want the authors to do? > For example, for each of the issue describe, list if this is also an issue with NATv4 or not, then add some sort of reference section at the end that will recap all that. - Alain. From owner-v6ops@ops.ietf.org Mon May 9 21:52:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07859 for ; Mon, 9 May 2005 21:52:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVJt9-00072A-3T for v6ops-data@psg.com; Tue, 10 May 2005 01:50:23 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVJt8-00071u-KH for v6ops@ops.ietf.org; Tue, 10 May 2005 01:50:22 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 09 May 2005 18:50:22 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4A1oJPo019065; Mon, 9 May 2005 18:50:19 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j4A1eAlZ029328; Mon, 9 May 2005 18:40:10 -0700 In-Reply-To: <6cc699d95c61a5e7c67ad12499cf50cb@tycool.net> References: <54277784f4166d4c478940341d31a534@cisco.com> <3b19a9cc29c540ba27fa08ca32940890@cisco.com> <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> <6cc699d95c61a5e7c67ad12499cf50cb@tycool.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <691c2ba8376f0c1476a058d28be03a13@cisco.com> Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt Date: Mon, 9 May 2005 18:50:17 -0700 To: Alain Durand X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115689210.552363"; x:"432200"; a:"rsa-sha1"; b:"nofws:377"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"jejZBjQoBHQ67sXOagpmSqL7pABagvCr8GAEN5xImQXhhD3uqf+QyEH0lXPD0dXhDoRxCZl5" "3beeS6OOAlwR5xS8vNGqmxvtDfW3Yk2BxusVTbVMfKN8tEy6SIzcUiwLECVAcp8lWfQVX8fURUS" "bCbvZ9aD00rv6gOE1xxnzfwA="; c:"From: Fred Baker "; c:"Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt"; c:"Date: Mon, 9 May 2005 18:50:17 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On May 9, 2005, at 5:18 PM, Alain Durand wrote: > On May 9, 2005, at 3:38 PM, Fred Baker wrote: >> OK, what specifically do you want the authors to do? > > For example, for each of the issue describe, list if this is also an > issue with NATv4 or not, then add some sort of reference section at > the end that will recap all that. > > - Alain. So you're looking for a major revision and reorganization of the document. Can I get you to have a dialog with the authors on that? From owner-v6ops@ops.ietf.org Mon May 9 22:54:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11247 for ; Mon, 9 May 2005 22:54:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVKr9-000C1p-IU for v6ops-data@psg.com; Tue, 10 May 2005 02:52:23 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVKr6-000C1R-Ck for v6ops@ops.ietf.org; Tue, 10 May 2005 02:52:20 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id 2168218D; Mon, 9 May 2005 19:52:24 -0700 (PDT) In-Reply-To: <691c2ba8376f0c1476a058d28be03a13@cisco.com> References: <54277784f4166d4c478940341d31a534@cisco.com> <3b19a9cc29c540ba27fa08ca32940890@cisco.com> <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> <6cc699d95c61a5e7c67ad12499cf50cb@tycool.net> <691c2ba8376f0c1476a058d28be03a13@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <36f30e6c6423983b92f171f67dab9219@tycool.net> Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" From: Alain Durand Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt Date: Mon, 9 May 2005 19:52:17 -0700 To: Fred Baker X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not necessarily anything major, the suggestion made by Elwyn is just fine. - Alain. On May 9, 2005, at 6:50 PM, Fred Baker wrote: > On May 9, 2005, at 5:18 PM, Alain Durand wrote: >> On May 9, 2005, at 3:38 PM, Fred Baker wrote: >>> OK, what specifically do you want the authors to do? >> >> For example, for each of the issue describe, list if this is also an >> issue with NATv4 or not, then add some sort of reference section at >> the end that will recap all that. >> >> - Alain. > > So you're looking for a major revision and reorganization of the > document. Can I get you to have a dialog with the authors on that? > From owner-v6ops@ops.ietf.org Tue May 10 00:48:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17902 for ; Tue, 10 May 2005 00:48:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVMdc-000Klt-J6 for v6ops-data@psg.com; Tue, 10 May 2005 04:46:32 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVMdb-000Klf-Mu for v6ops@ops.ietf.org; Tue, 10 May 2005 04:46:32 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4A4kGE06718; Tue, 10 May 2005 07:46:17 +0300 Date: Tue, 10 May 2005 07:46:16 +0300 (EEST) From: Pekka Savola To: Elwyn Davies cc: Fred Baker , Alain Durand , "'v6ops@ops.ietf.org '" Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt In-Reply-To: <4461296A.2080308@dial.pipex.com> Message-ID: References: <54277784f4166d4c478940341d31a534@cisco.com> <3b19a9cc29c540ba27fa08ca32940890@cisco.com> <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> <4461296A.2080308@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 10 May 2006, Elwyn Davies wrote: > I beleive that the items inherited from IPv4 NAT are basically at the > 'section' level in this document. Alain's point could be covered by adding a > paragraph to the introduction which lists the section numbers which are > common to any NAT-like solution. I think the list is ss 2.1, 2.2, 2.3, 2.5, > 2.6, plus the basic underlying issues in ss 3.2-3.4. I support this; let's not do anything more major than that. While it would be useful to also identify the generic NAT issues (the document does), rearranging the text at section level would not be wise because the issues are still slightly different and one would have to generalize, losing the current NAT-PT focus. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue May 10 04:52:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29461 for ; Tue, 10 May 2005 04:52:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVQQx-000Fiq-63 for v6ops-data@psg.com; Tue, 10 May 2005 08:49:43 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVQQv-000Fib-7a for v6ops@ops.ietf.org; Tue, 10 May 2005 08:49:41 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j4A8nci3010430 for ; Tue, 10 May 2005 09:49:38 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA18934 for ; Tue, 10 May 2005 09:49:36 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j4A8naX28941 for v6ops@ops.ietf.org; Tue, 10 May 2005 09:49:36 +0100 Date: Tue, 10 May 2005 09:49:36 +0100 From: Tim Chown To: "'v6ops@ops.ietf.org '" Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt Message-ID: <20050510084936.GF27741@login.ecs.soton.ac.uk> Mail-Followup-To: "'v6ops@ops.ietf.org '" References: <63974c9beaee21fd9150183ac4e388f6@cisco.com> <595419910bbe300d90c5497c82cd8db4@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <595419910bbe300d90c5497c82cd8db4@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, May 09, 2005 at 01:14:22PM -0700, Fred Baker wrote: > On Apr 18, 2005, at 3:10 PM, fred@cisco.com wrote: > >I believe that we are ready for a working group last call on > >draft-chown-v6ops-vlan-usage-02.txt. The proposed status is > >Informational. This call will end on May 6. Please finalize your > >comments on this draft or declare it ready for submission as-is. > > I have seen no comments on the draft, positive or negative. I guess I > assume it passed last call... > > However, it also expired a couple of days ago. > > Tim, could I prevail on you to repost it? Oops. I'l do so as draft-ietf. The only comment I have outstanding is regarding the example in the Appendix. Some people found it useful, though Pekka suggested an IOS example. I think if we keep it, it should probably stay 'vendor neutral'. -- Tim/::1 From owner-v6ops@ops.ietf.org Tue May 10 07:18:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14046 for ; Tue, 10 May 2005 07:18:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVSic-0004Z9-6P for v6ops-data@psg.com; Tue, 10 May 2005 11:16:06 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVSia-0004Yu-Fu for v6ops@ops.ietf.org; Tue, 10 May 2005 11:16:04 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 May 2005 04:16:04 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4ABFwER012443; Tue, 10 May 2005 04:15:59 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j4AB5msP031804; Tue, 10 May 2005 04:05:48 -0700 In-Reply-To: <20050510084936.GF27741@login.ecs.soton.ac.uk> References: <63974c9beaee21fd9150183ac4e388f6@cisco.com> <595419910bbe300d90c5497c82cd8db4@cisco.com> <20050510084936.GF27741@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54b4a5c80cde9233a49d2aa06cf25316@cisco.com> Content-Transfer-Encoding: 7bit Cc: internet-drafts@ietf.org, "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt Date: Tue, 10 May 2005 04:15:55 -0700 To: Tim Chown X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115723150.577096"; x:"432200"; a:"rsa-sha1"; b:"nofws:289"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ghfFkafBdwq2YqFtTOXND+FExes7ySjtC6KB/JaSZgUU8QZ6XoxLb1tLMpveoFE6Xqf/WZZV" "YNANclNQ2dYmwu+lDMGUZgrasPjNIX1n3Kwy+tt+VMNcCzrGEEzntVh8YqUMRT+1WnAeZngxwSn" "eqxMV3x9TEQJ8V1+jxZ6J5uY="; c:"From: Fred Baker "; c:"Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt"; c:"Date: Tue, 10 May 2005 04:15:55 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On May 10, 2005, at 1:49 AM, Tim Chown wrote: > Oops. I'l do so as draft-ietf-v6ops-vlan-usage-02.txt. The only > comment I have outstanding is regarding the example in the Appendix. > Some people found it useful, though Pekka suggested an IOS example. I > think if we keep it, it should probably stay 'vendor neutral'. yes, most likely. OK, thanks. From owner-v6ops@ops.ietf.org Tue May 10 07:29:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15427 for ; Tue, 10 May 2005 07:29:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVSv3-0005hX-PT for v6ops-data@psg.com; Tue, 10 May 2005 11:28:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVSuz-0005h7-Nt for v6ops@ops.ietf.org; Tue, 10 May 2005 11:28:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4ABSmV14943; Tue, 10 May 2005 14:28:50 +0300 Date: Tue, 10 May 2005 14:28:48 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: "'v6ops@ops.ietf.org '" Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt In-Reply-To: <20050510084936.GF27741@login.ecs.soton.ac.uk> Message-ID: References: <63974c9beaee21fd9150183ac4e388f6@cisco.com> <595419910bbe300d90c5497c82cd8db4@cisco.com> <20050510084936.GF27741@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 10 May 2005, Tim Chown wrote: > Oops. I'l do so as draft-ietf. The only comment I have outstanding > is regarding the example in the Appendix. Some people found it useful, > though Pekka suggested an IOS example. I think if we keep it, it should > probably stay 'vendor neutral'. Vendor neutral could be a problem. That is, the goal of the draft is to describe something that's rather obvious (to some people). If we don't have concrete examples that the readers can correspond to their existing configurations, I fear the example isn't going to be of much use. So my gut feeling is that (without knowing what kind of 'vendor neutral' text could be cooked up), - the current example is not good, because it's too verbose and based on BSD which isn't sufficiently commonplace so that the readers would gain additional understanding. - A Cisco example (one page would be enough) would be sufficient and widely understood (even by those who don't use Cisco) - A generic example, using pseudocode or whatever, would likely be counter-productive, so if we can't use a specific example, we'd be probably better off without the example at all. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue May 10 08:52:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23016 for ; Tue, 10 May 2005 08:52:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVUCJ-000EL5-E1 for v6ops-data@psg.com; Tue, 10 May 2005 12:50:51 +0000 Received: from [62.189.30.6] (helo=tortoise.webcentre.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVUCG-000EK4-1v for v6ops@ops.ietf.org; Tue, 10 May 2005 12:50:48 +0000 Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by tortoise.webcentre.net (8.9.3/8.9.3) with ESMTP id MAA09504 for ; Tue, 10 May 2005 12:58:40 +0100 (BST) Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j4AC4ri3018262 for ; Tue, 10 May 2005 13:04:53 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA07632 for ; Tue, 10 May 2005 13:04:51 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j4AC4pe02779 for v6ops@ops.ietf.org; Tue, 10 May 2005 13:04:51 +0100 Date: Tue, 10 May 2005 13:04:51 +0100 From: Tim Chown To: "'v6ops@ops.ietf.org '" Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt Message-ID: <20050510120451.GL29882@login.ecs.soton.ac.uk> Mail-Followup-To: "'v6ops@ops.ietf.org '" References: <63974c9beaee21fd9150183ac4e388f6@cisco.com> <595419910bbe300d90c5497c82cd8db4@cisco.com> <20050510084936.GF27741@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I don't have strong feelings. We can leave as is, remove the example altogether, or use an IOS one (if someone wants to write that). Tim On Tue, May 10, 2005 at 02:28:48PM +0300, Pekka Savola wrote: > On Tue, 10 May 2005, Tim Chown wrote: > >Oops. I'l do so as draft-ietf. The only comment I have outstanding > >is regarding the example in the Appendix. Some people found it useful, > >though Pekka suggested an IOS example. I think if we keep it, it should > >probably stay 'vendor neutral'. > > Vendor neutral could be a problem. That is, the goal of the draft is > to describe something that's rather obvious (to some people). If we > don't have concrete examples that the readers can correspond to their > existing configurations, I fear the example isn't going to be of much > use. > > So my gut feeling is that (without knowing what kind of 'vendor > neutral' text could be cooked up), > - the current example is not good, because it's too verbose and based > on BSD which isn't sufficiently commonplace so that the readers would > gain additional understanding. > - A Cisco example (one page would be enough) would be sufficient and > widely understood (even by those who don't use Cisco) > - A generic example, using pseudocode or whatever, would likely be > counter-productive, so if we can't use a specific example, we'd be > probably better off without the example at all. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Tim/::1 From owner-v6ops@ops.ietf.org Tue May 10 09:06:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24093 for ; Tue, 10 May 2005 09:06:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVURC-000GSs-Bf for v6ops-data@psg.com; Tue, 10 May 2005 13:06:14 +0000 Received: from [128.182.58.100] (helo=mailer1.psc.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVURA-000GSO-MD for v6ops@ops.ietf.org; Tue, 10 May 2005 13:06:12 +0000 Received: from [192.168.1.156] (ipl-67-0142.pppoe.stargate.net [206.210.67.142]) (authenticated bits=56) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j4AD6AQe001554; Tue, 10 May 2005 09:06:11 -0400 (EDT) In-Reply-To: References: <63974c9beaee21fd9150183ac4e388f6@cisco.com> <595419910bbe300d90c5497c82cd8db4@cisco.com> <20050510084936.GF27741@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <067489f3f598d4acaa7d920345423c74@psc.edu> Content-Transfer-Encoding: 7bit From: "Michael H. Lambert" Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt Date: Tue, 10 May 2005 09:06:05 -0400 To: "'v6ops@ops.ietf.org '" X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think a JUNOS example would also be worthy of consideration (probably readable by Cisco users; also somewhat resembling pseudocode). Michael On 10 May 2005, at 07:28, Pekka Savola wrote: > - A Cisco example (one page would be enough) would be sufficient and > widely understood (even by those who don't use Cisco) > - A generic example, using pseudocode or whatever, would likely be > counter-productive, so if we can't use a specific example, we'd be > probably better off without the example at all. From owner-v6ops@ops.ietf.org Tue May 10 11:36:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06684 for ; Tue, 10 May 2005 11:36:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVWkp-0003Mg-3x for v6ops-data@psg.com; Tue, 10 May 2005 15:34:39 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVWko-0003MU-Gi for v6ops@ops.ietf.org; Tue, 10 May 2005 15:34:38 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 May 2005 08:33:55 -0700 X-IronPort-AV: i="3.92,172,1112598000"; d="scan'208"; a="262968748:sNHT48942176912" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4AFXqER020576; Tue, 10 May 2005 08:33:53 -0700 (PDT) Received: from [171.71.101.239] (dhcp-171-71-101-239.cisco.com [171.71.101.239]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4AFNfZ4001132; Tue, 10 May 2005 08:23:41 -0700 In-Reply-To: References: <63974c9beaee21fd9150183ac4e388f6@cisco.com> <595419910bbe300d90c5497c82cd8db4@cisco.com> <20050510084936.GF27741@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <24b6b9e751eb93225c3aee6c775abf9a@cisco.com> Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" , Tim Chown From: Fred Baker Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt Date: Tue, 10 May 2005 08:33:49 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115738621.644950"; x:"432200"; a:"rsa-sha1"; b:"nofws:546"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"kZUuSvx9moPf5RNIh5cM1V3Fwd3Oc0oBQsZP4FudbWeujcy4espEhnf6RMiF5L4a1R+CPNP5" "E09Rtk4Kx6B5X2c83iucO9zDnxFCYr3/+chSe3n0HMfVW2sdCppqmsHpU5q/EUVnqta0lUtx2qf" "Bw58YeyT/1fXW2cJMbjVNo+E="; c:"From: Fred Baker "; c:"Subject: Re: WG Last Call: draft-chown-v6ops-vlan-usage-02.txt"; c:"Date: Tue, 10 May 2005 08:33:49 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On May 10, 2005, at 4:28 AM, Pekka Savola wrote: > If we don't have concrete examples that the readers can correspond to > their existing configurations, I fear the example isn't going to be of > much use. My question relates to what people will understand reading the document a decade from now. RFCs, unlike I-Ds, are forever, but the example is pretty specific not only to a vendor but to a specific equipment running a specific software release. If you want a vendor-specific example, I think it's only fair to say that and give the vendor the option of fixing it without having to explain to every customer for the next decade that the issue has been resolved. From owner-v6ops@ops.ietf.org Tue May 10 17:30:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23051 for ; Tue, 10 May 2005 17:30:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVcFN-0006eF-I3 for v6ops-data@psg.com; Tue, 10 May 2005 21:26:33 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVcFL-0006dv-BZ for v6ops@ops.ietf.org; Tue, 10 May 2005 21:26:31 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 May 2005 14:26:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4ALPhQS011782; Tue, 10 May 2005 14:26:28 -0700 (PDT) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 14:26:26 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 10 May 2005 14:26:24 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB2325DF@xmb-sjc-236.amer.cisco.com> Thread-Topic: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt Thread-Index: AcVU6DOT2SNjDA9/Qt68VUkTEX/d8QAvhlsQ From: "Senthil Sivakumar \(ssenthil\)" To: "Fred Baker \(fred\)" , "Alain Durand" Cc: X-OriginalArrivalTime: 10 May 2005 21:26:26.0379 (UTC) FILETIME=[EC1701B0:01C555A6] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This was raised way back in October that many of the issues are generic and not NAT-PT specific. Here is the email that was sent earlier. * To: "Cedric Aoun" * Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt * From: Senthil Sivakumar * Date: Fri, 08 Oct 2004 16:17:25 -0700 * Cc: V6OPS , "Elwyn Davies" * In-reply-to: * References: <200409211938.PAA14143@ietf.org> I see that the draft has consolidated all the previous drafts that highlighted the issues of NAT-PT and DNS ALG, which is a good thing. However, most of the issues mentioned here as NAT-PT issues are known issues with address translation (NAT) itself, so attributing them to NAT-PT is not correct. Those should be categorized as generic address translation issues. Some specfic comments on the following issues. * Disruption of all protocols which embed IP addresses (and/or ports) in packet payloads or which apply integrity mechanisms using IP addresses (and ports). (not NAT-PT specific). * Requirement for applications to use keep alive mechanisms to workaround connectivity issues caused by premature NAT-PT state timeout. (not NAT-PT specific). * Inability to redirect packet fragments after the first with NAPT-PT. (not NAT-PT specific). =20 o Issues which are exacerbated by the use of a DNS-ALG: * Constraints on network topology. (not NAT-PT specific). * Scalability concerns together with introduction of single point of failure and security attack nexus.(not NAT-PT specific). * Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS-ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keeping it alive once they start using it.(not NAT-PT specific). * Creation of a DOS threat relating to exhaustion of memory and address/port pool resources on the translator.(not NAT-PT specific). Regarding the conclusion, I don't agree with the fact that only applicable scenario is in 3G networks. During the past couple of years of my experience I have seen customers using it between isolated IPv6 networks to talk to existing IPv4 networks. A lot of cases it is not about the nodes being dual stack or not, it is the network that is not dual stacked for operational reasons. I have been gathering some inputs from the customers who are using NAT-PT currently regarding this draft. I can consolidate and forward the comments if you are interested in knowing and understanding why they think they are moving forward with NAT-PT. The point I am trying to stress is deprecating this would leave us with no workable solution for communicating between IPv4 only networks/nodes/apps IPv6 only networks/nodes/apps. As remote as it might seem for some, that is the use case scenario we have encountered as the applicability of NAT-PT. Senthil At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > Hi, > As discussed at IETF 60, the WG agreed to continue the NAT-PT deprecation analysis. > We would really appreciate if you could provide us your feedback on the initial version of the deprecation analysis by Monday October 4th. > Regards > Cedric Aoun > > ------ Forwarded Message=20 > From: =20 > Reply-To: =20 > Date: Tue, 21 Sep 2004 21:38:33 +0200=20 > To: =20 > Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : Reasons to Deprecate NAT-PT=20 > Author(s) : C. Aoun, E. Davies=20 > Filename : draft-aoun-v6ops-natpt-deprecate-00.txt=20 > Pages : 24=20 > Date : 2004-9-21=20 > =20 > This document discusses reasons why use of the specific form of=20 > IPv6-IPv4 protocol translation mechanism implemented by the Network=20 > Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766=20 > should be deprecated and RFC2766 moved to historic status.=20 > Description of an alternative protocol translation mechanism is out=20 > of scope for this document. > > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprecate-00. txt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the username=20 > "anonymous" and a password of your e-mail address. After logging in,=20 > type "cd internet-drafts" and then=20 > "get draft-aoun-v6ops-natpt-deprecate-00.txt". > > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to:=20 > mailserv@ietf.org.=20 > In the body type:=20 > "FILE /internet-drafts/draft-aoun-v6ops-natpt-deprecate-00.txt".=20 > =20 > NOTE: The mail server at ietf.org can return the document in=20 > MIME-encoded form by using the "mpack" utility. To use this=20 > feature, insert the command "ENCODING mime" before the "FILE"=20 > command. To decode the response(s), you will need "munpack" or=20 > a MIME-compliant mail reader. Different MIME-compliant mail readers=20 > exhibit different behavior, especially when dealing with=20 > "multipart" MIME messages (i.e. documents which have been split=20 > up into multiple messages), so check your local documentation on=20 > how to manipulate these messages.=20 > =20 > =20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > > =20 > > > > ------ End of Forwarded Message From owner-v6ops@ops.ietf.org Tue May 10 20:04:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05827 for ; Tue, 10 May 2005 20:04:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVeec-000JCV-6F for v6ops-data@psg.com; Wed, 11 May 2005 00:00:46 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVeeY-000JAm-BD for v6ops@ops.ietf.org; Wed, 11 May 2005 00:00:42 +0000 Received: from [81.187.254.247] (helo=[81.187.254.247]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DVeeO-0004F8-Rg; Wed, 11 May 2005 01:00:33 +0100 Message-ID: <42814B55.4010509@dial.pipex.com> Date: Wed, 11 May 2005 01:01:25 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" CC: "Fred Baker (fred)" , Alain Durand , v6ops@ops.ietf.org, Cedric Aoun Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt References: <85B2F271FDF6B949B3672BA5A7BB62FB2325DF@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB2325DF@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some of the issues are indeed generic problems with (v6-v4) address translation. It is not a matter of 'attributing' the issues to NAT-PT. If you implement/deploy NAT-PT, these issues *will* arise - this is what the draft is highlighting. As Alain was pointing out and seems to be part of your point, some of these issues will affect *any* v4-v6 translation mechanisms. We can mention which issues are implicated in an updated version of the draft if the list does not object, as I have suggested yesterday. I hope this will satisfy your point also. It will certainly be useful for anybody authoring alternative mechanisms to be aware of the genric issues in one place, IMO. It should also be noted that this is the only draft that has addressed the 'known issues with address translation' in the context of v4-v6 translation as opposed to v4-v4 NAT: there are subtle differences as Pekka pointed out so we need to cover them here, rather than by reference. Regards, Elwyn Senthil Sivakumar (ssenthil) wrote: >This was raised way back in October that many of the issues are generic >and not NAT-PT specific. Here is the email that was sent earlier. > > * To: "Cedric Aoun" > * Subject: Re: FW: I-D >ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > * From: Senthil Sivakumar > * Date: Fri, 08 Oct 2004 16:17:25 -0700 > * Cc: V6OPS , "Elwyn Davies" > > * In-reply-to: > * References: <200409211938.PAA14143@ietf.org> > >I see that the draft has consolidated all the previous drafts that >highlighted the issues >of NAT-PT and DNS ALG, which is a good thing. However, most of the >issues mentioned >here as NAT-PT issues are known issues with address translation (NAT) >itself, so >attributing them to NAT-PT is not correct. Those should be categorized >as generic address >translation issues. > >Some specfic comments on the following issues. > > * Disruption of all protocols which embed IP addresses (and/or > ports) in packet payloads or which apply integrity mechanisms > using IP addresses (and ports). (not NAT-PT specific). > > * Requirement for applications to use keep alive mechanisms to > workaround connectivity issues caused by premature NAT-PT state > timeout. (not NAT-PT specific). > > * Inability to redirect packet fragments after the first with > NAPT-PT. (not NAT-PT specific). > > o Issues which are exacerbated by the use of a DNS-ALG: > * Constraints on network topology. (not NAT-PT specific). > * Scalability concerns together with introduction of single point > of failure and security attack nexus.(not NAT-PT specific). > * Lack of address mapping persistence: Some applications require > address retention between sessions. The user traffic will be > disrupted if a different mapping is used. The use of the > DNS-ALG to create address mappings with limited lifetimes means > that applications must start using the address shortly after > the mapping is created, as well as keeping it alive once they > start using it.(not NAT-PT specific). > * Creation of a DOS threat relating to exhaustion of memory and > address/port pool resources on the translator.(not NAT-PT >specific). > >Regarding the conclusion, I don't agree with the fact that only >applicable scenario >is in 3G networks. During the past couple of years of my experience I >have seen >customers using it between isolated IPv6 networks to talk to existing >IPv4 networks. >A lot of cases it is not about the nodes being dual stack or not, it is >the network >that is not dual stacked for operational reasons. > >I have been gathering some inputs from the customers who are using >NAT-PT currently >regarding this draft. I can consolidate and forward the comments if you >are interested in >knowing and understanding why they think they are moving forward with >NAT-PT. > >The point I am trying to stress is deprecating this would leave us with >no workable >solution for communicating between IPv4 only networks/nodes/apps IPv6 >only >networks/nodes/apps. As remote as it might seem for some, that is the >use case >scenario we have encountered as the applicability of NAT-PT. > >Senthil > >At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > >>Hi, >>As discussed at IETF 60, the WG agreed to continue the NAT-PT >> >> >deprecation analysis. > > >>We would really appreciate if you could provide us your feedback on >> >> >the initial version of the deprecation analysis by Monday October 4th. > > >>Regards >>Cedric Aoun >> >> ------ Forwarded Message >> From: >> Reply-To: >> Date: Tue, 21 Sep 2004 21:38:33 +0200 >> To: >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> >directories. > > >> >> Title : Reasons to Deprecate NAT-PT >> Author(s) : C. Aoun, E. Davies >> Filename : draft-aoun-v6ops-natpt-deprecate-00.txt >> Pages : 24 >> Date : 2004-9-21 >> >> This document discusses reasons why use of the specific form of >> IPv6-IPv4 protocol translation mechanism implemented by the >> >> >Network > > >> Address Translator - Protocol Translator (NAT-PT) defined in >> >> >RFC 2766 > > >> should be deprecated and RFC2766 moved to historic status. >> Description of an alternative protocol translation mechanism is >> >> >out > > >> of scope for this document. >> >> A URL for this Internet-Draft is: >> >> >> >http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprecate-00. >txt > > >> To remove yourself from the I-D Announcement list, send a message >> >> >to > > >> i-d-announce-request@ietf.org with the word unsubscribe in the >> >> >body of the message. > > >> You can also visit >> >> >https://www1.ietf.org/mailman/listinfo/I-D-announce > > >> to change your subscription settings. >> >> >> >> Internet-Drafts are also available by anonymous FTP. Login with >> >> >the username > > >> "anonymous" and a password of your e-mail address. After logging >> >> >in, > > >> type "cd internet-drafts" and then >> "get draft-aoun-v6ops-natpt-deprecate-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE >> >> >/internet-drafts/draft-aoun-v6ops-natpt-deprecate-00.txt". > > >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use >> >> >this > > >> feature, insert the command "ENCODING mime" before the >> >> >"FILE" > > >> command. To decode the response(s), you will need >> >> >"munpack" or > > >> a MIME-compliant mail reader. Different MIME-compliant >> >> >mail readers > > >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been >> >> >split > > >> up into multiple messages), so check your local >> >> >documentation on > > >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> >> >>------ End of Forwarded Message >> >> > > > From owner-v6ops@ops.ietf.org Thu May 12 13:02:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11998 for ; Thu, 12 May 2005 13:02:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWH0k-000KuW-RN for v6ops-data@psg.com; Thu, 12 May 2005 16:58:10 +0000 Received: from [66.218.92.38] (helo=web40427.mail.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DWH0k-000KuC-4A for v6ops@ops.ietf.org; Thu, 12 May 2005 16:58:10 +0000 Received: (qmail 57198 invoked by uid 60001); 12 May 2005 16:58:09 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=6GmfnbqGpeh5b1Yg7k8PPSLJDvH0o5c+VU7YYWoYIzTN78sR5r224zx3u2g1bfDvQZ3921EX3n9k3thtvLCXFwCqQjRciGIKmGs9KJpdoJ/jA9Duc64MIWu57k3wSNnQ743IHKGEONiXNlUOQmLvwj9P22aa57JRlTaAwQP3ZEI= ; Message-ID: <20050512165809.57196.qmail@web40427.mail.yahoo.com> Received: from [64.142.116.2] by web40427.mail.yahoo.com via HTTP; Thu, 12 May 2005 09:58:09 PDT Date: Thu, 12 May 2005 09:58:09 -0700 (PDT) From: Pyda Srisuresh Subject: A Mialing list to discuss NATPY. To: v6ops@ops.ietf.org Cc: Tony Hain In-Reply-To: <42814B55.4010509@dial.pipex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk folks, We have a new mailing list ietf-natpt@cisco.com to discuss issues that need cleaning up in NAT-PT. Please join the list, if you have an interest in pursuing this effort. Thanks. cheers, suresh From owner-v6ops@ops.ietf.org Thu May 12 16:44:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08224 for ; Thu, 12 May 2005 16:44:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWKU1-0007JG-CG for v6ops-data@psg.com; Thu, 12 May 2005 20:40:37 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWKTz-0007H1-Af for v6ops@ops.ietf.org; Thu, 12 May 2005 20:40:35 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j4CKe9i5009517 for ; Thu, 12 May 2005 21:40:09 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA08793 for ; Thu, 12 May 2005 21:40:03 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j4CKe3932196 for v6ops@ops.ietf.org; Thu, 12 May 2005 21:40:03 +0100 Date: Thu, 12 May 2005 21:40:03 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: A Mialing list to discuss NATPY. Message-ID: <20050512204003.GE27595@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <42814B55.4010509@dial.pipex.com> <20050512165809.57196.qmail@web40427.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512165809.57196.qmail@web40427.mail.yahoo.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, May 12, 2005 at 09:58:09AM -0700, Pyda Srisuresh wrote: > folks, > > We have a new mailing list ietf-natpt@cisco.com to discuss issues that need > cleaning up in NAT-PT. Please join the list, if you have an interest in > pursuing this effort. Thanks. For info, if you try to join you get: "Your message to ietf-natpt@cisco.com has NOT been sent, please note that the address for this list is ietf-natpt@external.cisco.com. You should use this address to send mail to this list. You will need to resend your message to: ietf-natpt@external.cisco.com Note: This address contains people external to Cisco Systems, Inc. so do not send anything to this list that should be treated as confidential Cisco information." -- Tim/::1 From owner-v6ops@ops.ietf.org Thu May 12 17:45:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12226 for ; Thu, 12 May 2005 17:45:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWLTJ-000DgO-Mk for v6ops-data@psg.com; Thu, 12 May 2005 21:43:57 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWLTH-000DfE-RB for v6ops@ops.ietf.org; Thu, 12 May 2005 21:43:55 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id D72B1DF; Thu, 12 May 2005 14:43:51 -0700 (PDT) In-Reply-To: <20050512165809.57196.qmail@web40427.mail.yahoo.com> References: <20050512165809.57196.qmail@web40427.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Tony Hain , v6ops@ops.ietf.org From: Alain Durand Subject: Re: A Mialing list to discuss NATPY. Date: Thu, 12 May 2005 14:43:48 -0700 To: Pyda Srisuresh X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Could you please elaborate on what you are trying to accomplish? - Alain. On May 12, 2005, at 9:58 AM, Pyda Srisuresh wrote: > folks, > > We have a new mailing list ietf-natpt@cisco.com to discuss issues that > need > cleaning up in NAT-PT. Please join the list, if you have an interest in > pursuing this effort. Thanks. > > cheers, > suresh From owner-v6ops@ops.ietf.org Fri May 13 15:50:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22192 for ; Fri, 13 May 2005 15:50:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWg8W-000ADe-Af for v6ops-data@psg.com; Fri, 13 May 2005 19:47:52 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWg8V-000ADE-HQ for v6ops@ops.ietf.org; Fri, 13 May 2005 19:47:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21538; Fri, 13 May 2005 15:47:47 -0400 (EDT) Message-Id: <200505131947.PAA21538@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-security-overview-00.txt Date: Fri, 13 May 2005 15:47:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Transition/Co-existence Security Considerations Author(s) : E. Davies, et al. Filename : draft-ietf-v6ops-security-overview-00.txt Pages : 32 Date : 2005-5-13 The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-security-overview-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-security-overview-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-13155931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-security-overview-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-security-overview-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-13155931.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri May 13 16:35:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06264 for ; Fri, 13 May 2005 16:35:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWgrZ-000EUi-OQ for v6ops-data@psg.com; Fri, 13 May 2005 20:34:25 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DWgrX-000EUM-EH for v6ops@ops.ietf.org; Fri, 13 May 2005 20:34:23 +0000 Received: from [81.187.254.247] (helo=[81.187.254.247]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DWgrV-0001g5-FC for v6ops@ops.ietf.org; Fri, 13 May 2005 21:34:21 +0100 Message-ID: <42850F82.7010300@dial.pipex.com> Date: Fri, 13 May 2005 21:35:14 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Please comment on new draft: draft-ietf-v6ops-security-overview-00.txt References: <200505131947.PAA21538@ietf.org> In-Reply-To: <200505131947.PAA21538@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi. A new version of this draft (previously draft-savola-v6ops-security-overview) which is now a WG draft is available. Please let us have any comments asap - we intend to produce another new version incorporating any comments prior to IETF-63. This version incorporates a number of additional points contributed by SUZUKI Shinsuke for the Japan IPv6 Promotional Council as well as deal of updated wording. We are particularly interested on views of how we should proceed on the subject of ICMPv6 filtering in firewalls. Thanks, Elwyn Davies for the authors 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 IPv6 Operations Working Group of the IETF. > > Title : IPv6 Transition/Co-existence Security Considerations > Author(s) : E. Davies, et al. > Filename : draft-ietf-v6ops-security-overview-00.txt > Pages : 32 > Date : 2005-5-13 > >The transition from a pure IPv4 network to a network where IPv4 and > IPv6 co-exist brings a number of extra security considerations that > need to be taken into account when deploying IPv6 and operating the > dual-protocol network and the associated transition mechanisms. This > document attempts to give an overview of the various issues grouped > into three categories: > o issues due to the IPv6 protocol itself, > o issues due to transition mechanisms, and > o issues due to IPv6 deployment. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-v6ops-security-overview-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-security-overview-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > From owner-v6ops@ops.ietf.org Thu May 19 15:48:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15533 for ; Thu, 19 May 2005 15:48:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYqxm-0004l9-1T for v6ops-data@psg.com; Thu, 19 May 2005 19:45:46 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYqxl-0004ki-88 for v6ops@ops.ietf.org; Thu, 19 May 2005 19:45:45 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14818; Thu, 19 May 2005 15:45:42 -0400 (EDT) Message-Id: <200505191945.PAA14818@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-analysis-02.txt Date: Thu, 19 May 2005 15:45:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Analysis Author(s) : J. Bound, et al. Filename : draft-ietf-v6ops-ent-analysis-02.txt Pages : 33 Date : 2005-5-19 This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ent-analysis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-19153535.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-19153535.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu May 19 18:05:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06063 for ; Thu, 19 May 2005 18:05:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYt6V-000Eul-UZ for v6ops-data@psg.com; Thu, 19 May 2005 22:02:55 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYt6U-000EuS-08 for v6ops@ops.ietf.org; Thu, 19 May 2005 22:02:54 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 May 2005 15:02:53 -0700 X-IronPort-AV: i="3.93,121,1115017200"; d="scan'208"; a="267416047:sNHT31266432" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4JM2EQM016940 for ; Thu, 19 May 2005 15:02:51 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 15:02:51 -0700 Received: from [10.253.132.46] ([10.21.121.242]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 15:02:50 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <200505191945.PAA14818@ietf.org> References: <200505191945.PAA14818@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18d392ca9e8dd0476bdf3b1b2a3141e1@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Discussion of draft-ietf-v6ops-ent-analysis-02.txt Date: Thu, 19 May 2005 15:02:47 -0700 To: "'v6ops@ops.ietf.org '" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 19 May 2005 22:02:51.0068 (UTC) FILETIME=[7FFBD7C0:01C55CBE] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The enterprise analysis draft has been posted for review. Please read it and comment to the list. It would be nice to be able to complete last call on this before our meeting in August, or to know that there are issues we need face time to discuss. On May 19, 2005, at 12:45 PM, 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 IPv6 Operations Working Group of the > IETF. > > Title : IPv6 Enterprise Network Analysis > Author(s) : J. Bound, et al. > Filename : draft-ietf-v6ops-ent-analysis-02.txt > Pages : 33 > Date : 2005-5-19 > > This document analyzes the transition to IPv6 in enterprise > networks. These networks are characterized as a network that has > multiple internal links, one or more router connections, to one or > more Providers, and is managed by a network operations entity. The > analysis will focus on a base set of transition notational networks > and requirements expanded from a previous Enterprise Scenarios > document. Discussion is provided on a focused set of transition > analysis required for the enterprise to transition to IPv6, > assuming a Dual-IP layer (IPv4 and IPv6) network and node > environment, within the enterprise. Then a set of transition > mechanisms are recommended for each notational network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis > -02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-v6ops-ent-analysis-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ----------------------------------------------------------------------- > -- > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ----------------------------------------------------------------------- > -- > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a > seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j4JJm8re029656 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > > --OtherAccess-- From owner-v6ops@ops.ietf.org Fri May 20 12:18:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02929 for ; Fri, 20 May 2005 12:18:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZAA5-000Bmx-T0 for v6ops-data@psg.com; Fri, 20 May 2005 16:15:45 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DZAA5-000Bm5-71 for v6ops@ops.ietf.org; Fri, 20 May 2005 16:15:45 +0000 Received: from [10.0.0.171] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 372698; Fri, 20 May 2005 12:11:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <18d392ca9e8dd0476bdf3b1b2a3141e1@cisco.com> References: <200505191945.PAA14818@ietf.org> <18d392ca9e8dd0476bdf3b1b2a3141e1@cisco.com> Date: Fri, 20 May 2005 12:14:27 -0400 To: Fred Baker , "'v6ops@ops.ietf.org '" From: Margaret Wasserman Subject: Re: Discussion of draft-ietf-v6ops-ent-analysis-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Does the WG really have consensus on this recommendation? Later in the transition process, after the enterprise has transitioned to a predominately IPv6 infrastructure, the architect should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or in the case of early deployment of IPv6-dominant networks DSTM can be used too. This whole document comes down to a brief set of recommendations, and I think that it is important that we only make recommendations that have the clear consensus of the WG. I am not personally convinced that we should recommend DSTM as a solution for this stage of network transition (I haven't even read DSTM+, so I have no opinion on that), but perhaps I am part of the rough? Fred, was there an explicit consensus call on each of these recommendations that I missed while I was busy somewhere else? If the WG does have consensus that, at some point in an enterprise transition, administrators "should implement DSTM", what is our plan to standardize it? Margaret From owner-v6ops@ops.ietf.org Fri May 20 13:56:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16622 for ; Fri, 20 May 2005 13:56:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZBhL-000Ihp-7y for v6ops-data@psg.com; Fri, 20 May 2005 17:54:11 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DZBhK-000Ihb-Ip for v6ops@ops.ietf.org; Fri, 20 May 2005 17:54:10 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 May 2005 10:54:10 -0700 X-IronPort-AV: i="3.93,124,1115017200"; d="scan'208"; a="267754704:sNHT29736576" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4KHs7Po014821; Fri, 20 May 2005 10:54:08 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j4KHhJ5G023201; Fri, 20 May 2005 10:43:19 -0700 In-Reply-To: References: <200505191945.PAA14818@ietf.org> <18d392ca9e8dd0476bdf3b1b2a3141e1@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: Discussion of draft-ietf-v6ops-ent-analysis-02.txt Date: Fri, 20 May 2005 10:54:05 -0700 To: Margaret Wasserman X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116610999.898883"; x:"432200"; a:"rsa-sha1"; b:"nofws:1911"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ZwFy+T+G3hK/bmRCOCJPsPQEEHaNbX3g6SyfHlNJP3god+gyWR/po3l7kuK+6Pah7cjo1cBl" "FjVji9akWMvF9WyHMzci4oih37kvzLbQKZ4pR9Buxkkl15qxdRXMRJkxruZRek3EaKdCxnF8qCJ" "OTllsXOTwQv+kUDkqUTpSphA="; c:"From: Fred Baker "; c:"Subject: Re: Discussion of draft-ietf-v6ops-ent-analysis-02.txt"; c:"Date: Fri, 20 May 2005 10:54:05 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm not at all clear that DSTM is being recommended by the working group - or any specific transition mechanism. Our charter specifically excludes discussion of transition mechanisms, and I note that the IESG recently approved Teredo as a Proposed Standard, which I think means that the IETF recommends that. And personally, I'm not convinced that any of the proposed transition mechanisms are sufficient, as I don't see documented anywhere a single transition mechanism simultaneously solves all four problems: - an IPv4-only system finding and communicating with another IPv4-only system across an IPv6-only infrastructure - an IPv6-only system finding and communicating with another IPv6-only system across an IPv4-only infrastructure - an IPv4-only system finding and communicating with an IPv6-only system - an IPv6-only system finding and communicating with an IPv4-only system My history with this document and with the DSTM proposal is that I took over the WG last March. In the WG meeting in march, DSTM was not discussed, and the discussion of the enterprise analysis identified a number of items to be corrected. We have just gotten the updated document, and it needs thorough review. On May 20, 2005, at 9:14 AM, Margaret Wasserman wrote: > > Does the WG really have consensus on this recommendation? > > Later in the transition process, after the enterprise has > transitioned to a predominately IPv6 infrastructure, the architect > should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or > in the case of early deployment of IPv6-dominant networks DSTM can > be used too. > > This whole document comes down to a brief set of recommendations, and > I think that it is important that we only make recommendations that > have the clear consensus of the WG. > > I am not personally convinced that we should recommend DSTM as a > solution for this stage of network transition (I haven't even read > DSTM+, so I have no opinion on that), but perhaps I am part of the > rough? Fred, was there an explicit consensus call on each of these > recommendations that I missed while I was busy somewhere else? > > If the WG does have consensus that, at some point in an enterprise > transition, administrators "should implement DSTM", what is our plan > to standardize it? > > Margaret > From owner-v6ops@ops.ietf.org Mon May 23 19:43:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14401 for ; Mon, 23 May 2005 19:43:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaMWc-000EBA-M5 for v6ops-data@psg.com; Mon, 23 May 2005 23:39:58 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DaMWa-000EAs-Mk for v6ops@ops.ietf.org; Mon, 23 May 2005 23:39:56 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j4NNdti3025681 for ; Tue, 24 May 2005 00:39:55 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA29825 for ; Tue, 24 May 2005 00:39:51 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j4NNdpm16463 for v6ops@ops.ietf.org; Tue, 24 May 2005 00:39:51 +0100 Date: Tue, 24 May 2005 00:39:51 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: New IPv6 renumbering 'thinkabout' draft Message-ID: <20050523233951.GO6963@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Since it is not a WG item auto-posted here... Mainly an editorial update. The authors still seek feedback on the draft structure and content... thanks :) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Things to think about when Renumbering an IPv6 network Author(s) : T. Chown, et al. Filename : draft-chown-v6ops-renumber-thinkabout-02.txt Pages : 39 Date : 2005-5-23 This memo presents a summary of scenarios, issues for consideration and protocol features for IPv6 network renumbering, i.e. achieving the transition from the use of an existing network prefix to a new prefix in an IPv6 network. Its focus lies not in the procedure for renumbering, but as a set of "things to think about" when undertaking such a renumbering exercise. The document is not intended to be complete at this time, and will be enhanced as further operational experience is gathered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-v6ops-renumber-thinkabout-02.txt -- Tim/::1 From owner-v6ops@ops.ietf.org Tue May 24 11:01:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08165 for ; Tue, 24 May 2005 11:01:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Daas8-0005ry-Jx for v6ops-data@psg.com; Tue, 24 May 2005 14:59:08 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Daas6-0005rW-G8 for v6ops@ops.ietf.org; Tue, 24 May 2005 14:59:06 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j4OEwwqr186306 for ; Tue, 24 May 2005 14:58:59 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OEwwRM246740 for ; Tue, 24 May 2005 15:58:58 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j4OEwwmB028277 for ; Tue, 24 May 2005 15:58:58 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEwv3l028270; Tue, 24 May 2005 15:58:57 +0100 Received: from zurich.ibm.com (sig-9-146-219-181.de.ibm.com [9.146.219.181]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA85796; Tue, 24 May 2005 16:58:56 +0200 Message-ID: <42934129.8080700@zurich.ibm.com> Date: Tue, 24 May 2005 16:58:49 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Margaret Wasserman CC: Fred Baker , "'v6ops@ops.ietf.org '" Subject: Re: Discussion of draft-ietf-v6ops-ent-analysis-02.txt References: <200505191945.PAA14818@ietf.org> <18d392ca9e8dd0476bdf3b1b2a3141e1@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, Margaret Wasserman wrote: > > Does the WG really have consensus on this recommendation? > > Later in the transition process, after the enterprise has > transitioned to a predominately IPv6 infrastructure, the architect > should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or > in the case of early deployment of IPv6-dominant networks DSTM can > be used too. Could we agree on s/should implement/should consider implementing/? Brian From owner-v6ops@ops.ietf.org Tue May 24 11:25:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10495 for ; Tue, 24 May 2005 11:25:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DabHA-0008Jl-86 for v6ops-data@psg.com; Tue, 24 May 2005 15:25:00 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DabH6-0008JD-Ik for v6ops@ops.ietf.org; Tue, 24 May 2005 15:24:56 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 May 2005 08:24:56 -0700 X-IronPort-AV: i="3.93,132,1115017200"; d="scan'208"; a="269019881:sNHT28170308" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4OFOslq014909 for ; Tue, 24 May 2005 08:24:54 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j4OFDpVv018002 for ; Tue, 24 May 2005 08:13:52 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <093d788d0e635fd152422415fca1a201@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Fwd: 2461bis update Date: Tue, 24 May 2005 08:24:52 -0700 X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116947632.252735"; x:"432200"; a:"rsa-sha1"; b:"nofws:978"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"mmlEIcATXs1ak8DzhTejiFOrlrZNLvCr05pbK8ZpxHtZhnlRY2G1ND10ryuWzbzTN7RFi9t4" "EwVSnQMiOh16FawYoc5YrF3kivnKRa1f//In10HeRiSlxvFZsJmzRXsslFsMChFfxBziFb4tIrj" "hT40Nu5quavDKQMS7ZOhb1Ek="; c:"From: Fred Baker "; c:"Subject: Fwd: 2461bis update"; c:"Date: Tue, 24 May 2005 08:24:52 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Begin forwarded message: > From: "Soliman, Hesham" > Date: May 24, 2005 7:04:25 AM PDT > To: > Subject: 2461bis update > > Hi all, > > I submitted an updated revision of 2461bis which includes > the resolutions that were agreed on by the WG in the last meeting > (the SLLAO thread). It also includes fixes for the comments Tatuya > raised on the last version. > > I think this draft is now ready for the IESG. > > Thanks, > Hesham > > =========================================================== > This email may contain confidential and privileged material for the > sole use > of the intended recipient. Any review or distribution by others is > strictly > prohibited. If you are not the intended recipient please contact the > sender > and delete all copies. > =========================================================== > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From owner-v6ops@ops.ietf.org Wed May 25 08:06:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04066 for ; Wed, 25 May 2005 08:06:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dauat-000GPl-O6 for v6ops-data@psg.com; Wed, 25 May 2005 12:02:39 +0000 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dauar-000GPB-EC for v6ops@ops.ietf.org; Wed, 25 May 2005 12:02:37 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4PC23e02015; Wed, 25 May 2005 14:02:13 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (dhcp-bru-peg1-vl18-144-254-2-33.cisco.com [144.254.2.33]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4PC22F05659; Wed, 25 May 2005 14:02:02 +0200 (CEST) Message-Id: <4.3.2.7.2.20050525132405.03a6f268@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 May 2005 14:02:00 +0200 To: Mark Smith From: "Gunter Van de Velde (gvandeve)" Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Cc: "John Spence, CCSI, CCNA, CISSP" , v6ops@ops.ietf.org In-Reply-To: <20050406132724.361136e8.ipng@69706e6720323030352d30312d313 40a.nosense.org> References: <200504060315.j363FFpm020258@hestia.native6.com> <20050406123322.13307cb8.ipng@69706e6720323030352d30312d31340a.nosense.org> <200504060315.j363FFpm020258@hestia.native6.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Mark, All, I'm just falling back to this thread. >Yes, because I think that as the move to IPv6 is relatively disruptive >("disruptive" in the sense that deploying a new technology on a large >scale is usually disruptive no matter how well it is done - it is always >a significant change) it is a good opportunity also (re)introduce ideas >that we know in the long term will be beneficial. I think the >introduction of IPv6 is also an opportunity to change the way people >think and do things with and in their network. I'm not sure that i fully agree with the disruptive aspect of adding IPv6 services to a network infrastructure from technical perspective. One can add IPv6 as protocol in addition to IPv4 of an IP network without interrupting the network too much by use of the already planned and existing maintenance windows. In most cases the end-users won't even notice a difference or the glitches in the network when the ISIS or BGP experience sessions flaps due to capability exchanges. In this case there would be a nice coexistence of existing IPv4 services and additional IPv6 services can be provided after the migration. The next steps could be done step-by-step. For the end-systems, they can be made IPv6 aware if they are not already. This should/will be a none issue with most of the current existing OS's, not? To come back at the NAP aspects of the thread, these systems may or may not have their own protection against external influences and the network may exist out of different OS's (and potentially different flavors or releases of the OS's) which each implement their own version of a security model. This sounds like a nice way to create complexity and confusion about the existing security model used. For the home-user this could be sufficient, however i do like the idea that for home-users there should be some direction or statement that by a simple configuration he must be able to enable the state-full filtering mechanism in a NAT-like manner, this not to break the end-to-end model, but more to have this extra level of security. A distributed security mechanism, only on the end-systems will probably not be there in the next couple of years for organizations. The question is also if there is need for real 'none-filtered peer-2-peer communication between inside and outside an organization. However, a stateful filter placed at the boundary between inside and outside can limit these kind of connections based on certain configurable rules. The principle would be the same as when using a stateful address translator. To conclude, it would be good to have a recommendation for the easy enabling of a stateful filter to establish NAT like session security and control, and in addition to that (as result of the peer-2-peer potential of IPv6) the end-system OS's should have a similar recommendation. Would the above be a good summary to place in the next revision of the NAP draft? Groetjes, G/ At 13:27 6/04/2005 +0930, Mark Smith wrote: >Hi John, > >On Tue, 5 Apr 2005 20:15:10 -0700 >"John Spence, CCSI, CCNA, CISSP" wrote: > > > > > Mark; > > > > Good points all. I agree, host firewall is evolving fast, and will be more > > and more commonly deployed in the future. > > > > But are you suggesting that the NAP draft, in an effort to push > peer-to-peer > > "all the way", advocate removing edge firewalls and ACL in favor of only > > deploying distributed firewalls? I think that would be going way to far. > > The best way to pry NAT out of the hands of IPv4-oriented security managers > > is to make the case *for* stateful firewalls over NAT routers - not to try > > to suggest, at this stage, that even the stateful firewalls should be > pulled > > in favor of having the end nodes use host firewalls to support peer-to-peer > > networking in the purest sense. > >Yes and no :-) > >Yes, because I think that as the move to IPv6 is relatively disruptive >("disruptive" in the sense that deploying a new technology on a large >scale is usually disruptive no matter how well it is done - it is always >a significant change) it is a good opportunity also (re)introduce ideas >that we know in the long term will be beneficial. I think the >introduction of IPv6 is also an opportunity to change the way people >think and do things with and in their network. > >For example, as I mentioned, modern OSes have firewalling out of the >box. From what I'm aware of, the only component missing, at least in the >commercial space i.e., products you can buy, for scalable host based >firewalling is mechanisms to deploy the (corporate) firewalling policy >to the host. I think it just may be around the corner though - server >based authentication services obviously exist, user "login scripts" that >are pushed to the users host after authentication have been around a for >a long time, its just a matter of a commercially available mechanism to >push firewall policy to the user host in a similar manner to login >scripts. > >No, because I realise that people don't necessarily like change, and >also like to apply existing and understood models of operation to new >environments or technologies. > >Summarising, I'd like to see IPv6 used as an opporunity to introduce and >promote new thinking (well old, but new to most IPv4 people), and >provide "new" models of deployment. However, for those who are more >resistant to new thinking, identify "old" IPv4 mechanisms and how they >can work with IPv6 as a "fall back" alternative to new thinking or as >part of a migrationary path to "new thinking". > >Regards, >Mark. >-- > > The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Wed May 25 12:01:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23706 for ; Wed, 25 May 2005 12:01:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DayI4-0007SO-Oe for v6ops-data@psg.com; Wed, 25 May 2005 15:59:28 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DayI2-0007S2-AM for v6ops@ops.ietf.org; Wed, 25 May 2005 15:59:26 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 25 May 2005 08:59:26 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4PFxL3Q009300; Wed, 25 May 2005 08:59:23 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j4PFmEnL027996; Wed, 25 May 2005 08:48:14 -0700 In-Reply-To: <4.3.2.7.2.20050525132405.03a6f268@strange-brew> References: <200504060315.j363FFpm020258@hestia.native6.com> <20050406123322.13307cb8.ipng@69706e6720323030352d30312d31340a.nosense.org> <200504060315.j363FFpm020258@hestia.native6.com> <4.3.2.7.2.20050525132405.03a6f268@strange-brew> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "John Spence, CCSI, CCNA, CISSP" , v6ops@ops.ietf.org, Mark Smith From: Fred Baker Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Wed, 25 May 2005 08:59:19 -0700 To: "Gunter Van de Velde (gvandeve)" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117036095.638117"; x:"432200"; a:"rsa-sha1"; b:"nofws:8087"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"B3o0V85Vfw/NXrNiwcyHFqUJQ933zFZMwyhTpEeZwMS26bnBgkmuoAnVSUpFFYDxxPXancKo" "E/RQMynEBsvsSnB1LuR70iYthGxplvBdDNltEZ7zAfcT/WpzA2j7FnjJLucNkkIP8Uh5qMB500r" "OFF6A1w1vFwnk3opKWDqjgXU="; c:"From: Fred Baker "; c:"Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2]"; c:"Date: Wed, 25 May 2005 08:59:19 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Would the above be a good summary to place in the next revision of the > NAP draft? As stated, not quite (at least in my opinion), but pretty close. Note that in this note I am merely stating my own opinions. Regarding disruptiveness, when we talk about disruptive technologies, it is not that the network ceases working that is disruptive; businesses are disrupted. In the IPv6 deployment, the disruptive aspects for ISPs are that they have to upgrade equipment (perhaps hardware, surely software), which involves a testing effort and involves figuring out the best configurations for what they are trying to do. That deployment, even if the software is free and no hardware changes are required, can be pretty expensive. This is why the ISPs have been so willing to slow-roll the roll-out - they want to know that the money they expend is going to result in adequate ROI. And frankly, something that deploys in parallel and gives no added benefit is not going to convince consumers to buy, and therefore has limited ROI. So for the IPv6 roll-out to succeed, there actually has to be a disruption of some kind - either new services available as a result, or a change in the ISP cost model, or new applications available to consumers that would not otherwise be available, or something. The extra level of security of a simple stateful firewall is, I agree, a good thing. I wouldn't describe it as NAT-like; I think of it the other way around, that a NAT is stateful and provides some functions similar to a firewall, and therefore a NAT is in some respects like a firewall. Cisco's CBAC firewall (http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/ 121cgcr/secur_c/scprt3/scdcbac.htm) is a pretty good example of what you're describing; it allows into a network responses to queries generated from within the network plus configured accesses from outside, such as mail to the mail server and web traffic to the web server. I think it is important to state in the NAP draft the purpose of such a firewall, both in terms of what it does and what it doesn't. A firewall doesn't secure a network, because many attacks come from inside or are at a layer higher than the firewall can protect against. In the final analysis, every system has to be responsible for its own security, and every process running on a system has to be robust in the face of challenges like stack overflows and so on. What a firewall does is prevent a network administration from having to pay for bandwidth to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary. > A distributed security mechanism, only on the end-systems will > probably not be there in the next couple of years for organizations. Personally, I doubt that an end-system-only security mechanism will *ever* be widely deployed, for the reason above. End-system-only security mechanisms don't protect the network administration from being used as transit, or against ddos attacks against individual systems inside. > To conclude, it would be good to have a recommendation for the easy > enabling of a stateful filter to establish NAT like session security > and control, and in addition to that (as result of the peer-2-peer > potential of IPv6) the end-system OS's should have a similar > recommendation. I agree that it would be good to recommend that vendors provide a simple way to configure a stateful firewall, including ways to easily bypass it such as enabling simple access lists to allow stated application traffic to access stated systems, building a SIP Proxy or other application support tools into such a firewall system, perhaps providing a subscription service in which an authorized user could subscribe to let certain applications come to his/her machine, etc. Such controls should of course be user user control, and in the last case, with appropriate AAA support. On May 25, 2005, at 5:02 AM, Gunter Van de Velde (gvandeve) wrote: > Hi Mark, All, > > I'm just falling back to this thread. > > >> Yes, because I think that as the move to IPv6 is relatively disruptive >> ("disruptive" in the sense that deploying a new technology on a large >> scale is usually disruptive no matter how well it is done - it is >> always >> a significant change) it is a good opportunity also (re)introduce >> ideas >> that we know in the long term will be beneficial. I think the >> introduction of IPv6 is also an opportunity to change the way people >> think and do things with and in their network. > > > I'm not sure that i fully agree with the disruptive aspect of adding > IPv6 services to > a network infrastructure from technical perspective. One can add IPv6 > as protocol > in addition to IPv4 of an IP network without interrupting the network > too much by use > of the already planned and existing maintenance windows. In most cases > the end-users > won't even notice a difference or the glitches in the network when the > ISIS or BGP > experience sessions flaps due to capability exchanges. In this case > there would be > a nice coexistence of existing IPv4 services and additional IPv6 > services can be provided > after the migration. The next steps could be done step-by-step. > > For the end-systems, they can be made IPv6 aware if they are not > already. > This should/will be a none issue with most of the current existing > OS's, not? > > To come back at the NAP aspects of the thread, these systems may or > may not have their > own protection against external influences and the network may exist > out of different > OS's (and potentially different flavors or releases of the OS's) which > each implement > their own version of a security model. This sounds like a nice way to > create complexity > and confusion about the existing security model used. For the > home-user this could be > sufficient, however i do like the idea that for home-users there > should be some direction > or statement that by a simple configuration he > must be able to > enable the state-full filtering mechanism in a NAT-like manner, this > not to break the > end-to-end model, but more to have this extra level of security. > > A distributed security mechanism, only on the end-systems will > probably not be there > in the next couple of years for organizations. The question is also if > there is need for > real 'none-filtered peer-2-peer communication between inside and > outside an organization. > However, a stateful filter placed at the boundary between inside and > outside can limit these > kind of connections based on certain configurable rules. The principle > would be the same as > when using a stateful address translator. > > To conclude, it would be good to have a recommendation for the easy > enabling of > a stateful filter to establish NAT like session security and control, > and in addition to that > (as result of the peer-2-peer potential of IPv6) the end-system OS's > should have a similar > recommendation. > > > Groetjes, > G/ > > > > At 13:27 6/04/2005 +0930, Mark Smith wrote: >> Hi John, >> >> On Tue, 5 Apr 2005 20:15:10 -0700 >> "John Spence, CCSI, CCNA, CISSP" wrote: >> >> > >> > Mark; >> > >> > Good points all. I agree, host firewall is evolving fast, and will >> be more >> > and more commonly deployed in the future. >> > >> > But are you suggesting that the NAP draft, in an effort to push >> peer-to-peer >> > "all the way", advocate removing edge firewalls and ACL in favor of >> only >> > deploying distributed firewalls? I think that would be going way >> to far. >> > The best way to pry NAT out of the hands of IPv4-oriented security >> managers >> > is to make the case *for* stateful firewalls over NAT routers - not >> to try >> > to suggest, at this stage, that even the stateful firewalls should >> be pulled >> > in favor of having the end nodes use host firewalls to support >> peer-to-peer >> > networking in the purest sense. >> >> Yes and no :-) >> >> Yes, because I think that as the move to IPv6 is relatively disruptive >> ("disruptive" in the sense that deploying a new technology on a large >> scale is usually disruptive no matter how well it is done - it is >> always >> a significant change) it is a good opportunity also (re)introduce >> ideas >> that we know in the long term will be beneficial. I think the >> introduction of IPv6 is also an opportunity to change the way people >> think and do things with and in their network. >> >> For example, as I mentioned, modern OSes have firewalling out of the >> box. From what I'm aware of, the only component missing, at least in >> the >> commercial space i.e., products you can buy, for scalable host based >> firewalling is mechanisms to deploy the (corporate) firewalling policy >> to the host. I think it just may be around the corner though - server >> based authentication services obviously exist, user "login scripts" >> that >> are pushed to the users host after authentication have been around a >> for >> a long time, its just a matter of a commercially available mechanism >> to >> push firewall policy to the user host in a similar manner to login >> scripts. >> >> No, because I realise that people don't necessarily like change, and >> also like to apply existing and understood models of operation to new >> environments or technologies. >> >> Summarising, I'd like to see IPv6 used as an opporunity to introduce >> and >> promote new thinking (well old, but new to most IPv4 people), and >> provide "new" models of deployment. However, for those who are more >> resistant to new thinking, identify "old" IPv4 mechanisms and how they >> can work with IPv6 as a "fall back" alternative to new thinking or as >> part of a migrationary path to "new thinking". >> >> Regards, >> Mark. >> -- >> >> The Internet's nature is peer to peer. > From owner-v6ops@ops.ietf.org Wed May 25 16:36:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27436 for ; Wed, 25 May 2005 16:36:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Db2Zq-0002kI-4V for v6ops-data@psg.com; Wed, 25 May 2005 20:34:06 +0000 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Db2Zl-0002jj-DG for v6ops@ops.ietf.org; Wed, 25 May 2005 20:34:01 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id DE558AE; Wed, 25 May 2005 16:31:37 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 16:33:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Wed, 25 May 2005 16:33:50 -0400 Message-ID: <936A4045C332714F975800409DE092404A11AF@tayexc14.americas.cpqcorp.net> Thread-Topic: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Thread-Index: AcVhQyb6Xngl0YxuQhmNg4N+MPrtnwAJRH8A From: "Bound, Jim" To: "Fred Baker" , "Gunter Van de Velde (gvandeve)" Cc: "John Spence, CCSI, CCNA, CISSP" , , "Mark Smith" X-OriginalArrivalTime: 25 May 2005 20:33:53.0139 (UTC) FILETIME=[10CF0430:01C56169] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Just as note I agree with Fred but with one caveat, that is again just my opinion and not clear it is relative but will share it. I believe end-to-end security will be the norm in the future and believe it to be a requirement for true end-to-end trust model. But, I do believe the network must remain secure too. I envision the Firewall to become a Security Manager and a set of nodes being routers and servers at the network edge that will be able to watch the network for attack and know what is legal end-to-end secure traffic and when an attack happens. When the attack is obvious end-to-end is shut down and the Security Manager becomes similar to traditional firewall. I am not the only one with this view though and it is being discussed and prototypes will happen to analyze this thought further in both the public and private sectors. NAP is a useful spec but lets not make it the holy grail here and keep it simple folks and not over indulge in trying to predict or tell the market what to do, because that is not our IETF job IMO. thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > Sent: Wednesday, May 25, 2005 11:59 AM > To: Gunter Van de Velde (gvandeve) > Cc: John Spence, CCSI, CCNA, CISSP; v6ops@ops.ietf.org; Mark Smith > Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] >=20 >=20 > > Would the above be a good summary to place in the next=20 > revision of the =20 > > NAP draft? >=20 > As stated, not quite (at least in my opinion), but pretty=20 > close. Note =20 > that in this note I am merely stating my own opinions. >=20 > Regarding disruptiveness, when we talk about disruptive=20 > technologies, =20 > it is not that the network ceases working that is disruptive; =20 > businesses are disrupted. In the IPv6 deployment, the disruptive =20 > aspects for ISPs are that they have to upgrade equipment (perhaps =20 > hardware, surely software), which involves a testing effort and =20 > involves figuring out the best configurations for what they=20 > are trying =20 > to do. That deployment, even if the software is free and no hardware =20 > changes are required, can be pretty expensive. This is why the ISPs =20 > have been so willing to slow-roll the roll-out - they want to=20 > know that =20 > the money they expend is going to result in adequate ROI. And=20 > frankly, =20 > something that deploys in parallel and gives no added benefit is not =20 > going to convince consumers to buy, and therefore has limited=20 > ROI. So =20 > for the IPv6 roll-out to succeed, there actually has to be a=20 > disruption =20 > of some kind - either new services available as a result, or=20 > a change =20 > in the ISP cost model, or new applications available to=20 > consumers that =20 > would not otherwise be available, or something. >=20 > The extra level of security of a simple stateful firewall is,=20 > I agree, =20 > a good thing. I wouldn't describe it as NAT-like; I think of it the =20 > other way around, that a NAT is stateful and provides some functions =20 > similar to a firewall, and therefore a NAT is in some=20 > respects like a =20 > firewall. Cisco's CBAC firewall =20 > (http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/=20 > 121cgcr/secur_c/scprt3/scdcbac.htm) is a pretty good example of what =20 > you're describing; it allows into a network responses to queries =20 > generated from within the network plus configured accesses from =20 > outside, such as mail to the mail server and web traffic to the web =20 > server. >=20 > I think it is important to state in the NAP draft the purpose=20 > of such a =20 > firewall, both in terms of what it does and what it doesn't.=20 > A firewall =20 > doesn't secure a network, because many attacks come from=20 > inside or are =20 > at a layer higher than the firewall can protect against. In=20 > the final =20 > analysis, every system has to be responsible for its own=20 > security, and =20 > every process running on a system has to be robust in the face of =20 > challenges like stack overflows and so on. What a firewall does is =20 > prevent a network administration from having to pay for bandwidth to =20 > carry unauthorized traffic, and in so doing reduce the=20 > probability of =20 > certain kinds of attacks across the protected boundary. >=20 > > A distributed security mechanism, only on the end-systems will =20 > > probably not be there in the next couple of years for organizations. >=20 > Personally, I doubt that an end-system-only security mechanism will =20 > *ever* be widely deployed, for the reason above. End-system-only =20 > security mechanisms don't protect the network administration=20 > from being =20 > used as transit, or against ddos attacks against individual systems =20 > inside. >=20 > > To conclude, it would be good to have a recommendation for=20 > the easy =20 > > enabling of a stateful filter to establish NAT like session=20 > security =20 > > and control, and in addition to that (as result of the peer-2-peer =20 > > potential of IPv6) the end-system OS's should have a similar =20 > > recommendation. >=20 > I agree that it would be good to recommend that vendors provide a =20 > simple way to configure a stateful firewall, including ways=20 > to easily =20 > bypass it such as enabling simple access lists to allow stated =20 > application traffic to access stated systems, building a SIP=20 > Proxy or =20 > other application support tools into such a firewall system, perhaps =20 > providing a subscription service in which an authorized user could =20 > subscribe to let certain applications come to his/her machine, etc. =20 > Such controls should of course be user user control, and in the last =20 > case, with appropriate AAA support. >=20 > On May 25, 2005, at 5:02 AM, Gunter Van de Velde (gvandeve) wrote: >=20 > > Hi Mark, All, > > > > I'm just falling back to this thread. > > > > > >> Yes, because I think that as the move to IPv6 is=20 > relatively disruptive > >> ("disruptive" in the sense that deploying a new technology=20 > on a large > >> scale is usually disruptive no matter how well it is done - it is =20 > >> always > >> a significant change) it is a good opportunity also (re)introduce =20 > >> ideas > >> that we know in the long term will be beneficial. I think the > >> introduction of IPv6 is also an opportunity to change the=20 > way people > >> think and do things with and in their network. > > > > > > I'm not sure that i fully agree with the disruptive aspect=20 > of adding =20 > > IPv6 services to > > a network infrastructure from technical perspective. One=20 > can add IPv6 =20 > > as protocol > > in addition to IPv4 of an IP network without interrupting=20 > the network =20 > > too much by use > > of the already planned and existing maintenance windows. In=20 > most cases =20 > > the end-users > > won't even notice a difference or the glitches in the=20 > network when the =20 > > ISIS or BGP > > experience sessions flaps due to capability exchanges. In=20 > this case =20 > > there would be > > a nice coexistence of existing IPv4 services and additional IPv6 =20 > > services can be provided > > after the migration. The next steps could be done step-by-step. > > > > For the end-systems, they can be made IPv6 aware if they are not =20 > > already. > > This should/will be a none issue with most of the current existing =20 > > OS's, not? > > > > To come back at the NAP aspects of the thread, these=20 > systems may or =20 > > may not have their > > own protection against external influences and the network=20 > may exist =20 > > out of different > > OS's (and potentially different flavors or releases of the=20 > OS's) which =20 > > each implement > > their own version of a security model. This sounds like a=20 > nice way to =20 > > create complexity > > and confusion about the existing security model used. For the =20 > > home-user this could be > > sufficient, however i do like the idea that for home-users there =20 > > should be some direction > > or statement that by a simple configuration he =20 > > must be able to > > enable the state-full filtering mechanism in a NAT-like=20 > manner, this =20 > > not to break the > > end-to-end model, but more to have this extra level of security. > > > > A distributed security mechanism, only on the end-systems will =20 > > probably not be there > > in the next couple of years for organizations. The question=20 > is also if =20 > > there is need for > > real 'none-filtered peer-2-peer communication between inside and =20 > > outside an organization. > > However, a stateful filter placed at the boundary between=20 > inside and =20 > > outside can limit these > > kind of connections based on certain configurable rules.=20 > The principle =20 > > would be the same as > > when using a stateful address translator. > > > > To conclude, it would be good to have a recommendation for=20 > the easy =20 > > enabling of > > a stateful filter to establish NAT like session security=20 > and control, =20 > > and in addition to that > > (as result of the peer-2-peer potential of IPv6) the=20 > end-system OS's =20 > > should have a similar > > recommendation. > > > > > > Groetjes, > > G/ > > > > > > > > At 13:27 6/04/2005 +0930, Mark Smith wrote: > >> Hi John, > >> > >> On Tue, 5 Apr 2005 20:15:10 -0700 > >> "John Spence, CCSI, CCNA, CISSP" wrote: > >> > >> > > >> > Mark; > >> > > >> > Good points all. I agree, host firewall is evolving=20 > fast, and will =20 > >> be more > >> > and more commonly deployed in the future. > >> > > >> > But are you suggesting that the NAP draft, in an effort to push =20 > >> peer-to-peer > >> > "all the way", advocate removing edge firewalls and ACL=20 > in favor of =20 > >> only > >> > deploying distributed firewalls? I think that would be=20 > going way =20 > >> to far. > >> > The best way to pry NAT out of the hands of=20 > IPv4-oriented security =20 > >> managers > >> > is to make the case *for* stateful firewalls over NAT=20 > routers - not =20 > >> to try > >> > to suggest, at this stage, that even the stateful=20 > firewalls should =20 > >> be pulled > >> > in favor of having the end nodes use host firewalls to support =20 > >> peer-to-peer > >> > networking in the purest sense. > >> > >> Yes and no :-) > >> > >> Yes, because I think that as the move to IPv6 is=20 > relatively disruptive > >> ("disruptive" in the sense that deploying a new technology=20 > on a large > >> scale is usually disruptive no matter how well it is done - it is =20 > >> always > >> a significant change) it is a good opportunity also (re)introduce =20 > >> ideas > >> that we know in the long term will be beneficial. I think the > >> introduction of IPv6 is also an opportunity to change the=20 > way people > >> think and do things with and in their network. > >> > >> For example, as I mentioned, modern OSes have firewalling=20 > out of the > >> box. From what I'm aware of, the only component missing,=20 > at least in =20 > >> the > >> commercial space i.e., products you can buy, for scalable=20 > host based > >> firewalling is mechanisms to deploy the (corporate)=20 > firewalling policy > >> to the host. I think it just may be around the corner=20 > though - server > >> based authentication services obviously exist, user "login=20 > scripts" =20 > >> that > >> are pushed to the users host after authentication have=20 > been around a =20 > >> for > >> a long time, its just a matter of a commercially available=20 > mechanism =20 > >> to > >> push firewall policy to the user host in a similar manner to login > >> scripts. > >> > >> No, because I realise that people don't necessarily like=20 > change, and > >> also like to apply existing and understood models of=20 > operation to new > >> environments or technologies. > >> > >> Summarising, I'd like to see IPv6 used as an opporunity to=20 > introduce =20 > >> and > >> promote new thinking (well old, but new to most IPv4 people), and > >> provide "new" models of deployment. However, for those who are more > >> resistant to new thinking, identify "old" IPv4 mechanisms=20 > and how they > >> can work with IPv6 as a "fall back" alternative to new=20 > thinking or as > >> part of a migrationary path to "new thinking". > >> > >> Regards, > >> Mark. > >> -- > >> > >> The Internet's nature is peer to peer. > > >=20 >=20 From owner-v6ops@ops.ietf.org Wed May 25 17:37:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00903 for ; Wed, 25 May 2005 17:37:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Db3Xp-00088Z-0w for v6ops-data@psg.com; Wed, 25 May 2005 21:36:05 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1Db3Xi-00087D-Hn for v6ops@ops.ietf.org; Wed, 25 May 2005 21:35:59 +0000 Received: from [10.10.10.100] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001037859.msg for ; Wed, 25 May 2005 23:38:59 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 25 May 2005 23:33:48 +0200 Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" , "Bound, Jim" , Fred Baker , "Gunter Van de Velde (gvandeve)" CC: "John Spence, CCSI, CCNA, CISSP" , Mark Smith Message-ID: In-Reply-To: <936A4045C332714F975800409DE092404A11AF@tayexc14.americas.cpqcorp.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 25 May 2005 23:40:41 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jim, Fully agree. This is what we are doing in the distributed security work (some I-Ds being updated now). We call it instead of security manager "security policy manager". The function is to provide a policy for the nodes in the network, either a default one or a case by case one, or mixture of both, and act as the master lock, in case anything is broken. Regards, Jordi > De: "Bound, Jim" > Responder a: > Fecha: Wed, 25 May 2005 16:33:50 -0400 > Para: Fred Baker , "Gunter Van de Velde (gvandeve)" > > CC: "John Spence, CCSI, CCNA, CISSP" , > , Mark Smith > > Asunto: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] > > Just as note I agree with Fred but with one caveat, that is again just > my opinion and not clear it is relative but will share it. I believe > end-to-end security will be the norm in the future and believe it to be > a requirement for true end-to-end trust model. But, I do believe the > network must remain secure too. I envision the Firewall to become a > Security Manager and a set of nodes being routers and servers at the > network edge that will be able to watch the network for attack and know > what is legal end-to-end secure traffic and when an attack happens. > When the attack is obvious end-to-end is shut down and the Security > Manager becomes similar to traditional firewall. I am not the only one > with this view though and it is being discussed and prototypes will > happen to analyze this thought further in both the public and private > sectors. > > NAP is a useful spec but lets not make it the holy grail here and keep > it simple folks and not over indulge in trying to predict or tell the > market what to do, because that is not our IETF job IMO. > > thanks > /jim > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker >> Sent: Wednesday, May 25, 2005 11:59 AM >> To: Gunter Van de Velde (gvandeve) >> Cc: John Spence, CCSI, CCNA, CISSP; v6ops@ops.ietf.org; Mark Smith >> Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] >> >> >>> Would the above be a good summary to place in the next >> revision of the >>> NAP draft? >> >> As stated, not quite (at least in my opinion), but pretty >> close. Note >> that in this note I am merely stating my own opinions. >> >> Regarding disruptiveness, when we talk about disruptive >> technologies, >> it is not that the network ceases working that is disruptive; >> businesses are disrupted. In the IPv6 deployment, the disruptive >> aspects for ISPs are that they have to upgrade equipment (perhaps >> hardware, surely software), which involves a testing effort and >> involves figuring out the best configurations for what they >> are trying >> to do. That deployment, even if the software is free and no hardware >> changes are required, can be pretty expensive. This is why the ISPs >> have been so willing to slow-roll the roll-out - they want to >> know that >> the money they expend is going to result in adequate ROI. And >> frankly, >> something that deploys in parallel and gives no added benefit is not >> going to convince consumers to buy, and therefore has limited >> ROI. So >> for the IPv6 roll-out to succeed, there actually has to be a >> disruption >> of some kind - either new services available as a result, or >> a change >> in the ISP cost model, or new applications available to >> consumers that >> would not otherwise be available, or something. >> >> The extra level of security of a simple stateful firewall is, >> I agree, >> a good thing. I wouldn't describe it as NAT-like; I think of it the >> other way around, that a NAT is stateful and provides some functions >> similar to a firewall, and therefore a NAT is in some >> respects like a >> firewall. Cisco's CBAC firewall >> (http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/ >> 121cgcr/secur_c/scprt3/scdcbac.htm) is a pretty good example of what >> you're describing; it allows into a network responses to queries >> generated from within the network plus configured accesses from >> outside, such as mail to the mail server and web traffic to the web >> server. >> >> I think it is important to state in the NAP draft the purpose >> of such a >> firewall, both in terms of what it does and what it doesn't. >> A firewall >> doesn't secure a network, because many attacks come from >> inside or are >> at a layer higher than the firewall can protect against. In >> the final >> analysis, every system has to be responsible for its own >> security, and >> every process running on a system has to be robust in the face of >> challenges like stack overflows and so on. What a firewall does is >> prevent a network administration from having to pay for bandwidth to >> carry unauthorized traffic, and in so doing reduce the >> probability of >> certain kinds of attacks across the protected boundary. >> >>> A distributed security mechanism, only on the end-systems will >>> probably not be there in the next couple of years for organizations. >> >> Personally, I doubt that an end-system-only security mechanism will >> *ever* be widely deployed, for the reason above. End-system-only >> security mechanisms don't protect the network administration >> from being >> used as transit, or against ddos attacks against individual systems >> inside. >> >>> To conclude, it would be good to have a recommendation for >> the easy >>> enabling of a stateful filter to establish NAT like session >> security >>> and control, and in addition to that (as result of the peer-2-peer >>> potential of IPv6) the end-system OS's should have a similar >>> recommendation. >> >> I agree that it would be good to recommend that vendors provide a >> simple way to configure a stateful firewall, including ways >> to easily >> bypass it such as enabling simple access lists to allow stated >> application traffic to access stated systems, building a SIP >> Proxy or >> other application support tools into such a firewall system, perhaps >> providing a subscription service in which an authorized user could >> subscribe to let certain applications come to his/her machine, etc. >> Such controls should of course be user user control, and in the last >> case, with appropriate AAA support. >> >> On May 25, 2005, at 5:02 AM, Gunter Van de Velde (gvandeve) wrote: >> >>> Hi Mark, All, >>> >>> I'm just falling back to this thread. >>> >>> >>>> Yes, because I think that as the move to IPv6 is >> relatively disruptive >>>> ("disruptive" in the sense that deploying a new technology >> on a large >>>> scale is usually disruptive no matter how well it is done - it is >>>> always >>>> a significant change) it is a good opportunity also (re)introduce >>>> ideas >>>> that we know in the long term will be beneficial. I think the >>>> introduction of IPv6 is also an opportunity to change the >> way people >>>> think and do things with and in their network. >>> >>> >>> I'm not sure that i fully agree with the disruptive aspect >> of adding >>> IPv6 services to >>> a network infrastructure from technical perspective. One >> can add IPv6 >>> as protocol >>> in addition to IPv4 of an IP network without interrupting >> the network >>> too much by use >>> of the already planned and existing maintenance windows. In >> most cases >>> the end-users >>> won't even notice a difference or the glitches in the >> network when the >>> ISIS or BGP >>> experience sessions flaps due to capability exchanges. In >> this case >>> there would be >>> a nice coexistence of existing IPv4 services and additional IPv6 >>> services can be provided >>> after the migration. The next steps could be done step-by-step. >>> >>> For the end-systems, they can be made IPv6 aware if they are not >>> already. >>> This should/will be a none issue with most of the current existing >>> OS's, not? >>> >>> To come back at the NAP aspects of the thread, these >> systems may or >>> may not have their >>> own protection against external influences and the network >> may exist >>> out of different >>> OS's (and potentially different flavors or releases of the >> OS's) which >>> each implement >>> their own version of a security model. This sounds like a >> nice way to >>> create complexity >>> and confusion about the existing security model used. For the >>> home-user this could be >>> sufficient, however i do like the idea that for home-users there >>> should be some direction >>> or statement that by a simple configuration he >>> must be able to >>> enable the state-full filtering mechanism in a NAT-like >> manner, this >>> not to break the >>> end-to-end model, but more to have this extra level of security. >>> >>> A distributed security mechanism, only on the end-systems will >>> probably not be there >>> in the next couple of years for organizations. The question >> is also if >>> there is need for >>> real 'none-filtered peer-2-peer communication between inside and >>> outside an organization. >>> However, a stateful filter placed at the boundary between >> inside and >>> outside can limit these >>> kind of connections based on certain configurable rules. >> The principle >>> would be the same as >>> when using a stateful address translator. >>> >>> To conclude, it would be good to have a recommendation for >> the easy >>> enabling of >>> a stateful filter to establish NAT like session security >> and control, >>> and in addition to that >>> (as result of the peer-2-peer potential of IPv6) the >> end-system OS's >>> should have a similar >>> recommendation. >>> >>> >>> Groetjes, >>> G/ >>> >>> >>> >>> At 13:27 6/04/2005 +0930, Mark Smith wrote: >>>> Hi John, >>>> >>>> On Tue, 5 Apr 2005 20:15:10 -0700 >>>> "John Spence, CCSI, CCNA, CISSP" wrote: >>>> >>>>> >>>>> Mark; >>>>> >>>>> Good points all. I agree, host firewall is evolving >> fast, and will >>>> be more >>>>> and more commonly deployed in the future. >>>>> >>>>> But are you suggesting that the NAP draft, in an effort to push >>>> peer-to-peer >>>>> "all the way", advocate removing edge firewalls and ACL >> in favor of >>>> only >>>>> deploying distributed firewalls? I think that would be >> going way >>>> to far. >>>>> The best way to pry NAT out of the hands of >> IPv4-oriented security >>>> managers >>>>> is to make the case *for* stateful firewalls over NAT >> routers - not >>>> to try >>>>> to suggest, at this stage, that even the stateful >> firewalls should >>>> be pulled >>>>> in favor of having the end nodes use host firewalls to support >>>> peer-to-peer >>>>> networking in the purest sense. >>>> >>>> Yes and no :-) >>>> >>>> Yes, because I think that as the move to IPv6 is >> relatively disruptive >>>> ("disruptive" in the sense that deploying a new technology >> on a large >>>> scale is usually disruptive no matter how well it is done - it is >>>> always >>>> a significant change) it is a good opportunity also (re)introduce >>>> ideas >>>> that we know in the long term will be beneficial. I think the >>>> introduction of IPv6 is also an opportunity to change the >> way people >>>> think and do things with and in their network. >>>> >>>> For example, as I mentioned, modern OSes have firewalling >> out of the >>>> box. From what I'm aware of, the only component missing, >> at least in >>>> the >>>> commercial space i.e., products you can buy, for scalable >> host based >>>> firewalling is mechanisms to deploy the (corporate) >> firewalling policy >>>> to the host. I think it just may be around the corner >> though - server >>>> based authentication services obviously exist, user "login >> scripts" >>>> that >>>> are pushed to the users host after authentication have >> been around a >>>> for >>>> a long time, its just a matter of a commercially available >> mechanism >>>> to >>>> push firewall policy to the user host in a similar manner to login >>>> scripts. >>>> >>>> No, because I realise that people don't necessarily like >> change, and >>>> also like to apply existing and understood models of >> operation to new >>>> environments or technologies. >>>> >>>> Summarising, I'd like to see IPv6 used as an opporunity to >> introduce >>>> and >>>> promote new thinking (well old, but new to most IPv4 people), and >>>> provide "new" models of deployment. However, for those who are more >>>> resistant to new thinking, identify "old" IPv4 mechanisms >> and how they >>>> can work with IPv6 as a "fall back" alternative to new >> thinking or as >>>> part of a migrationary path to "new thinking". >>>> >>>> Regards, >>>> Mark. >>>> -- >>>> >>>> The Internet's nature is peer to peer. >>> >> >> > ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed May 25 21:01:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18115 for ; Wed, 25 May 2005 21:01:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Db6hk-0003U0-3j for v6ops-data@psg.com; Thu, 26 May 2005 00:58:32 +0000 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Db6hc-0003Rh-KQ for v6ops@ops.ietf.org; Thu, 26 May 2005 00:58:25 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 53664126; Wed, 25 May 2005 20:58:21 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 20:58:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Wed, 25 May 2005 20:58:06 -0400 Message-ID: <936A4045C332714F975800409DE092404A1256@tayexc14.americas.cpqcorp.net> Thread-Topic: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Thread-Index: AcVhcc2I0f4AZbkoQOWj8usGgS0ucQAG+AWA From: "Bound, Jim" To: , , "Fred Baker" , "Gunter Van de Velde (gvandeve)" Cc: "John Spence, CCSI, CCNA, CISSP" , "Mark Smith" X-OriginalArrivalTime: 26 May 2005 00:58:09.0374 (UTC) FILETIME=[FBDC77E0:01C5618D] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Jordi, Security Policy Manager is a far better connotation. I also like the ITU x.805 Security Model very much too, contributed by Bell Labs to ITU. What security will be will not be driven by vendors or a standards body but by the user community I also believe. thanks /jim=20 > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es]=20 > Sent: Wednesday, May 25, 2005 5:34 PM > To: v6ops@ops.ietf.org; Bound, Jim; Fred Baker; Gunter Van de=20 > Velde (gvandeve) > Cc: John Spence, CCSI, CCNA, CISSP; Mark Smith > Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] >=20 > Hi Jim, >=20 > Fully agree. This is what we are doing in the distributed=20 > security work > (some I-Ds being updated now). We call it instead of security manager > "security policy manager". The function is to provide a=20 > policy for the nodes > in the network, either a default one or a case by case one,=20 > or mixture of > both, and act as the master lock, in case anything is broken. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > > De: "Bound, Jim" > > Responder a: > > Fecha: Wed, 25 May 2005 16:33:50 -0400 > > Para: Fred Baker , "Gunter Van de Velde (gvandeve)" > > > > CC: "John Spence, CCSI, CCNA, CISSP" , > > , Mark Smith > > > > Asunto: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] > >=20 > > Just as note I agree with Fred but with one caveat, that is=20 > again just > > my opinion and not clear it is relative but will share it. =20 > I believe > > end-to-end security will be the norm in the future and=20 > believe it to be > > a requirement for true end-to-end trust model. But, I do believe the > > network must remain secure too. I envision the Firewall to become a > > Security Manager and a set of nodes being routers and servers at the > > network edge that will be able to watch the network for=20 > attack and know > > what is legal end-to-end secure traffic and when an attack happens. > > When the attack is obvious end-to-end is shut down and the Security > > Manager becomes similar to traditional firewall. I am not=20 > the only one > > with this view though and it is being discussed and prototypes will > > happen to analyze this thought further in both the public=20 > and private > > sectors. > >=20 > > NAP is a useful spec but lets not make it the holy grail=20 > here and keep > > it simple folks and not over indulge in trying to predict=20 > or tell the > > market what to do, because that is not our IETF job IMO. > >=20 > > thanks > > /jim=20 > >=20 > >> -----Original Message----- > >> From: owner-v6ops@ops.ietf.org > >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > >> Sent: Wednesday, May 25, 2005 11:59 AM > >> To: Gunter Van de Velde (gvandeve) > >> Cc: John Spence, CCSI, CCNA, CISSP; v6ops@ops.ietf.org; Mark Smith > >> Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] > >>=20 > >>=20 > >>> Would the above be a good summary to place in the next > >> revision of the=20 > >>> NAP draft? > >>=20 > >> As stated, not quite (at least in my opinion), but pretty > >> close. Note =20 > >> that in this note I am merely stating my own opinions. > >>=20 > >> Regarding disruptiveness, when we talk about disruptive > >> technologies, =20 > >> it is not that the network ceases working that is disruptive; > >> businesses are disrupted. In the IPv6 deployment, the disruptive > >> aspects for ISPs are that they have to upgrade equipment (perhaps > >> hardware, surely software), which involves a testing effort and > >> involves figuring out the best configurations for what they > >> are trying =20 > >> to do. That deployment, even if the software is free and=20 > no hardware > >> changes are required, can be pretty expensive. This is why the ISPs > >> have been so willing to slow-roll the roll-out - they want to > >> know that =20 > >> the money they expend is going to result in adequate ROI. And > >> frankly, =20 > >> something that deploys in parallel and gives no added=20 > benefit is not > >> going to convince consumers to buy, and therefore has limited > >> ROI. So =20 > >> for the IPv6 roll-out to succeed, there actually has to be a > >> disruption =20 > >> of some kind - either new services available as a result, or > >> a change =20 > >> in the ISP cost model, or new applications available to > >> consumers that =20 > >> would not otherwise be available, or something. > >>=20 > >> The extra level of security of a simple stateful firewall is, > >> I agree, =20 > >> a good thing. I wouldn't describe it as NAT-like; I think of it the > >> other way around, that a NAT is stateful and provides some=20 > functions > >> similar to a firewall, and therefore a NAT is in some > >> respects like a=20 > >> firewall. Cisco's CBAC firewall > >> (http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/ > >> 121cgcr/secur_c/scprt3/scdcbac.htm) is a pretty good=20 > example of what > >> you're describing; it allows into a network responses to queries > >> generated from within the network plus configured accesses from > >> outside, such as mail to the mail server and web traffic to the web > >> server. > >>=20 > >> I think it is important to state in the NAP draft the purpose > >> of such a =20 > >> firewall, both in terms of what it does and what it doesn't. > >> A firewall =20 > >> doesn't secure a network, because many attacks come from > >> inside or are =20 > >> at a layer higher than the firewall can protect against. In > >> the final =20 > >> analysis, every system has to be responsible for its own > >> security, and =20 > >> every process running on a system has to be robust in the face of > >> challenges like stack overflows and so on. What a firewall does is > >> prevent a network administration from having to pay for=20 > bandwidth to > >> carry unauthorized traffic, and in so doing reduce the > >> probability of =20 > >> certain kinds of attacks across the protected boundary. > >>=20 > >>> A distributed security mechanism, only on the end-systems will > >>> probably not be there in the next couple of years for=20 > organizations. > >>=20 > >> Personally, I doubt that an end-system-only security mechanism will > >> *ever* be widely deployed, for the reason above. End-system-only > >> security mechanisms don't protect the network administration > >> from being =20 > >> used as transit, or against ddos attacks against individual systems > >> inside. > >>=20 > >>> To conclude, it would be good to have a recommendation for > >> the easy =20 > >>> enabling of a stateful filter to establish NAT like session > >> security =20 > >>> and control, and in addition to that (as result of the peer-2-peer > >>> potential of IPv6) the end-system OS's should have a similar > >>> recommendation. > >>=20 > >> I agree that it would be good to recommend that vendors provide a > >> simple way to configure a stateful firewall, including ways > >> to easily =20 > >> bypass it such as enabling simple access lists to allow stated > >> application traffic to access stated systems, building a SIP > >> Proxy or =20 > >> other application support tools into such a firewall=20 > system, perhaps > >> providing a subscription service in which an authorized user could > >> subscribe to let certain applications come to his/her machine, etc. > >> Such controls should of course be user user control, and=20 > in the last > >> case, with appropriate AAA support. > >>=20 > >> On May 25, 2005, at 5:02 AM, Gunter Van de Velde (gvandeve) wrote: > >>=20 > >>> Hi Mark, All, > >>>=20 > >>> I'm just falling back to this thread. > >>>=20 > >>> > >>>> Yes, because I think that as the move to IPv6 is > >> relatively disruptive > >>>> ("disruptive" in the sense that deploying a new technology > >> on a large > >>>> scale is usually disruptive no matter how well it is done - it is > >>>> always > >>>> a significant change) it is a good opportunity also (re)introduce > >>>> ideas > >>>> that we know in the long term will be beneficial. I think the > >>>> introduction of IPv6 is also an opportunity to change the > >> way people > >>>> think and do things with and in their network. > >>> > >>>=20 > >>> I'm not sure that i fully agree with the disruptive aspect > >> of adding =20 > >>> IPv6 services to > >>> a network infrastructure from technical perspective. One > >> can add IPv6 =20 > >>> as protocol > >>> in addition to IPv4 of an IP network without interrupting > >> the network =20 > >>> too much by use > >>> of the already planned and existing maintenance windows. In > >> most cases =20 > >>> the end-users > >>> won't even notice a difference or the glitches in the > >> network when the > >>> ISIS or BGP > >>> experience sessions flaps due to capability exchanges. In > >> this case =20 > >>> there would be > >>> a nice coexistence of existing IPv4 services and additional IPv6 > >>> services can be provided > >>> after the migration. The next steps could be done step-by-step. > >>>=20 > >>> For the end-systems, they can be made IPv6 aware if they are not > >>> already. > >>> This should/will be a none issue with most of the current existing > >>> OS's, not? > >>>=20 > >>> To come back at the NAP aspects of the thread, these > >> systems may or =20 > >>> may not have their > >>> own protection against external influences and the network > >> may exist =20 > >>> out of different > >>> OS's (and potentially different flavors or releases of the > >> OS's) which =20 > >>> each implement > >>> their own version of a security model. This sounds like a > >> nice way to =20 > >>> create complexity > >>> and confusion about the existing security model used. For the > >>> home-user this could be > >>> sufficient, however i do like the idea that for home-users there > >>> should be some direction > >>> or statement that by a simple configuration he > >>> must be able to > >>> enable the state-full filtering mechanism in a NAT-like > >> manner, this =20 > >>> not to break the > >>> end-to-end model, but more to have this extra level of security. > >>>=20 > >>> A distributed security mechanism, only on the end-systems will > >>> probably not be there > >>> in the next couple of years for organizations. The question > >> is also if =20 > >>> there is need for > >>> real 'none-filtered peer-2-peer communication between inside and > >>> outside an organization. > >>> However, a stateful filter placed at the boundary between > >> inside and =20 > >>> outside can limit these > >>> kind of connections based on certain configurable rules. > >> The principle =20 > >>> would be the same as > >>> when using a stateful address translator. > >>>=20 > >>> To conclude, it would be good to have a recommendation for > >> the easy =20 > >>> enabling of > >>> a stateful filter to establish NAT like session security > >> and control, =20 > >>> and in addition to that > >>> (as result of the peer-2-peer potential of IPv6) the > >> end-system OS's=20 > >>> should have a similar > >>> recommendation. > >>>=20 > >>>=20 > >>> Groetjes, > >>> G/ > >>>=20 > >>>=20 > >>>=20 > >>> At 13:27 6/04/2005 +0930, Mark Smith wrote: > >>>> Hi John, > >>>>=20 > >>>> On Tue, 5 Apr 2005 20:15:10 -0700 > >>>> "John Spence, CCSI, CCNA, CISSP" wrote: > >>>>=20 > >>>>>=20 > >>>>> Mark; > >>>>>=20 > >>>>> Good points all. I agree, host firewall is evolving > >> fast, and will =20 > >>>> be more > >>>>> and more commonly deployed in the future. > >>>>>=20 > >>>>> But are you suggesting that the NAP draft, in an effort to push > >>>> peer-to-peer > >>>>> "all the way", advocate removing edge firewalls and ACL > >> in favor of =20 > >>>> only > >>>>> deploying distributed firewalls? I think that would be > >> going way =20 > >>>> to far. > >>>>> The best way to pry NAT out of the hands of > >> IPv4-oriented security > >>>> managers > >>>>> is to make the case *for* stateful firewalls over NAT > >> routers - not =20 > >>>> to try > >>>>> to suggest, at this stage, that even the stateful > >> firewalls should > >>>> be pulled > >>>>> in favor of having the end nodes use host firewalls to support > >>>> peer-to-peer > >>>>> networking in the purest sense. > >>>>=20 > >>>> Yes and no :-) > >>>>=20 > >>>> Yes, because I think that as the move to IPv6 is > >> relatively disruptive > >>>> ("disruptive" in the sense that deploying a new technology > >> on a large > >>>> scale is usually disruptive no matter how well it is done - it is > >>>> always > >>>> a significant change) it is a good opportunity also (re)introduce > >>>> ideas > >>>> that we know in the long term will be beneficial. I think the > >>>> introduction of IPv6 is also an opportunity to change the > >> way people > >>>> think and do things with and in their network. > >>>>=20 > >>>> For example, as I mentioned, modern OSes have firewalling > >> out of the > >>>> box. From what I'm aware of, the only component missing, > >> at least in =20 > >>>> the > >>>> commercial space i.e., products you can buy, for scalable > >> host based > >>>> firewalling is mechanisms to deploy the (corporate) > >> firewalling policy > >>>> to the host. I think it just may be around the corner > >> though - server > >>>> based authentication services obviously exist, user "login > >> scripts" =20 > >>>> that > >>>> are pushed to the users host after authentication have > >> been around a =20 > >>>> for > >>>> a long time, its just a matter of a commercially available > >> mechanism =20 > >>>> to > >>>> push firewall policy to the user host in a similar=20 > manner to login > >>>> scripts. > >>>>=20 > >>>> No, because I realise that people don't necessarily like > >> change, and > >>>> also like to apply existing and understood models of > >> operation to new > >>>> environments or technologies. > >>>>=20 > >>>> Summarising, I'd like to see IPv6 used as an opporunity to > >> introduce =20 > >>>> and > >>>> promote new thinking (well old, but new to most IPv4 people), and > >>>> provide "new" models of deployment. However, for those=20 > who are more > >>>> resistant to new thinking, identify "old" IPv4 mechanisms > >> and how they > >>>> can work with IPv6 as a "fall back" alternative to new > >> thinking or as > >>>> part of a migrationary path to "new thinking". > >>>>=20 > >>>> Regards, > >>>> Mark. > >>>> -- > >>>>=20 > >>>> The Internet's nature is peer to peer. > >>>=20 > >>=20 > >>=20 > >=20 >=20 >=20 >=20 >=20 > ************************************ > Barcelona 2005 Global IPv6 Summit > Registration open. Information available at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be=20 > privileged or confidential. The information is intended to be=20 > for the use of the individual(s) named above. If you are not=20 > the intended recipient be aware that any disclosure, copying,=20 > distribution or use of the contents of this information,=20 > including attached files, is prohibited. >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu May 26 04:08:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09097 for ; Thu, 26 May 2005 04:07:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbDNA-000HWb-CV for v6ops-data@psg.com; Thu, 26 May 2005 08:05:44 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbDN9-000HWL-Or for v6ops@ops.ietf.org; Thu, 26 May 2005 08:05:43 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 26 May 2005 01:05:43 -0700 X-IronPort-AV: i="3.93,138,1115017200"; d="scan'208"; a="638711965:sNHT32547532" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4Q85alw005560; Thu, 26 May 2005 01:05:36 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j4Q7sVT4002231; Thu, 26 May 2005 00:54:32 -0700 In-Reply-To: <936A4045C332714F975800409DE092404A11AF@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092404A11AF@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1a54b75b76fef72c52c155a114c0e5a4@cisco.com> Content-Transfer-Encoding: 7bit Cc: "John Spence, CCSI, CCNA, CISSP" , , "Mark Smith" , "Gunter Van de Velde (gvandeve)" From: Fred Baker Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Thu, 26 May 2005 01:05:33 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117094072.350412"; x:"432200"; a:"rsa-sha1"; b:"nofws:825"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"XbTKyocHNmlaznPm0QfFYvhWfFvgFETUzIeXhBb9olHI2RbS8gvGVdzJX65d+DuQtI7ldPHU" "YRUo2HNdwpe4n7VaciPzMeJQUjXJKmdR4pb/Rx3KuLVtq1ZfrIwDZgcCg50uD0V7T2YGkkT8wd1" "XrwEAiT6bMfvkTevFCXMM1zA="; c:"From: Fred Baker "; c:"Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2]"; c:"Date: Thu, 26 May 2005 01:05:33 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On May 25, 2005, at 1:33 PM, Bound, Jim wrote: > I believe end-to-end security will be the norm in the future and > believe it to be a requirement for true end-to-end trust model. But, I > do believe the network must remain secure too. yes and yes. The end system has to ensure that it is robust to attacks. The network needs to be able to prevent unauthorized use of its resources. The network can also help with various kinds of attacks - ddos being an obvious example, but ping sweeps and other things being also detectable and mitigable in the network. So using the network to detect and deal with things that an end system misses is reasonable. Please don't understand what I said to mean that I don't believe in an end-to-end trust model. What I said was that I didn't think that it was the only thing that would be implemented. I very much believe that there will be prophylactic services in the network for the foreseeable future, because there exist good network-related reasons for that to be true. From owner-v6ops@ops.ietf.org Thu May 26 08:19:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23857 for ; Thu, 26 May 2005 08:19:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbHI8-000C8x-SJ for v6ops-data@psg.com; Thu, 26 May 2005 12:16:48 +0000 Received: from [210.84.237.27] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbHI6-000C8U-3K for v6ops@ops.ietf.org; Thu, 26 May 2005 12:16:47 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 0C5EB62AAE; Thu, 26 May 2005 21:46:39 +0930 (CST) Date: Thu, 26 May 2005 21:46:38 +0930 From: Mark Smith To: Fred Baker , gvandeve@cisco.com Cc: jspence@native6.com, v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Message-Id: <20050526214638.41c532de.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <200504060315.j363FFpm020258@hestia.native6.com> <20050406123322.13307cb8.ipng@69706e6720323030352d30312d31340a.nosense.org> <200504060315.j363FFpm020258@hestia.native6.com> <4.3.2.7.2.20050525132405.03a6f268@strange-brew> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Gunter, Fred, On Wed, 25 May 2005 08:59:19 -0700 Fred Baker wrote: > > Regarding disruptiveness, when we talk about disruptive technologies, > it is not that the network ceases working that is disruptive; > businesses are disrupted. In the IPv6 deployment, the disruptive > aspects for ISPs are that they have to upgrade equipment (perhaps > hardware, surely software), which involves a testing effort and > involves figuring out the best configurations for what they are trying > to do. That deployment, even if the software is free and no hardware > changes are required, can be pretty expensive. This is why the ISPs > have been so willing to slow-roll the roll-out - they want to know that > the money they expend is going to result in adequate ROI. And frankly, > something that deploys in parallel and gives no added benefit is not > going to convince consumers to buy, and therefore has limited ROI. So > for the IPv6 roll-out to succeed, there actually has to be a disruption > of some kind - either new services available as a result, or a change > in the ISP cost model, or new applications available to consumers that > would not otherwise be available, or something. > Fred covered well a number of the other "non-technical" disruptiveness factors that deploying new technologies like IPv6 creates. My "disruptiveness" is a subset of Fred's business costs. To clarify the disuptiveness I was trying to describe, network administrators will have to put some effort into learning IPv6, to learn things such as the formatting and structure of addresses, ICMP based neighbour discovery etc. - the technical details of IPv6. Because effort has to be put into learning IPv6, while the network administrator is in "learning new-stuff mode", it can also be a good opportunity introduce or re-introduce broader conceptual ideas such the benefits of end-to-end, etc. Opportunities to start with a "clean conceptual slate" are relatively rare, so when they occur (as it will with IPv6), I think it is good to try to take as much advantage of them as is possible and practical. IPv6 is both similar and different to IPv4. The similarities help to learn IPv6, the differences need to be explained well so that people can see the advantages in deploying IPv6 and therefore also learn and understand why leaving behind the "warts" of IPv4 today (e.g., NAT) are part of IPv6's advantages. I certainly think the NAP draft is covering these topics, my interest is just to try to ensure that the "warts" of IPv4 are hopefully fully "explained" away from being deployed in IPv6. Regards, Mark. From owner-v6ops@ops.ietf.org Thu May 26 10:47:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04161 for ; Thu, 26 May 2005 10:47:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbJcD-000OP9-8a for v6ops-data@psg.com; Thu, 26 May 2005 14:45:41 +0000 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DbJc9-000OOm-Bt for v6ops@ops.ietf.org; Thu, 26 May 2005 14:45:37 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id EFAE7136; Thu, 26 May 2005 10:43:18 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 10:45:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Thu, 26 May 2005 10:45:34 -0400 Message-ID: <936A4045C332714F975800409DE09240541069@tayexc14.americas.cpqcorp.net> Thread-Topic: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Thread-Index: AcVhybo1P2oreUd6REmjGui+FGvVOwAN8ncg From: "Bound, Jim" To: "Fred Baker" Cc: "John Spence, CCSI, CCNA, CISSP" , , "Mark Smith" , "Gunter Van de Velde (gvandeve)" X-OriginalArrivalTime: 26 May 2005 14:45:36.0156 (UTC) FILETIME=[93A635C0:01C56201] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable thanks Fred we are in synch. thanks for clearing me up. I get it now. /jim=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Thursday, May 26, 2005 4:06 AM > To: Bound, Jim > Cc: John Spence, CCSI, CCNA, CISSP; v6ops@ops.ietf.org; Mark=20 > Smith; Gunter Van de Velde (gvandeve) > Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] >=20 > On May 25, 2005, at 1:33 PM, Bound, Jim wrote: > > I believe end-to-end security will be the norm in the future and=20 > > believe it to be a requirement for true end-to-end trust=20 > model. But, I=20 > > do believe the network must remain secure too. >=20 > yes and yes. The end system has to ensure that it is robust=20 > to attacks.=20 > The network needs to be able to prevent unauthorized use of its=20 > resources. The network can also help with various kinds of attacks -=20 > ddos being an obvious example, but ping sweeps and other things being=20 > also detectable and mitigable in the network. So using the network to=20 > detect and deal with things that an end system misses is reasonable. >=20 > Please don't understand what I said to mean that I don't=20 > believe in an=20 > end-to-end trust model. What I said was that I didn't think=20 > that it was=20 > the only thing that would be implemented. I very much believe that=20 > there will be prophylactic services in the network for the=20 > foreseeable=20 > future, because there exist good network-related reasons for=20 > that to be=20 > true. >=20 From owner-v6ops@ops.ietf.org Fri May 27 19:11:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13241 for ; Fri, 27 May 2005 19:11:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dbnvd-000H94-Hl for v6ops-data@psg.com; Fri, 27 May 2005 23:07:45 +0000 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dbnvb-000H8k-RC for v6ops@ops.ietf.org; Fri, 27 May 2005 23:07:44 +0000 Received: from eaglet (127.0.0.1:4983) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 27 May 2005 16:07:40 -0700 From: "Tony Hain" To: "'Alain Durand'" , "'Pyda Srisuresh'" Cc: Subject: RE: A Mialing list to discuss NATPY. Date: Fri, 27 May 2005 16:07:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVXO7KJcbF91K5wR0KcWl/4TplnWAL1PkHQ X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Alain Durand wrote: > Could you please elaborate on what you are trying to accomplish? Fixing the concerns that caused people to want the existing doc moved to experimental. Tony From owner-v6ops@ops.ietf.org Sat May 28 06:09:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09907 for ; Sat, 28 May 2005 06:09:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbyDe-000E4N-Jc for v6ops-data@psg.com; Sat, 28 May 2005 10:07:02 +0000 Received: from [210.84.237.27] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbyDZ-000E3L-JH for v6ops@ops.ietf.org; Sat, 28 May 2005 10:06:58 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id BC6B362AAE; Sat, 28 May 2005 19:36:53 +0930 (CST) Date: Sat, 28 May 2005 19:36:53 +0930 From: Mark Smith To: Elwyn Davies Cc: v6ops@ops.ietf.org Subject: Re: Please comment on new draft: draft-ietf-v6ops-security-overview-00.txt Message-Id: <20050528193653.3229b457.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <42850F82.7010300@dial.pipex.com> References: <200505131947.PAA21538@ietf.org> <42850F82.7010300@dial.pipex.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Elwyn, I'm reading through it the first time, it looks good. My $0.02 below. On Fri, 13 May 2005 21:35:14 +0100 Elwyn Davies wrote: > Please let us have any comments asap - we intend to produce another new > version incorporating any comments prior to IETF-63. > 2.1.11 Link-Local Addresses and Securing Neighbor Discovery "Because the link-local address can, by default, be acquired without external intervention or control, it allows an attacker to commence communication on the link without needing to acquire information about the address prefixes in use or communicate with any authorities on the link. This feature gives a malicious node the opportunity to mount an attack on any other node which is attached to this link; this vulnerability exists in addition to possible direct attacks on NDP." I think there is also a "non-malicious" use of link local addresses in the above scenario, in particular on wireless links, namely using the available link bandwidth to communicate between one or more "non-link authorised" nodes, rather than maliciously attacking "link-authorised" nodes. That is eluded to in the earlier part of the paragraph, possibly an explicit mention of this type of bandwidth theft could be useful. 2.3.2 Enterprise Network Security Model for IPv6 " o Development of centralized security policy repositories and distribution mechanisms which, in conjunction with trusted hosts, will allow network managers to place more reliance on security mechanisms at the end points and allow end points to influence the behavior of perimeter firewalls." My comment is probably a bit minor. The text is abstract about the security mechanisms on the end-points, yet is specific about the idea of allowing the end points to influence the perimeter firewalls. I'd like to suggest either being a bit more specific about end point security mechanisms (ie. explicit "end-node firewalling"), or be a bit more abstract about perimeter security mechanisms. It seems to me that the above paragraph is somewhat implying that the idea of perimeter firewalls is mostly agreed upon, yet I think that once the end points implement firewall type security themselves, with a policy distribution mechanism, perimeter firewalls would possibly be unnecessary. This end-node firewalling only security model would contradict the "and allow end points to influence the behavior of perimeter firewalls" text above. Possibly the "and" could be changed to an "or" ? Again, this point is probably minor. B.1 Exposing MAC Addresses "The MAC address, which with stateless address autoconfiguration, results in an EUI64, exposes the model of network card. The concern has been that a user might not want to expose the details of the system to outsiders, e.g., in the fear of a resulting burglary (e.g., if a crook identifies expensive equipment from the MAC addresses)." I've understood the more significant issue that exposing MAC addresses created wasn't being able to remotely identify the model/manufacturer of devices, but rather, that as EUI64s were derived from commonly world-wide unique EUI48s, the node address became a mechanism to allow tracking the access patterns of nodes, and therefore typically an individual person, no matter what their attachment point to the network/Internet, and how often they change it (therefore aquiring a new /64 prefix). "B.3 Exposing the Site by a Stable Prefix" mentions this privacy concern, although it seems to be constricting the privacy concern to a site, which I think tends to imply that if the node leaves the site, this issue disappears, and I'm pretty sure it doesn't. That's it for the moment. Regards, Mark. From 41audra@accessbancorp.com Sat May 28 20:57:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15980 for ; Sat, 28 May 2005 20:57:13 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcCQG-0003dx-8y for v6ops-archive@ietf.org; Sat, 28 May 2005 21:17:00 -0400 Received: from pcp09510571pcs.wchstr01.pa.comcast.net ([69.240.151.12]) by mx2.foretec.com with smtp (Exim 4.24) id 1DcC78-0005N3-D9 for v6ops-archive@ietf.org; Sat, 28 May 2005 20:57:15 -0400 Message-ID: From: "Kendra L. Brown" <41audra@accessbancorp.com> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgUGhvdG9zaG9wIDguMCAtIHZlcnkgbG93IHByaWNl?= Date: Sun, 29 May 2005 00:48:30 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_644CE4F4.8192F71A" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.3 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_644CE4F4.8192F71A Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_A6388003.C444B6D8" ------=_NextPart_001_0001_A6388003.C444B6D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the software you ever imagined for wholesale prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... To visit us go: http://www.oemdisks.biz Regards, Kendra L. Brown _____________________________________________________ To be taken off future campaigns, go: http://www.oemdisks.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_A6388003.C444B6D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Access all the software you ever imagined for wholesale prices!
We sell software 2-6 times cheaper than retail price.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 Quark Xpress 6 Passport Multilanguage

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... To visit us go:

http://www.oemdisks.biz

Regards,
Kendra L. Brown


_____________________________________________________
To be taken off future campaigns, go: http://www.oemdisks.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_A6388003.C444B6D8-- ------=_NextPart_000_0000_644CE4F4.8192F71A-- From alejandr@access-one.com Mon May 30 04:28:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27394 for ; Mon, 30 May 2005 04:28:26 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcfwj-0003Xm-Du for v6ops-archive@ietf.org; Mon, 30 May 2005 04:48:30 -0400 Received: from cpe-144-133-120-128.nsw.bigpond.net.au ([144.133.120.128]) by mx2.foretec.com with smtp (Exim 4.24) id 1DcfdL-0003wK-2F for v6ops-archive@ietf.org; Mon, 30 May 2005 04:28:28 -0400 Message-ID: From: "Richard K. Lee" To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBwaWxscyAtICQyLjk5L2Rvc2U=?= Date: Mon, 30 May 2005 07:25:00 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_26B30CB7.F9B12195" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_26B30CB7.F9B12195 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_C3A86BFC.3768426A" ------=_NextPart_001_0001_C3A86BFC.3768426A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Perfect erection Prolonged effect No prescription needed Only $2.99/$1.99 per dose (2 doses in each pill): CIALIS - http://www.wonderpills.biz/sv/ VIAGRA - http://www.wonderpills.biz/vt/ Directly from the manufacturer! _________________________________________________________________________ To be taken off future campaigns, go here _________________________________________________________________________ ------=_NextPart_001_0001_C3A86BFC.3768426A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Perfect erection
Prolonged effect
No prescription needed

Only $2.99/$1.99 per dose (2 doses in each pill):
CIALIS - http://www.wonderpills.biz/sv/
VIAGRA - http://www.wonderpills.biz/vt/

Directly from the manufacturer!


_________________________________________________________________________
To be taken off future campaigns, go here
_________________________________________________________________________

------=_NextPart_001_0001_C3A86BFC.3768426A-- ------=_NextPart_000_0000_26B30CB7.F9B12195-- From owner-v6ops@ops.ietf.org Tue May 31 11:48:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20326 for ; Tue, 31 May 2005 11:48:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dd8vY-0006nu-SI for v6ops-data@psg.com; Tue, 31 May 2005 15:45:12 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dd8vW-0006na-1g for v6ops@ops.ietf.org; Tue, 31 May 2005 15:45:10 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 May 2005 17:45:08 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4VFip7R014731 for ; Tue, 31 May 2005 17:45:06 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 May 2005 17:45:02 +0200 Received: from evyncke-w2k02.cisco.com ([10.55.1.165]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 17:45:02 +0200 Message-Id: <5.1.0.14.2.20050531172645.031118e0@127.0.0.1> X-Sender: evyncke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 May 2005 17:44:48 +0200 To: Fred Baker From: Eric Vyncke Subject: Re: Discussion of draft-ietf-v6ops-ent-analysis-02.txt Cc: "'v6ops@ops.ietf.org '" In-Reply-To: <18d392ca9e8dd0476bdf3b1b2a3141e1@cisco.com> References: <200505191945.PAA14818@ietf.org> <200505191945.PAA14818@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 31 May 2005 15:45:02.0719 (UTC) FILETIME=[B58D48F0:01C565F7] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Just a couple of minor issues: 4.2.1) about IPv6 routing capability, it may be wise to state the obvious: IPv6 routing capability should offer the same performance as the existing IPv4 routing in order to handle the peak load requested by dual stack hosts. Moreover, the IPv6 routing node should execute the same features as the IPv4 routing node: QoS, security, availability (redundant links for IPv6 when there are redundant links for IPv4) ... 5.1) the external IPv6 tunneling also presents security & QoS issues that should probably be mentioned The last point is linked to 4.2.1, when the IPv6 connectivity is poor: like route flapping, link flapping (spec. with tunnels), IPv6 isolated islands will be created and this will cause some applications to fail since they will insist in using IPv6 address (even if both ends are still using IPv4). On my own experience, this was really a pain in ... to detect this issue. Hope it helps -eric From owner-v6ops@ops.ietf.org Tue May 31 11:55:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20729 for ; Tue, 31 May 2005 11:55:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dd95D-0007bb-Ao for v6ops-data@psg.com; Tue, 31 May 2005 15:55:11 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1Dd95A-0007a9-Q0; Tue, 31 May 2005 15:55:09 +0000 Received: from portatilalvaro by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001054113.msg; Tue, 31 May 2005 17:54:54 +0200 Reply-To: From: "Alvaro Vives" To: , "'Elwyn Davies'" Cc: Subject: RE: Please comment on new draft: draft-ietf-v6ops-security-overview-00.txt Date: Tue, 31 May 2005 17:59:08 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVjbg+lwLYKxGDfS2uiJnB9NQpuOACilrMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050528193653.3229b457.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Authenticated-Sender: alvaro.vives@consulintel.es X-MDRemoteIP: 80.224.151.195 X-Return-Path: alvaro.vives@consulintel.es Message-ID: X-MDAV-Processed: consulintel.es, Tue, 31 May 2005 17:54:57 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mark, I would like to add some comments over your comments... See below: > Hi Elwyn, > > I'm reading through it the first time, it looks good. > > My $0.02 below. > > On Fri, 13 May 2005 21:35:14 +0100 > Elwyn Davies wrote: > > > > > Please let us have any comments asap - we intend to produce another > > new version incorporating any comments prior to IETF-63. > > > > 2.1.11 Link-Local Addresses and Securing Neighbor Discovery > > "Because the link-local address can, by default, be acquired without > external intervention or control, it allows an attacker to commence > communication on the link without needing to acquire information > about the address prefixes in use or communicate with any > authorities > on the link. This feature gives a malicious node the > opportunity to > mount an attack on any other node which is attached to this link; > this vulnerability exists in addition to possible direct attacks on > NDP." > > I think there is also a "non-malicious" use of link local > addresses in the above scenario, in particular on wireless > links, namely using the available link bandwidth to > communicate between one or more "non-link authorised" nodes, > rather than maliciously attacking "link-authorised" > nodes. That is eluded to in the earlier part of the > paragraph, possibly an explicit mention of this type of > bandwidth theft could be useful. This is an interesting idea and IMO not restricted to wireless links. I think the general idea is that link-local addresses allows communication among hosts within a LAN and no access control could be done. For example in a layer two infrastructure within a building two hosts could communicate among them. > > 2.3.2 Enterprise Network Security Model for IPv6 > > " o Development of centralized security policy repositories and > distribution mechanisms which, in conjunction with > trusted hosts, > will allow network managers to place more reliance on security > mechanisms at the end points and allow end points to > influence the > behavior of perimeter firewalls." > > My comment is probably a bit minor. The text is abstract > about the security mechanisms on the end-points, yet is > specific about the idea of allowing the end points to > influence the perimeter firewalls. I'd like to suggest either > being a bit more specific about end point security mechanisms > (ie. explicit "end-node firewalling"), or be a bit more > abstract about perimeter security mechanisms. It seems to me > that the above paragraph is somewhat implying that the idea > of perimeter firewalls is mostly agreed upon, yet I think > that once the end points implement firewall type security > themselves, with a policy distribution mechanism, perimeter > firewalls would possibly be unnecessary. This end-node > firewalling only security model would contradict the "and > allow end points to influence the behavior of perimeter > firewalls" text above. > Possibly the "and" could be changed to an "or" ? Again, this > point is probably minor. > I would suggest not to just think on end-node firewalling but in a more complex "security tool" which will enforce the security policy distributed. I could think in firewalling+IDS+anti-virus+anti-spam+.... Regards, Alvaro Vives Consulintel > B.1 Exposing MAC Addresses > > "The MAC address, which with stateless address autoconfiguration, > results in an EUI64, exposes the model of network card. > The concern > has been that a user might not want to expose the details of the > system to outsiders, e.g., in the fear of a resulting > burglary (e.g., > if a crook identifies expensive equipment from the MAC addresses)." > > I've understood the more significant issue that exposing MAC > addresses created wasn't being able to remotely identify the > model/manufacturer of devices, but rather, that as EUI64s > were derived from commonly world-wide unique EUI48s, the node > address became a mechanism to allow tracking the access > patterns of nodes, and therefore typically an individual > person, no matter what their attachment point to the > network/Internet, and how often they change it (therefore > aquiring a new > /64 prefix). "B.3 Exposing the Site by a Stable Prefix" > mentions this privacy concern, although it seems to be > constricting the privacy concern to a site, which I think > tends to imply that if the node leaves the site, this issue > disappears, and I'm pretty sure it doesn't. > > That's it for the moment. > > Regards, > Mark. > > > > > > ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue May 31 15:54:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13542 for ; Tue, 31 May 2005 15:54:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdCmp-000OU5-Qa for v6ops-data@psg.com; Tue, 31 May 2005 19:52:27 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdCmo-000OTm-M4 for v6ops@ops.ietf.org; Tue, 31 May 2005 19:52:27 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12739; Tue, 31 May 2005 15:52:24 -0400 (EDT) Message-Id: <200505311952.PAA12739@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-bb-deployment-scenarios-02.txt Date: Tue, 31 May 2005 15:52:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : ISP IPv6 Deployment Scenarios in Broadband Access Networks Author(s) : S. Asadullah, et al. Filename : draft-ietf-v6ops-bb-deployment-scenarios-02.txt Pages : 80 Date : 2005-5-31 This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging PLC/BPL access technology is also discussed for completion purposes. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these BB technologies using tunneling mechanisms and native IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-bb-deployment-scenarios-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-31155740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-bb-deployment-scenarios-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-31155740.I-D@ietf.org> --OtherAccess-- --NextPart--