From ipv6-bounces@ietf.org Mon Apr 02 02:44:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGAY-0006eT-HS; Mon, 02 Apr 2007 02:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGAW-0006eG-Uo for ipv6@ietf.org; Mon, 02 Apr 2007 02:37:32 -0400 Received: from zns001-0m9004.yokogawa.co.jp ([203.174.79.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYGAV-0003OK-BS for ipv6@ietf.org; Mon, 02 Apr 2007 02:37:32 -0400 Received: from zns001-0m9004.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l326bL73012830 for ; Mon, 2 Apr 2007 15:37:21 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l326bLAU012827 for ; Mon, 2 Apr 2007 15:37:21 +0900 (JST) 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 Date: Mon, 2 Apr 2007 15:37:20 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898A3C@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Reminder] The Registration of the 9th TAHI IPv6 Interoperability Test Event has been opened Thread-Index: Acd08V0rKXddIHr2QnqfdWzpZ1rksw== From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Reminder] The Registration of the 9th TAHI IPv6 Interoperability Test Event has been opened X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hello all, This is a reminder for the 9th TAHI IPv6 Interoperability Test Event. TAHI Project is planning to hold the 9th TAHI IPv6 Interoperability Test Event at 14th - 18th May, 2007. You can make a registration on=20 http://www.tahi.org/inop/9thinterop.html And you can also get the detailed information about the event. We are looking forward see you at the 9th TAHI event! Thanks, ...Hideshi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Apr 07 20:06:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaKpG-0007FF-9f; Sat, 07 Apr 2007 20:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaKpE-0007Cy-QO for ipv6@ietf.org; Sat, 07 Apr 2007 20:00:08 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaKpD-0003Si-HL for ipv6@ietf.org; Sat, 07 Apr 2007 20:00:08 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id DADDA28429 for ; Sun, 8 Apr 2007 00:00:02 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 08 Apr 2007 00:00:02 +0000 Message-Id: <20070408000002.DADDA28429@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 51.15% | 4055 | hideshi.enokihara@jp.yokogawa.com 50.00% | 1 | 48.85% | 3873 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 7928 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 10 05:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCq5-0005cf-4O; Tue, 10 Apr 2007 05:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCq3-0005cQ-9x for ipv6@ietf.org; Tue, 10 Apr 2007 05:40:35 -0400 Received: from [220.189.211.171] (helo=zist.edu.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbCq1-0005Hu-HJ for ipv6@ietf.org; Tue, 10 Apr 2007 05:40:35 -0400 X-EYOU-SPAMVALUE: 0 X-EYOU-DEALDRC: Received: (eyou anti_spam gateway 3.0); Tue, 10 Apr 2007 17:16:47 +0800 Message-ID: <376196607.08597@zist.edu.cn> X-EYOUMAIL-SMTPAUTH: licanhuang@zstu.edu.cn Received: from 172.21.0.33 by 192.168.101.2 with SMTP; Tue, 10 Apr 2007 17:16:47 +0800 Message-ID: <004a01c77b54$42ee95f0$210015ac@benq44baf9946b> From: "huang lican" To: Date: Tue, 10 Apr 2007 17:40:22 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ipv6@ietf.org Subject: Update internet draft about Distributed DNS Implementation in IpV6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1620638783==" Errors-To: ipv6-bounces@ietf.org --===============1620638783== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 ICBEZWFyIEFsbCwNCiAgSSBoYXZlIHN1Ym1pdHRlZCBhbiB1cGRhdGUgIGludGVybmV0IGRyYWZ0 IGFib3V0IGRpc3RyaWJ1dGVkIEROUyBpbXBsZW1lbnRhdGlvbiBpbiBJUFY2Lg0KICBUaGUgZm9s bG93aW5nIGlzIHRoZSBhZGRyZXNzOiAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbGljYW5odWFuZy1kbnNvcC1kaXN0cmlidXRlZGRucy0wMS50eHQNCiANCiAgUGxl YXNlIGdpdmUgeW91ciBjb21tZW50cy4NCiANCiAgVGhhbmtzIGEgbG90Lg0KICANCiAgDQogIExp Y2FuIEh1YW5nDQogDQog --===============1620638783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1620638783==-- From ipv6-bounces@ietf.org Sat Apr 14 20:01:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsA0-0000Us-Qy; Sat, 14 Apr 2007 20:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcs9y-0000Ud-WF for ipv6@ietf.org; Sat, 14 Apr 2007 20:00:03 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcs9y-0008I5-O7 for ipv6@ietf.org; Sat, 14 Apr 2007 20:00:02 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 266282844E for ; Sun, 15 Apr 2007 00:00:02 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 15 Apr 2007 00:00:02 +0000 Message-Id: <20070415000002.266282844E@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 3630 | Total --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 3630 | sra+ipng@hactrn.net Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 15 20:30:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdF6E-00079H-NK; Sun, 15 Apr 2007 20:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdF6C-00079C-SS for ipv6@ietf.org; Sun, 15 Apr 2007 20:29:40 -0400 Received: from zns001-0m9003.yokogawa.co.jp ([203.174.79.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdF69-0006BJ-Ad for ipv6@ietf.org; Sun, 15 Apr 2007 20:29:40 -0400 Received: from zns001-0m9003.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3G0TWE6027742 for ; Mon, 16 Apr 2007 09:29:33 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3G0TWp1027733 for ; Mon, 16 Apr 2007 09:29:32 +0900 (JST) 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 Date: Mon, 16 Apr 2007 09:29:31 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898A7D@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! Thread-Index: Acd/vkr+EpJV01V7Q4un2mSCnSEl8A== From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Dear all, This is a reminder for the 9th TAHI IPv6 Interoperability Test Event. As you know, TAHI Project is planning to hold the 9th TAHI IPv6 Interoperability Test Event at 14th - 18th May, 2007. You can make a registration on=20 http://www.tahi.org/inop/9thinterop.html And you can also get the detailed information about the event. The registration deadline is at 17:00 on Friday, 27th Apr. Please make a registration as soon as possible, if you are planning to participate to the event. We are looking forward to see you at the 9th TAHI event! Thanks, -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 15 20:54:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdFTo-0007O7-Hp; Sun, 15 Apr 2007 20:54:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdFTn-0007O2-LT for ipv6@ietf.org; Sun, 15 Apr 2007 20:54:03 -0400 Received: from zns001-0m9001.yokogawa.co.jp ([203.174.79.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdFTm-00032l-2K for ipv6@ietf.org; Sun, 15 Apr 2007 20:54:03 -0400 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3G0s0gs009308 for ; Mon, 16 Apr 2007 09:54:00 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3G0s0tU009289 for ; Mon, 16 Apr 2007 09:54:00 +0900 (JST) 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 Date: Mon, 16 Apr 2007 09:53:59 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898A86@EXCHANGE03.jp.ykgw.net> In-Reply-To: <0260031F55435342859BFB2CCA6773D81B898A7D@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! Thread-Index: Acd/vkr+EpJV01V7Q4un2mSCnSEl8AAA2hEQ From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: RE: [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Dear all, I forgot to tell you the important thing. The Early registration discount will be closed today!! at 17:00 JST 16th Apr. Thanks, > -----Original Message----- > From: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com)=20 > Sent: Monday, April 16, 2007 9:30 AM > To: ipv6@ietf.org > Subject: [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! >=20 > Dear all, >=20 > This is a reminder for the 9th TAHI IPv6 Interoperability Test Event. >=20 > As you know, TAHI Project is planning to hold the 9th TAHI=20 > IPv6 Interoperability Test Event at 14th - 18th May, 2007. > You can make a registration on=20 > http://www.tahi.org/inop/9thinterop.html >=20 > And you can also get the detailed information about the event. >=20 > The registration deadline is at 17:00 on Friday, 27th Apr. > Please make a registration as soon as possible, if you are=20 > planning to participate to the event. >=20 > We are looking forward to see you at the 9th TAHI event! >=20 > Thanks, >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 17 20:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdy3k-0000af-5L; Tue, 17 Apr 2007 20:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdy3i-0000aa-KU for ipv6@ietf.org; Tue, 17 Apr 2007 20:30:06 -0400 Received: from ns.64translator.com ([202.214.123.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdy3g-0005Pr-QV for ipv6@ietf.org; Tue, 17 Apr 2007 20:30:06 -0400 Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.13.6/8.13.6) with ESMTP id l3HFIbVL058357 for ; Wed, 18 Apr 2007 00:18:37 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Received: from thinkpad.64translator.com (dhcp225.64translator.com [10.21.32.225]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id l3I0SfHT034100 for ; Wed, 18 Apr 2007 09:28:41 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Date: Wed, 18 Apr 2007 09:28:08 +0900 From: Hideshi Enokihara To: ipv6@ietf.org Message-Id: <20070418092808.220e0020.Hideshi.Enokihara@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bahamas.64translator.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [9th TAHI Test Event] Registration System Failure X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org All, We would like to apologize for an error in the online registration system yesterday that resulted in registration being unable to be completed for the period of 17:15 - 20:22 JST. The error took place in the process of changing the registration rates from the early registration rates to the standard rates after yesterday's deadline. We apologize for the inconvenience caused and would ask that anyone who was unable to register during this time period to contact us. We will then asist you in processing your registration at the advance rates. Sincerely, 9th TAHI Registration Desk c/o Maki Ikegami, e-side, inc. email: 9thregister@tahi.org Fax: 81-3-3585-8162 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 18 13:09:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDeR-0005sB-K6; Wed, 18 Apr 2007 13:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDeQ-0005lI-5S for ipv6@ietf.org; Wed, 18 Apr 2007 13:09:02 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDeO-0005Zp-LZ for ipv6@ietf.org; Wed, 18 Apr 2007 13:09:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3IH8uVp024254 for ; Wed, 18 Apr 2007 20:08:58 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 20:08:57 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:08:49 -0500 Received: from 172.19.244.158 ([172.19.244.158]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 18 Apr 2007 17:08:48 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 18 Apr 2007 12:09:29 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Flags in router advts Thread-Index: AceB3FMUkaxvxe3PEduLRAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 17:08:49.0402 (UTC) FILETIME=[3B7A7DA0:01C781DC] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070418200858-5A254BB0-64A03943/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Flags in router advts X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hello, I-D draft-haberman-ipv6-ra-flags-option-xx proposes to extend the IPv6 Neighbor Discovery's Router Advertisement message. With Proxy MIP6 specification work now being done in the Netlmm WG, there is a need to advertise the support for network based mobility (PMIP6 capability) to a host when it attaches via a flag in the RA. A host may prefer to not have the access network emulate its home link and hence by knowing that PMIP6 is enabled in the network (via the RA), it can request a prefix or address that is local to the network. It also allows a host to manage its own mobility (a Mobile IPv6 capable MN) in case it chooses to do so. This is possible only when the MN is aware of the network being capable of managing its mobility. So extending the RA message to include new flags is required. -Raj -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 19 13:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hea63-0007GP-Re; Thu, 19 Apr 2007 13:07:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hea61-00079K-Io for ipv6@ietf.org; Thu, 19 Apr 2007 13:07:01 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hea61-0006Jd-22 for ipv6@ietf.org; Thu, 19 Apr 2007 13:07:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JH6gbP014901 for ; Thu, 19 Apr 2007 20:06:57 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 20:06:48 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 20:06:48 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 20:06:47 +0300 Received: from [209.157.142.166] (daec-linuxvpn058212.americas.nokia.com [10.241.58.212]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JH6fAo001025 for ; Thu, 19 Apr 2007 20:06:46 +0300 To: i-d-announce@ietf.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Resent-Date: Thu, 19 Apr 2007 10:06:30 -0700 Message-Id: Resent-To: IETF IPv6 Mailing List From: "ext i-d-announce-bounces@ietf.org" Content-Transfer-Encoding: 7bit Resent-From: Bob Hinden Resent-Message-Id: Date: Wed, 18 Apr 2007 18:50:02 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Apr 2007 17:06:48.0003 (UTC) FILETIME=[1D883930:01C782A5] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070419200657-3A08ABB0-23BC9274/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: I-D ACTION:draft-haberman-ipv6-ra-flags-option-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Resent-Date: Thu, 19 Apr 2007 13:07:03 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Router Advertisement Flags Option Author(s) : B. Haberman, R. Hinden Filename : draft-haberman-ipv6-ra-flags-option-01.txt Pages : 7 Date : 2007-4-18 The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberman-ipv6-ra-flags- option-01.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-haberman-ipv6-ra-flags-option-01.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-haberman-ipv6-ra-flags-option-01.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-Type: text/plain Content-ID: <2007-4-18155755.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 20 04:34:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeoZg-0008C6-1N; Fri, 20 Apr 2007 04:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXC4-000101-Te for ipv6@ietf.org; Thu, 19 Apr 2007 10:01:04 -0400 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXC3-0005wI-8S for ipv6@ietf.org; Thu, 19 Apr 2007 10:01:04 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.27071585; Thu, 19 Apr 2007 10:00:41 -0400 Message-ID: <46277609.30600@innovationslab.net> Date: Thu, 19 Apr 2007 10:00:41 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ipv X-Enigmail-Version: 0.94.1.2 Content-Type: multipart/mixed; boundary="------------080304070803010900040603" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-Mailman-Approved-At: Fri, 20 Apr 2007 04:34:27 -0400 Subject: [Fwd: I-D ACTION:draft-haberman-ipv6-ra-flags-option-01.txt] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --------------080304070803010900040603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IPv6 WG, This is an update based on feedback received on the list and via private e-mail. Please review and comment. I would still like to solicit input on WG adoption. Regards, Brian -------- Original Message -------- Subject: I-D ACTION:draft-haberman-ipv6-ra-flags-option-01.txt Date: Wed, 18 Apr 2007 18:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Router Advertisement Flags Option Author(s) : B. Haberman, R. Hinden Filename : draft-haberman-ipv6-ra-flags-option-01.txt Pages : 7 Date : 2007-4-18 The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberman-ipv6-ra-flags-option-01.txt --------------080304070803010900040603 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="draft-haberman-ipv6-ra-flags-option-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-haberman-ipv6-ra-flags-option-01.txt" Content-Type: text/plain Content-ID: <2007-4-18155755.I-D@ietf.org> --------------080304070803010900040603 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="file:///tmp/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------080304070803010900040603 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --------------080304070803010900040603-- From ipv6-bounces@ietf.org Fri Apr 20 05:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hep3r-0006sT-Qo; Fri, 20 Apr 2007 05:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hep3q-0006sI-Kl for ipv6@ietf.org; Fri, 20 Apr 2007 05:05:46 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hep3q-0007JH-AQ for ipv6@ietf.org; Fri, 20 Apr 2007 05:05:46 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1177059945!13130793!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31600 invoked from network); 20 Apr 2007 09:05:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 20 Apr 2007 09:05:45 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3K95jFS016995; Fri, 20 Apr 2007 02:05:45 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l3K95jeT022631; Fri, 20 Apr 2007 04:05:45 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l3K95hTc022562; Fri, 20 Apr 2007 04:05:44 -0500 (CDT) Message-ID: <46288262.1060902@gmail.com> Date: Fri, 20 Apr 2007 11:05:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Haberman References: <46277609.30600@innovationslab.net> In-Reply-To: <46277609.30600@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Ipv Subject: Re: [Fwd: I-D ACTION:draft-haberman-ipv6-ra-flags-option-01.txt] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Brian Haberman wrote: > IPv6 WG, This is an update based on feedback received on the list and > via private e-mail. Please review and comment. I would still like > to solicit input on WG adoption. My previous comment on the draft (this option is only for RA, not all NDP) was included. I support WG adoption of this document. There are at least three potential uses of this draft: DNA (cited in the draft), netlmm recently posted here and finally a potential use by Mobile Routers. A minor comment on the References section: RFC2461 is currently being revised by draft-ietf-ipv6-2461bis-11. I think maybe the document could also include a short paragraph about how legacy systems (those not implementing this draft) will not crash when this option is deployed in routers. But maybe this is already well understood. Alex > > Regards, Brian > > > -------- Original Message -------- Subject: I-D > ACTION:draft-haberman-ipv6-ra-flags-option-01.txt Date: Wed, 18 Apr > 2007 18:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: > internet-drafts@ietf.org To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 Router Advertisement Flags Option Author(s) : B. > Haberman, R. Hinden Filename : > draft-haberman-ipv6-ra-flags-option-01.txt Pages : 7 Date : > 2007-4-18 The IPv6 Neighbor Discovery's Router Advertisement message > contains an 8-bit field reserved for single-bit flags. Several > protocols have reserved flags in this field and others are preparing > to reserve a sufficient number of flags to exhaust the field. This > document defines an option to the Router Advertisement message that > expands the available number of flag bits available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haberman-ipv6-ra-flags-option-01.txt > > > > > ------------------------------------------------------------------------ > > > Content-Type: text/plain Content-ID: <2007-4-18155755.I-D@ietf.org> > > > > ------------------------------------------------------------------------ > > > _______________________________________________ I-D-Announce mailing > list I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > ------------------------------------------------------------------------ > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 20 12:17:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevnk-00055t-2F; Fri, 20 Apr 2007 12:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevni-00054Q-Gc for ipv6@ietf.org; Fri, 20 Apr 2007 12:17:34 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hevni-0000Y0-0Q for ipv6@ietf.org; Fri, 20 Apr 2007 12:17:34 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3KGHGkf008306; Fri, 20 Apr 2007 19:17:31 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 19:15:43 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 11:15:31 -0500 Received: from 172.19.244.145 ([172.19.244.145]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Apr 2007 16:15:30 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 20 Apr 2007 11:16:13 -0500 From: Basavaraj Patil To: ext Brian Haberman , Ipv Message-ID: Thread-Topic: [Fwd: I-D ACTION:draft-haberman-ipv6-ra-flags-option-01.txt] Thread-Index: AceDZzbxdb4XQu9aEduLRAARJNUNiA== In-Reply-To: <46277609.30600@innovationslab.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Apr 2007 16:15:31.0282 (UTC) FILETIME=[1E139B20:01C78367] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070420191732-1C7D4BB0-18C1278B/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: Re: [Fwd: I-D ACTION:draft-haberman-ipv6-ra-flags-option-01.txt] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org The RA flag space needs to be extended. Hence I support the adoption of this I-D as a WG doc. One of the immediate requirements for a flag is for Proxy MIP6 as I explained in : http://www1.ietf.org/mail-archive/web/ipv6/current/msg07266.html -Raj On 4/19/07 9:00 AM, "ext Brian Haberman" wrote: > IPv6 WG, > This is an update based on feedback received on the list and via > private e-mail. Please review and comment. I would still like to > solicit input on WG adoption. > > Regards, > Brian > > > -------- Original Message -------- > Subject: I-D ACTION:draft-haberman-ipv6-ra-flags-option-01.txt > Date: Wed, 18 Apr 2007 18:50:02 -0400 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 Router Advertisement Flags Option > Author(s) : B. Haberman, R. Hinden > Filename : draft-haberman-ipv6-ra-flags-option-01.txt > Pages : 7 > Date : 2007-4-18 > > The IPv6 Neighbor Discovery's Router Advertisement message contains > an 8-bit field reserved for single-bit flags. Several protocols have > reserved flags in this field and others are preparing to reserve a > sufficient number of flags to exhaust the field. This document > defines an option to the Router Advertisement message that expands > the available number of flag bits available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haberman-ipv6-ra-flags-option-01.txt > > Content-Type: text/plain > Content-ID: <2007-4-18155755.I-D@ietf.org> > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Apr 21 20:00:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfPUr-0007cb-Pt; Sat, 21 Apr 2007 20:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfPUq-0007cV-81 for ipv6@ietf.org; Sat, 21 Apr 2007 20:00:04 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfPUo-00023H-VG for ipv6@ietf.org; Sat, 21 Apr 2007 20:00:04 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 05F1F2844E for ; Sun, 22 Apr 2007 00:00:02 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 22 Apr 2007 00:00:02 +0000 Message-Id: <20070422000002.05F1F2844E@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 3 | 28.18% | 13280 | hideshi.enokihara@jp.yokogawa.com 22.22% | 2 | 22.87% | 10774 | basavaraj.patil@nsn.com 11.11% | 1 | 15.00% | 7070 | alexandru.petrescu@gmail.com 11.11% | 1 | 14.64% | 6896 | i-d-announce-bounces@ietf.org 11.11% | 1 | 11.76% | 5540 | brian@innovationslab.net 11.11% | 1 | 7.55% | 3559 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 9 |100.00% | 47119 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 23 19:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg8Lz-0004Ic-9R; Mon, 23 Apr 2007 19:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg8Lx-0004CM-F2 for ipv6@ietf.org; Mon, 23 Apr 2007 19:53:53 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg8Lu-00032L-0N for ipv6@ietf.org; Mon, 23 Apr 2007 19:53:53 -0400 Received: from [IPv6:2001:770:100:9e::2] (cl-159.dub-01.ie.sixxs.net [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 5D56F140C1E5; Tue, 24 Apr 2007 01:53:48 +0200 (CEST) Message-ID: <462D4706.4000504@spaghetti.zurich.ibm.com> Date: Tue, 24 Apr 2007 00:53:42 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: ipv6@ietf.org, v6ops@ops.ietf.org, IPv6 Ops list X-Enigmail-Version: 0.94.3.0 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV 0.90.1/3152/Tue Apr 24 00:34:59 2007 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2115204074==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2115204074== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig968FFC9C346E6B64DCBBF8A3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig968FFC9C346E6B64DCBBF8A3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just in case folks are missing out on this, find below a rather nasty security issue. Please use "IPv6 Ops list " for discussion, see also: http://lists.cluenet.de/pipermail/ipv6-ops/ Greets, Jeroen -------- Original Message -------- Subject: [dns-operations] IPv6 Type 0 Routing Header issues Date: Mon, 23 Apr 2007 17:07:57 +0200 From: Nicolas FISCHBACH To: dns-operations@lists.oarci.net Very interesting presentation by Arnaud and Phil: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf If you only care about the DNS related bits, start on page 29. Nico. --=20 Nicolas FISCHBACH Senior Manager - Network Engineering/Security - COLT Telecom e:(nico@securite.org) w: --------------enig968FFC9C346E6B64DCBBF8A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkYtRwYuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58IyyMAJ9nQQ8xfD1IE05WQZFNyNeemsO1 igCgtgIixrm6NsWGq/LacHFFi0aZ3IQ= =S+zd -----END PGP SIGNATURE----- --------------enig968FFC9C346E6B64DCBBF8A3-- --===============2115204074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2115204074==-- From ipv6-bounces@ietf.org Tue Apr 24 08:00:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJgc-0002MU-QW; Tue, 24 Apr 2007 07:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJgb-0002MO-7p for ipv6@ietf.org; Tue, 24 Apr 2007 07:59:57 -0400 Received: from zns001-0m9003.yokogawa.co.jp ([203.174.79.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgJgX-0000Nk-MF for ipv6@ietf.org; Tue, 24 Apr 2007 07:59:57 -0400 Received: from zns001-0m9003.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3OBxpE6006556 for ; Tue, 24 Apr 2007 20:59:51 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3OBxlp1006538 for ; Tue, 24 Apr 2007 20:59:51 +0900 (JST) 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 Date: Tue, 24 Apr 2007 20:59:46 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898ABE@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Remainder] TAHI Event Registration will be closed !! Thread-Index: AceGaA24Qs4iRBiwQwa2Yc3GWJdzgw== From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Remainder] TAHI Event Registration will be closed !! X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Dear all, This is a remainder. The Registration for TAHI Interoperability Test Event will be closed on 27th Apr (17P.M. JST). If you are planning to participate to the Event, please make a registration as soon as possible. =20 You can make a registration on http://www.tahi.org/inop/9thinterop.html Summary information of the event. - Venue: Nippon Convention Center (Makuhari Messe), Chiba, Japan. - Date: May 14 - May 18, 2007 - Registration & Information: http://www.tahi.org/inop/9thinterop.html We are looking forward to see you at 9th TAHI evnet! Best regards, ------------------- Hideshi Enokihara -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 24 08:10:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJqi-0005xe-Sd; Tue, 24 Apr 2007 08:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJqh-0005xU-6S for ipv6@ietf.org; Tue, 24 Apr 2007 08:10:23 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgJqe-00058l-Ib for ipv6@ietf.org; Tue, 24 Apr 2007 08:10:23 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH000AFG4FW0S@szxga02-in.huawei.com> for ipv6@ietf.org; Tue, 24 Apr 2007 20:09:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JH000BNK4FU57@szxga02-in.huawei.com> for ipv6@ietf.org; Tue, 24 Apr 2007 20:09:32 +0800 (CST) Received: from vijaykumar ([10.18.5.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JH0004464FQLQ@szxml04-in.huawei.com> for ipv6@ietf.org; Tue, 24 Apr 2007 20:09:30 +0800 (CST) Date: Tue, 24 Apr 2007 17:39:26 +0530 From: vijay To: ipv6@ietf.org Message-id: <000901c78669$6778b340$6005120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailer: Microsoft Office Outlook 11 Thread-index: AceGaWbu4v+5Z466R+2CiWH+d1eKYQ== X-Spam-Score: 0.2 (/) X-Scan-Signature: 856556672758705c159600f21b877eb4 Subject: IPv6 PTMU query X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vijaykumar@huawei.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0422184774==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0422184774== Content-type: multipart/alternative; boundary="Boundary_(ID_HVrsA4I4QjaCDLLUEXd2DA)" This is a multi-part message in MIME format. --Boundary_(ID_HVrsA4I4QjaCDLLUEXd2DA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, I am currently analyzing the IPv6 path MTU. As the IPv6 path MTU calculation is done by error correction method, I was thinking of suggesting a proposal for calculating the path MTU optimally. I am interested in knowing if the path MTU is a problem in real networks and how often packets are dropped due to MTU too small, in real networks? If there is some information regarding the same, please share it. Regards Vijay **************************************************************************** *************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** *************************************** --Boundary_(ID_HVrsA4I4QjaCDLLUEXd2DA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi All,

 

       I am currently analyzing the IPv6 path MTU.

