From owner-v6ops@ops.ietf.org Mon Jan 12 12:14:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06477 for ; Mon, 12 Jan 2004 12:14:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ag5ZP-000C4T-Bb for v6ops-data@psg.com; Mon, 12 Jan 2004 17:09:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag5ZA-000Blx-9k for v6ops@ops.ietf.org; Mon, 12 Jan 2004 17:09:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0CH9Q732544; Mon, 12 Jan 2004 19:09:26 +0200 Date: Mon, 12 Jan 2004 19:09:26 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com, Subject: Agenda items for Seoul Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, Please send the chairs the requests, comments, etc. for the v6ops agenda items for the Seoul IETF. Thanks, Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Tue Jan 13 00:18:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13316 for ; Tue, 13 Jan 2004 00:18:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgGsl-000PKB-Kj for v6ops-data@psg.com; Tue, 13 Jan 2004 05:14:27 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgGsZ-000PJf-64 for v6ops@ops.ietf.org; Tue, 13 Jan 2004 05:14:15 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0D5ED226409 for ; Tue, 13 Jan 2004 07:14:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 13 Jan 2004 07:14:13 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 13 Jan 2004 07:14:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Document Action: 'Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards' to Informational RFC Date: Tue, 13 Jan 2004 07:14:07 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195094A9D@esebe024.ntc.nokia.com> Thread-Topic: Document Action: 'Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards' to Informational RFC Thread-Index: AcPZKmcK8JBXoN3wQ2mXB90K9sx1AQAaTZrg From: To: X-OriginalArrivalTime: 13 Jan 2004 05:14:13.0724 (UTC) FILETIME=[1598F9C0:01C3D994] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, SUBJ_HAS_SPACES autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello v6ops, we got the IPv4 surveys done! Thank you for everybody who contributed to = the process to get these out of the door! A warm thank you, Bob, Jonne, and Pekka Chairs. > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org]On Behalf Of ext The IESG > Sent: 12 January, 2004 18:11 > To: IETF-Announce > Cc: Internet Architecture Board; RFC Editor; v6ops@ops.ietf.org > Subject: Document Action: 'Introduction to the Survey of IPv4=20 > Addresses > in Currently Deployed IETF Standards' to Informational RFC=20 >=20 >=20 > The IESG has approved the following documents: >=20 > - 'Survey of IPv4 Addresses in Currently Deployed IETF Internet Area=20 > Standards ' > as an Informational RFC > - 'Survey of IPv4 Addresses in Currently Deployed IETF=20 > Routing Area Standards ' > as an=20 > Informational RFC > - 'Survey of IPv4 Addresses in Currently Deployed IETF Security Area=20 > Standards ' > as an Informational RFC > - 'Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP=20 > Area Standards ' > as an Informational RFC > - 'Survey of IPv4 Addresses in Currently Deployed IETF Transport Area=20 > Standards ' > as an Informational RFC > - 'Introduction to the Survey of IPv4 Addresses in Currently=20 > Deployed IETF=20 > Standards ' > as an Informational RFC > - 'Survey of IPv4 Addresses in Currently Deployed IETF=20 > Application Area=20 > Standards ' > as an Informational RFC > - 'Survey of IPv4 Addresses in Currently Deployed IETF Operations &=20 > Management Area Standards ' > as an Informational RFC >=20 > These documents are products of the IPv6 Operations Working Group.=20 >=20 > The IESG contact person is Bert Wijnen. >=20 > Technical Summary > =20 > These documents provide an overview and introduction to the=20 > v6ops IETF > workgroup project of documenting all usage of IPv4 addresses in > IETF standards track and experimental RFCs. Besides the intro > document, there are seven documents conforming to the current IETF > areas. The intro document also describes the methodology used during > documentation, which type of RFCs that has been documented, and a > concatenated summary of results. >=20 > Working Group Summary > =20 > The WG has consensus to publish these documents as=20 > Informational RFCs. > The area specific documents were reviewed within the specific areas. > =20 > Protocol Quality > =20 > The intro and OPS area documents have been reviewed for the IESG by=20 > Bert Wijnen. The documents related to each specific area=20 > were reviewed > by at least one of the ADs of that area. >=20 > RFC-Editor notes: >=20 > - for document draft-ietf-v6ops-ipv4survey-intro-06.txt, inabstract, > pls change/clarify: >=20 > OLD: > This document is a general overview and introduction to the=20 > v6ops IETF > workgroup project of documenting all usage of IPv4 addresses in > currently deployed IETF documented standards. It is broken=20 > into seven > NEW: > This document is a general overview and introduction to the=20 > v6ops IETF > workgroup project of documenting all usage of IPv4 addresses in > IETF standards track and experimental RFCs. It is broken into seven >=20 >=20 > - For document draft-ietf-v6ops-ipv4survey-ops-05.txt in sect 5.107, > please remove an incorrect piece of text: >=20 > OLD: > section 4.3, which has "ipv4" in it; however, it's just an example, > and available to IPv6 as well with a simple replacement of "ipv4" > with "ipv6". > NEW: > section 4.3, which has "ipv4" in it. >=20 > - for draft-ietf-v6ops-ipv4survey-sec-04.txt, please add section > 7.4.2 after 7.4.1: > =20 > NEW: > 7.4.2: OSPF with Digital Signatures (RFC 2154) > =20 > This specification is IPv4-only, and relies on an IPv4-only routing > protocol, OSPFv2. Due to increased focus on routing security, this > specification may need to be revisited, and in that case it should > support both OSPFv2 and OSPFv3. >=20 > - For draft-ietf-v6ops-ipv4survey-int-03.txt, section 3.1,=20 > please replace: >=20 > OLD: >=20 > This specification defines IPv4 and is replaced by the IPv6 > specifications. >=20 > NEW: >=20 > This specification defines IPv4; IPv6 has been specified in=20 > separate documents. >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jan 13 03:07:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00829 for ; Tue, 13 Jan 2004 03:07:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgJW8-000IpR-AC for v6ops-data@psg.com; Tue, 13 Jan 2004 08:03:16 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgJVm-000Ijw-54 for v6ops@ops.ietf.org; Tue, 13 Jan 2004 08:02:54 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0D82qRT112244 for ; Tue, 13 Jan 2004 08:02:52 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0D82qUn280014 for ; Tue, 13 Jan 2004 09:02:52 +0100 Received: from zurich.ibm.com (sig-9-145-224-56.de.ibm.com [9.145.224.56]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA34692 for ; Tue, 13 Jan 2004 09:02:50 +0100 Message-ID: <4003A5E9.E4B3112C@zurich.ibm.com> Date: Tue, 13 Jan 2004 09:01:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: Document Action: 'Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards' to Informational RFC References: <2D3EB51EAED985419D54AB340A9D0195094A9D@esebe024.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As an FYI, the equivalent document for Global Grid Forum protocols is in WG Last Call in the GGF. True to GGF practice, the URL is somewhat long and may be split by some mail agents: https://forge.gridforum.org/projects/ipv6-wg/document/Survey_of_IPv4_Dependencies_in_Global_Grid_Forum_Specifications/en/2 Brian Jonne.Soininen@nokia.com wrote: > > Hello v6ops, > > we got the IPv4 surveys done! Thank you for everybody who contributed to the process to get these out of the door! > > A warm thank you, > > Bob, Jonne, and Pekka > Chairs. > > > -----Original Message----- > > From: owner-ietf-announce@ietf.org > > [mailto:owner-ietf-announce@ietf.org]On Behalf Of ext The IESG > > Sent: 12 January, 2004 18:11 > > To: IETF-Announce > > Cc: Internet Architecture Board; RFC Editor; v6ops@ops.ietf.org > > Subject: Document Action: 'Introduction to the Survey of IPv4 > > Addresses > > in Currently Deployed IETF Standards' to Informational RFC > > > > > > The IESG has approved the following documents: > > > > - 'Survey of IPv4 Addresses in Currently Deployed IETF Internet Area > > Standards ' > > as an Informational RFC > > - 'Survey of IPv4 Addresses in Currently Deployed IETF > > Routing Area Standards ' > > as an > > Informational RFC > > - 'Survey of IPv4 Addresses in Currently Deployed IETF Security Area > > Standards ' > > as an Informational RFC > > - 'Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP > > Area Standards ' > > as an Informational RFC > > - 'Survey of IPv4 Addresses in Currently Deployed IETF Transport Area > > Standards ' > > as an Informational RFC > > - 'Introduction to the Survey of IPv4 Addresses in Currently > > Deployed IETF > > Standards ' > > as an Informational RFC > > - 'Survey of IPv4 Addresses in Currently Deployed IETF > > Application Area > > Standards ' > > as an Informational RFC > > - 'Survey of IPv4 Addresses in Currently Deployed IETF Operations & > > Management Area Standards ' > > as an Informational RFC From owner-v6ops@ops.ietf.org Tue Jan 13 16:23:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13971 for ; Tue, 13 Jan 2004 16:23:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgVu7-000JTG-3d for v6ops-data@psg.com; Tue, 13 Jan 2004 21:16:51 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgVtu-000JSa-A8 for v6ops@ops.ietf.org; Tue, 13 Jan 2004 21:16:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0DLGaR21169 for ; Tue, 13 Jan 2004 23:16:37 +0200 Date: Tue, 13 Jan 2004 23:16:36 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: generic security work? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (writing just as a member of the WG..) I recall that there was some discussion around Minneapolis that some generic aspects of the transition scenarios may not have been documented properly (e.g., DNS, SMTP, etc.), and some work should be in order. There has been some activity recently: - apps transition: draft-ietf-v6ops-application-transition-00.txt - DNS: draft-ietf-dnsop-ipv6-dns-issues-03.txt - SMTP: draft-ietf-ngtrans-ipv6-smtp-requirement-07.txt (expired, but continuing as individual submission) The original posting also mentioned some generic security work. Does anyone have ideas how to tackle that? I've an old submission, an overview document, which I could try to dust off and polish a bit, if it's considered to be useful: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-security-overview-00.txt What do you think? Is there something (else) relevant missing? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jan 14 15:19:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08976 for ; Wed, 14 Jan 2004 15:19:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgrPn-0004nr-LH for v6ops-data@psg.com; Wed, 14 Jan 2004 20:14:59 +0000 Received: from [209.249.147.146] (helo=addr-mx02.addr.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgrPW-0004mu-0s for v6ops@ops.ietf.org; Wed, 14 Jan 2004 20:14:42 +0000 Received: from proxy1.addr.com (proxy1.addr.com [209.249.147.28]) by addr-mx02.addr.com (8.12.8/8.12.2) with ESMTP id i0EJZiBB085480; Wed, 14 Jan 2004 12:14:19 -0800 (PST) Received: from Downieville.thefinks.com ([66.81.111.220]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id i0EGkqI0016909; Wed, 14 Jan 2004 08:46:53 -0800 (PST) Message-Id: <5.2.0.9.0.20040114083712.01f50b78@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 14 Jan 2004 08:45:58 -0800 To: v6ops@ops.ietf.org From: Bob Fink Subject: retiring from co-chair Cc: Bert Wijnen , jonne.soininen@nokia.com, Pekka Savola Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AddrSpamFilterWarning: Low X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops Folk, I have officially retired from being a v6ops co-chair as of 1 January. This has been my plan for quite a while as I am now fully retired and spending much time with my family :-) I am pleased that v6ops has Pekka and Jonne, who are doing a great job as co-chairs. I am also pleased that progress is being made in the v6ops plan of work. I am staying involved with the 6bone to help it transit to phaseout (officially planned for 6/6/2006), and will help Jonne and Pekka as they might need on small administrative manners with v6ops. Thanks to all of you for your support and help over the 6bone, ngtrans and v6ops years. Bob Fink From owner-v6ops@ops.ietf.org Wed Jan 14 21:09:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26228 for ; Wed, 14 Jan 2004 21:09:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgwsP-000D0J-Hc for v6ops-data@psg.com; Thu, 15 Jan 2004 02:04:53 +0000 Received: from [192.11.222.161] (helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Agwrx-000CtJ-AU for v6ops@ops.ietf.org; Thu, 15 Jan 2004 02:04:25 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0F23Rs12188 for ; Wed, 14 Jan 2004 20:03:39 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Jan 2004 03:03:26 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503509E25@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Bob Fink , v6ops@ops.ietf.org Cc: jonne.soininen@nokia.com, Pekka Savola Subject: RE: retiring from co-chair Date: Thu, 15 Jan 2004 03:03:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk And of course THANKS to you Bob!!! Enjoy retirement... and your welcome to keep participating or to come back if you get renewed interest/time etc. Thanks again, Bert > -----Original Message----- > From: Bob Fink [mailto:bob@thefinks.com] > Sent: woensdag 14 januari 2004 17:46 > To: v6ops@ops.ietf.org > Cc: Bert Wijnen; jonne.soininen@nokia.com; Pekka Savola > Subject: retiring from co-chair > > > v6ops Folk, > > I have officially retired from being a v6ops co-chair as of 1 > January. This > has been my plan for quite a while as I am now fully retired > and spending > much time with my family :-) > > I am pleased that v6ops has Pekka and Jonne, who are doing a > great job as > co-chairs. I am also pleased that progress is being made in > the v6ops plan > of work. > > I am staying involved with the 6bone to help it transit to phaseout > (officially planned for 6/6/2006), and will help Jonne and > Pekka as they > might need on small administrative manners with v6ops. > > > Thanks to all of you for your support and help over the > 6bone, ngtrans and > v6ops years. > > Bob Fink > From owner-v6ops@ops.ietf.org Thu Jan 15 00:29:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01473 for ; Thu, 15 Jan 2004 00:28:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah00e-00086c-Qp for v6ops-data@psg.com; Thu, 15 Jan 2004 05:25:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgzyE-0007uH-SL for v6ops@ops.ietf.org; Thu, 15 Jan 2004 05:23:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0F5N5H09681 for ; Thu, 15 Jan 2004 07:23:05 +0200 Date: Thu, 15 Jan 2004 07:23:05 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: I-D ACTION:draft-savola-v6ops-transarch-03.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI. Comments welcome, of course. ---------- Forwarded message ---------- Date: Wed, 14 Jan 2004 15:54:08 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-v6ops-transarch-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A View on IPv6 Transition Architecture Author(s) : P. Savola Filename : draft-savola-v6ops-transarch-03.txt Pages : 21 Date : 2004-1-14 The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition doesn't seem to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult. This memo tries to point out some issues that will need consideration in the transition architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-transarch-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-savola-v6ops-transarch-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-transarch-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Thu Jan 15 05:11:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22832 for ; Thu, 15 Jan 2004 05:11:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah4QQ-000BOn-4W for v6ops-data@psg.com; Thu, 15 Jan 2004 10:08:30 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah4Pw-000BMT-Di for v6ops@ops.ietf.org; Thu, 15 Jan 2004 10:08:00 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FA7x217530 for ; Thu, 15 Jan 2004 12:07:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 12:07:38 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 12:07:36 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 12:07:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: retiring from co-chair Date: Thu, 15 Jan 2004 12:07:35 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195094AAF@esebe024.ntc.nokia.com> Thread-Topic: retiring from co-chair Thread-Index: AcPbC8lZ1c7p60T3Ti+bfUkYTVHLKAAQSAbw From: To: , , Cc: X-OriginalArrivalTime: 15 Jan 2004 10:07:35.0610 (UTC) FILETIME=[65F721A0:01C3DB4F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, I would also like to thank Bob for his efforts in this area. I'm sure I = can speak for all of us, wishing you good luck with your retirement and = hope that you still give an eye time to time to our little working = group. Thank you from my part as well, Jonne. > -----Original Message----- > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: 15 January, 2004 04:03 > To: Bob Fink; v6ops@ops.ietf.org > Cc: Soininen Jonne (Nokia-NET/Helsinki); Pekka Savola > Subject: RE: retiring from co-chair >=20 >=20 > And of course THANKS to you Bob!!! >=20 > Enjoy retirement... and your welcome to keep participating or > to come back if you get renewed interest/time etc. >=20 > Thanks again, > Bert=20 >=20 > > -----Original Message----- > > From: Bob Fink [mailto:bob@thefinks.com] > > Sent: woensdag 14 januari 2004 17:46 > > To: v6ops@ops.ietf.org > > Cc: Bert Wijnen; jonne.soininen@nokia.com; Pekka Savola > > Subject: retiring from co-chair > >=20 > >=20 > > v6ops Folk, > >=20 > > I have officially retired from being a v6ops co-chair as of 1=20 > > January. This=20 > > has been my plan for quite a while as I am now fully retired=20 > > and spending=20 > > much time with my family :-) > >=20 > > I am pleased that v6ops has Pekka and Jonne, who are doing a=20 > > great job as=20 > > co-chairs. I am also pleased that progress is being made in=20 > > the v6ops plan=20 > > of work. > >=20 > > I am staying involved with the 6bone to help it transit to phaseout=20 > > (officially planned for 6/6/2006), and will help Jonne and=20 > > Pekka as they=20 > > might need on small administrative manners with v6ops. > >=20 > >=20 > > Thanks to all of you for your support and help over the=20 > > 6bone, ngtrans and=20 > > v6ops years. > >=20 > > Bob Fink > >=20 >=20 From owner-v6ops@ops.ietf.org Fri Jan 16 05:05:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07367 for ; Fri, 16 Jan 2004 05:05:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhQkJ-0006fl-By for v6ops-data@psg.com; Fri, 16 Jan 2004 09:58:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhQk6-0006fD-RY for v6ops@ops.ietf.org; Fri, 16 Jan 2004 09:58:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0G9wH728860 for ; Fri, 16 Jan 2004 11:58:17 +0200 Date: Fri, 16 Jan 2004 11:58:17 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6ops milestones updated Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, We have updated the v6ops milestones at the IETF charter page. There is a lot of work to be done in the short-term, most importantly finishing the scenarios/analysis work. It would be particularly nice to finish some of those early or on schedule! We hope you can help with that ;-)! The intent is (if possible) to finish Transition Mechanisms *) and 3GPP Analysis, and WG Last Call at least Unmanaged and ISP Analysis before Seoul IETF. Thanks, Pekka & Jonne *) probably for PS, as we'll need to figure out implementation & interop reports first. From owner-v6ops@ops.ietf.org Sat Jan 17 09:43:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08508 for ; Sat, 17 Jan 2004 09:43:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhrY7-000DMr-8T for v6ops-data@psg.com; Sat, 17 Jan 2004 14:35:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhrXu-000DM9-IL for v6ops@ops.ietf.org; Sat, 17 Jan 2004 14:35:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0HEZTG13362; Sat, 17 Jan 2004 16:35:29 +0200 Date: Sat, 17 Jan 2004 16:35:29 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: mikael.lind@teliasonera.com, Subject: Please review the ISP analysis document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (chair hat on) The update to the ISP analysis document: draft-ietf-v6ops-isp-scenarios-analysis-00.txt .. is in progress, aimed to be published within 2 weeks, around the end of this month. Only one comment has been received to this version so far. Now would be a good time to review the document and send in comments on the list (preferable) or the editor(s): mikael.lind@teliasonera.com and vladimir.ksinant@6wind.com. Hopefully we can Last Call the document after this revision. Please help by reviewing it! Thanks, Pekka writing as co-chair From owner-v6ops@ops.ietf.org Mon Jan 19 15:36:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07811 for ; Mon, 19 Jan 2004 15:36:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aig2O-0005mA-OU for v6ops-data@psg.com; Mon, 19 Jan 2004 20:30:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aig2A-0005lI-3l for v6ops@ops.ietf.org; Mon, 19 Jan 2004 20:30:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0JKU3522259; Mon, 19 Jan 2004 22:30:03 +0200 Date: Mon, 19 Jan 2004 22:30:03 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: itojun@iijlab.net, Subject: Review Requested: SMTP IPv6 operational experience document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, (co-chair hat on) The working group has been asked by our Area Director to review the recently-revised SMTP operational experience document before it's published as an individual submission: draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt Please send comments, preferably in a week, by 26th January, either to the v6ops list (preferable), or directly to itojun (acting as the editor) and the chairs. Thanks, Pekka & Jonne v6ops co-chairs From owner-v6ops@ops.ietf.org Fri Jan 23 10:20:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04422 for ; Fri, 23 Jan 2004 10:20:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak30M-000FQI-1I for v6ops-data@psg.com; Fri, 23 Jan 2004 15:13:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak308-000FPP-MH for v6ops@ops.ietf.org; Fri, 23 Jan 2004 15:13:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0NFDdN19300 for ; Fri, 23 Jan 2004 17:13:39 +0200 Date: Fri, 23 Jan 2004 17:13:39 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Text on 3GPP UE tunneling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, (wg co-chair hat on) The 3GPP analysis document is being finished, and as there was not so much feedback, the chairs would like to avoid WG last-calling the document again. However, to avoid document revision churn and get an acceptable outcome, only the extensively discussed topic, UE tunneling, seems to warrant some discussion before shipping the document, on Monday or Tuesday. Below is a proposal on the wording to use (pay attention to the middle paragraph). The intent is to try to document all the sides of the argument and avoiding opening too many cans-of-worms, while being brief. Please send feedback whether you think that OK or not on the list. If you do not think it is appropriate, you MUST supply an alternative wording. Thanks, Pekka & Jonne [...] The use of private IPv4 addresses in the UE depends on the support of these addresses by the tunneling mechanism and the deployment scenario. In some cases public IPv4 addresses are required, but if the tunnel endpoints are in the same private domain, or the tunneling mechanism works through IPv4 NAT, private IPv4 addresses can be used. One deployment scenario example is using a laptop computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and IPv4 PDP context is activated. The used tunneling mechanism in that case depends on the support of tunneling mechanisms in the laptop computer. Another deployment scenario is making IPv6-in-IPv4 tunneling in the UE itself. Closer details for an applicable tunneling mechanism are not analyzed in this document. However, a simple host-to-router (automatic) tunneling mechanism may be a good fit. There is not yet consensus on the right approach. Primarily, ISATAP [ISATAP] has been proposed, but some issues have been raised about it, such as its unnecessary features and relative complexity for a simple task like this, and its inadequacy in providing security when crossing administrative domains. Proposed solution alternatives have been (at least) a simplified, but probably non-interoperable, version of ISATAP, and STEP [STEP]. In any case, further work is needed to find out the requirements for the scenario and to specify the mechanism. To generally solve this problem (IPv6 not available in the 3GPP network), this document strongly recommends the 3GPP operators to deploy basic IPv6 support in their GPRS networks. That also makes it possible to burden the transition effects in the network and make the 3GPP UEs simpler. [...] [STEP] refers to draft-savola-v6ops-conftun-setup-01.txt If the middle paragraph does not seem to be agreeable, we may use something more generic, like: Closer details for an applicable tunneling mechanism are not analyzed in this document. However, a simple host-to-router (automatic) tunneling mechanism may be a good fit. Further work is needed find out the requirements of the scenario and to specify the mechanism. From owner-v6ops@ops.ietf.org Fri Jan 23 16:31:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25739 for ; Fri, 23 Jan 2004 16:31:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak8pL-000KFu-TI for v6ops-data@psg.com; Fri, 23 Jan 2004 21:26:55 +0000 Received: from [131.155.140.144] (helo=hexagon.stack.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak8ol-000KBI-EO for v6ops@ops.ietf.org; Fri, 23 Jan 2004 21:26:19 +0000 Received: from dragon.stack.nl (dragon.stack.nl [IPv6:2001:610:1108:5011:207:e9ff:fe09:230]) by hexagon.stack.nl (Postfix) with ESMTP id 4011917A#35F5F51D5; Fri, 23 Jan 2004 22:26:18 +0100 (CET) Received: by dragon.stack.nl (Postfix, from userid 1600) id 2008A5F1CD; Fri, 23 Jan 2004 22:26:18 +0100 (CET) Date: Fri, 23 Jan 2004 22:26:18 +0100 From: Dean Strik To: Pekka Savola Cc: v6ops@ops.ietf.org, itojun@iijlab.net, jonne.soininen@nokia.com Subject: Re: Review Requested: SMTP IPv6 operational experience document Message-ID: <20040123212618.GC26724@dragon.stack.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes User-Agent: Mutt/1.5.5.1i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka Savola wrote: > Hello all, > > (co-chair hat on) > > The working group has been asked by our Area Director to review the > recently-revised SMTP operational experience document before it's > published as an individual submission: > > draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt > > Please send comments, preferably in a week, by 26th January, either to > the v6ops list (preferable), or directly to itojun (acting as the > editor) and the chairs. MAJOR 1) Section 2, second paragraph: "IP addresses for the destination host are also looked up to make SMTP transport." This is incomplete. This could refer to either of (a) or (b): (a) If no MX record is found, an A lookup is done for the domain part of the mail address to find a mail exchanger host; (b) IP(v*) lookups are then done, using A/AAAA, for each mail exchanger found by MX lookups. This needs clarification. 2) Section 3, paragraph "The algorithm for an SMTP server" (see also under MINOR 7): "When there is no reachable desti[o]nation address record found [..], the case should be treated just like MX records without address records [..]". This is simply wrong. There are two issues with this. First, "reachable" isn't properly defined. For example, a network outage (and the implied unreachability when contacting the host) is not a reason to pretend the host did not have MX addresses specified. It must be made clear that this special treatise (pretend there are no MX records) should only be applied if the host address cannot be reached due to network layer incompatibility. Second, is that this text says that, if no addresses are reachable (with the constraint above), it should be treated as if no MX records were specified. This leaves the possibility for mail to be delivered incorrectly. While this is the current situation, I would like to propose a different approach, more in the spirit of the IPv4->IPv6 transition. Namely, I suggest that IPv6-only senders will bail out if the destination is unreachable, instead of pretending there were no MX RRs. I think it is acceptable to ask IPv6-enabled ("modern") servers to avoid misdelivery (in SMTP, erroring is generally better than providing an uncertain path), while only legacy IPv4-only servers can treat IPv6-only hosts as MX-less. I see the ugly lack of symmetry here. Yet I don't think we should impose the chance of possible misdelivery (through the wrong host) on modern systems. We can do this on legacy systems since it's effectively what happens now, without this spec. This conforms more with the following from RFC 2821, Section 5: "If MX records are present, but none of them are usable, this situation MUST be reported as an error." This may be a little bit vague. If unclear, please let me know. 3) The example DNS configuration just below, has a "HINFO" record. This should be a TXT record. If any. It's redundant, and the document provides no explanation for the purpose of this RR. 4) Step (1) of the dual-stack SMTP sending algorithm doesn't specify the actions to take when a SERVFAIL is encountered. 5) In step (2) of the SMTP sender algorithm (section 3), I suggest we say "Compare each host name in MX records with the names of the sending host. If there is any match, [..]". (A host can have multiple names, at least in this mail delivery context.) 6) Step (2) lacks a comparison (and a few words). It should say, "drop all MX records which have equal to or larger than preference value [than the preference value of] *the lowest-preference matching MX*". (Alternatively, perform a sorting on preference before trying to match, and then iterate the list in order of ascending MX preference values). 7) Step (5), the "NOTE" paragraph is slightly arbitrary in its use of guideline words ("optional", "may", "should"). I suggest changing the text "If one or more address records are found, some MTA implementations may sort addresses based on based on the implementation's preference to A or AAAA records." to "An implementation MAY sort addresses based on the implementation's preference to A or AAAA records." and to drop the trailing line "But this type of sorting is optional." I also would like to see a clarification that this sorting may only reorder addresses from MX records of the same preference! Address family preference can't be more important than MX preference value. 8) The conclusion in the example in the last paragraph of section 4, (from "It is also possible[..]") "In such cases, [a] dual-stack MX host may not be listed in the MX list". This is incorrect, it doesn't follow from the example. I'm not sure what to replace it with. Perhaps removal is better. 9) In the first paragraph of section 5, the text says there were SERVFAIL errors "when attempting to obtain a canonical hostname [..] on AAAA record lookups". This is unclear to me. Doing a T_AAAA lookup is outside the scope of this document. Doing any lookup resulting in a canonical hostname should be independent of IPv6 or IPv4/v6 interop. Unfortunately, the referenced draft is gone. 10) In section 6, "Open issues", first item (scoped addresses in email addresses). The suggestion (which is of no consequence other than the notion, btw) speaks of "source routes" only. Do you mean "address literals as destination domains"? If so, please correct. If not, I would suggest to drop the source routes from this. MINOR 0) Throughout the document, usage of 'may', 'should', etc. are used. Perhaps these should be capitalized and strengthened as per RFC 2119? 1) In the Abstract, there is the sentence As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations are necessary for IPv6-capable MX records for stable dual-stack (IPv4 and IPv6) SMTP operation. Since there's no such thing as 'IPv6-capable MX records', I suggest changing this to something like this: As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. 2) I suggest removing the second paragraph from section one, or merging this with the last section, as they cover the same subject (the draft not being about single-stack systems). 3) Section 2, first paragraph: Add a reference to the DNS RFC? 4) Section 2, first paragraph: "domain name system" -> "the Domain Name System (DNS) [Reference]". "MX RRs are looked up to know destination hosts" -> "MX RRs are looked up in DNS to retrieve the names of hosts running MTAs associated with the domain part of the mail address". 5) Section 2, second paragraph: "In IPv4 environment, IPv4 IP addresses are defined with A RRs". Please remove this line. It's not relevant, the first part is extremely gratuitous, and the statement is incorrect as well. 6) Section 2, paragraph "But, every host may not support dual stack operation, some host entries may have only IPv4 or IPv6 RRs:", replace by "But, not every MX target may support dual-stack operation. Some MX targets may have only A RRs or AAAA RRs:". 7) Section 3, paragraph "The algorithm for an SMTP sender is basically the same as for an IPv4-only sender". Change "SMTP sender" to "dual-stack SMTP sender". 8) Section 3, algorithm, step (3) and (4): lookup A/AAAA *recordS* (plural). 9) Step (5); "No A or AAAA" is somewhat ambiguous. Instead, use "no A and no AAAA". 10) In section 4.1 we find the first use of a capitalized "SHOULD". This is not encountered anywhere else. 11) I'm not too happy about the wording of section 7 (Security considerations), esp. the rather imperfect sentence "MTA's would need to reject email with improper route-addr email address formats." The terms "route-addr", "improper" and "email address format" are not well-defined here. 12) In the References, the Morishita/Jinmei draft "Common misbehavior against DNS Queries for IPv6 Addresses" is no longer available, so should not be referenced (certainly not by filename). SPELLING & GRAMMAR, MINOR MINOR 0) The document sometimes spells "IPv4/v6" and sometimes "IPv4/IPv6". A consistent notation is better. (I use "IPv4/v6", which is used more often in this document, in the rest of my comments"). 1) The title in the document misspells 'environments' (environements) 2) Section 1, first paragraph: "submiter" -> "submitter"; "to configure all the system" -> "to configure all systems". 3) Section 1, first paragraph: "since mail message delivery system is rather complex on DNS setting than other Internet services". I suggest something like, "since the DNS configuration used by mail message delivery systems is more complex than other Internet services". 4) Section 1, first paragraph: "For the transition sate from IPv4 to IPv6, both IPv4 and IPv6 interoperability should be kept more carefully." Suggestion: something like "During the transition period from IPv4 to IPv6, more care should be applied to IPv4/v6 interoperability." 5) The first sentence of the third paragraph of section 1 ("IPv6-only MTA [..]") could be slightly reworded (grammar). 6) In section 2, paragraph "In transition period from IPv4 [..]", replace "many IPv4 sites" by "many IPv4-only sites" (only these have no interoperability of course). 7) Section 2, last paragraph: replace paragraph by grammatrically better "The following sections discuss how the sender side should operate with IPv4/v6 combined RRs (section 3) and how the receiver should define RRs to maintain interoperability between IPv4 and IPv6 networks (section 4)." 8) Section 3, paragraph "For a single MX record, there are mnay possible final states". There are 3, not many :) I also recommend changing "final states" into something else. 9) Paragraph "The algorithm for an SMTP sender": "destionation" -> "destination". Cheers, Dean -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli From owner-v6ops@ops.ietf.org Mon Jan 26 05:06:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28117 for ; Mon, 26 Jan 2004 05:06:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al3YZ-000OhN-8V for v6ops-data@psg.com; Mon, 26 Jan 2004 10:01:23 +0000 Received: from [213.165.64.20] (helo=mail.gmx.net) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Al3YE-000Ogg-Uo for v6ops@ops.ietf.org; Mon, 26 Jan 2004 10:01:03 +0000 Received: (qmail 12668 invoked by uid 65534); 26 Jan 2004 10:01:01 -0000 Received: from unknown (EHLO NicoLaptop) (192.166.62.145) by mail.gmx.net (mp023) with SMTP; 26 Jan 2004 11:01:01 +0100 X-Authenticated: #15262315 From: "Nico Bayer" To: "IPv6 Operations" Subject: Test, please ignore Date: Mon, 26 Jan 2004 10:59:00 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C3E3FB.67689730" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcPj8wT0Kc65tMnkSHCg0Me/uqhjYw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Level: **** X-Spam-Status: No, hits=4.6 required=5.0 tests=BAYES_90,HTML_90_100, HTML_MESSAGE,MIME_HTML_MOSTLY autolearn=no version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C3E3FB.67689730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0059_01C3E3FB.67689730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