As the IPv6 path MTU calculation is done by error correction method, I was thinking of suggesting a

proposal for calculating the path MTU optimally. I am interested in knowing if the path MTU is a problem

in real networks and how often packets are dropped due to MTU too small, in real networks?

 

       If there is some information regarding the same, please share it.

 

Regards

Vijay

 

*******************************************************************************************************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

*******************************************************************************************************************

 

 

--Boundary_(ID_HVrsA4I4QjaCDLLUEXd2DA)-- --===============0422184774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0422184774==-- From ipv6-bounces@ietf.org Tue Apr 24 09:12:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKoP-0002PB-03; Tue, 24 Apr 2007 09:12:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKoN-0002P2-UB for ipv6@ietf.org; Tue, 24 Apr 2007 09:12:03 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKoM-0002ly-KN for ipv6@ietf.org; Tue, 24 Apr 2007 09:12:03 -0400 Received: by poy.chewa.net (Postfix, from userid 33) id 2B30C967E2; Tue, 24 Apr 2007 15:12:01 +0200 (CEST) To: vijaykumar@huawei.com MIME-Version: 1.0 Date: Tue, 24 Apr 2007 15:12:01 +0200 From: Remi Denis-Courmont Organization: Remlab.net In-Reply-To: <000901c78669$6778b340$6005120a@china.huawei.com> References: <000901c78669$6778b340$6005120a@china.huawei.com> Message-ID: <7d89474cb9a3ffd93441ced7b001df60@localhost> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org Subject: Re: IPv6 PTMU query X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 24 Apr 2007 17:39:26 +0530, vijay wrote:=0D > I am interested in knowing if the path MTU is a problem in real network= s=0D =0D Yes it is. Some people have a 1492 MTU due to PPP encapsulation; some hav= e=0D 9000+ such a gigabit links. And in IPv6 case, 1480 (and 1472) are fairly=0D common because of IPv6 over IPv4 tunnels.=0D =0D > and how often packets are dropped due to MTU too small,=0D =0D It very much depends on the network topology. But it definitely happens i= n=0D various cases.=0D =0D --=0D R=C3=A9mi Denis-Courmont=0D http://www.remlab.net/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 24 11:17:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMkO-0001gO-7F; Tue, 24 Apr 2007 11:16:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzKE-0003dM-R0 for ipv6@ietf.org; Mon, 23 Apr 2007 10:15:30 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzKD-0002C1-3c for ipv6@ietf.org; Mon, 23 Apr 2007 10:15:30 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JGY0074MFFU8W@szxga04-in.huawei.com> for ipv6@ietf.org; Mon, 23 Apr 2007 22:11:54 +0800 (CST) Received: from szxmp02-in.huawei.com ([172.24.2.32]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JGY00E8OFF3HI@szxga04-in.huawei.com> for ipv6@ietf.org; Mon, 23 Apr 2007 22:11:54 +0800 (CST) Received: from 172.24.1.24 (EHLO huawei.com) ([172.24.1.24]) by szxmp02-in.huawei.com (MOS 3.8.4-GA FastPath queued) with ESMTP id AHH45041; Tue, 24 Apr 2007 22:11:22 +0800 (CST) Received: from p709321533 ([10.18.4.174]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGY00EU2FFHTW@szxml04-in.huawei.com> for ipv6@ietf.org; Mon, 23 Apr 2007 22:11:50 +0800 (CST) Date: Mon, 23 Apr 2007 19:41:36 +0530 From: Anushka To: ipv6@ietf.org Message-id: <003101c785b1$53e6aac0$ae04120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: AceFsMVhELWm5bACRK+pOvUd/cbB+QAAB7Ug X-Junkmail-IP-Whitelist: YES (by domain ip whitelist at szxmp02-in.huawei.com) X-Spam-Score: 0.2 (/) X-Scan-Signature: 8353da2fde044920180672209f5bf8a0 X-Mailman-Approved-At: Tue, 24 Apr 2007 11:16:02 -0400 Subject: Need info on IPv6 Path MTU X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1594207555==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1594207555== Content-type: multipart/alternative; boundary="Boundary_(ID_yEFIZi/1H37IvD5ufWLnCw)" This is a multi-part message in MIME format. --Boundary_(ID_yEFIZi/1H37IvD5ufWLnCw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, This is my first mail to Ipv6 working group. I am interested in getting some statistical data/ other relevant information regarding, 1. How big is the issue of Ipv6 path MTU calculation? How often the pack is dropped because of path MTU lesser than the packet size? How often fragmentation happens in Ipv6 real networks? 2. The same doubt as above for Ipv4 networks. Plz respond to the mail and you can also send me other information regarding the described topic. Regards Anushka --Boundary_(ID_yEFIZi/1H37IvD5ufWLnCw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi All,

       This is my first mail to Ipv6 working group. I am interested in getting some statistical data/ other relevant information

regarding,

1. How big is the issue of Ipv6 path MTU calculation? How often the pack is dropped because of path MTU lesser than

the packet size? How often fragmentation happens in Ipv6 real networks?

    2. The same doubt as above for Ipv4 networks.

 

Plz respond to the mail and you can also send me other information regarding the described topic.

 

Regards

Anushka