------=_NextPart_000_0059_01C3E3FB.67689730-- From owner-v6ops@ops.ietf.org Mon Jan 26 08:09:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05071 for ; Mon, 26 Jan 2004 08:09:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al6OF-000Ev1-N6 for v6ops-data@psg.com; Mon, 26 Jan 2004 13:02:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al6Nz-000Eue-Lt for v6ops@ops.ietf.org; Mon, 26 Jan 2004 13:02:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0QD2Zf32447; Mon, 26 Jan 2004 15:02:35 +0200 Date: Mon, 26 Jan 2004 15:02:35 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: itojun@iijlab.net Subject: Re: Review Requested: SMTP IPv6 operational experience document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Nice to see that Dean made an indepth review of the draft. Here's my review as an individual WG member. On Mon, 19 Jan 2004, Pekka Savola wrote: > draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt > > Please send comments, preferably in a week, by 26th January, either to > the v6ops list (preferable), or directly to itojun (acting as the > editor) and the chairs. First, I have to say that the beginning of the document (up to section 3 or so), is in an AWFUL English shape. Please review those in detail, even though I mention many of the editorial problems. I assume that this draft is going for Informational (and not e.g. BCP). bigger issues ------------- IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4 translators such as [Hagino, 2001] , however, there are no special SMTP considerations for translators needed; If there is SMTP traffic from an IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA will consider this as a normal IPv4 SMTP traffic. Protocols like IDENT [St.Johns, 1993] as well as SMTP HELO/EHLO may require special consideration when translators are used. ==> the latter, esp. SMTP EHLO/HELO is pretty important part of the scope of this document (aren't we interested of SMTP?), so it should probably elaborated a bit more. ... There are several technologies defined for the transition from IPv4 to IPv6. This document concentrates on SMTP issues in a dual-stack environment, e.g. delivery of emails from IPv6-only MTA to IPv4-only MTA is outside of the scope of the document. IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4 translators such as [Hagino, 2001] , however, there are no special SMTP considerations for translators needed; If there is SMTP traffic from an IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA will consider this as a normal IPv4 SMTP traffic. Protocols like IDENT [St.Johns, 1993] as well as SMTP HELO/EHLO may require special consideration when translators are used. The following sections explain how to make IPv4 SMTP and IPv6 SMTP coexist in a dual-stack environment. This document does not discuss the problems encountered when the sending MTA and the receiving MTA have no common protocol (e.g. the sending MTA is IPv4-only while the receiving MTA is IPv6-only). Such a situation should be resolved by making either side dual-stack or by making either side use a protocol translator. ==> 1, 2 and 4th paragraph seem to be slightly at odds with each another, and the third seems out of place. One should unify the text a bit, e.g., officially include discussion of the translators (etc.) or put them in an Appendix and refer to that in the introduction. example.org. IN MX 1 mx1.example.org. IN MX 10 mx10.example.org. mx1.example.org. IN AAAA 3ffe:501:ffff::1 mx10.example.org. IN AAAA 3ffe:501:ffff::2 ==> the IPv6 examples should use something more closely resemling a "documentation prefix", at this time, the closest would probably be 2001:db8::/32. 4. MX configuration in the recipient domain 4.1. Ensuring reachability for both protocol versions If a site has dual-stack reachability, the site SHOULD configure both A and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the site). This will help both IPv4 and IPv6 senders to reach the site efficiently. ==> you use uppercase keyword, but don't define them. However, for an operational document (and not a protocol specification, with interoperability requirements) like this, it would be better to not use them at all, i.e., s/SHOULD/should/ or the like. 7. Security considerations It could be problematic if the route-addr email address format is used across multiple scope zones. MTA's would need to reject email with improper route-addr email address formats. ==> this is the first time you mention "route-addr". You should provide a bit more background to this issue. References ==> these have to be split to informative and normative. Also note that an RFC obsoleting RFC1886 has been published. ==> this draft should also include the IPR and the copyrights sections at the end. editorial issues ---------------- ==> it would be nice if the text in the sections was indented a couple of spaces, for readibility, but this is OK as is too. SMTP operational experience in mixed IPv4/IPv6 environements ==> uppercase, s/ements/ments/ This document talks about SMTP operational experiences in IPv4/v6 dual ==> might be worth spelling out SMTP, even though everybody probably knows it.. Deliveries of mail messages to the final mail drop is not always done by ==> s/Deliveries/Delivery/ ? direct IP communication with submiter and final receiver, and there may ==> s/submiter/submitter/, add "the" times ? It is not so easy to configure all the system with consistency since mail message delivery system is rather ==> s/system/systems/, maybe s/with consistency/consistently/ ? complex on DNS setting than other Internet services. For the transition ==> s/setting/settings/ For the transition state from IPv4 to IPv6, both IPv4 and IPv6 interoperability should be kept more carefully. ==> the latter part of the sentence "kept more carefully" is barely english, please reword? :-) Mail messages on the Internet are delivered based on domain name system generally. ==> s/delivered ... generally/typically delivered .../ ? with domain part of a mail addresse. ==> s/addresse/address/ Similar to the way RFC's for IPv6 DNS lookup [Thomson, 1995] use IN class for both IPv4 and IPv6, IN MX records will be used for both IPv4 and IPv6 on mail message routing, hosts which have IPv6 transport and want to be delivered with the IPv6 transport must define IPv6 IP addresses for the host name as well as IPv4 IP addresses. ==> want *what* to be _delivered with_? Bad english, please reword, e.g.: DNS lookup [Thomson, 1995] uses IN class for both IPv4 and IPv6 and similarly IN MX records will be used for mail routing for both IPv4 and IPv6. Hosts which have IPv6 connectivity and want to have the mails delivered also using IPv6 must define IPv6 addresses for the host name as well as IPv4 addresses. A MX RR have two data, a preference value and the name of destination host. ==> s/have two data/has two arguments/ ? IP addresses for the destination host are also looked up to make SMTP transport [Partridge, 1986] . ==> s/ ././, s/make SMTP transport/initiate SMTP connection/ ? In the following sections, how sender side operates with IPv4/IPv6 combined RR definitions (section 3), and how receiver side should define RRs to keep interoperability with both IPv4 and IPv6 Internet (section 4) are considerd. ==> Start like "In the following section we consider how ..." NOTE: IPv6 addresses for hosts defined by MX records may be informed in additional information section of DNS querie's result ==> s/querie's/query's/ or s/querie's/queries'/ reachable and if a list of MX records is being traversed, try the next MX record (go to step (3)). If there is no list of MX ==> s/))/)/ condision reported, try the next MX record (go to step (3)). If an ==> s/condision/condition/ 6. Open issues o The document should really be integrated into RFC2821 [Klensin, 2001] (i.e. RFC2821 should talk about IPv6 cases). ==> I'd reword this a bit, like: o A future specification of SMTP should be updated to include the information in this memo. Change history ==> Here you could add something like: [[ RFC-Editor: please remove before publication ]] Author's address ==> replace with Authors' Addresses 2. Basic DNS resource record definitions for mail routing 3. SMTP sender algorithm in a dual-stack environment 4. MX configuration in the recipient domain 4.1. Ensuring reachability for both protocol versions 4.2. Reachability between the primary and secondary MX 5. Operational experience 6. Open issues ==> The section titles and the document title should be "first-character uppercased", like: 2. Basic DNS Resource Record Definitions for Mail Routing 3. SMTP Sender Algorithm in a Dual-stack Environment 4. MX Configuration in the Recipient Domain 4.1. Ensuring Reachability for Both Protocol Versions 4.2. Reachability Between the Primary and Secondary MX 5. Operational Experience 6. Open Issues -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Jan 26 08:15:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05178 for ; Mon, 26 Jan 2004 08:15:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al6Yf-000G3s-Ua for v6ops-data@psg.com; Mon, 26 Jan 2004 13:13:41 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al6YT-000G3M-W6 for v6ops@ops.ietf.org; Mon, 26 Jan 2004 13:13:30 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 36100B4; Mon, 26 Jan 2004 22:13:29 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: Re: Review Requested: SMTP IPv6 operational experience document In-Reply-To: Your message of "Mon, 26 Jan 2004 15:02:35 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040126131329.36100B4@coconut.itojun.org> Date: Mon, 26 Jan 2004 22:13:29 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > ==> this draft should also include the IPR and the copyrights sections at the end. in my understanding (and from past experience) copyright section is added by RFC editor, am I right? and is IPR section mandatory? (from my past experience it was not) itojun From owner-v6ops@ops.ietf.org Mon Jan 26 08:20:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05324 for ; Mon, 26 Jan 2004 08:20:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al6dD-000GaF-1T for v6ops-data@psg.com; Mon, 26 Jan 2004 13:18:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al6cj-000GTk-JD for v6ops@ops.ietf.org; Mon, 26 Jan 2004 13:17:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0QDHlD32631; Mon, 26 Jan 2004 15:17:47 +0200 Date: Mon, 26 Jan 2004 15:17:47 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: Re: Review Requested: SMTP IPv6 operational experience document In-Reply-To: <20040126131329.36100B4@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 26 Jan 2004, Jun-ichiro itojun Hagino wrote: > > ==> this draft should also include the IPR and the copyrights sections at the end. > > in my understanding (and from past experience) copyright section is > added by RFC editor, am I right? and is IPR section mandatory? > (from my past experience it was not) Both will be added by RFC editor, if they are missing, but it might be good practice to include them anyway (in case someone who doens't know the Internet-Draft copyright status reads them before the publication). The IPR section is not so important in the Informational operational documents for which it's pretty rare anybody claims IPR for, though (which is why the IPR issue is not usually considered a "hard rule" for Info documents).. Hopefully this clarified at least my understanding of the document "form" procedures. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Jan 26 08:33:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05658 for ; Mon, 26 Jan 2004 08:33:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al6pg-000I77-8t for v6ops-data@psg.com; Mon, 26 Jan 2004 13:31:16 +0000 Received: from [192.11.226.161] (helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al6pS-000I65-M7 for v6ops@ops.ietf.org; Mon, 26 Jan 2004 13:31:02 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0QDULF08597 for ; Mon, 26 Jan 2004 07:31:00 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Jan 2004 14:30:19 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550362C6C7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: itojun@itojun.org, pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: RE: Review Requested: SMTP IPv6 operational experience document Date: Mon, 26 Jan 2004 14:30:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Inline > -----Original Message----- > From: itojun@itojun.org [mailto:itojun@itojun.org] > Sent: maandag 26 januari 2004 14:13 > To: pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: Re: Review Requested: SMTP IPv6 operational > experience document > > > ==> this draft should also include the IPR and the > copyrights sections at the end. > > in my understanding (and from past experience) copyright section is > added by RFC editor, am I right? and is IPR section mandatory? > (from my past experience it was not) > Officially RFC Editor will do that. But in general I (and many others) prefer that the editor/author of a document adds it right away. As soon as the new IPR RFCs take effect, the statement probably needs to be somehwta different though... but we can deal with that when we get there. Bert > itojun > From owner-v6ops@ops.ietf.org Tue Jan 27 01:08:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08283 for ; Tue, 27 Jan 2004 01:08:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlML9-00090Y-5C for v6ops-data@psg.com; Tue, 27 Jan 2004 06:04:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlMKu-0008yY-QX for v6ops@ops.ietf.org; Tue, 27 Jan 2004 06:04:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0R64Pc16274; Tue, 27 Jan 2004 08:04:25 +0200 Date: Tue, 27 Jan 2004 08:04:25 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: Myung-Ki Shin , Subject: Volunteer(s) solicited: English proofreading Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (Writing as co-chair) We're looking for someone (or multiple someones) to do English proofreading and rewording as necessary on the upcoming document: draft-shin-v6ops-application-transition-01.txt (the version will be available off-list) .. as we've received feedback that the language could use a bit beefing up to be fluent. If you would be interesting in helping to improve the language of the document (within a couple of days, week, or at a later phase if that's best for you), please send a note off-list. Thanks, Pekka & Jonne From owner-v6ops@ops.ietf.org Tue Jan 27 09:46:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06683 for ; Tue, 27 Jan 2004 09:46:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlUNG-000MW8-JX for v6ops-data@psg.com; Tue, 27 Jan 2004 14:39:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlUN3-000MUQ-1K for v6ops@ops.ietf.org; Tue, 27 Jan 2004 14:39:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0REdFe30077 for ; Tue, 27 Jan 2004 16:39:15 +0200 Date: Tue, 27 Jan 2004 16:39:15 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Volunteer(s) solicited: English proofreading In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks to everybody who volunteered. We didn't quite expect to see the volunteers to turn in so quickly -- this was a very happy surprise. We'll keep this model of "job advertisement" in mind for the next documents which could use a bit of language proofing. Again, thanks to everyone who volunteered and those who are contributing in other ways, Pekka & Jonne On Tue, 27 Jan 2004, Pekka Savola wrote: > (Writing as co-chair) > > We're looking for someone (or multiple someones) to do English > proofreading and rewording as necessary on the upcoming document: > > draft-shin-v6ops-application-transition-01.txt > (the version will be available off-list) > > .. as we've received feedback that the language could use a bit > beefing up to be fluent. > > If you would be interesting in helping to improve the language of the > document (within a couple of days, week, or at a later phase if that's > best for you), please send a note off-list. > > Thanks, > Pekka & Jonne > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jan 28 06:39:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26533 for ; Wed, 28 Jan 2004 06:39:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alnz3-0008d1-Sp for v6ops-data@psg.com; Wed, 28 Jan 2004 11:35:49 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alnyq-0008bK-Jv for v6ops@ops.ietf.org; Wed, 28 Jan 2004 11:35:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0SBZU222122; Wed, 28 Jan 2004 13:35:31 +0200 Date: Wed, 28 Jan 2004 13:35:30 +0200 (EET) From: Pekka Savola To: Chirayu Patel cc: v6ops@ops.ietf.org, Subject: mech-v2: multiple packet drops with ICMPv4 and ICMPv6 [Re: comments on mech-v2-01] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I added the text below at the end of section 3.4 on ICMP errors. Does this address your concern? Or would you propose alternative text? Note that when IPv4 path MTU is exceeded, and ICMPv4 errors of only 8 bytes of payload are generated, or ICMPv4 errors do not cause the generation of ICMPv6 errors in case there is enough payload, there will be at least two packet drops instead of at least one (the case of a single layer of MTU discovery). Consider a case where a host is connected to a router, which is connected to a network where an ICMPv4 error about too big packet size is generated. First the router needs to learn the tunnel (IPv4) MTU which causes at least one packet loss, and then the host needs to learn the (IPv6) MTU from the router which causes at least one packet loss. Still, in all cases there can be more than one packet loss if there are multiple large packets in flight at the same time. On Mon, 10 Nov 2003, Erik Nordmark wrote: > > 1) A race is triggered when an IPv6 router that has a configured tunnel > > with another router is doing dynamic mtu detection. The outcome of the > > race is that one or more ICMPv6 "packet too big" message might not be > > sent out to an host. > > > > Assume an IPv6 network like: > > > > [H1]-------->[R1]===========>[R2]--------->[H2] > > > 5. H1->R1 TCP packet of size 1400 (this is a retry) > > 6. R1->H1 ICMPv6 "packet too big" with size 1300 > > 7. H1->R1 TCP packet of size 1400 (this is a retry) > > 8. ... (the above cycle might repeat if there are more IPv4 routers > > that send ICMPv4 "fragmentation needed" with 8 bytes of payload) > > I don't understand how it can repeat. Do you think it can repeat forever? > > When the 8-byte payload ICMP errors are sent then R1 will effectively > compute the minimum received (per IPv4 path MTU discovery). > > It is true that in the case of 8-byte payload ICMP errors you get at > least two packet drops instead of at least one in the case of a single layer > of MTU discovery (R1 needs to learn the tunnel MTU which causes at least one > packet loss, and then H1 needs to learn the MTU from R1 which causes at > least one packet loss. (And in all cases there can be more than one packet loss > if there are multiple large packets in flight at the same time.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jan 28 06:44:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26640 for ; Wed, 28 Jan 2004 06:44:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alo5K-0009j7-Kb for v6ops-data@psg.com; Wed, 28 Jan 2004 11:42:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alo57-0009hn-JF for v6ops@ops.ietf.org; Wed, 28 Jan 2004 11:42:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0SBg4e22270 for ; Wed, 28 Jan 2004 13:42:04 +0200 Date: Wed, 28 Jan 2004 13:42:04 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: mech-v2: unidirectional tunneling removed, SLLA/TLLA changes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, Two status issues on certain mech-v2 features: 1) Based on Chirayu's comments earlier, I've changed the rule (from SHOULD NOT) to MUST NOT send TLLA/SLLA options on configured tunnels. I believe some very old implementations, ages ago, did this, but it seems to make sense to get them fixed if they want to conform to the new specification. (See below.) This does not create a severe interop problem as long as the other end implements the "MUST ignore" as well. 2) As nobody has offered support for unidirectional tunnels, I removed them from the mech-v2 revision as well. If you have any objections, please raise them soon, and provide suggested alternatives. ====== For the purposes of Neighbor Discovery the configured tunnels speci­ fied in this document are assumed to NOT have a link-layer address, even though the link-layer (IPv4) does have address. This means that: - the sender of Neighbor Discovery packets MUST NOT include Source Link Layer Address options or Target Link Layer Address options on the tunnel link. - the receiver MUST, while otherwise processing the neighbor dis­ covery packet, silently ignore the content of any Source Link Layer Address options or Target Link Layer Address options received on the tunnel link. From owner-v6ops@ops.ietf.org Wed Jan 28 08:25:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00006 for ; Wed, 28 Jan 2004 08:25:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlpeS-000Mi5-Ij for v6ops-data@psg.com; Wed, 28 Jan 2004 13:22:40 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlpeF-000Mg8-9z for v6ops@ops.ietf.org; Wed, 28 Jan 2004 13:22:27 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i0SDMK606759; Wed, 28 Jan 2004 14:22:20 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i0SDMKSj006638; Wed, 28 Jan 2004 14:22:20 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200401281322.i0SDMKSj006638@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: mech-v2: unidirectional tunneling removed, SLLA/TLLA changes In-reply-to: Your message of Wed, 28 Jan 2004 13:42:04 +0200. Date: Wed, 28 Jan 2004 14:22:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: Two status issues on certain mech-v2 features: 1) Based on Chirayu's comments earlier, I've changed the rule (from SHOULD NOT) to MUST NOT send TLLA/SLLA options on configured tunnels. I believe some very old implementations, ages ago, did this, but it seems to make sense to get them fixed if they want to conform to the new specification. (See below.) This does not create a severe interop problem as long as the other end implements the "MUST ignore" as well. => I object to this change because some usages were found (so could be found in future) to IPv4 addresses in TLLA/SLLA: "SHOULD NOT" is enough. An example is the (expired, ask if you can't find it) draft "draft-ietf-ngtrans-hometun-01.txt" which was implemented and IMHO has still interested waiting for the MOBIKE stuff which should provide a better solution. If you have any objections, please raise them soon, and provide suggested alternatives. => keep previous text and if you'd not like to mix SHOULD and MUST use the more open one, i.e., SHOULD. Thanks Francis.Dupont@enst-bretagne.fr PS: a MUST is incompatible with 6over4 too and we have not free time to kill (i.e., make historic) 6over4 and all. From owner-v6ops@ops.ietf.org Wed Jan 28 08:44:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00833 for ; Wed, 28 Jan 2004 08:44:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlpwZ-0000pF-Bf for v6ops-data@psg.com; Wed, 28 Jan 2004 13:41:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlpwM-0000oC-DC for v6ops@ops.ietf.org; Wed, 28 Jan 2004 13:41:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0SDWG124748; Wed, 28 Jan 2004 15:32:16 +0200 Date: Wed, 28 Jan 2004 15:32:16 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: v6ops@ops.ietf.org Subject: Re: mech-v2: SLLA/TLLA changes In-Reply-To: <200401281322.i0SDMKSj006638@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In a slightly different order.. On Wed, 28 Jan 2004, Francis Dupont wrote: > > PS: a MUST is incompatible with 6over4 too and we have not free time to > kill (i.e., make historic) 6over4 and all. Yes, but that is 6over4, not mech-v2 bis (configured tunneling), so this seems orthogonal to this argument, specification-wise. > 1) Based on Chirayu's comments earlier, I've changed the rule (from > SHOULD NOT) to MUST NOT send TLLA/SLLA options on configured tunnels. > I believe some very old implementations, ages ago, did this, but it > seems to make sense to get them fixed if they want to conform to the > new specification. (See below.) This does not create a severe interop > problem as long as the other end implements the "MUST ignore" as well. > > => I object to this change because some usages were found (so could be found > in future) to IPv4 addresses in TLLA/SLLA: "SHOULD NOT" is enough. > An example is the (expired, ask if you can't find it) draft > "draft-ietf-ngtrans-hometun-01.txt" which was implemented and IMHO > has still interested waiting for the MOBIKE stuff which should provide > a better solution. I'm doubtful of the usefulness of preserving something like this, but unless there are others in the WG who feel that this should be a MUST NOT and not SHOULD NOT, I can put this back like it was because it doesn't really cost anything or cause problems. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jan 28 09:19:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01622 for ; Wed, 28 Jan 2004 09:19:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlqUz-00073G-B8 for v6ops-data@psg.com; Wed, 28 Jan 2004 14:16:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlqUm-0006xw-7X for v6ops@ops.ietf.org; Wed, 28 Jan 2004 14:16:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0SEGhs25704 for ; Wed, 28 Jan 2004 16:16:43 +0200 Date: Wed, 28 Jan 2004 16:16:43 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: mech-v2: decapsulation check updates Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Since the last version of the transmech document, the decapsulation checks have become much stronger: MUST check the v4 source of the tunnel, MUST check the v6 source addresses for bogus addresses and MAY/should use v4/v6 ingress filtering. Any objections to these changes? Other thoughts? ========= 3.6. Decapsulation When an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 addresses, and the value of the protocol field is 41, the packet is potentially part of a tunnel and needs to be verified to belong to one of the configured tunnel interfaces (by checking source/destination addresses), reassembled (if fragmented at the IPv4 level), have the IPv4 header removed and the resulting IPv6 datagram be submitted to the IPv6 layer code on the node. The decapsulator MUST verify that the tunnel source address is correct before further processing packets, to mitigate the problems with address spoofing (see section 4). This check also applies to packets which are delivered to transport protocols on the decapsulator. This is done by verifying that the source address is the IPv4 address of the other end of a tunnel configured on the node. Packets for which the IPv4 source address does not match MUST be discarded; an ICMP message (whether IPv4 or IPv6) SHOULD NOT be generated. A side effect of this address verification is that the node will silently discard packets with a wrong source address, and packets which were received by the node but not directly addressed to it (e.g., broadcast addresses). In addition, the node MAY perform ingress filtering [RFC2827] on the IPv4 source address, i.e., check that the packet is arriving from the interface in the direction of the route towards the tunnel end-point, similar to a Strict Reverse Path Forwarding (RPF) check [BCP38UPD]. If done, it is RECOMMENDED that this check is disabled by default. The packets caught by this check SHOULD be silently discarded. [[ skip paragraphs about MTU and figures..] After the decapsulation the node MUST silently discard a packet with an invalid IPv6 source address. The list of invalid source addresses SHOULD include at least: - all multicast addresses (FF00::/8) - the loopback address (::1) - all the IPv4-compatible IPv6 addresses [RFC3513] (::/96), excluding the unspecified address for Duplicate Address Detection (::/128) - all the IPv4-mapped IPv6 addresses (::ffff:0:0/96) In addition, the node should perform ingress filtering [RFC2827] on the IPv6 source address, as on any of its interfaces, e.g.: - if the tunnel is towards the Internet, check that the site's IPv6 prefixes are not used as the source addresses, or - if the tunnel is towards an edge network, check that the source address belongs to that edge network. From owner-v6ops@ops.ietf.org Wed Jan 28 09:22:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01728 for ; Wed, 28 Jan 2004 09:22:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlqYi-0007TI-Pn for v6ops-data@psg.com; Wed, 28 Jan 2004 14:20:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlqYV-0007Ri-J1 for v6ops@ops.ietf.org; Wed, 28 Jan 2004 14:20:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0SEKYn25774 for ; Wed, 28 Jan 2004 16:20:34 +0200 Date: Wed, 28 Jan 2004 16:20:34 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: mech-v2: rewritten security text Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I modified section 4 on spoofing threats a bit and rewrote Security Considerations to expand on the problems a bit. Objections or other suggestions? ====== 4. Threat Related to Source Address Spoofing The specification above contains rules that apply tunnel source address verification in particular and ingress filtering [RFC2827][BCP38UPD] in general to packets before they are decapsulated. When IP-in-IP tunneling (independent of IP versions) is used it is important that this can not be used to bypass any ingress filtering in use for non-tunneled packets. Thus the rules in this document are derived based on should ingress filtering be used for IPv4 and IPv6, the use of tunneling should not provide an easy way to circumvent the filtering. In this case, without specific ingress filtering checks in the decapsulator, it would be possible for an attacker to inject a packet with: - Outer IPv4 source: real IPv4 address of attacker - Outer IPv4 destination: IPv4 address of decapsulator - Inner IPv6 source: Alice which is either the decapsulator or a node close to it. - Inner IPv6 destination: Bob Even if all IPv4 routers between the attacker and the decapsulator implement IPv4 ingress filtering, and all IPv6 routers between the decapsulator and Bob implement IPv6 ingress filtering, the above spoofed packets will not be filtered out. As a result Bob will receive a packet that looks like it was sent from Alice even though the sender was some unrelated node. The solution to this is to have the decapsulator only accept encapsulated packets from the explicitly configured source address (i.e., the other end of the tunnel) as specified in section 3.6. While this does not provide complete protection in the case ingress filtering has not been deployed, it does provide a significant increase in security. The issue and the remainder threats are discussed at more length in Security Considerations. 5. Security Considerations An implementation of tunneling needs to be aware that while a tunnel is a link (as defined in [RFC2460]), the threat model for a tunnel might be rather different than for other links, since the tunnel potentially includes all of the Internet. Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count being 255 and/or the addresses being link-local for ensuring that a packet originated on-link, in a semi-trusted environment. Tunnels are more vulnerable to a breach of this assumption than physical links, as an attacker anywhere in the Internet can send an IPv6-in- IPv4 packet to the tunnel decapsulator, causing injection of an encapsulted IPv6 packet to the configured tunnel interface unless the decapsulation checks are able to discard packets injected in such a manner. Therefore, this memo specifies strict checks to ameliorate this threat: - IPv4 source address of the packet MUST be the same as configured for the tunnel end-point, - IPv4 ingress filtering MAY be implemented to check that the IPv4 packets are received from an expected interface, - IPv6 packets with several, obviously invalid IPv6 source address MUST be discarded (see Section 3.6 for details), and - IPv6 ingress filtering should be performed, to check that the IPv6 packets are received from an expected interface. Especially the first check is vital: the to avoid the check, the attacker must be able to know the source of the tunnel (difficult) and be able to spoof it (easier). If the remainder threats of tunnel source verification are considered to be significant, a tunneling scheme with authentication should be used instead, for example IPsec [RFC2401] (preferable) or Generic Routing Encapsulation (GRE) with a pre-configured secret key [RFC2890]. As the configured tunnels are set up more or less manually anyway, setting up the keying material is probably not a problem. If the tunneling is done inside an administrative domain, proper ingress filtering at the edge of the domain can also eliminate the threat from outside of the domain. Therefore shorter tunnels are preferable to longer ones, possibly spanning the whole Internet. Additionally, an implementation must treat interfaces to different links as separate e.g. to ensure that Neighbor Discovery packets arriving on one link does not effect other links. This is especially important for tunnel links. When dropping packets due to failing to match the allowed IPv4 source addresses for a tunnel the node should not "acknowledge" the existence of a tunnel, otherwise this could be used to probe the acceptable tunnel endpoint addresses. For that reason, the specification says that such packets MUST be discarded, and an ICMP error message SHOULD NOT be generated. From owner-v6ops@ops.ietf.org Wed Jan 28 12:57:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17100 for ; Wed, 28 Jan 2004 12:57:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alts0-000Cz2-3R for v6ops-data@psg.com; Wed, 28 Jan 2004 17:52:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Altrh-000Cxh-Tz for v6ops@ops.ietf.org; Wed, 28 Jan 2004 17:52:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0SHqXk30910 for ; Wed, 28 Jan 2004 19:52:33 +0200 Date: Wed, 28 Jan 2004 19:52:33 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: mech-v2: static MTU scope; feedback sought Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, There's still one (the most difficult IMO) issue in transmech-v2 update, triggered by Dave Thaler's comment: http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01717.html That is, a node with v4-in-v6 tunnel, v4 interface, and a v6-in-v6 MIPv6 tunnel: using default MTU 1280 on v4-in-v6 tunnel causes v6 fragmentation on the v6-in-v6 tunnel for the packets whose size is greater than 1240 bytes. On the other hand, there have been comments on the contrary, that mismatching MTU/MRU is a bad thing, like pointed out by itojun. I remember the message but have been unable to find the message referred to in: http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01718.html Now, I'd like to move on here. I personally don't see much of a problem with mismatching MRU/MTU values as long as they are below 1500. But I'd like to see whether there are any evidence indicating otherwise. In Dave's scenario, the obvious easy fix is to use dynamic MTU determination instead of the static one, but this avoids the real question of when it would be OK to raise the MTU w/ static MTU configuration. Moreover, I believe the static MTU case must also be able to react to the received ICMPv6 packet too big messages (e.g., you configure the interface to e.g. 1500, but someone sends you a message that 1280 is the maximum -- do you have to react to it? I assume yes, but I guess someone would view that this "very minimal v6 PMTU detection mechanism" would be out of scope. So, to sum my questions here, asking for feedback: - do you have references/evidence of the problems caused by mismatching MTU/MRU that should be considered here? - MUST a static tunnel MTU case also implement an algorithm to react to the received ICMPv6 Packet too Big messages, e.g. to lower the MTU? (or is this really a subset of dynamic tunnel MTU). RFC2463 sect 3.2 seems to give an impression that this would have to be done, but not sure. - if people agree with this MUST, and no MTU/MRU strong mismatch evidence is found, I believe the "MUST default to 1280" might be too strong -- the worst that could happen is to a) create a blackhole if a router is able to forward a packet but the on-link recipient not receive it, b) if too high value is picked, v4 fragmentation would ensue (bad). - do you think it would be OK to recommend dynamic MTU instead in the double encapsulation scenario described by Dave? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jan 29 13:19:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06209 for ; Thu, 29 Jan 2004 13:19:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmGfP-000MMX-G1 for v6ops-data@psg.com; Thu, 29 Jan 2004 18:13:27 +0000 Received: from [131.155.140.140] (helo=mailhost.stack.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmGf3-000MJV-3v for v6ops@ops.ietf.org; Thu, 29 Jan 2004 18:13:05 +0000 Received: from dragon.stack.nl (dragon.stack.nl [2001:610:1108:5011:207:e9ff:fe09:230]) by mailhost.stack.nl (Postfix) with ESMTP id 40194D30#2768D1F00A; Thu, 29 Jan 2004 19:13:04 +0100 (CET) Received: by dragon.stack.nl (Postfix, from userid 1600) id 1D8795F26A; Thu, 29 Jan 2004 19:13:04 +0100 (CET) Date: Thu, 29 Jan 2004 19:13:04 +0100 From: Dean Strik To: itojun@iijlab.net Cc: v6ops@ops.ietf.org Subject: Re: Review Requested: SMTP IPv6 operational experience document Message-ID: <20040129181304.GJ13043@dragon.stack.nl> References: <20040123212618.GC26724@dragon.stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040123212618.GC26724@dragon.stack.nl> X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes User-Agent: Mutt/1.5.5.1i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Dean Strik wrote: > > draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt There's one more small thing, which I didn't discuss in my earlier comments. I quote from the draft, section 3, the dual-stack algorithm: there's a note between steps (5) and (6), reading: NOTE: If one or more address records are found, some MTA implementation may sort addresses based on the implementation's preference of A or AAAA records. To encourage the transition from IPv4 SMTP to IPv6 SMTP, AAAA records should take precedence. But this type of sorting is optional. I already said: > I also would like to see a clarification that this sorting may only > reorder addresses from MX records of the same preference! Address > family preference can't be more important than MX preference value. According to RFC 2821, section 5, paragraph 4: Multiple MX records contain a preference indication that MUST be used in sorting (see below). Lower numbers are more preferred than higher ones. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily-reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization. Now, a dual-stack client has two sorting parameters. Maybe it would be nice to specify in this note that this IPv6 preference may take precedence over the randomization specified above (so first all IPv6 addresses are tried, then IPv4). Currently, my own implementation lets IPv6 take precedence. I'll make this configurable soon (mostly because people may want to have it otherwise). -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli From owner-v6ops@ops.ietf.org Thu Jan 29 15:08:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13965 for ; Thu, 29 Jan 2004 15:08:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmIOo-000Fnj-73 for v6ops-data@psg.com; Thu, 29 Jan 2004 20:04:26 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmIOU-000Fj7-4F for v6ops@ops.ietf.org; Thu, 29 Jan 2004 20:04:06 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0TK3wR08969; Thu, 29 Jan 2004 12:03:58 -0800 X-mProtect: <200401292003> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFTXSRP; Thu, 29 Jan 2004 12:03:56 PST Message-ID: <4019673B.6050703@iprg.nokia.com> Date: Thu, 29 Jan 2004 12:04:11 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: mech-v2: static MTU scope; feedback sought References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, See below for my thoughts on this: Pekka Savola wrote: >Hi, > >There's still one (the most difficult IMO) issue in transmech-v2 >update, triggered by Dave Thaler's comment: > >http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01717.html > >That is, a node with v4-in-v6 tunnel, v4 interface, and a v6-in-v6 >MIPv6 tunnel: using default MTU 1280 on v4-in-v6 tunnel causes v6 >fragmentation on the v6-in-v6 tunnel for the packets whose size is >greater than 1240 bytes. > >On the other hand, there have been comments on the contrary, that >mismatching MTU/MRU is a bad thing, like pointed out by itojun. I >remember the message but have been unable to find the message referred >to in: > >http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01718.html > >Now, I'd like to move on here. I personally don't see much of a >problem with mismatching MRU/MTU values as long as they are below >1500. But I'd like to see whether there are any evidence indicating >otherwise. > I agree that it is OK to have the MRU slightly larger than the MTU. Suppose the tunnel interface uses the IPv6 minMTU of 1280 bytes, but it is configured over an end-to-end L2 VPN interface. The VPN interface will insert extra header bytes for security headers, and the far end of the tunnel will require an MRU > 1280 bytes on the physical interface(s) that might receive the packet. Steve Deering gave good analysis supporting 1500bytes as the MRU for the physical interfaces at the far end of the tunnel in a November, 1997 message to the IPng list. See: http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1997-12/0052.html >In Dave's scenario, the obvious easy fix is to use dynamic MTU >determination instead of the static one, but this avoids the real >question of when it would be OK to raise the MTU w/ static MTU >configuration. > >Moreover, I believe the static MTU case must also be able to react to >the received ICMPv6 packet too big messages (e.g., you configure the >interface to e.g. 1500, but someone sends you a message that 1280 is >the maximum -- do you have to react to it? I assume yes, but I guess >someone would view that this "very minimal v6 PMTU detection >mechanism" would be out of scope. > >So, to sum my questions here, asking for feedback: > > - do you have references/evidence of the problems caused by > mismatching MTU/MRU that should be considered here? > Another reference, perhaps, would be PPP where (I believe) it is recommended to use a slightly larger MRU than the MTU. I am interested in operational experience others may have, however. > - MUST a static tunnel MTU case also implement an algorithm to > react to the received ICMPv6 Packet too Big messages, e.g. to lower > the MTU? (or is this really a subset of dynamic tunnel MTU). > RFC2463 sect 3.2 seems to give an impression that this would have > to be done, but not sure. > Well, the text you are citing says only that "An incoming Packet Too Big messaage MUST be passed to the upper-layer process"; I'm not really seeing anything about changing the tunnel MTU based on the ICMPv6 messages. > - if people agree with this MUST, and no MTU/MRU strong mismatch > evidence is found, I believe the "MUST default to 1280" might be > too strong -- the worst that could happen is to a) create a > blackhole if a router is able to forward a packet but the > on-link recipient not receive it, b) if too high value is picked, > v4 fragmentation would ensue (bad). > My concern here is for nodes with long, thin (i.e., slow) physical links. Suppose a tunnel interface is configured over a physical interface that takes the recommendations of BCP 48 and configures a small IPv4 MTU, e.g., 296 bytes. The tunnel interface will still have to configure at least the minimum IPv6 MTU of 1280 bytes, but the 296 byte IPv4 MTU of the underlying physical interface will be opaque to the upper layers. In this case, two possibilities exist when the tunnel interface sends encapsulated packets larger than 296 bytes: 1) The tunnel interface sends encapsulated packets with the DF bit NOT set in the IPv4 header, and the IPv4 stack performs intentional IPv4 fragmentation to a maximum fragment size of 296 bytes. 2) The tunnel interface sends encapsulated packets with the DF bit SET, and the IPv4 stack sends back a locally-generated ICMPv4 "fragmentation needed" message with MTU = 296. My thoughts on 1) are that any host-based IPv4 fragmentation should produce a controlled and minimal number of IPv4 fragments and should not severely impact performance. This is quite different than unmitigated IPv4 fragmentation caused by middleboxes in the network, since there is no way of knowing whether the middleboxes will incur slow path processing or otherwise experience performance degradation. On the other hand, I have heard that there are devices such as security gateways, NATs, etc. that drop incoming IPv4 fragments (perhaps only sending the first-fragment on to the final destination), i.e., black-holes may result. What are the operational experiences with this? My thoughts on 2) are that the locally-generated ICMPv4 "fragment needed" messages will be passed to the configured tunnel device driver in the kernel, but what actions should be taken? Should the driver: a) reduce the configured tunnel's MTU to 296-20 (i.e., less than the IPv6 minimum MTU)? b) keep the MTU in, e.g., a neighbor cache entry to provide a maximum fragment size for IPv6 fragmentation? c) translate the ICMPv4 "frag needed" into an ICMPv6 "packet too big" and pass it up to the application? d) other? I can imagine either a) or b) as acceptable answers. I have a hard time believing c) could be good, because it might cause TCPs to configure a too-small MSS. But, I'd like to hear operational experiences and/or other alternatives I may be missing. > - do you think it would be OK to recommend dynamic MTU instead in the > double encapsulation scenario described by Dave? > Possibly; the only concern is trust issues for ICMPv4 "fragmentation needed" messages generated by middleboxes. Perhaps if the ICMPv4s were only accepted from the localhost and from the far end of the tunnel it would be OK? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Jan 29 16:00:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18210 for ; Thu, 29 Jan 2004 16:00:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmJEl-000P87-Lj for v6ops-data@psg.com; Thu, 29 Jan 2004 20:58:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmJEY-000P6y-LE for v6ops@ops.ietf.org; Thu, 29 Jan 2004 20:57:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0TKv4N01699; Thu, 29 Jan 2004 22:57:04 +0200 Date: Thu, 29 Jan 2004 22:57:04 +0200 (EET) From: Pekka Savola To: david@iprg.nokia.com, cc: iesg-secretary@ietf.org, Subject: Request to Advance "Analysis on IPv6 Transition in 3GPP Networks" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk David and Bert, On behalf of the v6ops WG, we'd like to request that the following document be published as BCP RFC: Analysis on IPv6 Transition in 3GPP Networks http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-08.txt Working group last call for this documents wwas completed on 14th October. It has since then been revised twice to close the issues raised in the Last Call. Thanks, Pekka & Jonne v6ops WG co-chairs From owner-v6ops@ops.ietf.org Thu Jan 29 19:51:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03346 for ; Thu, 29 Jan 2004 19:51:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmMpD-0007vM-5l for v6ops-data@psg.com; Fri, 30 Jan 2004 00:47:59 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmMow-0007px-QL for v6ops@ops.ietf.org; Fri, 30 Jan 2004 00:47:42 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 89EA6C6; Fri, 30 Jan 2004 09:47:26 +0900 (JST) To: dean@ipnet6.org Cc: v6ops@ops.ietf.org Subject: Re: Review Requested: SMTP IPv6 operational experience document In-Reply-To: Your message of "Thu, 29 Jan 2004 19:13:04 +0100" <20040129181304.GJ13043@dragon.stack.nl> References: <20040129181304.GJ13043@dragon.stack.nl> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040130004726.89EA6C6@coconut.itojun.org> Date: Fri, 30 Jan 2004 09:47:26 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt thank you for numerous comments. i will try to integrate those into the document and submit another i-d (under individual name instead of "ngtrans", as suggested by ADs). > Now, a dual-stack client has two sorting parameters. Maybe it would be > nice to specify in this note that this IPv6 preference may take > precedence over the randomization specified above (so first all IPv6 > addresses are tried, then IPv4). > > Currently, my own implementation lets IPv6 take precedence. I'll make > this configurable soon (mostly because people may want to have it > otherwise). from IPv6 transition POV IPv6 should take precedence. having knob would be good for early transition period, mainly due to the problems documented in draft-morishita-dnsop-misbehavior-against-aaaa-00.txt, but please make IPv6 to take precedence by default. itojun From owner-v6ops@ops.ietf.org Thu Jan 29 20:52:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05519 for ; Thu, 29 Jan 2004 20:52:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmNmQ-000GIj-JN for v6ops-data@psg.com; Fri, 30 Jan 2004 01:49:10 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmNmD-000GHL-Ua for v6ops@ops.ietf.org; Fri, 30 Jan 2004 01:48:58 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 550BAA5; Fri, 30 Jan 2004 10:48:42 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: Re: mech-v2: static MTU scope; feedback sought In-Reply-To: Your message of "Wed, 28 Jan 2004 19:52:33 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040130014842.550BAA5@coconut.itojun.org> Date: Fri, 30 Jan 2004 10:48:42 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On the other hand, there have been comments on the contrary, that > mismatching MTU/MRU is a bad thing, like pointed out by itojun. I > remember the message but have been unable to find the message referred > to in: > > http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01718.html the operational problem we have experienced was between KAME and Juniper. Juniper (JunOS) sets tunnel MTU to infinity by default, and KAME defaults to 1280. with this setup ICMPv6 "need fragment" was not generated (don't remember from which end), and tunnel between Juniper and KAME did not work well too. setting Juniper's MTU to 1280 solved the problem. i'm not sure if Juniper's MTU configuration changes MRU or not. itojun From owner-v6ops@ops.ietf.org Fri Jan 30 01:18:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15018 for ; Fri, 30 Jan 2004 01:18:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmRtX-0006yN-Ix for v6ops-data@psg.com; Fri, 30 Jan 2004 06:12:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmRtK-0006xB-0E for v6ops@ops.ietf.org; Fri, 30 Jan 2004 06:12:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0U6CJX12304; Fri, 30 Jan 2004 08:12:19 +0200 Date: Fri, 30 Jan 2004 08:12:19 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: Re: mech-v2: static MTU scope; feedback sought In-Reply-To: <20040130014842.550BAA5@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 30 Jan 2004, Jun-ichiro itojun Hagino wrote: > > On the other hand, there have been comments on the contrary, that > > mismatching MTU/MRU is a bad thing, like pointed out by itojun. I > > remember the message but have been unable to find the message referred > > to in: > > > > http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01718.html Thanks for getting back at this. > the operational problem we have experienced was between KAME and > Juniper. Juniper (JunOS) sets tunnel MTU to infinity by default, and > KAME defaults to 1280. with this setup ICMPv6 "need fragment" was > not generated (don't remember from which end), and tunnel between > Juniper and KAME did not work well too. setting Juniper's MTU to > 1280 solved the problem. Well, not anymore at least. The default MTU is 1480 (I think it has been that for at least a year, but we don't do a lot of tunneling, so I don't know), so this should not be a problem as long as the other end has large enough MRU to receive packets of this size. Needs to be spelled out though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jan 30 01:49:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16411 for ; Fri, 30 Jan 2004 01:49:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmSPi-000BNb-B9 for v6ops-data@psg.com; Fri, 30 Jan 2004 06:46:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmSPT-000BMi-Lu for v6ops@ops.ietf.org; Fri, 30 Jan 2004 06:45:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0U6jik12881; Fri, 30 Jan 2004 08:45:44 +0200 Date: Fri, 30 Jan 2004 08:45:44 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: mech-v2: static MTU scope; feedback sought In-Reply-To: <4019673B.6050703@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for your feedback, Fred -- it helped a lot in clarifying my thinking. Inline -- On Thu, 29 Jan 2004, Fred Templin wrote: > >Now, I'd like to move on here. I personally don't see much of a > >problem with mismatching MRU/MTU values as long as they are below > >1500. But I'd like to see whether there are any evidence indicating > >otherwise. > > I agree that it is OK to have the MRU slightly larger than the MTU. [...] True. The scenario we must analyze a bit, however, is when someone in the path has a lower IPv6 MTU. Like: host <=================> router <----------> destination v6-in-v4 tunnel v6 link v6 MTU = 1380 v6 MTU = 1280 Router sends ICMPv6 packet too big to the sending host, connected over a tunnel. What happens when the host receives this ICMPv6 Packet too Big message? 1) If the node does not implement PMTUD, the all the packets will be discarded -- an unresolvable error condition: meaning, unless you do PMTUD, you must never send packets over MTU=1280. 2) If the node implements PMTUD, a) decrease the effective MTU of the IPv6 link (e.g., by adding a "cloned" route with lower MTU to the routing table (or whatever the implementation is), b) if this fails (e.g., UDP), start sending IPv6 fragments. However, note from the below: ICMPv6 spec states that implementation MUST pass Pkt Too Big up to the upper layers. This would imply that a simple form of 2) would have to be done without PMTUD as well, but that this should not typically happen as the nodes without PMTUD must restrict the size of packets they send to 1280 bytes, generating no such messages. > > - MUST a static tunnel MTU case also implement an algorithm to > > react to the received ICMPv6 Packet too Big messages, e.g. to lower > > the MTU? (or is this really a subset of dynamic tunnel MTU). > > RFC2463 sect 3.2 seems to give an impression that this would have > > to be done, but not sure. > > Well, the text you are citing says only that "An incoming Packet Too Big > messaage MUST be passed to the upper-layer process"; I'm not really seeing > anything about changing the tunnel MTU based on the ICMPv6 messages. Yes, in the highsight -- that's true. Note that this is independent of full PMTUD, so even if a node didn't implement PMTUD, it would have to implement the processing of Packet Too Big messages, which should reflect e.g., what MSS TCP uses, and maybe even fragment UDP packets if they are too big. It seems the picture is not consistent from the IPv6 implementation point-of-view. Perhaps this should be brought up there.. > My concern here is for nodes with long, thin (i.e., slow) physical links. > Suppose a tunnel interface is configured over a physical interface that > takes the recommendations of BCP 48 and configures a small IPv4 MTU, > e.g., 296 bytes. The tunnel interface will still have to configure at least > the minimum IPv6 MTU of 1280 bytes, but the 296 byte IPv4 MTU of > the underlying physical interface will be opaque to the upper layers. > In this case, two possibilities exist when the tunnel interface sends > encapsulated packets larger than 296 bytes: > > 1) The tunnel interface sends encapsulated packets with the DF bit > NOT set in the IPv4 header, and the IPv4 stack performs intentional > IPv4 fragmentation to a maximum fragment size of 296 bytes. > > 2) The tunnel interface sends encapsulated packets with the DF bit > SET, and the IPv4 stack sends back a locally-generated ICMPv4 > "fragmentation needed" message with MTU = 296. I think these cases aren't really all that different as long as they are done inside the node. I don't think an implementation would send "internal" frag needed messages, but just do the fragmentation, ultimately resulting in 1) whether going through 2) or not. > On the > other hand, I have heard that there are devices such as security gateways, > NATs, etc. that drop incoming IPv4 fragments (perhaps only sending > the first-fragment on to the final destination), i.e., black-holes may > result. What are the operational experiences with this? I can't say anything about that, this hasn't come up that much in our scenarios. > My thoughts on 2) are that the locally-generated ICMPv4 "fragment > needed" messages will be passed to the configured tunnel device driver > in the kernel, but what actions should be taken? Should the driver: > > a) reduce the configured tunnel's MTU to 296-20 (i.e., less than the > IPv6 minimum MTU)? > b) keep the MTU in, e.g., a neighbor cache entry to provide a maximum > fragment size for IPv6 fragmentation? > c) translate the ICMPv4 "frag needed" into an ICMPv6 "packet too big" > and pass it up to the application? > d) other? > > I can imagine either a) or b) as acceptable answers. I have a hard time > believing c) could be good, because it might cause TCPs to configure > a too-small MSS. But, I'd like to hear operational experiences and/or > other alternatives I may be missing. As the link-layer MTU is too low to accommodate IPv6 minimum MTU, c) is out of quetion in this instance. a) is also out of question, if you are talking about reducing v6 MTU below the minimum, as that would break a lot of assumptions small IPv6 devices have about the minimal path MTUs. So, I guess b) is the only option? Note that in this case, there does not have to be IPv6 fragmentation at all. IPv6 link should still be 1280 bytes even though the underlying v4 link is only e.g. 296 bytes. I don't think there is anything in the v6 spec that forbids the host from doing "voluntary fragmentation" even though it could send larger packets to accommodate for the slower links, but that's just a local optimization I think. > > > - do you think it would be OK to recommend dynamic MTU instead in the > > double encapsulation scenario described by Dave? > > > > Possibly; the only concern is trust issues for ICMPv4 "fragmentation > needed" messages generated by middleboxes. Perhaps if the ICMPv4s > were only accepted from the localhost and from the far end of the > tunnel it would be OK? These trust issues (whether one thinks they're really a problem or not is another thing) exist regardless of this specification, so I'm not sure whether we should work too hard to replacing the functionality of ICMPv4 frag needed messages. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jan 30 02:35:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00803 for ; Fri, 30 Jan 2004 02:35:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmT8O-000HyA-MF for v6ops-data@psg.com; Fri, 30 Jan 2004 07:32:12 +0000 Received: from [131.155.140.140] (helo=mailhost.stack.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmT8C-000HwM-BQ for v6ops@ops.ietf.org; Fri, 30 Jan 2004 07:32:00 +0000 Received: from dragon.stack.nl (dragon.stack.nl [2001:610:1108:5011:207:e9ff:fe09:230]) by mailhost.stack.nl (Postfix) with ESMTP id 401A086F#619CE1F006; Fri, 30 Jan 2004 08:31:59 +0100 (CET) Received: by dragon.stack.nl (Postfix, from userid 1600) id 588285F27E; Fri, 30 Jan 2004 08:31:59 +0100 (CET) Date: Fri, 30 Jan 2004 08:31:59 +0100 From: Dean Strik To: Jun-ichiro itojun Hagino Cc: dean@ipnet6.org, v6ops@ops.ietf.org Subject: Re: Review Requested: SMTP IPv6 operational experience document Message-ID: <20040130073159.GK13043@dragon.stack.nl> References: <20040129181304.GJ13043@dragon.stack.nl> <20040130004726.89EA6C6@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040130004726.89EA6C6@coconut.itojun.org> X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes User-Agent: Mutt/1.5.5.1i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jun-ichiro itojun Hagino wrote: > > Currently, my own implementation lets IPv6 take precedence. I'll make > > this configurable soon (mostly because people may want to have it > > otherwise). > > from IPv6 transition POV IPv6 should take precedence. > having knob would be good for early transition period, mainly due to > the problems documented in > draft-morishita-dnsop-misbehavior-against-aaaa-00.txt, > but please make IPv6 to take precedence by default. Yes, I had no intention to change the default. -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli From owner-v6ops@ops.ietf.org Fri Jan 30 02:44:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01023 for ; Fri, 30 Jan 2004 02:44:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmTIZ-000JSP-QK for v6ops-data@psg.com; Fri, 30 Jan 2004 07:42:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmTIE-000JNZ-PV for v6ops@ops.ietf.org; Fri, 30 Jan 2004 07:42:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0U7gJU14025; Fri, 30 Jan 2004 09:42:19 +0200 Date: Fri, 30 Jan 2004 09:42:19 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: itojun@itojun.org Subject: mech-v2: Decapsulation/MRU requirements and Static MTU changes? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I'm trying to find a proper way to ensure that the decapsulation and Static MTU change rules appropriate. I'm Cc:ing itojun in particular, as he has been the strongest proponent of "only 1280 for static MTU case". Would there be objections to changing the decapsulation and static MTU rules as follows: 1) all decapsulators MUST be capable of reassembling an IPv4 packet up to the maximum of _1300_ bytes, the largest (IPv4) interface MTU on the decapsulator, _and 1500 bytes_. (changes highlighted with _underline_; in practice this would add no new practical requirements but could simplify certain assumptions; I raised 1280 bytes to 1300 because we must allow 1280+20 bytes.) 2) all decapsulators MUST be capable of having an IPv6 Maximum Receive Unit (MRU) of at least the maximum of of 1280 bytes, the largest (IPv6) interface MTU on the decapsulator, and 1500 bytes. (in practice, I don't think this adds any more requirement which would not exist today. Even though one would set MTU=1280, you still have to be able to receive the packets up to the physical MTU of the interface anyway. There was some discussion of MRU in the past, and I believe there was something close to rough consensus to require even MRU of 4400 bytes, but it was not added for other reasons.) 3) A node using a static tunnel MTU MUST treat the tunnel interface as having a fixed interface MTU. By default, the MTU MUST be between 1280 and 1480 bytes (inclusive), but it SHOULD be 1280 bytes. In case the default is not 1280 bytes, the implementation MUST have a configuration knob which can be used to change the MTU value. (This may be objectionable -- but my point is, with the above two 1)-2) clarifications, there would not be an interoperability problem with setting an interface MTU to be higher than 1280 by default, as long as it's not "too high". I'm tempted to make this change, as a large number of implementations are just doing static MTU, and IMHO static MTU=1280 seems to hurt more than it helps -- and there is only about one implementation I know of which actually adheres to this "1280 bytes" rule (the most common is 1480 I think)) (Additionally, there would be some text describing the applicability and the problems of certain scenarios.) Even if there would be objections to 3), I think adding 1) and 2) would still make sense to ensure maximal interoperability. The alternative to the change 3) would be leaving the text as is, describing the problems it causes at a bit more length, and live with the disparity of the spec and the implementations. (co-chair hat on) yes, there will be a 1 week last call when done, but trying to get some measure of consensus on the changes will likely avoid unnecessary churn (hat off). Thoughts? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jan 30 11:25:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24466 for ; Fri, 30 Jan 2004 11:25:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmbNk-0000tj-Nx for v6ops-data@psg.com; Fri, 30 Jan 2004 16:20:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmbNY-0000sX-At for v6ops@ops.ietf.org; Fri, 30 Jan 2004 16:20:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0UGKNL24695; Fri, 30 Jan 2004 18:20:23 +0200 Date: Fri, 30 Jan 2004 18:20:22 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: WG Last Call: draft-ietf-v6ops-mech-v2-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, This is the second WG Last Call for comments on sending draft-ietf-v6ops-mech-v2-02.txt, "Basic Transition Mechanisms for IPv6 Hosts and Routers", to the IESG for consideration as Proposed Standard. Because of the current I-D submission latency, the document has not been published yet, and is available at: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-02.txt There is also an HTML wdiff against the -01 version for the interested: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-02-changes-01.html There have been a large number of updates since the last version, and we hope to ensure that rough consensus exists for the document to go forward. The intent is to start to work on the interoperability and implementation reports soon, and recycle to Draft Standard with the required changes within 6 months. Please review the document and provide feedback on the list. The last call will end in a bit more than 1 week, on 8th February. Thanks, Pekka & Jonne From owner-v6ops@ops.ietf.org Fri Jan 30 11:31:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24973 for ; Fri, 30 Jan 2004 11:31:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmbVy-0002PA-4q for v6ops-data@psg.com; Fri, 30 Jan 2004 16:29:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmbVl-0002No-Qi for v6ops@ops.ietf.org; Fri, 30 Jan 2004 16:28:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0UGSqV24928 for ; Fri, 30 Jan 2004 18:28:52 +0200 Date: Fri, 30 Jan 2004 18:28:52 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: transmech implementation & interoperability Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, (co-chair hat on) Even though we cannot go to Draft Standard directly, due to the number of changes, we'd like to start preparing for that even now. To further that end, I've submitted an individual I-D on a possible implementation/interoperability template. It's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-mechv2-interop-impl-template-00.txt I have been extremely attentive to the specification details in the template. This should also provide a checklist for an implementation, collecting all the features specified in the document. Writing this has also helped a lot in being able to eliminate internal inconsistencies and the requirements in the transmech update, so I'd expect it would be very interesting to read to also non-implementers. Feedback would be appreciated, also on the template, and if you have thoughts on the procedure to use to eventually move the document to Draft Standard. Thanks, Pekka From owner-v6ops@ops.ietf.org Fri Jan 30 11:52:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27180 for ; Fri, 30 Jan 2004 11:52:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ambqg-0005ty-Qn for v6ops-data@psg.com; Fri, 30 Jan 2004 16:50:30 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmbqS-0005rz-Vw for v6ops@ops.ietf.org; Fri, 30 Jan 2004 16:50:17 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26871; Fri, 30 Jan 2004 11:50:13 -0500 (EST) Message-Id: <200401301650.LAA26871@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-08.txt Date: Fri, 30 Jan 2004 11:50:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-08.txt Pages : 21 Date : 2004-1-29 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-analysis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-30121058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30121058.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jan 30 12:25:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00498 for ; Fri, 30 Jan 2004 12:25:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmcL8-000BZw-23 for v6ops-data@psg.com; Fri, 30 Jan 2004 17:21:58 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmcKX-000BQd-1V for v6ops@ops.ietf.org; Fri, 30 Jan 2004 17:21:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0UHLJK26377 for ; Fri, 30 Jan 2004 19:21:19 +0200 Date: Fri, 30 Jan 2004 19:21:19 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: I-D ACTION:draft-savola-v6ops-conftun-setup-02.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, The major addition is an inclusion of somekind of comparison with the other mechanisms usable in similar scenarios. Feedback is of course welcome. ---------- Forwarded message ---------- Date: Fri, 30 Jan 2004 11:49:51 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-v6ops-conftun-setup-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP) Author(s) : P. Savola Filename : draft-savola-v6ops-conftun-setup-02.txt Pages : 18 Date : 2004-1-29 This memo describes a set of operational procedures, a UDP encapsulation for configured tunnels, and one implementation mechanism to provide a very simple and straightforward way to easily manage IPv6-over-IPv4 configured tunnels between an ISP and a customer. The configured tunnels work even if the IPv4 addresses change dynamically, or are private addresses; the procedure provides at least a /64 prefix per customer and requires no administrative set-up. NAT traversal is also supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-conftun-setup-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-savola-v6ops-conftun-setup-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-conftun-setup-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.