--Boundary_(ID_yEFIZi/1H37IvD5ufWLnCw)-- --===============1594207555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1594207555==-- From ipv6-bounces@ietf.org Tue Apr 24 17:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgSqH-0006qm-1y; Tue, 24 Apr 2007 17:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgSqE-0006qd-Q0 for ipv6@ietf.org; Tue, 24 Apr 2007 17:46:30 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgSqD-0005Jm-CH for ipv6@ietf.org; Tue, 24 Apr 2007 17:46:30 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3844A19868C; Wed, 25 Apr 2007 00:46:28 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E4FFE19866A; Wed, 25 Apr 2007 00:46:27 +0300 (EEST) Message-ID: <462E7AB4.3050807@piuha.net> Date: Wed, 25 Apr 2007 00:46:28 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Jeroen Massar References: <462D4706.4000504@spaghetti.zurich.ibm.com> In-Reply-To: <462D4706.4000504@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: v6ops@ops.ietf.org, ipv6@ietf.org, IPv6 Ops list Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Just in case folks are missing out on this, find below a rather nasty > security issue. > I cannot say that this is a big surprise, even if the specific attack is news to me and it has a major impact. Some issues with Type 0 have been known for years; I think draft-savola-ipv6-rh-ha was the first to report these. RFC 4294 warns of the issues and RFC 3775 design was based on the idea of avoiding Type 0 because it was felt that at some point Type 0 would likely be filtered due to its problems. Also, draft-ietf-v6ops-security-overview was recently approved. It notes, among other things that "it may be desirable to forbid or limit the processing of Type 0 Routing Headers in hosts and some routers." So I think we should take that advice and modify the stacks that do not do the right thing today. A good first approximation is to add a configuration knob for processing Type 0 headers in both hosts and routers, with default set to off. Better firewall support for doing this would also be needed (without disabling use of Type 2, of course). But we at the IETF also need to draw a conclusion about the state of Type 0. This feature needs to be retired. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 24 22:25:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgX91-0002Qp-UO; Tue, 24 Apr 2007 22:22:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgX90-0002QR-F2 for ipv6@ietf.org; Tue, 24 Apr 2007 22:22:10 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgX8z-0001Tf-3s for ipv6@ietf.org; Tue, 24 Apr 2007 22:22:10 -0400 Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l3P2Lc0S077949; Tue, 24 Apr 2007 19:21:38 -0700 (PDT) Date: Wed, 25 Apr 2007 10:49:25 +0900 Message-ID: From: "George V. Neville-Neil" To: Jari Arkko In-Reply-To: <462E7AB4.3050807@piuha.net> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: v6ops@ops.ietf.org, ipv6@ietf.org, IPv6 Ops list Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Wed, 25 Apr 2007 00:46:28 +0300, Jari Arkko wrote: > > > > Just in case folks are missing out on this, find below a rather nasty > > security issue. > > > > I cannot say that this is a big surprise, even if the specific attack > is news to me and it has a major impact. Some issues with Type 0 > have been known for years; I think draft-savola-ipv6-rh-ha was the > first to report these. RFC 4294 warns of the issues and RFC 3775 > design was based on the idea of avoiding Type 0 because it > was felt that at some point Type 0 would likely be filtered due > to its problems. Also, draft-ietf-v6ops-security-overview was recently > approved. It notes, among other things that "it may be desirable > to forbid or limit the processing of Type 0 Routing Headers > in hosts and some routers." > > So I think we should take that advice and modify the stacks that > do not do the right thing today. A good first approximation is > to add a configuration knob for processing Type 0 headers > in both hosts and routers, with default set to off. Better > firewall support for doing this would also be needed (without > disabling use of Type 2, of course). > FreeBSD has already committed patches disabling the processing of route header option 0 by default in all 3 of the currently shipping branches (HEAD, 6-STABLE and 5-STABLE). > But we at the IETF also need to draw a conclusion about the > state of Type 0. This feature needs to be retired. The sooner that decision is made the better. Those of us working on the stacks would like to remove this processing if the feature is retired. Best, George Neville-Neil (FreeBSD Security Team and Core Member) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 03:41:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgc7k-0007tP-U2; Wed, 25 Apr 2007 03:41:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgc7j-0007tE-IC for ipv6@ietf.org; Wed, 25 Apr 2007 03:41:11 -0400 Received: from mail.ki.iif.hu ([193.6.222.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgc7j-0000Qb-67 for ipv6@ietf.org; Wed, 25 Apr 2007 03:41:11 -0400 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id DB6945651; Wed, 25 Apr 2007 09:41:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id D9F2A5650; Wed, 25 Apr 2007 09:41:09 +0200 (CEST) Date: Wed, 25 Apr 2007 09:41:09 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "George V. Neville-Neil" In-Reply-To: Message-ID: <20070425093402.A30586@mignon.ki.iif.hu> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: v6ops@ops.ietf.org, ipv6@ietf.org, IPv6 Ops list Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi All, I think this is not a solution. The problems of routing header type 0 well know by the community since long time. This has been documented for more than 2-3 years know (raised 4 years ago). Are there any consensus, that type 0 routing header should be deprecated? Until that it is documented to be filtered if there is no need for it. The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. I would rather focus on pf changes - allow filtering based on the routing header type. Currently you can filter based existence/non-existence of routing header type. This is currently clearly not enough.... Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 25 Apr 2007, George V. Neville-Neil wrote: > At Wed, 25 Apr 2007 00:46:28 +0300, > Jari Arkko wrote: >> >> >>> Just in case folks are missing out on this, find below a rather nasty >>> security issue. >>> >> >> I cannot say that this is a big surprise, even if the specific attack >> is news to me and it has a major impact. Some issues with Type 0 >> have been known for years; I think draft-savola-ipv6-rh-ha was the >> first to report these. RFC 4294 warns of the issues and RFC 3775 >> design was based on the idea of avoiding Type 0 because it >> was felt that at some point Type 0 would likely be filtered due >> to its problems. Also, draft-ietf-v6ops-security-overview was recently >> approved. It notes, among other things that "it may be desirable >> to forbid or limit the processing of Type 0 Routing Headers >> in hosts and some routers." >> >> So I think we should take that advice and modify the stacks that >> do not do the right thing today. A good first approximation is >> to add a configuration knob for processing Type 0 headers >> in both hosts and routers, with default set to off. Better >> firewall support for doing this would also be needed (without >> disabling use of Type 2, of course). >> > > FreeBSD has already committed patches disabling the processing of > route header option 0 by default in all 3 of the currently shipping > branches (HEAD, 6-STABLE and 5-STABLE). > >> But we at the IETF also need to draw a conclusion about the >> state of Type 0. This feature needs to be retired. > > The sooner that decision is made the better. Those of us working on > the stacks would like to remove this processing if the feature is > retired. > > Best, > George Neville-Neil > (FreeBSD Security Team and Core Member) > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 04:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcuD-0008AC-Vj; Wed, 25 Apr 2007 04:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcuC-0008A7-Ny for ipv6@ietf.org; Wed, 25 Apr 2007 04:31:16 -0400 Received: from salmon.maths.tcd.ie ([2001:770:10:300::86e2:510b]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgcuB-0000z3-6k for ipv6@ietf.org; Wed, 25 Apr 2007 04:31:16 -0400 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 25 Apr 2007 09:31:13 +0100 (BST) Date: Wed, 25 Apr 2007 09:31:12 +0100 From: David Malone To: Mohacsi Janos Message-ID: <20070425083112.GA47411@walton.maths.tcd.ie> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070425093402.A30586@mignon.ki.iif.hu> User-Agent: Mutt/1.5.6i X-Spam-Score: -2.8 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: v6ops@ops.ietf.org, ipv6@ietf.org, IPv6 Ops list Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, Apr 25, 2007 at 09:41:09AM +0200, Mohacsi Janos wrote: > I think this is not a solution. The problems of routing header type 0 well > know by the community since long time. This has been documented for more > than 2-3 years know (raised 4 years ago). Are there any consensus, that > type 0 routing header should be deprecated? Until that it is documented to > be filtered if there is no need for it. The current patch provided by > OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. > I would rather focus on pf changes - allow filtering based on the routing > header type. Currently you can filter based existence/non-existence of > routing header type. It seems to me that there are at least two questions here. One is, "Should IPv6 nodes process type 0 routing headers by default?" The second is, "should the network allow type 0 routing headers to pass?" This is a bit like they choice you have for blocking a smurf attack. You can block it by turning off directed broadcasts (on the edge) or you can block it by blocking ICMP packets throughout the network. I think it may actually be that we do not want nodes to process type 0 routing headers by default, but the network should pass them. The reason for this is that the type 0 headers have useful applications which could be secured by end hosts without getting the network involved at all. Then end hosts that want to use the routing header can, and those that don't are secure by default. I could easily be wrong though... David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 04:47:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgd9O-00019P-N3; Wed, 25 Apr 2007 04:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgd9N-00015X-48 for ipv6@ietf.org; Wed, 25 Apr 2007 04:46:57 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgd9L-00067X-PW for ipv6@ietf.org; Wed, 25 Apr 2007 04:46:57 -0400 Received: by poy.chewa.net (Postfix, from userid 33) id 4C001967E2; Wed, 25 Apr 2007 10:46:54 +0200 (CEST) To: Gert Doering MIME-Version: 1.0 Date: Wed, 25 Apr 2007 10:46:54 +0200 From: Remi Denis-Courmont Organization: Remlab.net In-Reply-To: <20070425082408.GB73965@Space.Net> References: <20070425082408.GB73965@Space.Net> Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org, Mohacsi Janos , IPv6 Ops list , v6ops@ops.ietf.org Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering wrote:=0D > Well, one could argue that the standard isn't very well-written then - = a=0D > machine that is a *host* should NEVER forward packets, period.=0D =0D That's a BSD bug, not a standard bug.=0D =0D The IPv6 specification says host must process RT0. It does not say they m= ust=0D forward packets as if they were routers on the sole basis of RT0 presence= .=0D =0D By the current spec (as far as I understand), if a host receives a RT0, i= t=0D must process it. Then it must apply the same rules to the "new" packet=0D destination as it would do to any packet it receives; in particular, if t= he=0D packet cannot be delivered locally, it is dropped. You do the exact same=0D thing when you receive a packet from link-layer while you are not the=0D destination at network-layer.=0D =0D Whether RT0 is evil and it should be deprecated so routers do not handle = it=0D anymore is the real problem.=0D =0D --=0D R=C3=A9mi Denis-Courmont=0D http://www.remlab.net/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 09:03:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgh9Y-0005Hc-QL; Wed, 25 Apr 2007 09:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgh9X-0005HW-G9 for ipv6@ietf.org; Wed, 25 Apr 2007 09:03:23 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgh9X-0008Tu-0S for ipv6@ietf.org; Wed, 25 Apr 2007 09:03:23 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 267A51C063; Wed, 25 Apr 2007 22:03:20 +0900 (JST) To: rdenis@simphalempin.com In-Reply-To: Your message of "Wed, 25 Apr 2007 10:46:54 +0200" References: X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070425130320.267A51C063@coconut.itojun.org> Date: Wed, 25 Apr 2007 22:03:20 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -2.8 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ipv6@ietf.org, mohacsi@niif.hu, ipv6-ops@lists.cluenet.de, v6ops@ops.ietf.org, gert@space.net Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering wrote: > > Well, one could argue that the standard isn't very well-written then - a > > machine that is a *host* should NEVER forward packets, period. bzzzt. with IPv6 spec NODE (host + router) has to handle routing header type 0 and forward *even if ip6.forwarding is 0. that's the steve deering's last word before he left to Canada for retirement. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 09:31:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghah-0006yI-60; Wed, 25 Apr 2007 09:31:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghaf-0006xe-0x for ipv6@ietf.org; Wed, 25 Apr 2007 09:31:25 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hghad-0000aU-P0 for ipv6@ietf.org; Wed, 25 Apr 2007 09:31:25 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 245DB11432; Wed, 25 Apr 2007 13:31:23 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: v6ops@ops.ietf.org, ipv6@ietf.org, ipv6-ops@lists.cluenet.de In-Reply-To: Your message of "Wed, 25 Apr 2007 09:41:09 +0200." <20070425093402.A30586@mignon.ki.iif.hu> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 25 Apr 2007 13:31:23 +0000 Message-ID: <35875.1177507883@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > ... The problems of routing header type 0 well know by the community since > long time. This has been documented for more than 2-3 years know (raised 4 > years ago). Are there any consensus, that type 0 routing header should be > deprecated? ... yes. nobody anywhere still thinks that this is necessary for any purpose. (if noone within the sound of my voice disagrees, then you have your proof.) ((i just wish i'd had the guts to turn it off on f-root BEFORE the cansecwest presentation, so that we would not have been such a convenient example.)) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 09:44:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghnD-0005NS-TV; Wed, 25 Apr 2007 09:44:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghnC-0005NE-GB for ipv6@ietf.org; Wed, 25 Apr 2007 09:44:22 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HghnB-0002cU-Sl for ipv6@ietf.org; Wed, 25 Apr 2007 09:44:22 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id B420E1C062; Wed, 25 Apr 2007 22:44:19 +0900 (JST) To: paul@vix.com In-Reply-To: Your message of "Wed, 25 Apr 2007 13:31:23 +0000" <35875.1177507883@sa.vix.com> References: <35875.1177507883@sa.vix.com> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070425134419.B420E1C062@coconut.itojun.org> Date: Wed, 25 Apr 2007 22:44:19 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: v6ops@ops.ietf.org, ipv6@ietf.org, ipv6-ops@lists.cluenet.de Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > ... The problems of routing header type 0 well know by the community since > > long time. This has been documented for more than 2-3 years know (raised 4 > > years ago). Are there any consensus, that type 0 routing header should be > > deprecated? ... > > yes. nobody anywhere still thinks that this is necessary for any purpose. > (if noone within the sound of my voice disagrees, then you have your proof.) > > ((i just wish i'd had the guts to turn it off on f-root BEFORE the cansecwest > presentation, so that we would not have been such a convenient example.)) i heard that, in some of peering agreement contract, traceroute -g (something that works like routing header type 0) is needed (for debugging or make sure the peer is not cheating. to make them happy, we need secure version of rthdr0 which supports such use and no bad sideeffect (with new type, like routing header type 7). itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 10:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiFb-00055Q-IE; Wed, 25 Apr 2007 10:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiFa-00055I-4K for ipv6@ietf.org; Wed, 25 Apr 2007 10:13:42 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiFY-0002Ip-NE for ipv6@ietf.org; Wed, 25 Apr 2007 10:13:42 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 35B4E28477; Wed, 25 Apr 2007 14:13:37 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E95D522875; Wed, 25 Apr 2007 10:13:36 -0400 (EDT) Date: Wed, 25 Apr 2007 10:13:36 -0400 From: Rob Austein To: v6ops@ops.ietf.org, ipv6@ietf.org, ipv6-ops@lists.cluenet.de In-Reply-To: <20070425093402.A30586@mignon.ki.iif.hu> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070425141336.E95D522875@thrintun.hactrn.net> X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: > > The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 > implemenation non-conformant to standard. Sometimes violating the standard is the only reasonable thing for an implementor to do. The (IPv4) stack I worked on back in the '90s shipped with forwarding of directed broadcast disabled by default, long before anybody had heard of a "smurf attack". The stack had a compile-time option to enable forwarding of directed broadcast; from memory, the documentation for that option went something like this: "This option exists solely to allow this software to comply with RFC 1812. Directed broadcast is dangerous, no matter what RFC 1812 says. Never enable this option under any circumstances." Eventually the IETF gathered the collective will to update the standard, but as implementors we would have been derelict in our duty to our customers had we waited for the IETF. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 11:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjCC-0007TU-Fu; Wed, 25 Apr 2007 11:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjCB-0007S7-90 for ipv6@ietf.org; Wed, 25 Apr 2007 11:14:15 -0400 Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgjCA-0000LV-01 for ipv6@ietf.org; Wed, 25 Apr 2007 11:14:15 -0400 Received: from vms071.mailsrvcs.net ([192.168.1.2]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JH200DT97NEFE50@vms044.mailsrvcs.net> for ipv6@ietf.org; Wed, 25 Apr 2007 10:14:02 -0500 (CDT) Received: from 209.6.167.241 ([209.6.167.241]) by vms071.mailsrvcs.net (Verizon Webmail) with HTTP; Wed, 25 Apr 2007 10:14:02 -0500 (CDT) Date: Wed, 25 Apr 2007 10:14:02 -0500 (CDT) From: Tim Enos X-Originating-IP: [209.6.167.241] To: Rob Austein , v6ops@ops.ietf.org, ipv6@ietf.org, ipv6-ops@lists.cluenet.de Message-id: <19554098.3052141177514042800.JavaMail.root@vms071.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Yes, absolutely. Rob, I couldn't agree more. >From: Rob Austein >Date: 2007/04/25 Wed AM 09:13:36 CDT >To: v6ops@ops.ietf.org, ipv6@ietf.org, ipv6-ops@lists.cluenet.de >Subject: Re: IPv6 Type 0 Routing Header issues >At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: >> >> The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 >> implemenation non-conformant to standard. > >Sometimes violating the standard is the only reasonable thing for an >implementor to do. The (IPv4) stack I worked on back in the '90s >shipped with forwarding of directed broadcast disabled by default, >long before anybody had heard of a "smurf attack". The stack had a >compile-time option to enable forwarding of directed broadcast; from >memory, the documentation for that option went something like this: > > "This option exists solely to allow this software to comply with RFC > 1812. Directed broadcast is dangerous, no matter what RFC 1812 > says. Never enable this option under any circumstances." > >Eventually the IETF gathered the collective will to update the >standard, but as implementors we would have been derelict in our duty >to our customers had we waited for the IETF. > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 20:39:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgs1K-0004Fx-80; Wed, 25 Apr 2007 20:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgs1J-0004Fs-Cf for ipv6@ietf.org; Wed, 25 Apr 2007 20:39:37 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgs1H-0003tC-Tq for ipv6@ietf.org; Wed, 25 Apr 2007 20:39:37 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3Q0dXEc016029 for ; Thu, 26 Apr 2007 03:39:34 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 03:39:33 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 03:39:33 +0300 Received: from [172.19.74.200] (dadhcp-172019074200.americas.nokia.com [172.19.74.200]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3Q0dUjR012223 for ; Thu, 26 Apr 2007 03:39:31 +0300 In-Reply-To: <462F7005.50700@sri.com> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 25 Apr 2007 17:39:40 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Apr 2007 00:39:33.0079 (UTC) FILETIME=[5BA85E70:01C7879B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org [trimming this to just the IPv6 w.g.] We think the question for the IPv6 working group on this topic is does the working group want to do anything to address the issues raised about the Type 0 routing header. Possible actions include: 1) Deprecate all usage of RH0 2) Recommend that RH0 support be off by default in hosts and routers 3) Recommend that RH0 support be off by default in hosts 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of addresses in one RH0. These examples are not all mutually exclusive. Please respond to the list with your preference and justifications. Thanks, Bob Hinden / Brian Haberman IPv6 W.G. Chairs p.s. We will send a note to the other lists that the IPv6 w.g. will be discussing this issue. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 25 23:02:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguEo-0002HL-NH; Wed, 25 Apr 2007 23:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguEo-0002HG-7H for ipv6@ietf.org; Wed, 25 Apr 2007 23:01:42 -0400 Received: from warlock.cs.waikato.ac.nz ([130.217.250.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HguEk-0007dD-D5 for ipv6@ietf.org; Wed, 25 Apr 2007 23:01:42 -0400 Received: from [130.217.250.13] (helo=[130.217.250.13] ident=perry) by warlock.cs.waikato.ac.nz with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1HguEY-00055X-4h for ipv6@ietf.org; Thu, 26 Apr 2007 15:01:35 +1200 Message-ID: <46301604.6080005@coders.net> Date: Thu, 26 Apr 2007 15:01:24 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 CC: IETF IPv6 Mailing List References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Scanned-By: warlock.cs.waikato.ac.nz (bb70bf0569141ec45ed731f0b23495ea4e7f03d6) X-Spam-Score: -3.9 (---) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Bob Hinden wrote: > [trimming this to just the IPv6 w.g.] > > We think the question for the IPv6 working group on this topic is does > the working group want to do anything to address the issues raised about > the Type 0 routing header. Possible actions include: > > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers I see these two as being equivalent. If RH0 is going to be off by default in routers, then it's for all intents and purposes unusable and should be fully deprecated. > 3) Recommend that RH0 support be off by default in hosts This is what everyone already expects the behavior to be, and even people on this list have shown surprise when they have discovered that this is not the case. I'd completely agree with this. > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of > addresses in one RH0. The use case that I would want to use is allowing trace routes from a->b when you don't have access to either end, or for asking for a reverse trace route from a host back to yourself. These don't require multiple RH0's. If it's not done already (I've not had time to read the spec carefully), you should also check that the scope is the same (or possibly greater) to prevent people for example using RH0 to talk to hosts that only have link local addresses via a router that has a globally routable address. So, I'd prefer disabling it for end hosts, enabling it by default on routers but limiting it to only one RH0 header with the same scope. If that is not acceptable, then deprecate the entire feature. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 03:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgyIW-00032w-GS; Thu, 26 Apr 2007 03:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgyIU-00032q-W8 for ipv6@ietf.org; Thu, 26 Apr 2007 03:21:47 -0400 Received: from mx1.its.eads.net ([193.56.40.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgyIU-0004mk-IF for ipv6@ietf.org; Thu, 26 Apr 2007 03:21:46 -0400 Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by mx1.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Apr 2007 09:19:17 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Apr 2007 09:24:34 +0200 Received: from [172.16.23.99] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92ZKX5F; Thu, 26 Apr 2007 09:31:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Mailer: Apple Mail (2.752.2) Content-class: urn:content-classes:message Date: Thu, 26 Apr 2007 09:21:27 +0200 Message-ID: <49B8EAEE-DB49-45CE-8111-A1AE7232C107@eads.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] Thread-Index: AceH1OovxqJi5raDR2+QOpIvJDMIlg== From: "Ebalard, Arnaud" To: X-OriginalArrivalTime: 26 Apr 2007 07:24:34.0843 (UTC) FILETIME=[F0A346B0:01C787D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Guillaume Valadon , Philippe Biondi , arno@natisbad.org, IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi *, Le 26 avr. 07 =E0 02:39, Bob Hinden a =E9crit : > [trimming this to just the IPv6 w.g.] > > We think the question for the IPv6 working group on this topic is > does the working group want to do anything to address the issues > raised about the Type 0 routing header. Possible actions include: > > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers > 3) Recommend that RH0 support be off by default in hosts > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of addresses in one RH0. > > These examples are not all mutually exclusive. > > Please respond to the list with your preference and justifications. After the time spent playing with the mechanism, my conclusion is =20 that RH0 is clearly too powerful and impacting to still allow core =20 routers and even simple routers to process it by default. For host =20 case, forwarding of packets with RH0 is an error (quite obviously) =20 and even processing is questionable. Regarding the needs, 99.999...% of worldwide IPv6 traffic does not =20 use the mechanism and still perfectly flows. The remaining part is =20 from researchers or attackers that want to DoS infrastructure =20 elements or bypass filtering devices. Just as Paul Vixie asked, I =20 would also be interested to hear from people that use it in a day to =20 day basis and for valid reasons. Where some will argue that you can still filter incoming traffic that =20 includes Type 0 Routing Header in destination sites, this is clearly =20 not a solution, but only a bad workaround as it may still be too late =20 at that point. If 4) is selected and even if a low number of addresses are allowed, =20 anycast will still be defeated. Among others, maintainers of =20 infrastructures that uses this routing scheme should be asked before =20 selecting that action. If 3) is selected and hosts simply drop all packets that include RH0 =20 (_even_ those with a null SegLeft value), this will clearly limit the =20 interest of the mechanism for attackers, as none of their packets =20 will be processed on an ultimate destination (I mean upper layer =20 processing in default configuration). This action will not prevent =20 amplification issues. If 2) is selected, this will also prevent attackers from using the =20 mechanism on routers (on networks that are not specifically =20 configured to accept it) to perform all the nasty things Philippe and =20 I presented. This idea has already been ported to the attention of =20 vendors (Cisco and Juniper) as the default configuration of their =20 routers at the moment is to support RH0 by default (as expected from =20 the specification). From my perspective, this action should be =20 selected if 1) has too many side effects. If 1) is selected, this would simplify the specification (more than =20 15% deals with RH), simplify stacks and would also put a final =20 conclusion to the blind source routing issues that bother everyone =20 for years. My preference goes to this one. IMHO, the main concern =20 associated with that removal is MIPv6: the side effects on RH2 should =20 be carefully considered, if any. hope this helps, Regards, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 06:17:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh11p-0007H3-GF; Thu, 26 Apr 2007 06:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh11n-0007Gi-F5 for ipv6@ietf.org; Thu, 26 Apr 2007 06:16:43 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh11j-0002jb-C1 for ipv6@ietf.org; Thu, 26 Apr 2007 06:16:42 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l3QAGcOr109934 for ; Thu, 26 Apr 2007 10:16:38 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3QAGbHM3395620 for ; Thu, 26 Apr 2007 12:16:37 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3QAGbD0028510 for ; Thu, 26 Apr 2007 12:16:37 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3QAGbsk028499 for ; Thu, 26 Apr 2007 12:16:37 +0200 Received: from [9.4.210.19] ([9.4.210.19]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA317388 for ; Thu, 26 Apr 2007 12:16:36 +0200 Message-ID: <46307C0E.9060809@zurich.ibm.com> Date: Thu, 26 Apr 2007 12:16:46 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: IETF IPv6 Mailing List References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-04-26 02:39, Bob Hinden wrote: > [trimming this to just the IPv6 w.g.] > > We think the question for the IPv6 working group on this topic is does > the working group want to do anything to address the issues raised about > the Type 0 routing header. Possible actions include: > > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers > 3) Recommend that RH0 support be off by default in hosts > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number of > addresses in one RH0. Excuse my ignorance, but have the following three rules ever been considered? 1. The list of addresses in an RH0 MUST NOT include the packet's source address. 2. The same address MUST NOT occur more than once in an RH0. 3. A node processing an RH0 MUST discard any packet breaking these two rules. I'd be interested in whether this would eliminate the various attacks. (I'm not really advocating this, since it is added complexity for a feature that we don't obviously need anyway. But if we don't deprecate it, all the other options seem to leave the threats in place.) Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 06:58:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1gP-0005s0-Hn; Thu, 26 Apr 2007 06:58:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1gN-0005qz-IH for ipv6@ietf.org; Thu, 26 Apr 2007 06:58:39 -0400 Received: from salmon.maths.tcd.ie ([2001:770:10:300::86e2:510b]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hh1gM-00036r-2o for ipv6@ietf.org; Thu, 26 Apr 2007 06:58:39 -0400 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 26 Apr 2007 11:58:36 +0100 (BST) Date: Thu, 26 Apr 2007 11:58:36 +0100 From: David Malone To: Bob Hinden Message-ID: <20070426105836.GA67535@walton.maths.tcd.ie> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: -2.8 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, Apr 25, 2007 at 05:39:40PM -0700, Bob Hinden wrote: > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers > 3) Recommend that RH0 support be off by default in hosts > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of addresses in one RH0. > > These examples are not all mutually exclusive. > > Please respond to the list with your preference and justifications. I wonder if it might be good to have a knob that controls how many _remaining_ hops you are willing to consider. This can then be used to used to implement (2) or (3). For example, the default could be set this knob to zero on end hosts by default, so we only process RH0 where we are the last hop. We could also set this knob to one on routers by default. This would mean you can do things like intermediate-point-traceroute on the IPv6 Internet, which is useful for diagnosing all sorts of things (e.g. is my current route to a praticular host dead, or is the problem elsewhere?). The choice to limit the remaining hops (rather than total number of hops) means that an organisation could use RH0 internally as much as it liked, just as long as only one intermediate hop remained by the time it left the organisation. An attacker might still be able to bounce packets between two organisations that had configured a higher limit, providing that they weren't already doing ingress/egress filtering. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 07:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1sa-00074T-VF; Thu, 26 Apr 2007 07:11:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1sZ-000747-5G for ipv6@ietf.org; Thu, 26 Apr 2007 07:11:15 -0400 Received: from salmon.maths.tcd.ie ([2001:770:10:300::86e2:510b]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hh1sY-0004q7-JW for ipv6@ietf.org; Thu, 26 Apr 2007 07:11:15 -0400 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 26 Apr 2007 12:11:13 +0100 (BST) Date: Thu, 26 Apr 2007 12:11:13 +0100 From: David Malone To: Brian E Carpenter Message-ID: <20070426111113.GB67535@walton.maths.tcd.ie> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <46307C0E.9060809@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46307C0E.9060809@zurich.ibm.com> User-Agent: Mutt/1.5.6i X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, Apr 26, 2007 at 12:16:46PM +0200, Brian E Carpenter wrote: > Excuse my ignorance, but have the following three rules ever been > considered? > > 1. The list of addresses in an RH0 MUST NOT include the packet's source > address. > 2. The same address MUST NOT occur more than once in an RH0. > 3. A node processing an RH0 MUST discard any packet breaking these two > rules. > > I'd be interested in whether this would eliminate the various attacks. I think we did talk about some rules like this before, maybe about the time of the security considerations draft. I think these rules make the attack only slightly more difficult, while at the same time making some possibly valid uses of RH0 require trickery. For example, these rules make it hard to use traceroute to find a round-trip route from me to you. The obvious thing to do here is do a traceroute where SRC=me, RH0[0]=you, RH0[1]=me. Of course, I can always get almost the same information by doing SRC=me, RH0[0]=you RH0[1]=someone_in_my_subnet. You can use the same idea to make the attacks work even with the restrictions above. If I want to flood a link, I find hosts X1 ... XN on one side of the link and Y1 ... YN on the other side. Then I send lots of packets with RH0[0] = X1, RH0[1] = Y1, RH0[2] = X2, RH0[3] = Y2, ... David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 07:24:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh25Q-0000kW-Bg; Thu, 26 Apr 2007 07:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh25O-0000kJ-Ba for ipv6@ietf.org; Thu, 26 Apr 2007 07:24:30 -0400 Received: from mistral.mail.adnap.net.au ([203.6.132.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh25M-0006in-TQ for ipv6@ietf.org; Thu, 26 Apr 2007 07:24:30 -0400 Received: from 219-90-233-111.ip.adam.com.au ([219.90.233.111] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Hh25J-000E5X-3z; Thu, 26 Apr 2007 20:54:25 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id A8DD71FF53; Thu, 26 Apr 2007 20:54:23 +0930 (CST) Date: Thu, 26 Apr 2007 20:54:23 +0930 From: Mark Smith To: vijaykumar@huawei.com Message-Id: <20070426205423.a1441499.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <000901c78669$6778b340$6005120a@china.huawei.com> References: <000901c78669$6778b340$6005120a@china.huawei.com> X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: IPv6 PTMU query X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Vijay, On Tue, 24 Apr 2007 17:39:26 +0530 vijay wrote: > Hi All, > > > > I am currently analyzing the IPv6 path MTU. > > As the IPv6 path MTU calculation is done by error correction method, I was > thinking of suggesting a > > proposal for calculating the path MTU optimally. I am interested in knowing > if the path MTU is a problem > > in real networks and how often packets are dropped due to MTU too small, in > real networks? > > > > If there is some information regarding the same, please share it. > Just in case you aren't aware of it, a recent RFC specifies a mechanism to use probing of Path MTUs via different sizes of packets rather than ICMP error feedback : "RFC4821 - Packetization Layer Path MTU Discovery" There is also an implementation of this in fairly recent Linux kernels. HTH, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 08:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3Qj-000808-8h; Thu, 26 Apr 2007 08:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjB8-0006rC-Ly for ipv6@ietf.org; Wed, 25 Apr 2007 11:13:10 -0400 Received: from mailgate-internal1.sri.com ([128.18.84.103]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgjB7-0000BT-8O for ipv6@ietf.org; Wed, 25 Apr 2007 11:13:10 -0400 Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 25 Apr 2007 15:13:07 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2007042508130729011 for ; Wed, 25 Apr 2007 08:13:07 -0700 Received: from [127.0.0.1] (static-68-236-201-128.nwrk.east.verizon.net [68.236.201.128]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JH200M9Q7LT8PMK@mail.sri.com> for ipv6@ietf.org; Wed, 25 Apr 2007 08:13:07 -0700 (PDT) Date: Wed, 25 Apr 2007 11:13:09 -0400 From: Ed Jankiewicz In-reply-to: <20070425141336.E95D522875@thrintun.hactrn.net> To: v6ops@ops.ietf.org Message-id: <462F7005.50700@sri.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Thu, 26 Apr 2007 08:50:32 -0400 Cc: Rob Austein , "nav6tf@ipv6forum.com" , ipv6@ietf.org, ipv6-ops@lists.cluenet.de Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I am facing a similar dilemma. Currently editing version 2.0 draft of the US DoD "DISR Product Profiles for IPv6" and considering adding a THOU SHALT NOT or at least "it would be a great idea if you didn't" forward based on RH0 due to this vulnerability. At the very least I will note this risk, suggesting that vendors SHOULD provide a means of disabling RH0, and also consider disabling by default. Especially interested in strong opinions from vendors about difficulty in complying if that were the case. Cross posting to NAv6TF as well, but please reply directly to ed.jankiewicz@sri.com and avoid cluttering up the lists with specific objections and suggestions. I will summarize back to the lists. Thanks Ed J. Rob Austein wrote: > At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: > >> The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 >> implemenation non-conformant to standard. >> > > Sometimes violating the standard is the only reasonable thing for an > implementor to do. The (IPv4) stack I worked on back in the '90s > shipped with forwarding of directed broadcast disabled by default, > long before anybody had heard of a "smurf attack". The stack had a > compile-time option to enable forwarding of directed broadcast; from > memory, the documentation for that option went something like this: > > "This option exists solely to allow this software to comply with RFC > 1812. Directed broadcast is dangerous, no matter what RFC 1812 > says. Never enable this option under any circumstances." > > Eventually the IETF gathered the collective will to update the > standard, but as implementors we would have been derelict in our duty > to our customers had we waited for the IETF. > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 08:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3Qg-0007z7-Uz; Thu, 26 Apr 2007 08:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgfZS-0002JN-Fz for ipv6@ietf.org; Wed, 25 Apr 2007 07:22:02 -0400 Received: from 207-172-85-4.c3-0.slvr-ubr2.lnh-slvr.md.static.cable.rcn.com ([207.172.85.4] helo=claudius.sentinelchicken.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgfZR-000501-8b for ipv6@ietf.org; Wed, 25 Apr 2007 07:22:02 -0400 Received: (qmail 28836 invoked from network); 25 Apr 2007 11:22:00 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.0.1.2) by claudius.sentinelchicken.org with SMTP; 25 Apr 2007 11:22:00 -0000 Received: (qmail 24777 invoked from network); 25 Apr 2007 11:22:00 -0000 Received: from feynman.sentinelchicken.org (10.0.1.3) by pascal.sentinelchicken.org with SMTP; 25 Apr 2007 11:22:00 -0000 Received: (nullmailer pid 2818 invoked by uid 1000); Wed, 25 Apr 2007 11:22:00 -0000 Date: Wed, 25 Apr 2007 07:22:00 -0400 From: Tim To: David Malone Message-ID: <20070425112200.GA2753@sentinelchicken.org> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425083112.GA47411@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070425083112.GA47411@walton.maths.tcd.ie> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 26 Apr 2007 08:50:32 -0400 Cc: v6ops@ops.ietf.org, ipv6@ietf.org, IPv6 Ops list Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I think it may actually be that we do not want nodes to process > type 0 routing headers by default, but the network should pass them. > The reason for this is that the type 0 headers have useful applications > which could be secured by end hosts without getting the network > involved at all. Then end hosts that want to use the routing header > can, and those that don't are secure by default. Then how would one deal with the "flux capacitor" attacks as described at CanSecWest? Eventually the bot herders will figure out how to use this and flatten a few networks with little effort. Also, combining ping-pong style RH0 attack with TCP handshake amplification (or any other reflected amplification attacks that reverse the source routing headers on reply and double or triple the number of packets) gives you an even bigger amplification, which could target the upstream routers of a victim network. This would probably work even better than smurf attaFrom ipv6-bounces@ietf.org Thu Apr 26 08:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3Qj-000808-8h; Thu, 26 Apr 2007 08:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjB8-0006rC-Ly for ipv6@ietf.org; Wed, 25 Apr 2007 11:13:10 -0400 Received: from mailgate-internal1.sri.com ([128.18.84.103]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgjB7-0000BT-8O for ipv6@ietf.org; Wed, 25 Apr 2007 11:13:10 -0400 Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 25 Apr 2007 15:13:07 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2007042508130729011 for ; Wed, 25 Apr 2007 08:13:07 -0700 Received: from [127.0.0.1] (static-68-236-201-128.nwrk.east.verizon.net [68.236.201.128]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JH200M9Q7LT8PMK@mail.sri.com> for ipv6@ietf.org; Wed, 25 Apr 2007 08:13:07 -0700 (PDT) Date: Wed, 25 Apr 2007 11:13:09 -0400 From: Ed Jankiewicz In-reply-to: <20070425141336.E95D522875@thrintun.hactrn.net> To: v6ops@ops.ietf.org Message-id: <462F7005.50700@sri.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Thu, 26 Apr 2007 08:50:32 -0400 Cc: Rob Austein , "nav6tf@ipv6forum.com" , ipv6@ietf.org, ipv6-ops@lists.cluenet.de Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I am facing a similar dilemma. Currently editing version 2.0 draft of the US DoD "DISR Product Profiles for IPv6" and considering adding a THOU SHALT NOT or at least "it would be a great idea if you didn't" forward based on RH0 due to this vulnerability. At the very least I will note this risk, suggesting that vendors SHOULD provide a means of disabling RH0, and also consider disabling by default. Especially interested in strong opinions from vendors about difficulty in complying if that were the case. Cross posting to NAv6TF as well, but please reply directly to ed.jankiewicz@sri.com and avoid cluttering up the lists with specific objections and suggestions. I will summarize back to the lists. Thanks Ed J. Rob Austein wrote: > At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: > >> The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 >> implemenation non-conformant to standard. >> > > Sometimes violating the standard is the only reasonable thing for an > implementor to do. The (IPv4) stack I worked on back in the '90s > shipped with forwarding of directed broadcast disabled by default, > long before anybody had heard of a "smurf attack". The stack had a > compile-time option to enable forwarding of directed broadcast; from > memory, the documentation for that option went something like this: > > "This option exists solely to allow this software to comply with RFC > 1812. Directed broadcast is dangerous, no matter what RFC 1812 > says. Never enable thicks did "back in the day" when one could still use them. Loose source routing is just a bad idea. Yeah, great for testing, but should be off by default on everything. This lesson was learned long ago, why are we repeating the same mistakes? That's my $0.02. (Take it with a grain of salt, since I'm no networking expert.) cheers, tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- s option under any circumstances." > > Eventually the IETF gathered the collective will to update the > standard, but as implementors we would have been derelict in our duty > to our customers had we waited for the IETF. > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 08:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3Qg-0007z7-Uz; Thu, 26 Apr 2007 08:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgfZS-0002JN-Fz for ipv6@ietf.org; Wed, 25 Apr 2007 07:22:02 -0400 Received: from 207-172-85-4.c3-0.slvr-ubr2.lnh-slvr.md.static.cable.rcn.com ([207.172.85.4] helo=claudius.sentinelchicken.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgfZR-000501-8b for ipv6@ietf.org; Wed, 25 Apr 2007 07:22:02 -0400 Received: (qmail 28836 invoked from network); 25 Apr 2007 11:22:00 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.0.1.2) by claudius.sentinelchicken.org with SMTP; 25 Apr 2007 11:22:00 -0000 Received: (qmail 24777 invoked from network); 25 Apr 2007 11:22:00 -0000 Received: from feynman.sentinelchicken.org (10.0.1.3) by pascal.sentinelchicken.org with SMTP; 25 Apr 2007 11:22:00 -0000 Received: (nullmailer pid 2818 invoked by uid 1000); Wed, 25 Apr 2007 11:22:00 -0000 Date: Wed, 25 Apr 2007 07:22:00 -0400 From: Tim To: David Malone Message-ID: <20070425112200.GA2753@sentinelchicken.org> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425083112.GA47411@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070425083112.GA47411@walton.maths.tcd.ie> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 26 Apr 2007 08:50:32 -0400 Cc: v6ops@ops.ietf.org, ipv6@ietf.org, IPv6 Ops list Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I think it may actually be that we do not want nodes to process > type 0 routing headers by default, but the network should pass them. > The reason for this is that the type 0 headers have useful applications > which could be secured by end hosts without getting the network > involved at all. Then end hosts that want to use the routing header > can, and those that don't are secure by default. Then how would one deal with the "flux capacitor" attacks as described at CanSecWest? Eventually the bot herders will figure out how to use this and flatten a few networks with little effort. Also, combining ping-pong style RH0 attack with TCP handshake amplification (or any other reflected amplification attacks that reverse the source routing headers on reply and double or triple the number of packets) gives you an even bigger amplification, which could target the upstream routers of a victim network. This would probably work even better than smurf attacks did "back in the day" when one could still use them. Loose source routing is just a bad idea. Yeah, great for testing, but should be off by default on everything. This lesson was learned long ago, why are we repeating the same mistakes? That's my $0.02. (Take it with a grain of salt, since I'm no networking expert.) cheers, tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 08:51:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3RP-00089a-GT; Thu, 26 Apr 2007 08:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcnL-0003o4-74 for ipv6@ietf.org; Wed, 25 Apr 2007 04:24:11 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgcnJ-0007Ew-JT for ipv6@ietf.org; Wed, 25 Apr 2007 04:24:11 -0400 Received: (qmail 82598 invoked by uid 1007); 25 Apr 2007 08:24:08 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=YS4JIe8VdMNRa93/3kxi49PEl/oD5J+PxTSyQhPdZfiuYzF+LC856bjcWNJyLVSa ; Date: Wed, 25 Apr 2007 10:24:08 +0200 From: Gert Doering To: Mohacsi Janos Message-ID: <20070425082408.GB73965@Space.Net> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070425093402.A30586@mignon.ki.iif.hu> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Thu, 26 Apr 2007 08:51:18 -0400 Cc: v6ops@ops.ietf.org, ipv6@ietf.org, IPv6 Ops list Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, On Wed, Apr 25, 2007 at 09:41:09AM +0200, Mohacsi Janos wrote: > I think this is not a solution. The problems of routing header type 0 well > know by the community since long time. This has been documented for more > than 2-3 years know (raised 4 years ago). Are there any consensus, that > type 0 routing header should be deprecated? Until that it is documented to > be filtered if there is no need for it. The current patch provided by > OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. Well, one could argue that the standard isn't very well-written then - a machine that is a *host* should NEVER forward packets, period. That's what we have routers for, and there is a well-defined way to change a *BSD machine from a "host" to a "router" (turn on ip6.forwarding). > I would rather focus on pf changes - allow filtering based on the routing > header type. Currently you can filter based existence/non-existence of > routing header type. This is currently clearly not enough.... Extending pf(4) accordingly would certainly be a good thing, as it could help other machines behind a NetBSD firewall. (BTW - what's pf(4) doing if a packet comes with with RH0? Which address does it use for ACL checking, and which address is used for state setup?) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 08:51:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3RQ-0008CO-84; Thu, 26 Apr 2007 08:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgeRn-00014E-NG for ipv6@ietf.org; Wed, 25 Apr 2007 06:10:03 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgeRm-0007ya-9z for ipv6@ietf.org; Wed, 25 Apr 2007 06:10:03 -0400 Received: (qmail 19051 invoked by uid 1007); 25 Apr 2007 10:10:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=KYVmSEM3THt/Uly4NKtEgvODm1v4gNSwQJk8KcuQq4Z/RgR2pBq51bF4ssAsvZlG ; Date: Wed, 25 Apr 2007 12:10:01 +0200 From: Gert Doering To: Remi Denis-Courmont Message-ID: <20070425101001.GH73965@Space.Net> References: <20070425082408.GB73965@Space.Net> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Thu, 26 Apr 2007 08:51:18 -0400 Cc: ipv6@ietf.org, Mohacsi Janos , IPv6 Ops list , v6ops@ops.ietf.org, Gert Doering Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0105198993==" Errors-To: ipv6-bounces@ietf.org --===============0105198993== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f8lmXUvqnCdFQPaI" Content-Disposition: inline --f8lmXUvqnCdFQPaI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Apr 25, 2007 at 10:46:54AM +0200, Remi Denis-Courmont wrote: >=20 > On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering wrote: >=20 > > Well, one could argue that the standard isn't very well-written then - a > > machine that is a *host* should NEVER forward packets, period. >=20 > That's a BSD bug, not a standard bug. >=20 > The IPv6 specification says host must process RT0. It does not say they m= ust > forward packets as if they were routers on the sole basis of RT0 presence. >=20 > By the current spec (as far as I understand), if a host receives a RT0, it > must process it. Then it must apply the same rules to the "new" packet > destination as it would do to any packet it receives; in particular, if t= he > packet cannot be delivered locally, it is dropped. You do the exact same > thing when you receive a packet from link-layer while you are not the > destination at network-layer. Thanks for the clarification. Indeed, this explains the necessity to process the RH0 header locally (it might point to a different address on th= e=20 *same host*). Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --f8lmXUvqnCdFQPaI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBRi8o+akuBuNlUUl1AQJ3jAP/Qgi9rWPu0EJHGxqz2p81OJ6m5+Ng4yZb H9LZXgNM2MGwrmKRBvSSFTbHULBhiK2iLnPq7GZyio0zBlgtdEYiyV/HpJ5M7BSQ SMfiC/ZB0Bch088JK/ppeb8DExZ1wb6tsx1AQ+d2eI6FG4Da/HNOt7iHSj2b9UVH mm9YFVpDAHo= =cNbS -----END PGP SIGNATURE----- --f8lmXUvqnCdFQPaI-- --===============0105198993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0105198993==-- From ipv6-bounces@ietf.org Thu Apr 26 11:03:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5Ux-0000Cl-Hx; Thu, 26 Apr 2007 11:03:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5Uw-0000Cg-NK for ipv6@ietf.org; Thu, 26 Apr 2007 11:03:06 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh5Uv-0004yo-El for ipv6@ietf.org; Thu, 26 Apr 2007 11:03:06 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3QF33kK010315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Apr 2007 10:03:04 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3QF32ln023395; Thu, 26 Apr 2007 08:03:03 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3QF2rC7022865; Thu, 26 Apr 2007 08:02:54 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 11:02:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Apr 2007 11:02:50 -0400 Message-ID: In-Reply-To: <20070425101001.GH73965@Space.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Type 0 Routing Header issues Thread-Index: AceIAa6HuP4+0Lm9RSu2Fd9lb2FPKgAEcskg References: <20070425082408.GB73965@Space.Net> <20070425101001.GH73965@Space.Net> From: "Manfredi, Albert E" To: "Gert Doering" X-OriginalArrivalTime: 26 Apr 2007 15:02:50.0481 (UTC) FILETIME=[F550AE10:01C78813] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipv6@ietf.org Subject: RE: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Gert Doering [mailto:gert@space.net]=20 > On Wed, Apr 25, 2007 at 10:46:54AM +0200, Remi Denis-Courmont wrote: > >=20 > > On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering=20 > wrote: > >=20 > > > Well, one could argue that the standard isn't very=20 > well-written then - a > > > machine that is a *host* should NEVER forward packets, period. > >=20 > > That's a BSD bug, not a standard bug. > >=20 > > The IPv6 specification says host must process RT0. It does=20 > not say they must > > forward packets as if they were routers on the sole basis=20 > of RT0 presence. > >=20 > > By the current spec (as far as I understand), if a host=20 > receives a RT0, it > > must process it. Then it must apply the same rules to the=20 > "new" packet > > destination as it would do to any packet it receives; in=20 > particular, if the > > packet cannot be delivered locally, it is dropped. You do=20 > the exact same > > thing when you receive a packet from link-layer while you=20 > are not the > > destination at network-layer. >=20 > Thanks for the clarification. Indeed, this explains the necessity to > process the RH0 header locally (it might point to a different=20 > address on the=20 > *same host*). Which would be a good tool for anyone intending a DOS attack on that single host. I've been trying to figure out why Steve Deering wanted RHO to be supported in hosts and routers. Maybe this was the reason. Multiple IP addresses in a host. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 11:18:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5k3-00049m-W2; Thu, 26 Apr 2007 11:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5k3-00049h-30 for ipv6@ietf.org; Thu, 26 Apr 2007 11:18:43 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh5k2-0007St-BQ for ipv6@ietf.org; Thu, 26 Apr 2007 11:18:43 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id E300A1C063; Fri, 27 Apr 2007 00:18:39 +0900 (JST) To: Arnaud.Ebalard@eads.net In-Reply-To: Your message of "Thu, 26 Apr 2007 09:21:27 +0200" <49B8EAEE-DB49-45CE-8111-A1AE7232C107@eads.net> References: <49B8EAEE-DB49-45CE-8111-A1AE7232C107@eads.net> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-Id: <20070426151839.E300A1C063@coconut.itojun.org> Date: Fri, 27 Apr 2007 00:18:39 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -2.8 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: guedou@hongo.wide.ad.jp, phil@secdev.org, arno@natisbad.org, bob.hinden@nokia.com, ipv6@ietf.org Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Le 26 avr. 07 .AN` 02:39, Bob Hinden a Nicrit :*B ah, finally. i even try to reach Steve saying "no time for Salmon fishing, man". > > [trimming this to just the IPv6 w.g.] > > > > We think the question for the IPv6 working group on this topic is > > does the working group want to do anything to address the issues > > raised about the Type 0 routing header. Possible actions include: > > > > 1) Deprecate all usage of RH0 > > 2) Recommend that RH0 support be off by default in hosts and routers > > 3) Recommend that RH0 support be off by default in hosts > > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > > of addresses in one RH0. > > > > These examples are not all mutually exclusive. > > > > Please respond to the list with your preference and justifications. are you still did not get the urgency? haven't you read my analysis and THE PDF file? it's total doomsday for IPv6 (if not the planet). we were really lucky that IPv6-haters did not get it. do you know how many sleepless nights i have been spending starting last Friday (when theo woke me up and pointed me to the PDF). we must spread the word "never miss the next software update from Apple" since Apple is the most dangerous beast since it does 6to4/teredo (oops, was teredo MS only?) by default. we have already leaked it to the japanese press people. i wonder how many of them are clever enough to understand it (i told my close friend but he works for TV station, so i even leaked the real effect). itojun PS: if i do not get postel award (if not novel prize of peace) i'll quit KAME and become a new life as a freelance IPv6 evangelist. first target is Skype, which is totally IPv6-unfriendly. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 12:14:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6bk-0002cF-2i; Thu, 26 Apr 2007 12:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6bi-0002c8-Rj for ipv6@ietf.org; Thu, 26 Apr 2007 12:14:10 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6bi-0007JS-DW for ipv6@ietf.org; Thu, 26 Apr 2007 12:14:10 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id C38951C068; Fri, 27 Apr 2007 01:14:08 +0900 (JST) To: perry@coders.net In-Reply-To: Your message of "Thu, 26 Apr 2007 15:01:24 +1200" <46301604.6080005@coders.net> References: <46301604.6080005@coders.net> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070426161408.C38951C068@coconut.itojun.org> Date: Fri, 27 Apr 2007 01:14:08 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ipv6@ietf.org Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Bob Hinden wrote: > > [trimming this to just the IPv6 w.g.] > > > > We think the question for the IPv6 working group on this topic is does > > the working group want to do anything to address the issues raised about > > the Type 0 routing header. Possible actions include: > > > > 1) Deprecate all usage of RH0 > > 2) Recommend that RH0 support be off by default in hosts and routers > > I see these two as being equivalent. If RH0 is going to be off by > default in routers, then it's for all intents and purposes unusable and > should be fully deprecated. no, do not place sysctl. devote time to develop new type 'routing header type 123' instead. it does not have bad sideffect but can perform something like rthdr0. in this doomsday story and samurais saving the planet, we were extremely lucky beacause: - iPv6-haters still didn't get it (or did they changed their mind?) - MIP6 was NOT using rthdr0 it's a message from god. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 18:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCi4-0000L4-RH; Thu, 26 Apr 2007 18:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCi3-0000Ka-Lk for ipv6@ietf.org; Thu, 26 Apr 2007 18:45:07 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhCi1-0008A4-6R for ipv6@ietf.org; Thu, 26 Apr 2007 18:45:07 -0400 Received: from eagle (127.0.0.1:2552) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 26 Apr 2007 15:44:59 -0700 From: "Tony Hain" To: "'Ed Jankiewicz'" , References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> In-Reply-To: <462F7005.50700@sri.com> Date: Thu, 26 Apr 2007 15:44:50 -0700 Message-ID: <017401c78854$805ac050$811040f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceHTKgMBHU9OvoyTfyxYpjQatrdWgBBwUTw Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: 'Rob Austein' , nav6tf@ipv6forum.com, ipv6@ietf.org, ipv6-ops@lists.cluenet.de Subject: RE: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Before you kill this off too quickly, James Woodyatt's proxy redirection is a perfect example of a use for Type 0 Routing Headers. He wants the firewall to redirect traffic through a designated point (what this header was designed to do), and the only hammer at his immediate disposal was IPv6/IPv6 nat. It is certainly reasonable to have a BCP that says 'these should be filtered at policy boundaries unless there is a good reason to do otherwise', but they are a tool to solve some very specific corner cases. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Ed Jankiewicz > Sent: Wednesday, April 25, 2007 8:13 AM > To: v6ops@ops.ietf.org > Cc: Rob Austein; ipv6@ietf.org; ipv6-ops@lists.cluenet.de; > nav6tf@ipv6forum.com > Subject: Re: IPv6 Type 0 Routing Header issues > > I am facing a similar dilemma. Currently editing version 2.0 draft of > the US DoD "DISR Product Profiles for IPv6" and considering adding a > THOU SHALT NOT or at least "it would be a great idea if you didn't" > forward based on RH0 due to this vulnerability. At the very least I > will note this risk, suggesting that vendors SHOULD provide a means of > disabling RH0, and also consider disabling by default. > > Especially interested in strong opinions from vendors about difficulty > in complying if that were the case. Cross posting to NAv6TF as well, > but please reply directly to ed.jankiewicz@sri.com and avoid cluttering > up the lists with specific objections and suggestions. I will summarize > back to the lists. > > Thanks > Ed J. > > Rob Austein wrote: > > At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote: > > > >> The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6 > >> implemenation non-conformant to standard. > >> > > > > Sometimes violating the standard is the only reasonable thing for an > > implementor to do. The (IPv4) stack I worked on back in the '90s > > shipped with forwarding of directed broadcast disabled by default, > > long before anybody had heard of a "smurf attack". The stack had a > > compile-time option to enable forwarding of directed broadcast; from > > memory, the documentation for that option went something like this: > > > > "This option exists solely to allow this software to comply with RFC > > 1812. Directed broadcast is dangerous, no matter what RFC 1812 > > says. Never enable this option under any circumstances." > > > > Eventually the IETF gathered the collective will to update the > > standard, but as implementors we would have been derelict in our duty > > to our customers had we waited for the IETF. > > > > > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research > Supporting DISA Standards Engineering Branch > 732-389-1003 or ed.jankiewicz@sri.com > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 18:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCp3-0004yc-GV; Thu, 26 Apr 2007 18:52:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCp1-0004tv-Ez for ipv6@ietf.org; Thu, 26 Apr 2007 18:52:19 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhCoz-0000e3-Vn for ipv6@ietf.org; Thu, 26 Apr 2007 18:52:19 -0400 Received: from eagle (127.0.0.1:2630) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 26 Apr 2007 15:52:15 -0700 From: "Tony Hain" To: "'Manfredi, Albert E'" , "'Gert Doering'" References: <20070425082408.GB73965@Space.Net> <20070425101001.GH73965@Space.Net> In-Reply-To: Date: Thu, 26 Apr 2007 15:52:07 -0700 Message-ID: <017501c78855$84a6f380$8df4da80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceIAa6HuP4+0Lm9RSu2Fd9lb2FPKgAEcskgABBiriA= Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ipv6@ietf.org Subject: RE: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org As I recall the primary goal was to allow a system to state a specific transit path because it was the one that the subscriber had a contract with. Think dialing a local number to get a specific long-distance carrier's presence, rather than paying the extortion rate that the local provider charges for their random selection of long-distance. Tony > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Thursday, April 26, 2007 8:03 AM > To: Gert Doering > Cc: ipv6@ietf.org > Subject: RE: IPv6 Type 0 Routing Header issues > > > -----Original Message----- > > From: Gert Doering [mailto:gert@space.net] > > > On Wed, Apr 25, 2007 at 10:46:54AM +0200, Remi Denis-Courmont wrote: > > > > > > On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering > > wrote: > > > > > > > Well, one could argue that the standard isn't very > > well-written then - a > > > > machine that is a *host* should NEVER forward packets, period. > > > > > > That's a BSD bug, not a standard bug. > > > > > > The IPv6 specification says host must process RT0. It does > > not say they must > > > forward packets as if they were routers on the sole basis > > of RT0 presence. > > > > > > By the current spec (as far as I understand), if a host > > receives a RT0, it > > > must process it. Then it must apply the same rules to the > > "new" packet > > > destination as it would do to any packet it receives; in > > particular, if the > > > packet cannot be delivered locally, it is dropped. You do > > the exact same > > > thing when you receive a packet from link-layer while you > > are not the > > > destination at network-layer. > > > > Thanks for the clarification. Indeed, this explains the necessity to > > process the RH0 header locally (it might point to a different > > address on the > > *same host*). > > Which would be a good tool for anyone intending a DOS attack on that > single host. > > I've been trying to figure out why Steve Deering wanted RHO to be > supported in hosts and routers. Maybe this was the reason. Multiple IP > addresses in a host. > > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 18:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCvJ-0007dc-EL; Thu, 26 Apr 2007 18:58:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCvI-0007dU-Ex for ipv6@ietf.org; Thu, 26 Apr 2007 18:58:48 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhCvH-00025Y-Vn for ipv6@ietf.org; Thu, 26 Apr 2007 18:58:48 -0400 Received: from eagle (127.0.0.1:2669) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 26 Apr 2007 15:58:46 -0700 From: "Tony Hain" To: "'Brian E Carpenter'" , "'IETF IPv6 Mailing List'" References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <46307C0E.9060809@zurich.ibm.com> In-Reply-To: <46307C0E.9060809@zurich.ibm.com> Date: Thu, 26 Apr 2007 15:58:37 -0700 Message-ID: <017601c78856$6d2b7cc0$47827640$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceH7AuZvGsv1j2WTs60CpVyMXIfeAAaduHg Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I thought we already limited to 1 RH0 per packet, but I will have to go = back and take a closer look.=20 As I said on V6ops, before you kill this off too quickly, James = Woodyatt's proxy redirection is a perfect example of a valid use for = Type 0 Routing Headers. He wants the firewall to redirect traffic = through a designated point (what this header was designed to do), and = the only hammer at his immediate disposal was IPv6/IPv6 nat. What I = don't know is if the firewall can insert one that did not exist, because = the source wouldn't know about his 'transparent' proxy.=20 It is certainly reasonable to have a BCP that says 'these should be = filtered at policy boundaries unless there is a good reason to do = otherwise', but they are a tool to solve some very specific corner = cases. I would say that firewalls should drop these by default, but the = rest of the system should recognize them as normal. Tony > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Thursday, April 26, 2007 3:17 AM > To: IETF IPv6 Mailing List > Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header > issues] >=20 > On 2007-04-26 02:39, Bob Hinden wrote: > > [trimming this to just the IPv6 w.g.] > > > > We think the question for the IPv6 working group on this topic is = does > > the working group want to do anything to address the issues raised > about > > the Type 0 routing header. Possible actions include: > > > > 1) Deprecate all usage of RH0 > > 2) Recommend that RH0 support be off by default in hosts and = routers > > 3) Recommend that RH0 support be off by default in hosts > > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of > > addresses in one RH0. >=20 > Excuse my ignorance, but have the following three rules ever been > considered? >=20 > 1. The list of addresses in an RH0 MUST NOT include the packet's = source > address. > 2. The same address MUST NOT occur more than once in an RH0. > 3. A node processing an RH0 MUST discard any packet breaking these two > rules. >=20 > I'd be interested in whether this would eliminate the various attacks. >=20 > (I'm not really advocating this, since it is added complexity for > a feature that we don't obviously need anyway. But if we don't = deprecate > it, all the other options seem to leave the threats in place.) >=20 > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 20:18:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhE9v-0007ok-1q; Thu, 26 Apr 2007 20:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhE9t-0007oZ-D3 for ipv6@ietf.org; Thu, 26 Apr 2007 20:17:57 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhE9s-0008RO-13 for ipv6@ietf.org; Thu, 26 Apr 2007 20:17:57 -0400 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3R0Ht9A000640 for ; Thu, 26 Apr 2007 17:17:55 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 4E8CB10081 for ; Thu, 26 Apr 2007 17:17:55 -0700 (PDT) X-AuditID: 11807124-a24a0bb000000872-22-46314133530b Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay6.apple.com (Apple SCV relay) with ESMTP id 4083810044 for ; Thu, 26 Apr 2007 17:17:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <017601c78856$6d2b7cc0$47827640$@net> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <46307C0E.9060809@zurich.ibm.com> <017601c78856$6d2b7cc0$47827640$@net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5690ABCA-8385-4C5F-941E-1012D1CA35B7@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 26 Apr 2007 17:17:54 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Apr 26, 2007, at 15:58, Tony Hain wrote: > > As I said on V6ops, before you kill this off too quickly, James > Woodyatt's proxy redirection is a perfect example of a valid use > for Type 0 Routing Headers. He wants the firewall to redirect > traffic through a designated point (what this header was designed > to do), and the only hammer at his immediate disposal was IPv6/IPv6 > nat. What I don't know is if the firewall can insert one that did > not exist, because the source wouldn't know about his 'transparent' > proxy. I should make clear that I'm not persuaded that use of the routing extension header gives me a way to do what I've been talking about in both V6OPS and BEHAVE. Moreover, I *really* don't think RH type code **ZERO** is a better hammer than simple IPv6 NAT. (Oh boy... I've just whacked another beehive, haven't I?) For my immediate purposes, where I only need to redirect inside the routing node between the packet filter and the node's own stack, I can probably define my own internal routing extension header type code. In fact, since the packets aren't going anywhere on the wire, I could just dispense with the extension header altogether and just overwrite the destination address in the IPv6 header while inserting an appropriate state record into the packet filter for the proxy to find. This will be functionally equivalent to using IPv6 NAT, and I'll be doing this in the code that implements the IPv4 NAT and SPI filter, but if it makes everyone feel more warm and fuzzy that no actual NAT is going on, I'll use another word for it. I wouldn't want anybody to lose more sleep. Where the situation gets a lot more interesting is when the transparent application proxy is not resident on the same node as the filter where the diversion happens. That's where the routing extension header could be necessary. In that case, I still don't think type code *ZERO* is the wrong choice, because something must *remove* the extension header on the return path for the proxy to remain transparent. -- j h woodyatt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 20:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhERq-0003vV-W9; Thu, 26 Apr 2007 20:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhERq-0003vQ-1B for ipv6@ietf.org; Thu, 26 Apr 2007 20:36:30 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhERn-0002XG-Mg for ipv6@ietf.org; Thu, 26 Apr 2007 20:36:30 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3R0aRF9026498 for ; Thu, 26 Apr 2007 17:36:27 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 051BC404FD for ; Thu, 26 Apr 2007 17:36:27 -0700 (PDT) X-AuditID: 11807126-a0e85bb0000012e1-70-4631458a074a Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay8.apple.com (Apple SCV relay) with ESMTP id E5E8740472 for ; Thu, 26 Apr 2007 17:36:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <5690ABCA-8385-4C5F-941E-1012D1CA35B7@apple.com> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <46307C0E.9060809@zurich.ibm.com> <017601c78856$6d2b7cc0$47827640$@net> <5690ABCA-8385-4C5F-941E-1012D1CA35B7@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E8AE577-95D3-4941-A405-B995B5275F69@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 26 Apr 2007 17:36:26 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Apr 26, 2007, at 17:17, james woodyatt wrote: > > [...] I still don't think type code *ZERO* is the wrong choice [...]. Oops. This should have read, "I still think type code *ZERO* is the wrong choice..." Sorry for any confusion. -- j h woodyatt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 26 21:07:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhEvq-0000Hu-Mm; Thu, 26 Apr 2007 21:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhEvp-0000Hc-6K for ipv6@ietf.org; Thu, 26 Apr 2007 21:07:29 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhEvn-0007W7-Rd for ipv6@ietf.org; Thu, 26 Apr 2007 21:07:29 -0400 Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l3R167Nc016490; Thu, 26 Apr 2007 18:06:07 -0700 (PDT) Date: Fri, 27 Apr 2007 10:06:01 +0900 Message-ID: From: "George V. Neville-Neil" To: "Tony Hain" In-Reply-To: <017501c78855$84a6f380$8df4da80$@net> References: <20070425082408.GB73965@Space.Net> <20070425101001.GH73965@Space.Net> <017501c78855$84a6f380$8df4da80$@net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ipv6@ietf.org, 'Gert Doering' Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, I would be interested in a list of cases FOR the Type 0 Routing Header. If there are no good cases for it, it seems to me that removing it is the best thing to do. Best, George -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 05:05:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMNM-0005pj-1x; Fri, 27 Apr 2007 05:04:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMNK-0005nl-Rt for ipv6@ietf.org; Fri, 27 Apr 2007 05:04:22 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhMNJ-0006sJ-IM for ipv6@ietf.org; Fri, 27 Apr 2007 05:04:22 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Apr 2007 11:04:21 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3R94K3c001033; Fri, 27 Apr 2007 11:04:20 +0200 Received: from ukse-xdm1.cisco.com (ukse-xdm1.cisco.com [64.103.71.41]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3R94HlZ022276; Fri, 27 Apr 2007 09:04:20 GMT Received: (alevans@localhost) by ukse-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id l3R94H117922; Fri, 27 Apr 2007 10:04:17 +0100 (BST) X-Authentication-Warning: ukse-xdm1.cisco.com: alevans set sender to alun@cisco.com using -f From: Alun Evans To: "George V. Neville-Neil" References: <20070425082408.GB73965@Space.Net> <20070425101001.GH73965@Space.Net> <017501c78855$84a6f380$8df4da80$@net> Date: Fri, 27 Apr 2007 10:04:17 +0100 In-Reply-To: (George V. Neville-Neil's message of "Fri, 27 Apr 2007 10:06:01 +0900") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.2 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=503; t=1177664660; x=1178528660; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alun@cisco.com; z=From:=20Alun=20Evans=20 |Subject:=20Re=3A=20IPv6=20Type=200=20Routing=20Header=20issues |Sender:=20; bh=DHi/Voq7vR+yDzWaCOgbq6Av05oGgmM3TLoGsqvrKbs=; b=MANnB+epwVHZFEryDGOrFdE9U6FFMty4kicOhodcIp+V/aNHGSBmlfws3pcGNg+3InqJjEIx xo9pER+3GkAoG8R7fZ8bSMVw8Wb3jGnsACyktw2zLKnsZOmCWnxmd187; Authentication-Results: ams-dkim-2; header.From=alun@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org, 'Gert Doering' , Tony Hain Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri 27 Apr '07 at 02:06 "George V. Neville-Neil" wrote: > > Hi, > > I would be interested in a list of cases FOR the Type 0 Routing > Header. If there are no good cases for it, it seems to me that > removing it is the best thing to do. I quite like traceroute for the return path. Which would also explain why Hosts are meant to process the routing header. A. -- Alun Evans IOS Software Engineer, cisco Systems. http://www.cisco.com/go/ipv6/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 05:19:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMbU-000657-5Y; Fri, 27 Apr 2007 05:19:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMbS-0005zu-97 for ipv6@ietf.org; Fri, 27 Apr 2007 05:18:58 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhMbP-0001kS-LZ for ipv6@ietf.org; Fri, 27 Apr 2007 05:18:58 -0400 Received: from [IPv6:2001:770:100:9e::2] (cl-159.dub-01.ie.sixxs.net [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 64B28140C3E6; Fri, 27 Apr 2007 11:18:54 +0200 (CEST) Message-ID: <4631C005.2000609@spaghetti.zurich.ibm.com> Date: Fri, 27 Apr 2007 10:19:01 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Alun Evans References: <20070425082408.GB73965@Space.Net> <20070425101001.GH73965@Space.Net> <017501c78855$84a6f380$8df4da80$@net> In-Reply-To: X-Enigmail-Version: 0.94.3.0 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV 0.90.1/3168/Fri Apr 27 10:23:30 2007 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipv6@ietf.org Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1305948131==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1305948131== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2891EA922E8B1217ECB1C4D6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2891EA922E8B1217ECB1C4D6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alun Evans wrote: >=20 > On Fri 27 Apr '07 at 02:06 "George V. Neville-Neil" wrote: >> Hi, >> >> I would be interested in a list of cases FOR the Type 0 Routing >> Header. If there are no good cases for it, it seems to me that >> removing it is the best thing to do. >=20 > I quite like traceroute for the return path. This 'problem' can be solved with looking glass websites, not which such an obvious security problem as RH0. That said, there should be a well defined system for Looking Glasses. Please see the proposal I made to the RIPE Database WG to define these: http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00040.html As there where at least no negative comments, I guess I should make a more formal proposal soon to solve this, for both IPv4 and IPv6 and in a standard way (hoping that the other RIR's will follow in providing this data too, but as some RIR's don't have a real IRR yet that might take tim= e). Greets, Jeroen --------------enig2891EA922E8B1217ECB1C4D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkYxwAUuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58IyjEAKC8/fFRIIVSGwHzKdOq3j7mWVVL LgCdE38kveDU9tAcyL4H2AmLXHIlO7k= =UbEc -----END PGP SIGNATURE----- --------------enig2891EA922E8B1217ECB1C4D6-- --===============1305948131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1305948131==-- From ipv6-bounces@ietf.org Fri Apr 27 05:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMj6-0002oo-2q; Fri, 27 Apr 2007 05:26:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMj4-0002oW-Fp for ipv6@ietf.org; Fri, 27 Apr 2007 05:26:50 -0400 Received: from salmon.maths.tcd.ie ([2001:770:10:300::86e2:510b]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhMj1-0004Aw-W6 for ipv6@ietf.org; Fri, 27 Apr 2007 05:26:50 -0400 Date: Fri, 27 Apr 2007 10:26:45 +0100 From: David Malone To: Jeroen Massar Message-ID: <20070427092645.GA16970@salmon.maths.tcd.ie> References: <20070425082408.GB73965@Space.Net> <20070425101001.GH73965@Space.Net> <017501c78855$84a6f380$8df4da80$@net> <4631C005.2000609@spaghetti.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4631C005.2000609@spaghetti.zurich.ibm.com> User-Agent: Mutt/1.5.6i X-Spam-Score: -2.8 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ipv6@ietf.org Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, Apr 27, 2007 at 10:19:01AM +0100, Jeroen Massar wrote: > This 'problem' can be solved with looking glass websites, not which such > an obvious security problem as RH0. Surely the number of looking glass websites are a clear sign of a difficency in IPv4? (Also, having to parse input to web pages and pass information to command line tools has had more than its fair share of security problems ;-) David -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 07:02:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOCn-00014a-2V; Fri, 27 Apr 2007 07:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOCl-00012f-Cl for ipv6@ietf.org; Fri, 27 Apr 2007 07:01:35 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOCk-0004Ex-Vk for ipv6@ietf.org; Fri, 27 Apr 2007 07:01:35 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 4A1E81C04E; Fri, 27 Apr 2007 20:01:32 +0900 (JST) To: jhw@apple.com In-Reply-To: Your message of "Thu, 26 Apr 2007 17:36:26 -0700" <5E8AE577-95D3-4941-A405-B995B5275F69@apple.com> References: <5E8AE577-95D3-4941-A405-B995B5275F69@apple.com> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070427110132.4A1E81C04E@coconut.itojun.org> Date: Fri, 27 Apr 2007 20:01:32 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) X-Spam-Score: -2.8 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ipv6@ietf.org Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > On Apr 26, 2007, at 17:17, james woodyatt wrote: > > > > [...] I still don't think type code *ZERO* is the wrong choice [...]. > > Oops. This should have read, "I still think type code *ZERO* is the > wrong choice..." Sorry for any confusion. don't worry, the world is in panic like 1912. everybody is in panic(). itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 08:40:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPj4-0003WV-4m; Fri, 27 Apr 2007 08:39:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPj2-0003WO-LV for ipv6@ietf.org; Fri, 27 Apr 2007 08:39:00 -0400 Received: from ns2.its.eads.net ([193.56.40.67] helo=mx2.its.eads.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPj1-0001jB-87 for ipv6@ietf.org; Fri, 27 Apr 2007 08:39:00 -0400 Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by mx2.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Apr 2007 14:36:36 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Apr 2007 14:41:51 +0200 Received: from [172.16.23.99] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92ZK7JH; Fri, 27 Apr 2007 14:48:49 +0200 X-Mailer: Apple Mail (2.752.2) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Apr 2007 14:38:37 +0200 Message-ID: <8A6FCC38-EA35-4EC2-A195-B8E327D50DA2@eads.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Type 0 Routing Header issues Thread-Index: AceIymbYA+ItkeiOTE2Pclpc/4UQeg== From: "Ebalard, Arnaud" To: "Alun Evans" X-OriginalArrivalTime: 27 Apr 2007 12:41:51.0812 (UTC) FILETIME=[6DF7F840:01C788C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ipv6@ietf.org, Gert Doering , Tony Hain Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Alun, Hi *, Le 27 avr. 07 =E0 11:04, Alun Evans a =E9crit : >> I would be interested in a list of cases FOR the Type 0 Routing >> Header. If there are no good cases for it, it seems to me that >> removing it is the best thing to do. > > I quite like traceroute for the return path. > > Which would also explain why Hosts are meant to process the routing > header. The thing is that we are dealing here with IPv6, the network layer =20 protocol that we expect to carry most of the data and communications =20 exchanged in the world in a near future. What we want that protocol to provide is an efficient and resilient =20 service. As we all know (i hope so), this can only be achieved by =20 keeping its basis light and simple, and preventing useless extensions =20 to pollute routers' stacks (especially core routers). This has been a =20 design goal of IPv6, to limit the processing performed by routers (no =20 checksum in IPv6 header, fixed size, limited number of fields, no =20 fragmentation in the network, smart address aggregation, ...). IMHO, =20 having RH0 in the specification is an error. You more than many others should agree on the fact that complexity =20 and stability/security do not fit well together, especially in =20 stacks' implementations : - Cisco IOS had implementation issues regarding RH0, - all *BSD stacks (including Mac OS X) also made mistakes regarding =20 RH0 processing, - Linux just prevented its use even in router mode (2.6.20.9). And those points are only implementation issues. So if you add to =20 those facts that the mechanism is also potentially impacting at the =20 infrastructure level, I think this clearly outweighs the =20 "convenience" of remote traceroutes and co., which by the way seem to =20 be used by 3 geeks around the world. From my perspective, RH0 should be deprecated to simplify IPv6 =20 specification, stacks' implementations and suppress associated =20 threats. Keeping the generic RH mechanism will be sufficient for new =20 protocols to __carefully__ provide associated functionalities (if =20 any), just like the designers of Mobile IPv6 did with RH2 (IMHO, =20 processing limited to MIPv6 implementations, no external forwarding, =20 one address max, ...). Cheers, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 08:54:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPx0-00070b-Sh; Fri, 27 Apr 2007 08:53:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPwy-0006vS-W0 for ipv6@ietf.org; Fri, 27 Apr 2007 08:53:24 -0400 Received: from postfix.iai.uni-bonn.de ([131.220.8.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPwx-0007hi-LO for ipv6@ietf.org; Fri, 27 Apr 2007 08:53:24 -0400 X-IAI-Env-From: : [131.220.4.211] Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 7A9485C830 for ; Fri, 27 Apr 2007 14:53:22 +0200 (MEST) (envelope-from ignatios@cello.cs.uni-bonn.de) (envelope-to ipv6@ietf.org) (1) (internal use: ta=0, tu=1, te=0, am=-, au=-) Received: from cello.cs.uni-bonn.de (cello.cs.uni-bonn.de [131.220.4.178]) by theory.cs.uni-bonn.de (8.12.9/8.12.9) with SMTP id l3RCrMb6012150 for ; Fri, 27 Apr 2007 14:53:22 +0200 (MEST) Received: (from ignatios@cello.cs.uni-bonn.de) by cello.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb4 7oct2003); Fri, 27 Apr 2007 14:53:22 CEST (sender ignatios@cello.cs.uni-bonn.de) Date: Fri, 27 Apr 2007 14:53:22 +0200 From: Ignatios Souvatzis Cc: IETF IPv6 Mailing List Message-ID: <20070427125322.GC952@cs.uni-bonn.de> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, Apr 25, 2007 at 05:39:40PM -0700, Bob Hinden wrote: > [trimming this to just the IPv6 w.g.] > > We think the question for the IPv6 working group on this topic is > does the working group want to do anything to address the issues > raised about the Type 0 routing header. Possible actions include: > > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers > 3) Recommend that RH0 support be off by default in hosts > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of addresses in one RH0. > > These examples are not all mutually exclusive. > > Please respond to the list with your preference and justifications. It seems to me 2, maybe combined with 4, would be appropriate for now. I've read or thought about two theoretical uses: - use it to enforce a specific path that's less costly (commercially) than the default, or to avoid crossing a hostile part of the network. It occurs to me that access to such a path would probably be secured by IPSec or similar; naked, unsecured redirection would be useless in this context. - use it to access otherwise unrouted to the public networks Again, those would either be guarded by IPsec or some other VPN technology, or not really useful. Anyway, if any such setup would need RT0 in a controlled enviroment, it could be switched back on there. (After controlling RT0 *transmission* past the environment borders.) Regards, -is -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 09:59:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQxQ-00079q-6R; Fri, 27 Apr 2007 09:57:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQxO-00078r-4D; Fri, 27 Apr 2007 09:57:54 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQxM-0001iL-Sh; Fri, 27 Apr 2007 09:57:54 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id DDA281C060; Fri, 27 Apr 2007 22:57:49 +0900 (JST) To: alh-ietf@tndh.net, iesg@ietf.org, iab@ietf.org In-Reply-To: Your message of "Thu, 26 Apr 2007 15:52:07 -0700" <017501c78855$84a6f380$8df4da80$@net> References: <017501c78855$84a6f380$8df4da80$@net> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070427135749.DDA281C060@coconut.itojun.org> Date: Fri, 27 Apr 2007 22:57:49 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) X-Spam-Score: -2.8 (--) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: funya@sfc.wide.ad.jp, ipv6@ietf.org, gert@space.net, deraadt@openbsd.org Subject: itojun2.0 (RE: IPv6 Type 0 Routing Header issues) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org even though Japanese, itojun2.0 is much like Theo so bare with me. i will use quite a language, so it's X-rated. and for those who didn't know, theo finally plan about enabling INET6 on cvs.openbsd.org and studying jinmei/shima/qingli book. our 15 years of effort was not a waste! then this doomsday news. how ironical. > > > > That's a BSD bug, not a standard bug. no, both. RFC problem: - standard introduced mistake in RFC1883 -> RFC2460 (dropped loose/strict bit, at the same time maxhop/rthdr0 bumped to 128) for this hinden or deering needs harakiri - no limit in # routing headers in packet diagram just show typical header ordering not limitation so it's a big pitfall. in a very small font "you can put as many routing headers in a packet"!! for ths i guess deering harakiri exercise: how many hops you can make if link MTU=1280? or 9000? - even HOST must forward rthdr (we have checked w/ Steve 1000 times so KAME does not need harakiri, Deering is) implementation support - we were too spec conformant :-) - didn't know hinden/deering are spec writer, no coder they may have code when they were young, but in 1995 they had grandchild or big kid - forcused too much onto IPv6, forgot about 1992 common sense "routing header considered harmful" (another ironical coindidence, INET92 kobe was where ipng effort was started). because IPv4 option was dead from the beginning (WIDE"s mobility protocol, VIP, used IPv4 option and it could not reach the States due to banned IPv4 option for this one, KAME needs to harakiri. with this doomsday situation and feel of guilt, how can i (or kame) take even a nap? that's why you see i keep posting and posting. deering is total slacker because he's in canada fishing Salmon!! i tried very hard to reach the author, and hinden came to us with total non-understanding and optimism when tomorrow is the doomsday. how do you think? nokia people, someone is trying to impersonate lovely hinden. if i'm wrong and it was real hinden he sent to SM club and spanked by thousands of dominas before harakiri. but that's may actually what makes him happy. but joy of SM and bondage world will finish by harakiri, we gladly allow him to enjoy SM and bondage. now, think about how IETF work as ex-IAB: in IPv4 days: - implement and test - then write a draft or, - BSD IPv4 code is there - everyone cheated and looked at it today: - write a draft with pipe dream - spam IESG - then implement - big issue happen - go back to 1 now, in KAME we meant to make t-shirt "code then spec, not spec then code' clearly KAME made successful "spec then code", but it was because Jun Murai bawed million (if not billion) times to get people like jinmei (he's ICHIRO or GOILLA MATSUI of toshiba), kazu (in project management he is also ICHIRO) and me (king of v6, jinmei beats me in careful spec reading because i'm spine-coder and nanosleep guy) to make "IPv6 samurais", which is IPv6. and we seriously we devoted our very lives onto that i was dumped by two or three girlfriends. that guilt adds up. then spice domestic violence by father, knowledge of DNA and darwin theory (hate father, then hate myself because half of my blood is toilet water), you have a guy with mental illness. yes, that's very reason you do not bump into me at IETF venue. too much computing hurts you, i know, but to deploy IPv6 in "spec then code" way we need a Kamikaze attack by IPv6 samurais. let us assume 2^128 was not enough. another set of harakiri and feel guilt. i would go suicide. not suicide attack, but the game hangman. to summarize, to stop this kind of doomsday spec issue we have to switch our mind from "spec then code" to "code then spec". require 2 interoperable independent implementation to submit draft. effects are: - robust protocol - much fewer drafts - no spam-like loony tune drafts - iesg hapy - iesg queue flushes quickly so, everyone will happy. if you object, you can call me any time, i won't be able to sleep until very last IPv6-capable machine gets upgraded. hope it will finish before i become zombie. i leave "code then spec" discussion to current IESG/IAB. at least IESG will be extremely happy about it. do not hesitate to cc: me, if it is IAB/IESG and email amount moderate so that i can handle rthdr0. i'm an ex IAB, so keep me in the loop. thanks for reading this rant. itojun PS: "itojun2.0" is like "Web2.0". i.e. i know how to control adrenaline rush, i now forgot about my father completely. i slack sometimes when my friend calls me so do not worry. noone but me can work and post 24x7 without sleeping. PPS: no need to send "please sleep" letters to me, i got plenty of them already. i need to read rthdr0 spams so i do not need more spams. i do know you all love me and i love you all, it's just the feel of guilt which keeps me awake. and my next door neighbor is my doctor so i don't need to even call ambulance. and if tomorrow is doomsday, what do you care? harakiri? kamikaze? family? no, i do not have family i'm alone so only people who cries when i die would be theo and IPv6 samurais and of course, "Father of Japanese net", Jun Murai, IAB 1992-94. PPPS: i'm not crazy. i'm quite sane. i'm king of v6. the mental illness story is real. if you think you can beat me you ay fuck my anal and suck my dick, or perform scull fuck. or you can check with jinmei, who is the only guy beats me. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 12:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSrK-0002oD-VW; Fri, 27 Apr 2007 11:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSrI-0002md-Qd; Fri, 27 Apr 2007 11:59:44 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSrH-0001sB-CI; Fri, 27 Apr 2007 11:59:44 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 0E4851C063; Sat, 28 Apr 2007 00:59:41 +0900 (JST) To: alh-ietf@tndh.net, iesg@ietf.org, iab@ietf.org In-Reply-To: Your message of "Fri, 27 Apr 2007 22:57:49 +0900 (JST)" <20070427135749.DDA281C060@coconut.itojun.org> References: <20070427135749.DDA281C060@coconut.itojun.org> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070427155941.0E4851C063@coconut.itojun.org> Date: Sat, 28 Apr 2007 00:59:41 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) X-Spam-Score: -2.8 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: funya@sfc.wide.ad.jp, ipv6@ietf.org, gert@space.net, deraadt@openbsd.org Subject: Re: itojun2.0 (RE: IPv6 Type 0 Routing Header issues) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > he is also ICHIRO) and me (king of v6, jinmei beats me in careful > spec reading because i'm spine-coder and nanosleep guy) > to make "IPv6 samurais", which is IPv6. $s/IPv6\.$/KAME./ it's miracle that i need to correct only one typo. my hands are shaking due to 24x7. now i can finally take a nap. you can see if i'm awake/bbusy bby skype status of itojun.hagino (do not DDoS me please) itojun2.0 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 13:44:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUU9-0005iN-B9; Fri, 27 Apr 2007 13:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUU7-0005iB-Oa for ipv6@ietf.org; Fri, 27 Apr 2007 13:43:55 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUU6-0003qn-AN for ipv6@ietf.org; Fri, 27 Apr 2007 13:43:55 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2A0E119868D; Fri, 27 Apr 2007 20:43:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D8E0E19867E; Fri, 27 Apr 2007 20:43:52 +0300 (EEST) Message-ID: <46323659.2090406@piuha.net> Date: Fri, 27 Apr 2007 20:43:53 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: bob.hinden@nokia.com References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Brian Carpenter , IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers > 3) Recommend that RH0 support be off by default in hosts > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of addresses in one RH0. My preference is 2 or alternatively 1. I am currently not aware of any real use case for Type 0 header (but please educate me if there is some). It has been known to be dangerous for a long time and without a use case, it seems waste of energy to work on 4 or other more detailed limitations to make it safe. In particular I would very much like to see us publishing the RFC deprecating/turning this off soon. Developing the rules for 4 is possible, but it will take time. More fundamentally, I believe functions like this need to be tailored to a specific need before they can be made restricted enough to be safe and useful at the same. This is what was done with Type 2, for instance. If we will see a future need for something like this, I suspect that it may need a new Type number anyway. Alternative 3 is an interesting one. It would actually align IPv6 with current IPv4 specifications. RFC 1812 calls for a configuration option to turn off source routes, but requires the default to be that the source routes are processed. I'm not sure this is right, however... perhaps we should update corresponding IPv4 specifications at the same time, too. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 14:43:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVPj-00022c-Sp; Fri, 27 Apr 2007 14:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVPi-00022W-5C for ipv6@ietf.org; Fri, 27 Apr 2007 14:43:26 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVPg-0001qP-Qe for ipv6@ietf.org; Fri, 27 Apr 2007 14:43:26 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3RIhO26026945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Apr 2007 11:43:24 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3RIhNZ9018535; Fri, 27 Apr 2007 11:43:23 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3RIhDav018223; Fri, 27 Apr 2007 11:43:23 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 14:43:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2007 14:43:21 -0400 Message-ID: In-Reply-To: <017501c78855$84a6f380$8df4da80$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Type 0 Routing Header issues Thread-Index: AceIAa6HuP4+0Lm9RSu2Fd9lb2FPKgAEcskgABBiriAAKYdiIA== References: <017501c78855$84a6f380$8df4da80$@net> From: "Manfredi, Albert E" To: X-OriginalArrivalTime: 27 Apr 2007 18:43:22.0558 (UTC) FILETIME=[EEA925E0:01C788FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: RE: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net]=20 > Sent: Thursday, April 26, 2007 6:52 PM >=20 > As I recall the primary goal was to allow a system to state a specific > transit path because it was the one that the subscriber had a=20 > contract with. > Think dialing a local number to get a specific long-distance carrier's > presence, rather than paying the extortion rate that the=20 > local provider > charges for their random selection of long-distance. That makes good sense for the sending host. But the receiving host would have no reason to forward anything beyond the destination address of the packet, no matter what the extension header says. Except for the case of multiple IP addresses in that host, which I had not considered. If Steve Deering wanted all hosts, whether set to forward packets or not, to process extension headers, my only conclusion is that he was thinking of multiple IP addresses in that host. Just trying to figure out what the corner cases are. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 15:24:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhW3a-0007W7-Ld; Fri, 27 Apr 2007 15:24:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhW3Z-0007W2-FW for ipv6@ietf.org; Fri, 27 Apr 2007 15:24:37 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhW3Y-0005oV-0x for ipv6@ietf.org; Fri, 27 Apr 2007 15:24:37 -0400 Received: from eagle (127.0.0.1:1815) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 27 Apr 2007 12:24:32 -0700 From: "Tony Hain" To: "'Manfredi, Albert E'" References: <017501c78855$84a6f380$8df4da80$@net> In-Reply-To: Date: Fri, 27 Apr 2007 12:24:20 -0700 Message-ID: <02e801c78901$a7dd2890$f79779b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceIAa6HuP4+0Lm9RSu2Fd9lb2FPKgAEcskgABBiriAAKYdiIAABFofA Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipv6@ietf.org Subject: RE: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Manfredi, Albert E wrote: > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Thursday, April 26, 2007 6:52 PM > > > > As I recall the primary goal was to allow a system to state a specific > > transit path because it was the one that the subscriber had a > > contract with. > > Think dialing a local number to get a specific long-distance carrier's > > presence, rather than paying the extortion rate that the > > local provider > > charges for their random selection of long-distance. > > That makes good sense for the sending host. But the receiving host would > have no reason to forward anything beyond the destination address of the > packet, no matter what the extension header says. Except for the case of > multiple IP addresses in that host, which I had not considered. Well by definition a host does not forward, else it becomes a router. In any case, I don't recall discussion about using it for alternate path selection to the same destination, but assuming the source tried RH0 using the address set from dns, it would be a lot simpler than the shim6 sillyness with exactly the same security downsides. The thing that it doesn't do is take the alternate addressing out of the source host and put it under control of the network boundary policy. > > If Steve Deering wanted all hosts, whether set to forward packets or > not, to process extension headers, my only conclusion is that he was > thinking of multiple IP addresses in that host. Except for hop-by-hop, the extension headers are explicitly about taking the end-to-end options out of the base IPv6 header. Essentially every extension header is there for processing by the receiving host. The fact that there are artifacts of the routing extension that might be useful to the receiving host was not a design goal. > > Just trying to figure out what the corner cases are. What you are witnessing is the eternal struggle for -control- between the end system oriented implementers and the network operations oriented implementers. There are use cases on both sides that can & will be abused. People tend to disparage the use cases that don't fit their particular take on the 'who is in control' issue, and rather than defining best practice configurations they would rather take the easy out of abolishing things that give the other side some degree of control. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 17:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhY3M-0005x2-9S; Fri, 27 Apr 2007 17:32:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhY3K-0005ox-PF for ipv6@ietf.org; Fri, 27 Apr 2007 17:32:30 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhY3K-00036C-Dv for ipv6@ietf.org; Fri, 27 Apr 2007 17:32:30 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 27 Apr 2007 14:32:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.25; Fri, 27 Apr 2007 14:32:29 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Apr 2007 14:32:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2007 14:32:18 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC053929E6@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <46323659.2090406@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] Thread-Index: AceI88XoTU7hR0lRTqWNR+a9IFPdvgAHqm0Q References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <46323659.2090406@piuha.net> From: Dave Thaler To: Jari Arkko , X-OriginalArrivalTime: 27 Apr 2007 21:32:29.0279 (UTC) FILETIME=[8E93E6F0:01C78913] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Brian Carpenter , IETF IPv6 Mailing List Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Two scenarios that are much less harmful are=20 when there is only 1 address in only one RH0: 1) when the intermediate destination address and the final destination address are addresses of the same node. 2) when the final destination address is equal to the=20 source address. In both cases, the intermediate destination isn't being used as transit between two other nodes. A sample use case of the second scenario is for a round-trip=20 traceroute. -Dave -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Friday, April 27, 2007 10:44 AM To: bob.hinden@nokia.com Cc: Brian Carpenter; IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers > 3) Recommend that RH0 support be off by default in hosts > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of addresses in one RH0. My preference is 2 or alternatively 1. I am currently not aware of any real use case for Type 0 header (but please educate me if there is some). It has been known to be dangerous for a long time and without a use case, it seems waste of energy to work on 4 or other more detailed limitations to make it safe. In particular I would very much like to see us publishing the RFC deprecating/turning this off soon. Developing the rules for 4 is possible, but it will take time. More fundamentally, I believe functions like this need to be tailored to a specific need before they can be made restricted enough to be safe and useful at the same. This is what was done with Type 2, for instance. If we will see a future need for something like this, I suspect that it may need a new Type number anyway. Alternative 3 is an interesting one. It would actually align IPv6 with current IPv4 specifications. RFC 1812 calls for a configuration option to turn off source routes, but requires the default to be that the source routes are processed. I'm not sure this is right, however... perhaps we should update corresponding IPv4 specifications at the same time, too. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 18:22:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhYpz-00060d-Le; Fri, 27 Apr 2007 18:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhYpy-0005vo-Ax for ipv6@ietf.org; Fri, 27 Apr 2007 18:22:46 -0400 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhYnd-0001oJ-DU for ipv6@ietf.org; Fri, 27 Apr 2007 18:20:22 -0400 Received: from alerion.mentat.com (alerion.mentat.com [192.88.122.132]) by roll.mentat.com (Postfix) with ESMTP id 3FF7341141; Fri, 27 Apr 2007 15:19:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id 740533F0021; Fri, 27 Apr 2007 15:20:20 -0700 (PDT) Received: from alerion.mentat.com ([127.0.0.1]) by localhost (alerion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26219-05; Fri, 27 Apr 2007 15:20:19 -0700 (PDT) Received: from [192.88.122.144] (feller.mentat.com [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id 109523F0020; Fri, 27 Apr 2007 15:20:19 -0700 (PDT) From: Tim Hartrick To: bob.hinden@nokia.com In-Reply-To: <0c126c4f66f44430f54517e287076133@message.md5> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <0c126c4f66f44430f54517e287076133@message.md5> Content-Type: text/plain Organization: Packeteer, Inc. Date: Fri, 27 Apr 2007 15:20:18 -0700 Message-Id: <1177712418.13779.23.camel@feller> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tim@mentat.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Bob, On Wed, 2007-04-25 at 17:39 -0700, Bob Hinden wrote: > > We think the question for the IPv6 working group on this topic is > does the working group want to do anything to address the issues > raised about the Type 0 routing header. Possible actions include: > > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers > 3) Recommend that RH0 support be off by default in hosts > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of addresses in one RH0. > > These examples are not all mutually exclusive. > > Please respond to the list with your preference and justifications. > I am a bit surprised that the security problems with the routing header come as some sort of revelation at this stage. The intent, as I recall, in including this feature was to duplicate IPv4 source routing (originally strict source routing was supported) with all the problems, but get the specification of the processing cleaned up. That was accomplished in spades. As I recall from my conversations with him, Steve Deering never wanted this mess in the specification in the first place. I don't think it was part of SIPP but I don't have the spec handy. My recollection of a conversation with Steve on this topic back in the previous century, at an IPv6 bake-off, was that it was "forced upon us" by the politics of the IPng "process". I think we can safely put to bed the idea that the designers were dolts who didn't learn from history. That doesn't mean there weren't dolts involved in the "process".:-) That said I am in favor of 2. It is the easiest to retrofit onto existing implementations. The question I have is what action should a host and/or router take if it receives a datagram with a routing header while support is disabled: 1) ICMPv6 destination unreachable/admininistratively prohibited. 2) Other ICMPv6 destination unreachable. 3) Silent discard. I vote for 3 but I could be convinced about 1 or 2. It appears that IPv4 is supposed to do the equivalent of 1. Tim Hartrick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 22:29:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhcgO-0007MK-9F; Fri, 27 Apr 2007 22:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhcgM-0007MF-NX for ipv6@ietf.org; Fri, 27 Apr 2007 22:29:06 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhcgL-00043y-9v for ipv6@ietf.org; Fri, 27 Apr 2007 22:29:06 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 8A2821C062; Sat, 28 Apr 2007 11:29:02 +0900 (JST) To: jari.arkko@piuha.net In-Reply-To: Your message of "Fri, 27 Apr 2007 20:43:53 +0300" <46323659.2090406@piuha.net> References: <46323659.2090406@piuha.net> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070428022902.8A2821C062@coconut.itojun.org> Date: Sat, 28 Apr 2007 11:29:02 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) X-Spam-Score: -2.8 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org, brc@zurich.ibm.com, bob.hinden@nokia.com Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > 1) Deprecate all usage of RH0 > > 2) Recommend that RH0 support be off by default in hosts and routers > > 3) Recommend that RH0 support be off by default in hosts > > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > > of addresses in one RH0. > > My preference is 2 or alternatively 1. I am currently not bzzzt, you got Z grade. were you sleeping? itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 22:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhcie-0002B1-Ps; Fri, 27 Apr 2007 22:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhcid-00028U-H3 for ipv6@ietf.org; Fri, 27 Apr 2007 22:31:27 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhcic-0004L8-Lu for ipv6@ietf.org; Fri, 27 Apr 2007 22:31:27 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 706E41C064; Sat, 28 Apr 2007 11:31:25 +0900 (JST) To: alh-ietf@tndh.net In-Reply-To: Your message of "Fri, 27 Apr 2007 12:24:20 -0700" <02e801c78901$a7dd2890$f79779b0$@net> References: <02e801c78901$a7dd2890$f79779b0$@net> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070428023125.706E41C064@coconut.itojun.org> Date: Sat, 28 Apr 2007 11:31:25 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) X-Spam-Score: -2.8 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipv6@ietf.org Subject: RE: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org i don't understand, rthdr0 must be killed, grilled, diced into million pieces. say farewell. you did not do my exercise even: - how many hops you can make w/ a packet sized 1280? itojun > Manfredi, Albert E wrote: > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: Thursday, April 26, 2007 6:52 PM > > > > > > As I recall the primary goal was to allow a system to state a specific > > > transit path because it was the one that the subscriber had a > > > contract with. > > > Think dialing a local number to get a specific long-distance carrier's > > > presence, rather than paying the extortion rate that the > > > local provider > > > charges for their random selection of long-distance. > > > > That makes good sense for the sending host. But the receiving host would > > have no reason to forward anything beyond the destination address of the > > packet, no matter what the extension header says. Except for the case of > > multiple IP addresses in that host, which I had not considered. > > Well by definition a host does not forward, else it becomes a router. > In any case, I don't recall discussion about using it for alternate path > selection to the same destination, but assuming the source tried RH0 using > the address set from dns, it would be a lot simpler than the shim6 sillyness > with exactly the same security downsides. The thing that it doesn't do is > take the alternate addressing out of the source host and put it under > control of the network boundary policy. > > > > > If Steve Deering wanted all hosts, whether set to forward packets or > > not, to process extension headers, my only conclusion is that he was > > thinking of multiple IP addresses in that host. > > Except for hop-by-hop, the extension headers are explicitly about taking the > end-to-end options out of the base IPv6 header. Essentially every extension > header is there for processing by the receiving host. The fact that there > are artifacts of the routing extension that might be useful to the receiving > host was not a design goal. > > > > > Just trying to figure out what the corner cases are. > > What you are witnessing is the eternal struggle for -control- between the > end system oriented implementers and the network operations oriented > implementers. There are use cases on both sides that can & will be abused. > People tend to disparage the use cases that don't fit their particular take > on the 'who is in control' issue, and rather than defining best practice > configurations they would rather take the easy out of abolishing things that > give the other side some degree of control. > > Tony > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 27 23:08:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhdHs-0001PV-S0; Fri, 27 Apr 2007 23:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhdHr-0001PQ-94 for ipv6@ietf.org; Fri, 27 Apr 2007 23:07:51 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhdHq-00024Q-Gf for ipv6@ietf.org; Fri, 27 Apr 2007 23:07:51 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id D37D71C069; Sat, 28 Apr 2007 12:07:48 +0900 (JST) To: tim@mentat.com In-Reply-To: Your message of "Fri, 27 Apr 2007 15:20:18 -0700" <1177712418.13779.23.camel@feller> References: <1177712418.13779.23.camel@feller> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070428030748.D37D71C069@coconut.itojun.org> Date: Sat, 28 Apr 2007 12:07:48 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) X-Spam-Score: -2.8 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org, bob.hinden@nokia.com, deraadt@openbsd.org Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I am a bit surprised that the security problems with the routing header > come as some sort of revelation at this stage. The intent, as I recall, yup, it's such 1992 problem. hinden and kame needs harakiri. > handy. My recollection of a conversation with Steve on this topic back > in the previous century, at an IPv6 bake-off, was that it was "forced > upon us" by the politics of the IPng "process". I think we can safely > put to bed the idea that the designers were dolts who didn't learn from > history. That doesn't mean there weren't dolts involved in the > "process".:-) steve and bob are too optimistic/academic, or too focused into ipv6 so that they forget about ipv4. they need to come to japan and take "real world ipv6" tutorial then visit Calgary for "security" tutorial by theo. it's just like boot camp (no, not apple's, but army). openbsd group meeting, called c2k7 next month, and theo will gladly sneak you in so that they can put two of you into BBQ grill (but they may free to bomit). > That said I am in favor of 2. It is the easiest to retrofit onto 2 is not the right answer. bzzzt. bad boy. you ate 10 minutes of sleeping time of mine. itojun PS: for those of you contacted me to say "sleep man", stop. my skype is keep rebooting and my cellphone battery is dying... it's "sleep man" spam. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Apr 28 08:24:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhlya-00011A-Oi; Sat, 28 Apr 2007 08:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhfii-0007Xn-DJ for ipv6@ietf.org; Sat, 28 Apr 2007 01:43:44 -0400 Received: from cvs.openbsd.org ([199.185.137.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhfii-0007Ln-0j for ipv6@ietf.org; Sat, 28 Apr 2007 01:43:44 -0400 Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (8.14.1/8.12.1) with ESMTP id l3S5giO9010539; Fri, 27 Apr 2007 23:42:45 -0600 (MDT) Message-Id: <200704280542.l3S5giO9010539@cvs.openbsd.org> To: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) In-reply-to: Your message of "Sat, 28 Apr 2007 12:07:48 +0900." <20070428030748.D37D71C069@coconut.itojun.org> Date: Fri, 27 Apr 2007 23:42:44 -0600 From: Theo de Raadt X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Sat, 28 Apr 2007 08:24:31 -0400 Cc: ipv6@ietf.org, bob.hinden@nokia.com, tim@mentat.com, deraadt@openbsd.org Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I think we can safely > put to bed the idea that the designers were dolts who didn't learn from > history. That doesn't mean there weren't dolts involved in the > "process".:-) Bob, actually, why should we put anything to bed? Are you statements not some "put it to bed, shove it under the carpet" game? Really -- why not just call them stupid dolts? Why not hold them accountable? Is accountability suddenly un-American and un-IETF? The only people who I see discounting accountability (on various lists) are the ones who either don't understand the scope and impact of the problem, or are to escape the impact of the disaster that IETF has thrown at the IPV4 operators who now suddenly face this problem of IPV6-over-tunnels on the networks they operate. Talk to some operators. It's no longer DoS. You take your DoS, you IPV6 it, and voila -- it's DoS x 100, at least. You wait and see. So, why do we need to wipe the slate clean? Why not should we not identify the academics involved in IETF who are unaware of the pushback against source routing that happened in 1992-1995? If people are unaware if how IPV4 source routing was pushed back against, should they be at all involved in an any future IETF process that rubber stamps their kind of bullshit in a "New generation" protocol? If you don't blame the people who pushed for this crap, who will you blame? Noone? Or is the wiping clean of the slate just another retarded IETF process that will let this stupid mistake be made again, by an IETF that thinks that the "academic inclusion, uber ales, minus actual code in use" principle they believe in helps they build things better than crap? If I have come to one viewpoint in life it is this: IF NOONE LEARNS, NOONE LEARNS. And here I see Bob Hindin (and perhaps some others) making apologies for his buddies who he personally gave the scope to screw things up this badly. Bob, you were there. You are one of the dolts. If IETF has no accountability at present time, now is the time for accountability. You guys were given a *responsibility* to try to do right, hell -- the industry and goverments gave you a MANDATE. Instead you fucked the dog, and my lord, you fucked the dog to death, and potentially the cat and the canary too. Bob, I don't know who totally fucked this up; not exactly. But either the leaders of the process did, or... noone did. And I think we need to know who did fuck it up, so that they never let their stupid ideas of process enter into the Internet game again, or the researchers they listened to (who totally ignore an IETF directive of "security concerns must be addressed".) If you were unaware of the vendor and operator push-back against IPV4 source routing, and let this go through, then you are #1 retard of the century. If you did not, but simply managed researchers who sold you a bum ride -- you need to say who they were or you are an even bigger retard. Yes, I am mean. But Bob, I have dealt with you before and you should have gotten out of technology a long time ago. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Apr 28 14:56:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhs4z-0007KL-Uy; Sat, 28 Apr 2007 14:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhs4z-0007KG-F7 for ipv6@ietf.org; Sat, 28 Apr 2007 14:55:33 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhs4x-00033F-Vz for ipv6@ietf.org; Sat, 28 Apr 2007 14:55:33 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3SItGLd022913; Sat, 28 Apr 2007 21:55:17 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 21:55:16 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 21:55:16 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 21:55:16 +0300 Received: from [209.157.142.166] (daec-linuxvpn058130.americas.nokia.com [10.241.58.130]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3SItCfI012376; Sat, 28 Apr 2007 21:55:13 +0300 In-Reply-To: <200704280542.l3S5giO9010539@cvs.openbsd.org> References: <200704280542.l3S5giO9010539@cvs.openbsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Sat, 28 Apr 2007 11:55:23 -0700 To: Theo de Raadt X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Apr 2007 18:55:16.0289 (UTC) FILETIME=[C27D9B10:01C789C6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF IPv6 Mailing List , tim@mentat.com, deraadt@openbsd.org Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Theo, On Apr 27, 2007, at 10:42 PM, ext Theo de Raadt wrote: >> I think we can safely >> put to bed the idea that the designers were dolts who didn't learn >> from >> history. That doesn't mean there weren't dolts involved in the >> "process".:-) > > Bob, actually, why should we put anything to bed? Are you statements > not some "put it to bed, shove it under the carpet" game? Before you launch a personal attack on me on the list you at least attack the words I actually wrote on the topic. I have not suggested putting anything to bed. This is clearly a problem we should fix. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Apr 28 20:00:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhwpg-0004Qm-UI; Sat, 28 Apr 2007 20:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhwpf-0004Qf-3q for ipv6@ietf.org; Sat, 28 Apr 2007 20:00:03 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhwpe-0004OV-Ma for ipv6@ietf.org; Sat, 28 Apr 2007 20:00:03 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 1D56928475 for ; Sun, 29 Apr 2007 00:00:02 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 29 Apr 2007 00:00:02 +0000 Message-Id: <20070429000002.1D56928475@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 19.61% | 10 | 15.25% | 47581 | itojun@itojun.org 7.84% | 4 | 7.90% | 24652 | alh-ietf@tndh.net 1.96% | 1 | 12.53% | 39106 | vijaykumar@huawei.com 7.84% | 4 | 5.92% | 18472 | dwmalone@maths.tcd.ie 1.96% | 1 | 6.76% | 21105 | anushka@gmail.com 3.92% | 2 | 4.31% | 13447 | arnaud.ebalard@eads.net 3.92% | 2 | 3.83% | 11963 | jeroen@unfix.org 3.92% | 2 | 3.56% | 11126 | albert.e.manfredi@boeing.com 3.92% | 2 | 3.36% | 10499 | jhw@apple.com 3.92% | 2 | 3.11% | 9714 | bob.hinden@nokia.com 3.92% | 2 | 2.99% | 9321 | jari.arkko@piuha.net 3.92% | 2 | 2.83% | 8824 | gnn@neville-neil.com 3.92% | 2 | 2.59% | 8070 | rdenis@simphalempin.com 1.96% | 1 | 2.19% | 6837 | dthaler@windows.microsoft.com 1.96% | 1 | 2.03% | 6349 | deraadt@cvs.openbsd.org 1.96% | 1 | 2.02% | 6294 | mohacsi@niif.hu 1.96% | 1 | 1.95% | 6085 | tim@mentat.com 1.96% | 1 | 1.78% | 5560 | ignatios@cs.uni-bonn.de 1.96% | 1 | 1.76% | 5507 | brc@zurich.ibm.com 1.96% | 1 | 1.69% | 5276 | perry@coders.net 1.96% | 1 | 1.68% | 5229 | alun@cisco.com 1.96% | 1 | 1.66% | 5191 | tim-projects@sentinelchicken.org 1.96% | 1 | 1.55% | 4834 | timbeck04@verizon.net 1.96% | 1 | 1.49% | 4640 | sra@isc.org 1.96% | 1 | 1.42% | 4429 | ipng@69706e6720323030352d30312d31340a.nosense.org 1.96% | 1 | 1.34% | 4197 | hideshi.enokihara@jp.yokogawa.com 1.96% | 1 | 1.25% | 3896 | paul@vix.com 1.96% | 1 | 1.25% | 3886 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 51 |100.00% | 312090 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 03:44:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiQXl-0007s1-67; Mon, 30 Apr 2007 03:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiQXj-0007rm-Q2 for ipv6@ietf.org; Mon, 30 Apr 2007 03:43:31 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiQXi-00068s-Dv for ipv6@ietf.org; Mon, 30 Apr 2007 03:43:31 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l3U7hPnV013492; Mon, 30 Apr 2007 10:43:25 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l3U7hOsc013489; Mon, 30 Apr 2007 10:43:25 +0300 Date: Mon, 30 Apr 2007 10:43:24 +0300 (EEST) From: Pekka Savola To: Dave Thaler In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC053929E6@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <46323659.2090406@piuha.net> <271CF87FD652F34DBF877CB0CB5D16FC053929E6@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.2/3179/Sun Apr 29 13:28:45 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: IETF IPv6 Mailing List Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, On Fri, 27 Apr 2007, Dave Thaler wrote: > Two scenarios that are much less harmful are > when there is only 1 address in only one RH0: > 1) when the intermediate destination address and the final > destination address are addresses of the same node. > 2) when the final destination address is equal to the > source address. > > In both cases, the intermediate destination isn't being > used as transit between two other nodes. A sample use > case of the second scenario is for a round-trip > traceroute. FWIW, I personally think 2) [turn off by default everywhere] seems like the best choice, but I think 1) [deprecate] would also be OK. I wouldn't mind 4) but I wonder if it's worth the trouble. Some IPv4 perspective: ---------------------- IPv4 specifications (RFC 1812) require source routing to be enabled on routers by default (a MUST). IPv4 hosts MAY process routing headers (RFC 1122) and there are some specifications what should happen. It seems that -- specification-wise -- the same attacks as exist for IPv6 (multiple routing headers, multiple waypoints) are possible with IPv4 as well. IPv4 specifications also require that a host MUST reverse the routing header if they're a final recipient (leading to a symmetric return path). (IPv6 specs allow reversing only if RT header was authenticated) Because attacks would likely be possible using v4 source routing as well -- unless implementation defaults differ significantly here -- we should be able to walk, not run, to a decision. Similarly, a decision should likely affect IPv4 as well. Some operations perspective: ---------------------------- Please remember that using source routing for 'reverse path traceroute' is only possible if networks don't implement ingress/egress filtering. As such, I cannot support the 'reverse path traceroute' usage scenario for source routing, because doing so shouldn't work in the first place in well-operated networks, and could be yet another roadblock to appropriate filtering. The other scenario Dave mentions is AFAICS the one where type 2 routing header was designed for, and could probably be used in that scenario as well, even if MIPv6 was not used. A couple of folks mentioned using routing header for traffic path selection (in the middle of the network). That also interferes with ingress/egress filtering, but not quite as badly. This is probably mostly useful for research purposes and I'm having difficulty seeing a business case for doing this in production. The reason why I'd prefer disabling instead of complete deprecation is that I can imagine use cases where source routing can be a useful diagnostics tool inside one administrative domain, and if we deprecate it, it's gone for good (unless we define a new type, and transition to it would take a long time). On the other hand, given that these usage cases are rather limited, I don't think they're in wide use, and still cause problems for ingress/egress filters, I'm also ok with deprecation. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 05:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRuJ-0002Bu-GA; Mon, 30 Apr 2007 05:10:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRuI-000266-4t for ipv6@ietf.org; Mon, 30 Apr 2007 05:10:54 -0400 Received: from mx1.its.eads.net ([193.56.40.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiRuF-0005hO-JV for ipv6@ietf.org; Mon, 30 Apr 2007 05:10:54 -0400 Received: from fr-gate1.mailhub.intra.corp ([53.154.16.33]) by mx1.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Mon, 30 Apr 2007 11:08:29 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Apr 2007 11:13:47 +0200 Received: from [172.16.23.99] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92ZLBSP; Mon, 30 Apr 2007 11:20:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.752.2) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Mon, 30 Apr 2007 11:10:45 +0200 Message-ID: <0A34B154-A146-4700-A70F-1A5792D1B405@eads.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissu es] Thread-Index: AceLCNgdEBqZmuzlR165Ek+4sMWIhw== From: "Ebalard, Arnaud" To: "Pekka Savola" X-OriginalArrivalTime: 30 Apr 2007 09:13:47.0546 (UTC) FILETIME=[DC0167A0:01C78B07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IETF IPv6 Mailing List , Dave Thaler Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissu es] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi *, Le 30 avr. 07 =E0 09:43, Pekka Savola a =E9crit : > Some IPv4 perspective: > ---------------------- > > IPv4 specifications (RFC 1812) require source routing to be enabled on > routers by default (a MUST). IPv4 hosts MAY process routing headers > (RFC 1122) and there are some specifications what should happen. It > seems that -- specification-wise -- the same attacks as exist for IPv6 > (multiple routing headers, multiple waypoints) are possible with IPv4 > as well. Size of IPv4 options is limited to 44 bytes, which leaves room for at =20 most 10 addresses in the LSRR/SSRR options. With IPv6 Type 0 Routing =20 Header, the only limitation is the MTU, which allow *at least* 77 =20 addresses in the RH0 (1280 bytes MTU. In real life networks, 87 or 88 =20 is closer to what you can really do. In RFC 1883, the format of RH0 was different, and closer to IPv4 LSRR =20 one. The number of addresses was limited to 23. This has been removed =20 in RFC 2460. Wasn't there during the discussions, so I don't know why =20 but this would be interesting to dig in the list archives. > Because attacks would likely be possible using v4 source routing as > well -- unless implementation defaults differ significantly here -- > we should be able to walk, not run, to a decision. AFAIK, the processing of IPv4 options is deactivated by all network =20 maintainers (soft path processing, attack surface). This is also the =20 default on most (if not all) IPv4 stacks. For IPv6, since last week, all major stacks are already no more IPv6 =20 compliant regarding RH0 processing : FreeBSD : http://security.freebsd.org/advisories/FreeBSD-=20 SA-07:03.ipv6.asc OpenBSD : http://openbsd.org/errata40.html#012_route6 NetBSD : http://www.nabble.com/heads-up:-IPv6-routing-header-0-=20 issues-t3643494.html Linux : http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.9 Apple is aware of the issue, but has more latency. Cisco and Juniper too, but no public statement/decision is available =20 yet (this is obviously not that simple for them). > Similarly, a decision should likely affect IPv4 as well. Interesting. > Some operations perspective: > ---------------------------- > > Please remember that using source routing for 'reverse path > traceroute' is only possible if networks don't implement > ingress/egress filtering. From tests I performed, this is not that much implemented (this was =20 at least valid 10 days ago :-)). > The reason why I'd prefer disabling instead of complete deprecation is > that I can imagine use cases where source routing can be a useful > diagnostics tool inside one administrative domain, and if we deprecate > it, it's gone for good (unless we define a new type, and transition to > it would take a long time). If it is kept in the specification (i.e. not deprecated), all IPv6 =20 stacks will be required to have it, even if they will (obviously) =20 deactivate by default. One question is : is it worth having =20 associated code in the stacks (cell phones, PDA, other portables =20 devices) if there is no expected use. As the amount of code has impact on stability/maintenance/security/=20 costs, IMHO, keeping the mechanism should be a motivated decision. > On the other hand, given that these usage cases are rather limited, I > don't think they're in wide use, and still cause problems for > ingress/egress filters, I'm also ok with deprecation. You should also add anycast to the list. a+ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 05:15:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRyj-0005oG-C3; Mon, 30 Apr 2007 05:15:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRyh-0005oA-UH for ipv6@ietf.org; Mon, 30 Apr 2007 05:15:27 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiRyg-0006n4-Hh for ipv6@ietf.org; Mon, 30 Apr 2007 05:15:27 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id l3U9FPXC335954 for ; Mon, 30 Apr 2007 09:15:25 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3U9FK2Z3612742 for ; Mon, 30 Apr 2007 11:15:25 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3U9F905028827 for ; Mon, 30 Apr 2007 11:15:10 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3U9F9B2028323; Mon, 30 Apr 2007 11:15:09 +0200 Received: from [9.146.222.171] (chvb1001.de.ibm.com [9.146.222.171]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA146898; Mon, 30 Apr 2007 11:14:52 +0200 Message-ID: <4635B397.8080409@zurich.ibm.com> Date: Mon, 30 Apr 2007 11:15:03 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Theo de Raadt References: <200704280542.l3S5giO9010539@cvs.openbsd.org> In-Reply-To: <200704280542.l3S5giO9010539@cvs.openbsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: bob.hinden@nokia.com, ipv6@ietf.org, tim@mentat.com, deraadt@openbsd.org Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Theo, Your language is unfitting for professional discussion, in my opinion. The issue having been raised, we should deal with it as an engineering matter. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 07:24:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTyx-0007Sp-LK; Mon, 30 Apr 2007 07:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTyv-000744-Dg for ipv6@ietf.org; Mon, 30 Apr 2007 07:23:49 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiTys-0000u6-HD for ipv6@ietf.org; Mon, 30 Apr 2007 07:23:49 -0400 Received: from [IPv6:2001:770:100:9e::2] (cl-159.dub-01.ie.sixxs.net [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 813C4140C202; Mon, 30 Apr 2007 13:23:44 +0200 (CEST) Message-ID: <4635D1C2.6010906@spaghetti.zurich.ibm.com> Date: Mon, 30 Apr 2007 12:23:46 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: IETF IPv6 Mailing List References: <0A34B154-A146-4700-A70F-1A5792D1B405@eads.net> In-Reply-To: <0A34B154-A146-4700-A70F-1A5792D1B405@eads.net> X-Enigmail-Version: 0.94.3.0 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV 0.90.1/3182/Mon Apr 30 10:38:40 2007 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "Ebalard, Arnaud" Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissu es] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0626838108==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0626838108== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig736E9D2110BE7384732C9FDF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig736E9D2110BE7384732C9FDF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, First off, my take on this is to disable RH0 and deprecate it. This has already been done in all the SixXS PoPs to avoid them and their users to be a source/destination of this problem. Although it would be fun to see the traffic levels go over 0.1% of IPv4 that kind of traffic is not the traffic we want to see I guess :) Also quite a large number of operators are already DROP-ing these options. Which leads to another question: Should one DROP or REJECT (icmp admin prohibited) these packets. Pro's/Con's on this anyone? Ebalard, Arnaud wrote: [..] > For IPv6, since last week, all major stacks are already no more IPv6 =20 > compliant regarding RH0 processing : >=20 > FreeBSD : http://security.freebsd.org/advisories/FreeBSD-=20 > SA-07:03.ipv6.asc > OpenBSD : http://openbsd.org/errata40.html#012_route6 > NetBSD : http://www.nabble.com/heads-up:-IPv6-routing-header-0-=20 > issues-t3643494.html > Linux : http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.= 9 >=20 > Apple is aware of the issue, but has more latency. > Cisco and Juniper too, but no public statement/decision is available =20 > yet (this is obviously not that simple for them). I've started collecting ways to disable this at: http://www.sixxs.net/faq/connectivity/?faq=3Dfilters This also lists Cisco already who made a security announcement quite some days ago, see the following URL which includes workarounds: http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml Not all platforms are addressed with that of course and most thus require updates, for some though there are no updates yet. =46rom Juniper I only know that they are 'working on it' and that was an unofficial statement from one of their employees. [..] >> On the other hand, given that these usage cases are rather limited, I >> don't think they're in wide use, and still cause problems for >> ingress/egress filters, I'm also ok with deprecation. >=20 > You should also add anycast to the list. Why Anycast? I guess you are not using any Root DNS servers or any content distribution network? :) There are a lot of uses for anycast, which you won't even notice that they are being used. Also Anycast per se is not a special feature of IPv6, it is also used in IPv4. Greets, Jeroen --------------enig736E9D2110BE7384732C9FDF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkY10cIuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58IwIVAJ9/ARSpMsWHEgNCizgfnQEDNHZi mQCgsN70rmrgAGCUV0WMSB3gPlGK6Tg= =Wjaf -----END PGP SIGNATURE----- --------------enig736E9D2110BE7384732C9FDF-- --===============0626838108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0626838108==-- From ipv6-bounces@ietf.org Mon Apr 30 08:28:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUzK-0002Mk-1U; Mon, 30 Apr 2007 08:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUzH-0002F1-MK for ipv6@ietf.org; Mon, 30 Apr 2007 08:28:15 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiUzG-0007vi-EY for ipv6@ietf.org; Mon, 30 Apr 2007 08:28:15 -0400 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id DFB472FDF3 for ; Mon, 30 Apr 2007 14:28:09 +0200 (CEST) From: Pars Mutaf To: IETF IPv6 Mailing List In-Reply-To: References: <200704280542.l3S5giO9010539@cvs.openbsd.org> Content-Type: text/plain Organization: INT Evry Date: Mon, 30 Apr 2007 14:28:29 +0200 Message-Id: <1177936109.26572.23.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >> - how many hops you can make w/ a packet sized 1280? Maybe I'm missing something, but the attacker wouldn't rather send millions of *very small* packets (to keep the routers busy) instead sending elephants?? My 0.02 cents pars -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 10:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWRm-0003xb-Tx; Mon, 30 Apr 2007 10:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWRl-0003xV-1K for ipv6@ietf.org; Mon, 30 Apr 2007 10:01:45 -0400 Received: from ns1.its.eads.net ([193.56.40.66] helo=mx1.its.eads.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiWRj-0000To-Kp for ipv6@ietf.org; Mon, 30 Apr 2007 10:01:45 -0400 Received: from fr-gate1.mailhub.intra.corp ([53.154.16.33]) by mx1.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Mon, 30 Apr 2007 15:59:20 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Apr 2007 16:04:37 +0200 Received: from [172.16.23.99] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92ZLCJC; Mon, 30 Apr 2007 16:11:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Mailer: Apple Mail (2.752.2) Content-class: urn:content-classes:message Date: Mon, 30 Apr 2007 16:01:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissu es] Thread-Index: AceLMXhjbte8JFd4RR6vy97tZbM6Sw== From: "Ebalard, Arnaud" To: X-OriginalArrivalTime: 30 Apr 2007 14:04:37.0734 (UTC) FILETIME=[7D20C860:01C78B30] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissu es] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Le 30 avr. 07 =E0 14:28, Pars Mutaf a =E9crit : >>> - how many hops you can make w/ a packet sized 1280? > > Maybe I'm missing something, but the attacker wouldn't > rather send millions of *very small* packets (to keep the > routers busy) instead sending elephants?? This morning, just to test it on a Mac Mini, i pushed a little more =20 than 1MB/s of such RH0 packets (those you call "elephants") between a =20 Linux box (forwarding activated, pre 2.6.20.9) and the Mac (both =20 gigabit, directly connected). This is slide 35/57 of the =20 presentation. The Bandwidth monitor output on the Linux is below =20 (same on the Mac) : Bandwidth Monitor 1.1.0 Iface RX(KB/sec) TX(KB/sec) Total(KB/sec) eth0 45512.315 46102.463 91614.778 lo 0.985 0.985 1.970 [...] I can ensure you that when you are limited by your upload bandwidth, =20 and only with few KB/s, you simply saturate a 100Mbit/s Ethernet link. When you send millions of packets at X KB/s, the routers still have =20 to cope with that amount of bandwidth (X KB/s). "Elephants" simply =20 amplify your bandwidth between the 2 routers (44*X KB/s upload and =20 44*X KB/s download, as if there were almost 90 people like you on the =20 link). Cheers, a+ ps : 44 is the number of pairs of @ (rtr1, rtr2) in the RH0. -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 11:27:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXll-00036e-Ab; Mon, 30 Apr 2007 11:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXlj-00036Z-G8 for ipv6@ietf.org; Mon, 30 Apr 2007 11:26:27 -0400 Received: from cvs.openbsd.org ([199.185.137.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXlh-0000QD-Qk for ipv6@ietf.org; Mon, 30 Apr 2007 11:26:27 -0400 Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (8.14.1/8.12.1) with ESMTP id l3UFQHeK003615; Mon, 30 Apr 2007 09:26:18 -0600 (MDT) Message-Id: <200704301526.l3UFQHeK003615@cvs.openbsd.org> To: Brian E Carpenter In-reply-to: Your message of "Mon, 30 Apr 2007 11:15:03 +0200." <4635B397.8080409@zurich.ibm.com> Date: Mon, 30 Apr 2007 09:26:17 -0600 From: Theo de Raadt X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: bob.hinden@nokia.com, ipv6@ietf.org, tim@mentat.com, deraadt@openbsd.org Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Your language is unfitting for professional discussion, > in my opinion. > > The issue having been raised, we should deal with it as > an engineering matter. If it is an engineering matter, then perhaps the IETF should be left out of it, especially those particular people who created this problem. 10 years of source route-routing impacts in IPv4 resulted in source-routing eventually being disabled by vendors -- and then IETF grudgingly followed suit. Engineering disciplines in all other fields normally react to problems before consumers/vendors do. After that, nearly 10 years of warnings about the impact of source-routing in IPv6 having severe security impacts resulted in the IETF process ENTIRELY IGNORING THE SECURITY IMPACTS. You call that 'Engineering'? Engineering groups plan for safety ahead of the consumers -- in this case the network operators who will face these issues for years to come. IETF doesn't deserve the word Engineering, if this is the best they can do. If there is no mailing list for accountability, then perhaps one should be setup. Until then, I think it is very important for the IETF IPv6 forum to realize that engineering had nothing to do with the RH0 inclusion in IPv6. A few academics wanted the extra complexity, and they pushed it through. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 13:33:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZjH-0007Lr-JB; Mon, 30 Apr 2007 13:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZjF-0007Lk-Fq for ipv6@ietf.org; Mon, 30 Apr 2007 13:32:01 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZjF-0001yD-1w for ipv6@ietf.org; Mon, 30 Apr 2007 13:32:01 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 30 Apr 2007 10:32:00 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Mon, 30 Apr 2007 10:31:58 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Apr 2007 10:31:57 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2007 10:30:57 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC05392DD8@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] Thread-Index: AceK+0b6J87AkG2hS5alBpjg4y6JDAAUM17g References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <46323659.2090406@piuha.net> <271CF87FD652F34DBF877CB0CB5D16FC053929E6@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Dave Thaler To: Pekka Savola X-OriginalArrivalTime: 30 Apr 2007 17:31:57.0625 (UTC) FILETIME=[73E18290:01C78B4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: IETF IPv6 Mailing List Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Round-trip traceroute is useful inside intra-domain environments as=20 you note, where ingress filtering isn't generally deployed. Hence it works in many places today and it can be very useful for debugging. Also, as noted in the original PDF that started this thread, Windows (and I think at least one other OS if I remember the PDF correctly) supports RH for compliance, but already disables RH by default.=20 Since that's already the deployed behavior of many hosts, I'd support the disabled-by-default as the best choice. -Dave > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, April 30, 2007 12:43 AM > To: Dave Thaler > Cc: Jari Arkko; IETF IPv6 Mailing List > Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing > Headerissues] >=20 > Hi, >=20 > On Fri, 27 Apr 2007, Dave Thaler wrote: > > Two scenarios that are much less harmful are > > when there is only 1 address in only one RH0: > > 1) when the intermediate destination address and the final > > destination address are addresses of the same node. > > 2) when the final destination address is equal to the > > source address. > > > > In both cases, the intermediate destination isn't being > > used as transit between two other nodes. A sample use > > case of the second scenario is for a round-trip > > traceroute. >=20 > FWIW, I personally think 2) [turn off by default everywhere] seems > like the best choice, but I think 1) [deprecate] would also be OK. I > wouldn't mind 4) but I wonder if it's worth the trouble. >=20 > Some IPv4 perspective: > ---------------------- >=20 > IPv4 specifications (RFC 1812) require source routing to be enabled on > routers by default (a MUST). IPv4 hosts MAY process routing headers > (RFC 1122) and there are some specifications what should happen. It > seems that -- specification-wise -- the same attacks as exist for IPv6 > (multiple routing headers, multiple waypoints) are possible with IPv4 > as well. >=20 > IPv4 specifications also require that a host MUST reverse the routing > header if they're a final recipient (leading to a symmetric return > path). (IPv6 specs allow reversing only if RT header was > authenticated) >=20 > Because attacks would likely be possible using v4 source routing as > well -- unless implementation defaults differ significantly here -- > we should be able to walk, not run, to a decision. >=20 > Similarly, a decision should likely affect IPv4 as well. >=20 > Some operations perspective: > ---------------------------- >=20 > Please remember that using source routing for 'reverse path > traceroute' is only possible if networks don't implement > ingress/egress filtering. >=20 > As such, I cannot support the 'reverse path traceroute' usage scenario > for source routing, because doing so shouldn't work in the first place > in well-operated networks, and could be yet another roadblock to > appropriate filtering. >=20 > The other scenario Dave mentions is AFAICS the one where type 2 > routing header was designed for, and could probably be used in that > scenario as well, even if MIPv6 was not used. >=20 > A couple of folks mentioned using routing header for traffic path > selection (in the middle of the network). That also interferes with > ingress/egress filtering, but not quite as badly. This is probably > mostly useful for research purposes and I'm having difficulty seeing a > business case for doing this in production. >=20 > The reason why I'd prefer disabling instead of complete deprecation is > that I can imagine use cases where source routing can be a useful > diagnostics tool inside one administrative domain, and if we deprecate > it, it's gone for good (unless we define a new type, and transition to > it would take a long time). >=20 > On the other hand, given that these usage cases are rather limited, I > don't think they're in wide use, and still cause problems for > ingress/egress filters, I'm also ok with deprecation. >=20 > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 13:47:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZxh-0000js-4U; Mon, 30 Apr 2007 13:46:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZxg-0000jn-Hk for ipv6@ietf.org; Mon, 30 Apr 2007 13:46:56 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZxf-00051D-2c for ipv6@ietf.org; Mon, 30 Apr 2007 13:46:56 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id DFF0A1C067; Tue, 1 May 2007 02:46:52 +0900 (JST) To: dthaler@windows.microsoft.com In-Reply-To: Your message of "Mon, 30 Apr 2007 10:30:57 -0700" <271CF87FD652F34DBF877CB0CB5D16FC05392DD8@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <271CF87FD652F34DBF877CB0CB5D16FC05392DD8@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Cue version 0.8 (070406-1309/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070430174652.DFF0A1C067@coconut.itojun.org> Date: Tue, 1 May 2007 02:46:52 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org, pekkas@netcore.fi Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org again reading from backwards. > Round-trip traceroute is useful inside intra-domain environments as > you note, where ingress filtering isn't generally deployed. Hence > it works in many places today and it can be very useful for debugging. > > Also, as noted in the original PDF that started this thread, Windows > (and I think at least one other OS if I remember the PDF correctly) > supports RH for compliance, but already disables RH by default. > Since that's already the deployed behavior of many hosts, I'd > support the disabled-by-default as the best choice. i know! that's why "routing header type 7" (a variant of routing header type 0 which has no bad sideeffect) was mentioned a couple of days ago! itojun PS: please let me sleep. stop wasteful repetitive proposal before i turn into zombie. your cooperation is needed, but "go to bed" DDoS stops my work. tnx. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 30 14:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaXj-0005Fw-9T; Mon, 30 Apr 2007 14:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaXh-00059i-Kh for ipv6@ietf.org; Mon, 30 Apr 2007 14:24:09 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiaXf-0004ax-Aq for ipv6@ietf.org; Mon, 30 Apr 2007 14:24:09 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1687602wxd for ; Mon, 30 Apr 2007 11:24:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AJxCdKijR4a8c9Y1La7VqaiTJuKCS+Iz5yDSmLj/xfBGpXAcqJgcLYspFsEuuKyfIAUOfJtkVbzvavDBf0qoDIa0XDJck5mhcDWfcOBi1oZqD9nhRfewg0371HUTzbTa2zab7zsiWRQz+lbVNEmPTyxBgvUSNd5TOS8yjIEA4Eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tuhnG5c/GD7ex7lWdDo0l/D5TrWhM6rmjOiZJfkN4JPjdIXRjZ9Ftl0FjHSuLaLtx6XgtrnBDtpyvXHAHxPMrz173wlU1xFzDdhqSlyB8TudYByWbnotuFe5NqBYrznWeF7VMJqkkuq6ImSqAeRld2Q5DHq0p521nq0JFQDcyXg= Received: by 10.90.86.10 with SMTP id j10mr5597870agb.1177957446210; Mon, 30 Apr 2007 11:24:06 -0700 (PDT) Received: by 10.90.73.1 with HTTP; Mon, 30 Apr 2007 11:24:06 -0700 (PDT) Message-ID: <18d24aa20704301124r26112198y152ff79d2f94815d@mail.gmail.com> Date: Mon, 30 Apr 2007 21:24:06 +0300 From: "Eric Klein" To: "David Malone" In-Reply-To: <20070426105836.GA67535@walton.maths.tcd.ie> MIME-Version: 1.0 References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <20070426105836.GA67535@walton.maths.tcd.ie> X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF IPv6 Mailing List , Bob Hinden Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1516793320==" Errors-To: ipv6-bounces@ietf.org --===============1516793320== Content-Type: multipart/alternative; boundary="----=_Part_264130_20390644.1177957446107" ------=_Part_264130_20390644.1177957446107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have just noticed that this topic seems to be going on simutaniously on both the IPv6 and v6OPS mailing lists. The two threads are not coordinated, but both seem very concerned with IPv6 Type 0 Routing Header issues. This is seperate to the rash of Linux related warnings that have come out in the new IPv6 news - weekly summary : *Security: *Linux Kernel IPv6 Protocol Type 0 Route Header Remote Denial of Service Vulnerability http://www.ipv6tf.org/news/counter.php?id=2837 FreeBSD Security Advisory - IPv6 Routing Header 0 is dangerous http://www.ipv6tf.org/news/counter.php?id=2834 OpenBSD IPv6 Type 0 Route Headers Denial of Service http://www.ipv6tf.org/news/counter.php?id=2819 It concerns me that the two teams are working seperatly to solve the same issue. Eric ------=_Part_264130_20390644.1177957446107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I have just noticed that this topic seems to be going on simutaniously on both the IPv6 and v6OPS mailing lists.
 
The two threads are not coordinated, but both seem very concerned with IPv6 Type 0 Routing Header issues.
 
This is seperate to the rash of Linux related warnings that have come out in the new IPv6 news - weekly summary :
Security:
Linux Kernel IPv6 Protocol Type 0 Route Header Remote Denial of Service Vulnerability
 http://www.ipv6tf.org/news/counter.php?id=2837

FreeBSD Security Advisory - IPv6 Routing Header 0 is dangerous
 http://www.ipv6tf.org/news/counter.php?id=2834

OpenBSD IPv6 Type 0 Route Headers Denial of Service
 http://www.ipv6tf.org/news/counter.php?id=2819
 
It concerns me that the two teams are working seperatly to solve the same issue.
 
Eric
------=_Part_264130_20390644.1177957446107-- --===============1516793320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1516793320==-- From ipv6-bounces@ietf.org Mon Apr 30 20:44:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HigST-0002N7-5L; Mon, 30 Apr 2007 20:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HigSR-0002N2-PD for ipv6@ietf.org; Mon, 30 Apr 2007 20:43:07 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HigSQ-00050q-E9 for ipv6@ietf.org; Mon, 30 Apr 2007 20:43:07 -0400 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l410h5NY005683 for ; Mon, 30 Apr 2007 17:43:05 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id AADBA29C006 for ; Mon, 30 Apr 2007 17:43:05 -0700 (PDT) X-AuditID: 11807123-a0dd9bb0000013cb-cd-46368d19bdfe Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay5.apple.com (Apple SCV relay) with ESMTP id 9D57030400B for ; Mon, 30 Apr 2007 17:43:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <8A6FCC38-EA35-4EC2-A195-B8E327D50DA2@eads.net> References: <8A6FCC38-EA35-4EC2-A195-B8E327D50DA2@eads.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E7CB2B0-2AA7-43DB-840A-437240A4B653@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Mon, 30 Apr 2007 17:43:04 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: Re: IPv6 Type 0 Routing Header issues X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Apr 27, 2007, at 05:38, Ebalard, Arnaud wrote: > Bob Hinden wrote: >> >> Possible actions include: >> >> 1) Deprecate all usage of RH0 >> 2) Recommend that RH0 support be off by default in hosts and routers >> 3) Recommend that RH0 support be off by default in hosts >> 4) Limit it's usage to one RH0 per IPv6 packet and limit the >> number of addresses in one RH0. >> >> These examples are not all mutually exclusive. > > From my perspective, RH0 should be deprecated to simplify IPv6 > specification, stacks' implementations and suppress associated > threats. Keeping the generic RH mechanism will be sufficient for > new protocols to __carefully__ provide associated functionalities > (if any), just like the designers of Mobile IPv6 did with RH2 > (IMHO, processing limited to MIPv6 implementations, no external > forwarding, one address max, ...). I agree that all transmissions of RH0 should be deprecated, and I further recommend the draft standards be amended to require that RH0 be rejected with an ICMP error when received at the first destination and dropped silently in all other cases. This will allow operators to identify and neutralize preemptively exactly those nodes which do not comply with the amended standard. -- j h woodyatt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------