From owner-v6ops@ops.ietf.org Tue Jun 1 03:57:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03426 for ; Tue, 1 Jun 2004 03:57:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV467-000As4-1q for v6ops-data@psg.com; Tue, 01 Jun 2004 07:54:11 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV465-000ArR-6W for v6ops@ops.ietf.org; Tue, 01 Jun 2004 07:54:09 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13006; Tue, 25 May 2004 15:51:32 -0400 (EDT) Message-Id: <200405251951.PAA13006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-10.txt Date: Tue, 25 May 2004 15:51:32 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_96_XX,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 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-10.txt Pages : 22 Date : 2004-5-25 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM), or Universal Mobile Telecommunications System (UMTS) / Wideband Code Division Multiple Access (WCDMA) technology. 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-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-analysis-10.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-10.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-5-25161324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-25161324.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jun 1 04:46: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 EAA06580 for ; Tue, 1 Jun 2004 04:46:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV4ty-000INU-7V for v6ops-data@psg.com; Tue, 01 Jun 2004 08:45:42 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV4tu-000IMV-Q1 for v6ops@ops.ietf.org; Tue, 01 Jun 2004 08:45:38 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i518jVo01246; Tue, 1 Jun 2004 11:45:31 +0300 (EET DST) X-Scanned: Tue, 1 Jun 2004 11:44:27 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i518iR2Q006585; Tue, 1 Jun 2004 11:44:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00RClRHZ; Tue, 01 Jun 2004 11:42:06 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i518fuH05443; Tue, 1 Jun 2004 11:41:56 +0300 (EET DST) Received: from essat-vlan154-2-224240.ntc.nokia.com ([172.21.224.240]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Jun 2004 11:41:56 +0300 Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt From: "Soininen Jonne (Nokia-NET/Helsinki)" To: "ext Bound, Jim" Cc: ext Pekka Savola , v6ops@ops.ietf.org In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644C22E@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B0644C22E@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Message-Id: <1086079315.9096.5.camel@essat-vlan154-2-224240.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Tue, 01 Jun 2004 11:41:55 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2004 08:41:56.0813 (UTC) FILETIME=[4C026FD0:01C447B4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, (not answering this mail, but the last call in general) I checked the list of comments that the document got and there was a few that result in changes to the document. Could you, please, implement the agreed comments and then we (the chairs) can start pushing the document through to the IESG. Thank you for your efforts! Cheers, Jonne. On Tue, 2004-05-25 at 18:12, ext Bound, Jim wrote: > Of course we will reword/add clarity per the input to make clear network > c scenario. Also realize users are seeing the benefit for cost reasons > to move to IPv6 native networks sooner rather than later and this is > affecting transition planning in process now. But your bias is clear in > all discussion. > > /jim > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim > > Sent: Tuesday, May 25, 2004 10:46 AM > > To: Pekka Savola; rfgraveman@nac.net > > Cc: v6ops@ops.ietf.org > > Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt > > > > This will never be added to this document your out of control > > but thanks for your opinion. You continue to miss the point > > of Native IPv6 deployment. And realize as you say your are > > ONE person here not a GATE to our hard work and efforts to > > work on specifications. To even say that this scenarios is > > unfit in a mail on this honoroable list of highly techncial > > and well informed, long time, engieers, architects and many > > of us who have been implementing, shipping, and deploying > > Ipv6 for many years and you the IETF spec reviewer to say > > that a scenario is unfit when you have nothing more in > > bullets clearly demonstrates your bias and continued denial > > of a deployment model that is not just for defense networks > > but Telcos, Enterprises you don't know anytbing about is > > beyond my comprehension. I am so tired of your biased input > > I am uclear if I can even work with you anymore as one of the > > true leaders and workers of > > IPv6 that does more than sit around and pontificate on specifications. > > It is unfortunate that you are a co-chair of the working > > group with such a bias. > > > > /jim > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > > > Sent: Tuesday, May 25, 2004 2:29 AM > > > To: rfgraveman@nac.net > > > Cc: v6ops@ops.ietf.org > > > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt > > > > > > On Mon, 24 May 2004 rfgraveman@nac.net wrote: > > > > > I think Example network C, a security defense network, is not > > > > > mainstream enough to be applicable to be investigated in the > > > > > scenarios. There are probably 1, 5 or 10 such networks > > > in the world. > > > > > We should be focusing on more common scenarios (even addressing > > > > > "80/20" would be good). [I have a few specific comments for > > > > > clarification within this example, but I'll send them if this > > > > > example is not replaced by something else.] ... > > > > > > > > OTOH, some of these networks are large, and they buy a lot of > > > > equipment, so some major vendors take their requirements quite > > > > seriously. Therefore, I would be against dropping this > > case. We can > > > > discuss further whether this is exactly the right > > > characterization, however. > > > > > > I can see the argument why this needs to be considered .. > > > money is a language everybody understands .. but I'm concerned that > > > this would be painted as a "model" for v6 deployment, i.e., > > that other > > > enterprises which have very little in common with such defense > > > networks would start mimicking their deployment strategies just > > > because those are the ones described in our documents. This is why > > > I'm worried about keeping this here. > > > > > > But let's hear if there are more opinions about this. > > > > > > In any case, if it stays, this could probably be clarified a bit, > > > like: > > > > > > A Security Defense Network Operation: > > > > > > > > > ==> add here something like: > > > > > > Note that these kind of networks are uncommon and unfit to be a > > > model or example for deployment for enterprises in general. > > > However, due to their importance to the vendor community, their > > > requirements should be considered explicitly. > > > > > > ... > > > > > > - External network required at secure specific points. > > > > > > ==> I had hard time parsing this, "at secure"? Did you mean: > > > > > > - External network is required, but only at specific, secure, > > > exit points. > > > > > > ... > > > > > > - Network must be able to absorb ad-hoc creation of > > sub-Networks. > > > > > > ==> I didn't quite understand what this meant, please > > clarify. (I've > > > a hunch, but..) > > > > > > - Entire parts of the Network are completely mobile. > > > > > > ==> are we talking about a mobile network (NEMO sense), or nomadic > > > network (network de-attaches, moves, network > > > re-attaches) ? The latter would at least be feasible, while the > > > former may be a bit more problematic. Maybe worth > > clarifying a bit.. > > > > > > - Network must be able to bolt on to the Internet to share > > > bandwidth as required from Providers. > > > > > > ==> "bolt on to the Internet" ? I wasn't sure what this > > was trying to > > > say -- that the network must be able to multihome for load-sharing > > > purposes, or...? > > > > > > - Nodes must be able to access IPv4 legacy > > applications over IPv6 > > > network. > > > > > > ==> are these internal legacy apps, external ones, or > > possibly both? > > > Isn't this assumptive about IPv6 deployment ("v6-only") and > > unfit for > > > requirements? > > > > > > -- > > > 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 Jun 2 00:29:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23421 for ; Wed, 2 Jun 2004 00:29:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVNKD-000Gkg-O9 for v6ops-data@psg.com; Wed, 02 Jun 2004 04:26:01 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVNKA-000Gjr-By for v6ops@ops.ietf.org; Wed, 02 Jun 2004 04:25:58 +0000 Received: from dfnjgl21 (c-24-1-99-5.client.comcast.net[24.1.99.5]) by comcast.net (rwcrmhc13) with SMTP id <2004060204255201500n7ldne> (Authid: sdawkins@comcast.net); Wed, 2 Jun 2004 04:25:58 +0000 Message-ID: <017801c44859$b457d200$0200a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: , Cc: , , , , , , References: <245DBCAEEC4F074CB77B3F984FF9834F020CE392@esebe005.ntc.nokia.com> Subject: Re: 3GPP Analysis revision -10 (resolving IESG comments) Date: Tue, 1 Jun 2004 23:25:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Juha, Thanks for adding the summary of recommendations up-front. That's got to help! Spencer From: To: Cc: ; ; ; ; ; ; ; Sent: Wednesday, May 26, 2004 2:51 AM Subject: 3GPP Analysis revision -10 (resolving IESG comments) Hi all, I finally managed to compose revision -10 of the 3GPP Analysis document. The draft can be found here: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt The document now *should* resolve IESG discuss comments, the major changes compared to -09 are the following: - summary/recommendations section - IMS scenario 1 text (based on Allison Mankin's text) - I am still a bit unsure about the text... - editorial changes / proofreading done by Spencer Dawkins This is what I wrote in the summary/recommendations section: ------------ This document has analyzed five GPRS and two IMS IPv6 transition scenarios. Numerous 3GPP networks are using private IPv4 addresses today, and introducing IPv6 is an important thing. The two first GPRS scenarios and both IMS scenarios are seen the most relevant. The authors summarize some main recommendations here: - Dual-stack UEs are recommended instead of IPv4-only or IPv6- only UEs. It is important to take care that the applications in the UEs support IPv6. IPv6-only UEs can become feasible when IPv6 is widely deployed in the networks, and most services work on IPv6. - It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. - IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node. - This document strongly recommends the 3GPP operators to deploy basic IPv6 support in their GPRS networks as soon as possible. That makes it possible to lessen the transition effects in the UEs. - A tunneling mechanism in the UE may be needed during the early phases of the IPv6 transition process. A lightweight, automatic tunneling mechanism should be standardized in the IETF. - Tunneling mechanisms can be used in 3GPP networks, and only generic recommendations are given in this document. More details can be found, for example, in [ISP-sa]. - We recommend that a detailed solution for the general SIP/SDP/media IPv4/IPv6 transition problem will be specified as soon as possible as a task within the SIP WGs in the IETF. ----------- Rgds, -Juha W.- From owner-v6ops@ops.ietf.org Wed Jun 2 05:51: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 FAA11296 for ; Wed, 2 Jun 2004 05:51:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVSM4-000CN8-5A for v6ops-data@psg.com; Wed, 02 Jun 2004 09:48:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVSM2-000CMt-36 for v6ops@ops.ietf.org; Wed, 02 Jun 2004 09:48:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i529mDx05476 for ; Wed, 2 Jun 2004 12:48:13 +0300 Date: Wed, 2 Jun 2004 12:48:12 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: New ID-Checklist to replace ID-nits (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) If anyone missed this, please take a look, especially the document editors. In particular, the editors please make sure that your documents include the new RFC3668 boilerplates, which now seem to be required by the IESG. (co-chair hat off) Btw. for those struggling with the tools to use for editing, I can recommend using xml2rc. I can provide a simple template to get started if that helps. There is also work in progress to make such a "starter template" accessible on a prominent web page. ---------- Forwarded message ---------- Date: Thu, 20 May 2004 09:34:26 -0400 From: The IESG To: IETF-Announce: ; Subject: New ID-Checklist to replace ID-nits As you probably all know, we have used the ID-nits for a few years to help you all to prepare your Internet-Drafts such that they will process faster through the AD-review, IETF Last Call and IESG approval process. The name was somewhat wrong in that it is more a serious checklist than merely "nits" (however, there are some nits too). The IESG, RFC-Editor and IANA have evaluated the checklist, and a new (improved) ID-Checklist is now available at http://www.ietf.org/ID-Checklist.html Please help us all by actually CHECKING your Internet-Draft BEFORE you pass it on to your AD and the IESG via a "request to publish". It will help to make the process go faster and reduce the workload on all of us if your document has been checked and complies with the guidance/rules in the ID-Checklist. Thanks, the IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-v6ops@ops.ietf.org Wed Jun 2 06:42: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 GAA14136 for ; Wed, 2 Jun 2004 06:42:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVTAy-000LA6-44 for v6ops-data@psg.com; Wed, 02 Jun 2004 10:40:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVTAw-000L9W-PN for v6ops@ops.ietf.org; Wed, 02 Jun 2004 10:40:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i52AenV06254; Wed, 2 Jun 2004 13:40:49 +0300 Date: Wed, 2 Jun 2004 13:40:49 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, (co-chair hat on) This is the WG Last Call for comments on sending draft-ietf-v6ops-6to4-security-02.txt, "Security Considerations for 6to4" to the IESG for consideration as Informational: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-02.txt Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. The last call will end in 2 weeks, on 16th June. Thanks! From owner-v6ops@ops.ietf.org Wed Jun 2 08:05:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17723 for ; Wed, 2 Jun 2004 08:05:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVUTO-000AS2-0G for v6ops-data@psg.com; Wed, 02 Jun 2004 12:03:58 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVUTL-000AR9-Vm for v6ops@ops.ietf.org; Wed, 02 Jun 2004 12:03:56 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 81148A538; Wed, 2 Jun 2004 08:03:55 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Jun 2004 08:03:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Date: Wed, 2 Jun 2004 08:03:57 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C565@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Thread-Index: AcRHtPVC6dOqAPWRT0efC4px11plzQA5KzbA From: "Bound, Jim" To: "Soininen Jonne (Nokia-NET/Helsinki)" Cc: "ext Pekka Savola" , X-OriginalArrivalTime: 02 Jun 2004 12:03:55.0357 (UTC) FILETIME=[ADA340D0:01C44899] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Jonne, Yes. /jim=20 > -----Original Message----- > From: Soininen Jonne (Nokia-NET/Helsinki)=20 > [mailto:jonne.soininen@nokia.com]=20 > Sent: Tuesday, June 01, 2004 4:42 AM > To: Bound, Jim > Cc: ext Pekka Savola; v6ops@ops.ietf.org > Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt >=20 > Jim, >=20 > (not answering this mail, but the last call in general) >=20 > I checked the list of comments that the document got and=20 > there was a few that result in changes to the document. Could=20 > you, please, implement the agreed comments and then we (the=20 > chairs) can start pushing the document through to the IESG. >=20 > Thank you for your efforts! >=20 > Cheers, >=20 > Jonne. >=20 > On Tue, 2004-05-25 at 18:12, ext Bound, Jim wrote: > > Of course we will reword/add clarity per the input to make clear=20 > > network c scenario. Also realize users are seeing the benefit for=20 > > cost reasons to move to IPv6 native networks sooner rather=20 > than later=20 > > and this is affecting transition planning in process now. But your=20 > > bias is clear in all discussion. > >=20 > > /jim > >=20 > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim > > > Sent: Tuesday, May 25, 2004 10:46 AM > > > To: Pekka Savola; rfgraveman@nac.net > > > Cc: v6ops@ops.ietf.org > > > Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt > > >=20 > > > This will never be added to this document your out of control but=20 > > > thanks for your opinion. You continue to miss the point=20 > of Native=20 > > > IPv6 deployment. And realize as you say your are ONE person here=20 > > > not a GATE to our hard work and efforts to work on=20 > specifications. =20 > > > To even say that this scenarios is unfit in a mail on this=20 > > > honoroable list of highly techncial and well informed, long time,=20 > > > engieers, architects and many of us who have been implementing,=20 > > > shipping, and deploying > > > Ipv6 for many years and you the IETF spec reviewer to say that a=20 > > > scenario is unfit when you have nothing more in bullets clearly=20 > > > demonstrates your bias and continued denial of a deployment model=20 > > > that is not just for defense networks but Telcos, Enterprises you=20 > > > don't know anytbing about is beyond my comprehension. I=20 > am so tired=20 > > > of your biased input I am uclear if I can even work with=20 > you anymore=20 > > > as one of the true leaders and workers of > > > IPv6 that does more than sit around and pontificate on=20 > specifications. > > > It is unfortunate that you are a co-chair of the working=20 > group with=20 > > > such a bias. > > >=20 > > > /jim > > >=20 > > > > -----Original Message----- > > > > From: owner-v6ops@ops.ietf.org > > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > > > > Sent: Tuesday, May 25, 2004 2:29 AM > > > > To: rfgraveman@nac.net > > > > Cc: v6ops@ops.ietf.org > > > > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt > > > >=20 > > > > On Mon, 24 May 2004 rfgraveman@nac.net wrote: > > > > > > I think Example network C, a security defense=20 > network, is not=20 > > > > > > mainstream enough to be applicable to be=20 > investigated in the=20 > > > > > > scenarios. There are probably 1, 5 or 10 such networks > > > > in the world. > > > > > > We should be focusing on more common scenarios (even=20 > > > > > > addressing "80/20" would be good). [I have a few specific=20 > > > > > > comments for clarification within this example, but=20 > I'll send=20 > > > > > > them if this example is not replaced by something else.] ... > > > > >=20 > > > > > OTOH, some of these networks are large, and they buy a lot of=20 > > > > > equipment, so some major vendors take their=20 > requirements quite=20 > > > > > seriously. Therefore, I would be against dropping this > > > case. We can > > > > > discuss further whether this is exactly the right > > > > characterization, however. > > > >=20 > > > > I can see the argument why this needs to be considered ..=20 > > > > money is a language everybody understands .. but I'm concerned=20 > > > > that this would be painted as a "model" for v6 deployment, i.e., > > > that other > > > > enterprises which have very little in common with such defense=20 > > > > networks would start mimicking their deployment strategies just=20 > > > > because those are the ones described in our documents. This is=20 > > > > why I'm worried about keeping this here. > > > >=20 > > > > But let's hear if there are more opinions about this. > > > >=20 > > > > In any case, if it stays, this could probably be=20 > clarified a bit, > > > > like: > > > >=20 > > > > A Security Defense Network Operation: > > > > =20 > > > > =20 > > > > =3D=3D> add here something like: > > > >=20 > > > > Note that these kind of networks are uncommon and=20 > unfit to be a > > > > model or example for deployment for enterprises in=20 > general. =20 > > > > However, due to their importance to the vendor=20 > community, their > > > > requirements should be considered explicitly. > > > >=20 > > > > ... > > > >=20 > > > > - External network required at secure specific points. > > > > =20 > > > > =3D=3D> I had hard time parsing this, "at secure"? Did you = mean: > > > >=20 > > > > - External network is required, but only at=20 > specific, secure,=20 > > > > exit points. > > > > =20 > > > > ... > > > >=20 > > > > - Network must be able to absorb ad-hoc creation of > > > sub-Networks. > > > > =20 > > > > =3D=3D> I didn't quite understand what this meant, please > > > clarify. (I've > > > > a hunch, but..) > > > >=20 > > > > - Entire parts of the Network are completely mobile. > > > > =20 > > > > =3D=3D> are we talking about a mobile network (NEMO sense),=20 > or nomadic=20 > > > > network (network de-attaches, moves, network > > > > re-attaches) ? The latter would at least be feasible,=20 > while the=20 > > > > former may be a bit more problematic. Maybe worth > > > clarifying a bit.. > > > >=20 > > > > - Network must be able to bolt on to the Internet to share > > > > bandwidth as required from Providers. > > > >=20 > > > > =3D=3D> "bolt on to the Internet" ? I wasn't sure what this > > > was trying to > > > > say -- that the network must be able to multihome for=20 > load-sharing=20 > > > > purposes, or...? > > > >=20 > > > > - Nodes must be able to access IPv4 legacy > > > applications over IPv6 > > > > network. > > > >=20 > > > > =3D=3D> are these internal legacy apps, external ones, or > > > possibly both? =20 > > > > Isn't this assumptive about IPv6 deployment ("v6-only") and > > > unfit for > > > > requirements? > > > >=20 > > > > --=20 > > > > Pekka Savola "You each name yourselves=20 > king, yet the > > > > Netcore Oy kingdom bleeds." > > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of=20 > > > > Kings > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jun 2 08:05:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17755 for ; Wed, 2 Jun 2004 08:05:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVUTz-000Adh-0D for v6ops-data@psg.com; Wed, 02 Jun 2004 12:04:35 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVUTx-000Abs-8O for v6ops@ops.ietf.org; Wed, 02 Jun 2004 12:04:33 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C6C144C10; Wed, 2 Jun 2004 08:04:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Jun 2004 08:04:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Date: Wed, 2 Jun 2004 08:04:34 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C566@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Thread-Index: AcRHtPVC6dOqAPWRT0efC4px11plzQA5L8ig From: "Bound, Jim" To: "Soininen Jonne (Nokia-NET/Helsinki)" Cc: "ext Pekka Savola" , X-OriginalArrivalTime: 02 Jun 2004 12:04:32.0619 (UTC) FILETIME=[C3D8FBB0:01C44899] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable And thanks for all the edits and comments I have to assemble all and now do edit. Thanks again, /jim=20 > -----Original Message----- > From: Soininen Jonne (Nokia-NET/Helsinki)=20 > [mailto:jonne.soininen@nokia.com]=20 > Sent: Tuesday, June 01, 2004 4:42 AM > To: Bound, Jim > Cc: ext Pekka Savola; v6ops@ops.ietf.org > Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt >=20 > Jim, >=20 > (not answering this mail, but the last call in general) >=20 > I checked the list of comments that the document got and=20 > there was a few that result in changes to the document. Could=20 > you, please, implement the agreed comments and then we (the=20 > chairs) can start pushing the document through to the IESG. >=20 > Thank you for your efforts! >=20 > Cheers, >=20 > Jonne. >=20 > On Tue, 2004-05-25 at 18:12, ext Bound, Jim wrote: > > Of course we will reword/add clarity per the input to make clear=20 > > network c scenario. Also realize users are seeing the benefit for=20 > > cost reasons to move to IPv6 native networks sooner rather=20 > than later=20 > > and this is affecting transition planning in process now. But your=20 > > bias is clear in all discussion. > >=20 > > /jim > >=20 > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim > > > Sent: Tuesday, May 25, 2004 10:46 AM > > > To: Pekka Savola; rfgraveman@nac.net > > > Cc: v6ops@ops.ietf.org > > > Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt > > >=20 > > > This will never be added to this document your out of control but=20 > > > thanks for your opinion. You continue to miss the point=20 > of Native=20 > > > IPv6 deployment. And realize as you say your are ONE person here=20 > > > not a GATE to our hard work and efforts to work on=20 > specifications. =20 > > > To even say that this scenarios is unfit in a mail on this=20 > > > honoroable list of highly techncial and well informed, long time,=20 > > > engieers, architects and many of us who have been implementing,=20 > > > shipping, and deploying > > > Ipv6 for many years and you the IETF spec reviewer to say that a=20 > > > scenario is unfit when you have nothing more in bullets clearly=20 > > > demonstrates your bias and continued denial of a deployment model=20 > > > that is not just for defense networks but Telcos, Enterprises you=20 > > > don't know anytbing about is beyond my comprehension. I=20 > am so tired=20 > > > of your biased input I am uclear if I can even work with=20 > you anymore=20 > > > as one of the true leaders and workers of > > > IPv6 that does more than sit around and pontificate on=20 > specifications. > > > It is unfortunate that you are a co-chair of the working=20 > group with=20 > > > such a bias. > > >=20 > > > /jim > > >=20 > > > > -----Original Message----- > > > > From: owner-v6ops@ops.ietf.org > > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > > > > Sent: Tuesday, May 25, 2004 2:29 AM > > > > To: rfgraveman@nac.net > > > > Cc: v6ops@ops.ietf.org > > > > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt > > > >=20 > > > > On Mon, 24 May 2004 rfgraveman@nac.net wrote: > > > > > > I think Example network C, a security defense=20 > network, is not=20 > > > > > > mainstream enough to be applicable to be=20 > investigated in the=20 > > > > > > scenarios. There are probably 1, 5 or 10 such networks > > > > in the world. > > > > > > We should be focusing on more common scenarios (even=20 > > > > > > addressing "80/20" would be good). [I have a few specific=20 > > > > > > comments for clarification within this example, but=20 > I'll send=20 > > > > > > them if this example is not replaced by something else.] ... > > > > >=20 > > > > > OTOH, some of these networks are large, and they buy a lot of=20 > > > > > equipment, so some major vendors take their=20 > requirements quite=20 > > > > > seriously. Therefore, I would be against dropping this > > > case. We can > > > > > discuss further whether this is exactly the right > > > > characterization, however. > > > >=20 > > > > I can see the argument why this needs to be considered ..=20 > > > > money is a language everybody understands .. but I'm concerned=20 > > > > that this would be painted as a "model" for v6 deployment, i.e., > > > that other > > > > enterprises which have very little in common with such defense=20 > > > > networks would start mimicking their deployment strategies just=20 > > > > because those are the ones described in our documents. This is=20 > > > > why I'm worried about keeping this here. > > > >=20 > > > > But let's hear if there are more opinions about this. > > > >=20 > > > > In any case, if it stays, this could probably be=20 > clarified a bit, > > > > like: > > > >=20 > > > > A Security Defense Network Operation: > > > > =20 > > > > =20 > > > > =3D=3D> add here something like: > > > >=20 > > > > Note that these kind of networks are uncommon and=20 > unfit to be a > > > > model or example for deployment for enterprises in=20 > general. =20 > > > > However, due to their importance to the vendor=20 > community, their > > > > requirements should be considered explicitly. > > > >=20 > > > > ... > > > >=20 > > > > - External network required at secure specific points. > > > > =20 > > > > =3D=3D> I had hard time parsing this, "at secure"? Did you = mean: > > > >=20 > > > > - External network is required, but only at=20 > specific, secure,=20 > > > > exit points. > > > > =20 > > > > ... > > > >=20 > > > > - Network must be able to absorb ad-hoc creation of > > > sub-Networks. > > > > =20 > > > > =3D=3D> I didn't quite understand what this meant, please > > > clarify. (I've > > > > a hunch, but..) > > > >=20 > > > > - Entire parts of the Network are completely mobile. > > > > =20 > > > > =3D=3D> are we talking about a mobile network (NEMO sense),=20 > or nomadic=20 > > > > network (network de-attaches, moves, network > > > > re-attaches) ? The latter would at least be feasible,=20 > while the=20 > > > > former may be a bit more problematic. Maybe worth > > > clarifying a bit.. > > > >=20 > > > > - Network must be able to bolt on to the Internet to share > > > > bandwidth as required from Providers. > > > >=20 > > > > =3D=3D> "bolt on to the Internet" ? I wasn't sure what this > > > was trying to > > > > say -- that the network must be able to multihome for=20 > load-sharing=20 > > > > purposes, or...? > > > >=20 > > > > - Nodes must be able to access IPv4 legacy > > > applications over IPv6 > > > > network. > > > >=20 > > > > =3D=3D> are these internal legacy apps, external ones, or > > > possibly both? =20 > > > > Isn't this assumptive about IPv6 deployment ("v6-only") and > > > unfit for > > > > requirements? > > > >=20 > > > > --=20 > > > > Pekka Savola "You each name yourselves=20 > king, yet the > > > > Netcore Oy kingdom bleeds." > > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of=20 > > > > Kings > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jun 2 10:44: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 KAA26088 for ; Wed, 2 Jun 2004 10:44:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVWwI-000C2o-OO for v6ops-data@psg.com; Wed, 02 Jun 2004 14:41:58 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVWwH-000C2T-BU for v6ops@ops.ietf.org; Wed, 02 Jun 2004 14:41:57 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i52Efulg068724 for ; Wed, 2 Jun 2004 14:41:56 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i52EftMS157742 for ; Wed, 2 Jun 2004 16:41:55 +0200 Received: from zurich.ibm.com (dhcp23-112.zurich.ibm.com [9.4.23.112]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA24966 for ; Wed, 2 Jun 2004 16:41:55 +0200 Message-ID: <40BDE72F.5060303@zurich.ibm.com> Date: Wed, 02 Jun 2004 16:41:51 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think this is ready to ship. Brian Pekka Savola wrote: > Hi all, > > (co-chair hat on) > > This is the WG Last Call for comments on sending > draft-ietf-v6ops-6to4-security-02.txt, "Security Considerations for > 6to4" to the IESG for consideration as Informational: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-02.txt > > Please review the document carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this > document is ready to go to the IESG. > > The last call will end in 2 weeks, on 16th June. > > Thanks! > > > > From owner-v6ops@ops.ietf.org Wed Jun 2 12:09:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00358 for ; Wed, 2 Jun 2004 12:09:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVYHd-00018C-Bt for v6ops-data@psg.com; Wed, 02 Jun 2004 16:08:05 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVYHb-00017d-SX for v6ops@ops.ietf.org; Wed, 02 Jun 2004 16:08:04 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i52G82WE025634 for ; Wed, 2 Jun 2004 17:08:02 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA21971 for ; Wed, 2 Jun 2004 17:08:00 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i52G80h11710 for v6ops@ops.ietf.org; Wed, 2 Jun 2004 17:08:00 +0100 Date: Wed, 2 Jun 2004 17:08:00 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt Message-ID: <20040602160800.GE7083@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Ready to ship, I agree, and a nice piece of work! Minor nits: - Missing opening bracket on text spanning page 8 bottom split. - Delete 'the' in 'the Section' at start of 4.1.3 - Bottom of 4.3, remove the XXX line - send-ndopt and psreq I-Ds now at draft 5, April 2004 - ISATAP is now at Draft 22 Minor comment: - Should p.15 recommend against using the anycast source address? Do we have field reports of 6to4 abuse to date? (Curious if they are recorded anywhere) It seems many ISPs (NRENs, usually) simply avoid advertising 2002::/16 outside their border, or the IPv4 anycast address outsude their border, to limit their "traffic magnet". I guess this is your model in Section 6.2, but you talk about 2002::/16 limitation, rather than the IPv4 anycast limitation? This is probably why most people see SWITCH's relay ;) While there are enough "third party relays" (as you call them), the closed model still appears to work because of the current traffic levels and available relays like SWITCH's. It's not clear how many recommendations in your (very thorough!) draft are widely implemented - would be very interesting to know... Tim On Wed, Jun 02, 2004 at 01:40:49PM +0300, Pekka Savola wrote: > Hi all, > > (co-chair hat on) > > This is the WG Last Call for comments on sending > draft-ietf-v6ops-6to4-security-02.txt, "Security Considerations for > 6to4" to the IESG for consideration as Informational: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-02.txt > > Please review the document carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this > document is ready to go to the IESG. > > The last call will end in 2 weeks, on 16th June. > > Thanks! > > > From owner-v6ops@ops.ietf.org Thu Jun 3 01:36:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24725 for ; Thu, 3 Jun 2004 01:36:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVkpk-000GPB-Tw for v6ops-data@psg.com; Thu, 03 Jun 2004 05:32:08 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVkpj-000GOk-Ge for v6ops@ops.ietf.org; Thu, 03 Jun 2004 05:32:07 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i535W5v22772; Thu, 3 Jun 2004 08:32:05 +0300 (EET DST) X-Scanned: Thu, 3 Jun 2004 08:31:58 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i535VwBh003648; Thu, 3 Jun 2004 08:31:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 000u5HkY; Thu, 03 Jun 2004 08:31:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i535VtH27646; Thu, 3 Jun 2004 08:31:55 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Jun 2004 08:31:38 +0300 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: New draft: IPv6 Host Configuration of Recursive DNS Server Date: Thu, 3 Jun 2004 08:31:37 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE3D7@esebe005.ntc.nokia.com> Thread-Topic: IPv6 Host Configuration of Recursive DNS Server Thread-Index: AcRJB7WgdazXpx0ASMSxnG9HUoRN4QAIXcJg From: To: , , Cc: X-OriginalArrivalTime: 03 Jun 2004 05:31:38.0054 (UTC) FILETIME=[0AB99660:01C4492C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, (Firstly, my apologies for cross-posting) Forwarding Paul's e-mail also on IPv6, v6ops and dhc lists. Your = comments on the draft are appreciated on the dnsop mailing list = dnsop@lists.uoregon.edu (no cross-posting, please). BR, -Juha W.- -----Original Message----- From: dnsop-v6conf-bounces@nominum.com [mailto:dnsop-v6conf-bounces@nominum.com]On Behalf Of ext Jaehoon Paul Jeong Sent: 03 June, 2004 04:10 To: dnsop@lists.uoregon.edu Cc: IPv6 DNS Configuration Subject: IPv6 Host Configuration of Recursive DNS Server Hello DNSOP members, As you know, a new draft has been published for IPv6 Host Configuration = of DNS Server Information Approaches: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configurati= on-00.txt For a long time, DNS Discovery has been discussed at both IPv6 and DNSOP = working groups. The long discussion seems to be resolved through this draft. In this draft, three approaches are suggested: (a) RA option, (b) DHCPv6 = option, and (c) Well-known anycast addresses for Recursive DNS Servers. We, authors, used "DNS Configuration" instead of "DNS Discovery" because = recursive DNS server address is=20 only configured in IPv6 host, not generating DNS server address like in = IPv6 address autoconfiguration. This draft focuses on describing the attributes of three approaches and = suggesting four applicable scenarios: (a) ISP network, (b) Enterprise network, (c) 3GPP network, (d) Unmanaged = network. Through your review and comments, this will be published as = Informational RFC according to our milestones. IMHO, if necessary, the drafts of two other approaches except DHCPv6 = option will be developed into separate RFCs. Thanks. Paul,=20 IPv6 DNS Configuration Design Team. ------------------------------------------------------ Jaehoon Paul Jeong (Research Engineer) TEL. +82-42-860-1664 Mobile +82-16-711-1765 161 Gajeong-dong Yuseong-gu, Daejeon 305-350, Korea NGI Standardization Research Team/PEC/ETRI Homepage: http://www.adhoc.6ants.net/~paul From owner-v6ops@ops.ietf.org Thu Jun 3 02:33: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 CAA12570 for ; Thu, 3 Jun 2004 02:33:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVllr-000PJ8-91 for v6ops-data@psg.com; Thu, 03 Jun 2004 06:32:11 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVllp-000PIl-Sx; Thu, 03 Jun 2004 06:32:10 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i536W6E15690; Thu, 3 Jun 2004 09:32:06 +0300 (EET DST) X-Scanned: Thu, 3 Jun 2004 09:31:36 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i536VaMg003053; Thu, 3 Jun 2004 09:31:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00DeQBiD; Thu, 03 Jun 2004 09:31:35 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i536VYH23110; Thu, 3 Jun 2004 09:31:34 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Jun 2004 09:31:32 +0300 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: 3GPP Analysis revision -10 (resolving IESG comments) Date: Thu, 3 Jun 2004 09:31:30 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE3D9@esebe005.ntc.nokia.com> Thread-Topic: 3GPP Analysis revision -10 (resolving IESG comments) Thread-Index: AcRC9jw3iHMBKOMKRsecd8eQLcKPMwBzu3RgARtJPOA= From: To: , Cc: , , , , , , , X-OriginalArrivalTime: 03 Jun 2004 06:31:32.0023 (UTC) FILETIME=[68E5BC70:01C44934] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Gabor, I share your concerns...that's why I wrote "I am still a bit unsure = about the text..." in my e-mail. At this point it would be very = important to get comments from Allison (that has suggested text for IMS = scenario 1). Some other comments below: -----Original Message----- From: Bajko Gabor Sent: 28 May, 2004 18:52 A few questions to the text in the draft: In section 4.1 it is written: "... this approach would not take = advantage of SIP's ability to use proxy routing" I can not really see what kind of ability is lost here. What exactly the = authors think it is lost? JW: This is also a point that is unclear for me. Allison, can you = comment? Further down in the same section: "IMS data is time-sensitive ... Alternatives include=20 routing to a transcoder, whose task is to terminate an IPv6 stream=20 and start an IPv4 stream" I failed to understand the advantage of a transcoder to a NAT-PT. Why is = an alternative to process a packet also at application layer when you = can do it at IP layer? Also, time sensitiveness is not always an = issue... JW: Right... Time sensitiviness depends on whether you are using = real-time services or non-real-time (IMS) services. Can Allison clarify = the transcoder point? Then: "The authors=20 recommend that a detailed solution for the general SIP/SDP/media=20 IPv4/IPv6 transition problem will be specified as soon as possible=20 as a task within the SIP WGs in the IETF. " The above statement sounds strange for me. It could be instead said that = this document describes a solution based on SIP-ALG and NAT-PT, and = other solutions might (or might not) become available later. JW: I think that the recommendation to specify a future solution is = valid and the ball clearly goes to the SIPpish wgs. But in *my* opinion, = we also need a higher level solution in this document. If we take the = (SIP-ALG + translator) solution out (or remove details), this document = does not provide much useful information for IMS scen 1...=20 Thanks, -Juha- From owner-v6ops@ops.ietf.org Thu Jun 3 03:33:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16132 for ; Thu, 3 Jun 2004 03:33:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVmgS-0006Oj-IS for v6ops-data@psg.com; Thu, 03 Jun 2004 07:30:40 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVmgR-0006OA-60 for v6ops@ops.ietf.org; Thu, 03 Jun 2004 07:30:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i537Ubd28239; Thu, 3 Jun 2004 10:30:37 +0300 Date: Thu, 3 Jun 2004 10:30:37 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: Agenda items for IETF60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, IETF60 agenda scheduling is approaching. Please send in your requests for agenda items. Please state at least: a) The topic name and the draft name, b) Requested slot duration (how much presentation and discussion?), and c) What is the goal of the agenda item, i.e., what do you want to accomplish. If you have specific items which you would like to see presented (but you would not be presenting them), you can also send feedback to the chairs. You're also encouraged to submit agenda requests for short "operational" presentations of IPv6 deployment or related subjects; we'll try to include one or two of these in the agenda. Thanks, Pekka & Jonne From owner-v6ops@ops.ietf.org Thu Jun 3 03:58: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 DAA17852 for ; Thu, 3 Jun 2004 03:58:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVn5O-0009Lb-2a for v6ops-data@psg.com; Thu, 03 Jun 2004 07:56:26 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVn5D-0009Iq-7z for v6ops@ops.ietf.org; Thu, 03 Jun 2004 07:56:15 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i537uECM012739 for ; Thu, 3 Jun 2004 08:56:14 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA04963 for ; Thu, 3 Jun 2004 08:56:11 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i537u6A20517 for v6ops@ops.ietf.org; Thu, 3 Jun 2004 08:56:06 +0100 Date: Thu, 3 Jun 2004 08:56:06 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt Message-ID: <20040603075606.GF20039@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20040602160800.GE7083@login.ecs.soton.ac.uk> <40BE4C05.2010607@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BE4C05.2010607@iprg.nokia.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Another comment: The example in 6.1 cites compatible addresses. While these are in use, they are being deprecated in draft-ietf-v6ops-mech-v2-02, so I suggest the example is reworked a little and that the reference is to the new draft and not RFC2893 (reference [4]). Tim From owner-v6ops@ops.ietf.org Thu Jun 3 12:36: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 MAA24013 for ; Thu, 3 Jun 2004 12:36:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVv9S-000LG5-1T for v6ops-data@psg.com; Thu, 03 Jun 2004 16:33:10 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVv9R-000LFo-89 for v6ops@ops.ietf.org; Thu, 03 Jun 2004 16:33:09 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i53GX1M06971; Thu, 3 Jun 2004 09:33:01 -0700 X-mProtect: <200406031633> 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 smtpd9bHsen; Thu, 03 Jun 2004 09:33:00 PDT Message-ID: <40BF52C8.7010309@iprg.nokia.com> Date: Thu, 03 Jun 2004 09:33:12 -0700 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: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt References: <20040602160800.GE7083@login.ecs.soton.ac.uk> <40BE4C05.2010607@iprg.nokia.com> <20040603075606.GF20039@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: >Another comment: > >The example in 6.1 cites compatible addresses. While these are in use, >they are being deprecated in draft-ietf-v6ops-mech-v2-02, so I suggest >the example is reworked a little and that the reference is to the new >draft and not RFC2893 (reference [4]). > > I agree with Tim about updating the [MECH] reference, but I was also wondering about when it would be OK for implementations to begin dropping support for IPv4-compatible addresses? I guess there could be several alternative approaches, including: 1) remove the IPv4-compatible address support code completely? 2) leave the code, but surround it with compile-time directives? (default-disabled vs. default-enabled is another decision point) 3) other? I seem to recall seeing some earlier discussion on this, but perhaps there are more current viewpoints based on the extensive scenarios and analysis work done by 'v6ops'? Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Jun 3 16:42: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 QAA13651 for ; Thu, 3 Jun 2004 16:42:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVyzk-0001aZ-SI for v6ops-data@psg.com; Thu, 03 Jun 2004 20:39:24 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVyzj-0001a5-OP for v6ops@ops.ietf.org; Thu, 03 Jun 2004 20:39:23 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08390; Thu, 3 Jun 2004 15:53:18 -0400 (EDT) Message-Id: <200406031953.PAA08390@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-unmaneval-03.txt Date: Thu, 03 Jun 2004 15:53:17 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 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 : Evaluation of Transition Mechanisms for Unmanaged Networks Author(s) : C. Huitema, D.Haskins Filename : draft-ietf-v6ops-unmaneval-03.txt Pages : 18 Date : 2004-6-3 In a companion paper we defined the "unmanaged networks", which typically correspond to home networks or small office networks, and the requirements for transition mechanisms in various scenarios of transition to IPv6. We start from this analysis and evaluate here the suitability of mechanisms that have already been specified, proposed or deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-unmaneval-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-unmaneval-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-3154249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unmaneval-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unmaneval-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-3154249.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jun 3 17:31:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20290 for ; Thu, 3 Jun 2004 17:31:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVzn8-000DiM-39 for v6ops-data@psg.com; Thu, 03 Jun 2004 21:30:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVzn6-000Dgx-CF for v6ops@ops.ietf.org; Thu, 03 Jun 2004 21:30:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i53LTjF12184; Fri, 4 Jun 2004 00:29:45 +0300 Date: Fri, 4 Jun 2004 00:29:45 +0300 (EEST) From: Pekka Savola To: david.kessens@nokia.com cc: bwijnen@lucent.com, , Subject: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk David, On behalf of the v6ops WG, we'd like to request that the following document be published as Informational RFC: Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-03.txt The first WG last call was completed on 26th February. -02 version was published, and a one-week WGLC held which ended on 30th May; only one person responded with minor nits, and those have been fixed in -03. Thanks, Pekka & Jonne v6ops WG co-chairs From owner-v6ops@ops.ietf.org Thu Jun 3 19:33:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09393 for ; Thu, 3 Jun 2004 19:33:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW1gc-000BTc-Gt for v6ops-data@psg.com; Thu, 03 Jun 2004 23:31:50 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW1gb-000BT8-Jj for v6ops@ops.ietf.org; Thu, 03 Jun 2004 23:31:49 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i53NV3A09029; Thu, 3 Jun 2004 16:31:03 -0700 X-mProtect: <200406032331> 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 smtpd2P4m9n; Thu, 03 Jun 2004 16:31:01 PDT Message-ID: <40BFB4C3.6040901@iprg.nokia.com> Date: Thu, 03 Jun 2004 16:31:15 -0700 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: david.kessens@nokia.com, bwijnen@lucent.com, iesg-secretary@ietf.org, v6ops@ops.ietf.org, ftemplin@iprg.nokia.com Subject: Re: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not sure what the procedure is here, but I just noticed that this document fails to mention [ISATAP] as an applicable automatic tunnel mechanism (without NAT traversal) for unmanaged networks. [ISATAP] is needed for host-to-host and host-to-router interactions within unmanaged networks - especially accross bridges, ND proxies, multi-link subnets, etc. Fred L. Templin ftemplin@iprg.nokia.com Pekka Savola wrote: >David, > >On behalf of the v6ops WG, we'd like to request that the following >document be published as Informational RFC: > >Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-03.txt > >The first WG last call was completed on 26th February. -02 version >was published, and a one-week WGLC held which ended on 30th May; >only one person responded with minor nits, and those have been fixed >in -03. > >Thanks, > Pekka & Jonne > v6ops WG co-chairs > > From owner-v6ops@ops.ietf.org Fri Jun 4 05:17: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 FAA23827 for ; Fri, 4 Jun 2004 05:17:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWAm1-0009ry-Kj for v6ops-data@psg.com; Fri, 04 Jun 2004 09:14:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWAm0-0009r3-6g for v6ops@ops.ietf.org; Fri, 04 Jun 2004 09:14:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i549Djf25454; Fri, 4 Jun 2004 12:13:45 +0300 Date: Fri, 4 Jun 2004 12:13:45 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: david.kessens@nokia.com, , Subject: Re: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" In-Reply-To: <40BFB4C3.6040901@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Fred Templin wrote: > Not sure what the procedure is here, but I just noticed that this document > fails to mention [ISATAP] as an applicable automatic tunnel mechanism > (without NAT traversal) for unmanaged networks. > > [ISATAP] is needed for host-to-host and host-to-router interactions > within unmanaged networks - especially accross bridges, ND proxies, > multi-link subnets, etc. (without any hats) Good point -- I don't think ISATAP has been discussed to be used *within* an unmanaged network. I personally think this is probably of very marginal applicability, as the unmanaged networks are very small (typically only one subnet or link), with about one router. Further, the links almost always used inside an unmanaged network are able to support IPv6. So, it would seem that ISATAP might make sense here either if 1) the gateway supported IPv6 but the links wouldn't, or 2) the gateway wouldn't support IPv6, but the nodes in a multi-link unmanaged network would want to use IPv6 between each other. Both cases seem very marginal to me. Hence, I personally don't think it is necessary to include ISATAP here. (Remember that so-called [multi-hop] ad-hoc networks, where this would possibly be more strongly arguable for, were considered out of scope for the v6ops scenarios work, AFAIR.) And since we're already past WG last call(s), this is probably a moot point in any case.. -- 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 Jun 4 05:33: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 FAA24354 for ; Fri, 4 Jun 2004 05:33:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWB3q-000DJL-Pm for v6ops-data@psg.com; Fri, 04 Jun 2004 09:32:26 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWB3n-000DIu-DM for v6ops@ops.ietf.org; Fri, 04 Jun 2004 09:32:23 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i549VrnG005213; Fri, 4 Jun 2004 10:31:53 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA21258; Fri, 4 Jun 2004 10:31:50 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i549Voh12607; Fri, 4 Jun 2004 10:31:50 +0100 Date: Fri, 4 Jun 2004 10:31:50 +0100 From: Tim Chown To: Pekka Savola Cc: Fred Templin , david.kessens@nokia.com, bwijnen@lucent.com, v6ops@ops.ietf.org Subject: Re: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" Message-ID: <20040604093150.GI8111@login.ecs.soton.ac.uk> Mail-Followup-To: Pekka Savola , Fred Templin , david.kessens@nokia.com, bwijnen@lucent.com, v6ops@ops.ietf.org References: <40BFB4C3.6040901@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I was just about to post with pretty much what Pekka said. I would support a comment in the draft saying why ISATAP is not so applicable here (and unmanaged usally implies single link, and no managed networking within the SOHO site). The comment could point to the enterprise analysis where ISATAP (I hope!) will be soundly included as a tool for disparate nodes in a large site. Otherwise the reader may think "but what about ISATAP?". Tim On Fri, Jun 04, 2004 at 12:13:45PM +0300, Pekka Savola wrote: > On Thu, 3 Jun 2004, Fred Templin wrote: > > Not sure what the procedure is here, but I just noticed that this document > > fails to mention [ISATAP] as an applicable automatic tunnel mechanism > > (without NAT traversal) for unmanaged networks. > > > > [ISATAP] is needed for host-to-host and host-to-router interactions > > within unmanaged networks - especially accross bridges, ND proxies, > > multi-link subnets, etc. > > (without any hats) > > Good point -- I don't think ISATAP has been discussed to be used > *within* an unmanaged network. > > I personally think this is probably of very marginal applicability, as > the unmanaged networks are very small (typically only one subnet or > link), with about one router. Further, the links almost always used > inside an unmanaged network are able to support IPv6. > > So, it would seem that ISATAP might make sense here either if > > 1) the gateway supported IPv6 but the links wouldn't, or > > 2) the gateway wouldn't support IPv6, but the nodes in a multi-link > unmanaged network would want to use IPv6 between each other. > > Both cases seem very marginal to me. > > Hence, I personally don't think it is necessary to include ISATAP > here. (Remember that so-called [multi-hop] ad-hoc networks, where > this would possibly be more strongly arguable for, were considered out > of scope for the v6ops scenarios work, AFAIR.) > > And since we're already past WG last call(s), this is probably a moot > point in any case.. > > -- > 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 Jun 4 09:23:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07406 for ; Fri, 4 Jun 2004 09:23:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWEcL-000O4T-Ln for v6ops-data@psg.com; Fri, 04 Jun 2004 13:20:17 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWEcJ-000O3t-Te for v6ops@ops.ietf.org; Fri, 04 Jun 2004 13:20:16 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i54DKA118027; Fri, 4 Jun 2004 16:20:10 +0300 (EET DST) X-Scanned: Fri, 4 Jun 2004 16:18:35 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i54DIZgO030219; Fri, 4 Jun 2004 16:18:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00inZwg4; Fri, 04 Jun 2004 16:18:03 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i54DHvH01861; Fri, 4 Jun 2004 16:17:57 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Jun 2004 16:17:17 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 172.21.154.47 172.21.154.47 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15447.ntc.nokia.com by ESEBE024.noe.nokia.com; 04 Jun 2004 16:17:17 +0300 Subject: Re: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Tim Chown Cc: ext Pekka Savola , Fred Templin , david.kessens@nokia.com, bwijnen@lucent.com, v6ops@ops.ietf.org In-Reply-To: <20040604093150.GI8111@login.ecs.soton.ac.uk> References: <40BFB4C3.6040901@iprg.nokia.com> <20040604093150.GI8111@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1086355036.4828.14.camel@essrv103nok15447.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Fri, 04 Jun 2004 16:17:17 +0300 X-OriginalArrivalTime: 04 Jun 2004 13:17:17.0914 (UTC) FILETIME=[4297A3A0:01C44A36] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody, (chair hat on) there has been a lot of time to comment on this draft (years) and this has not come up. We have concluded that the draft is good enough to go to the IESG and it has been submitted. I don't think this is such an important issue that we would recall the draft from the IESG. However (ok here we go ;), there is always the IETF last-call. Comments can be made to the document during the IETF last-call and you are not too late for that. Summary: If you think this is that important issue in the draft that it really does need changing, you can give the comments during the IETF last-call. (Well, basically everybody can!) Cheers, Jonne. On Fri, 2004-06-04 at 12:31, ext Tim Chown wrote: > I was just about to post with pretty much what Pekka said. > > I would support a comment in the draft saying why ISATAP is not so applicable > here (and unmanaged usally implies single link, and no managed networking > within the SOHO site). The comment could point to the enterprise analysis > where ISATAP (I hope!) will be soundly included as a tool for disparate nodes > in a large site. > > Otherwise the reader may think "but what about ISATAP?". > > Tim > > On Fri, Jun 04, 2004 at 12:13:45PM +0300, Pekka Savola wrote: > > On Thu, 3 Jun 2004, Fred Templin wrote: > > > Not sure what the procedure is here, but I just noticed that this document > > > fails to mention [ISATAP] as an applicable automatic tunnel mechanism > > > (without NAT traversal) for unmanaged networks. > > > > > > [ISATAP] is needed for host-to-host and host-to-router interactions > > > within unmanaged networks - especially accross bridges, ND proxies, > > > multi-link subnets, etc. > > > > (without any hats) > > > > Good point -- I don't think ISATAP has been discussed to be used > > *within* an unmanaged network. > > > > I personally think this is probably of very marginal applicability, as > > the unmanaged networks are very small (typically only one subnet or > > link), with about one router. Further, the links almost always used > > inside an unmanaged network are able to support IPv6. > > > > So, it would seem that ISATAP might make sense here either if > > > > 1) the gateway supported IPv6 but the links wouldn't, or > > > > 2) the gateway wouldn't support IPv6, but the nodes in a multi-link > > unmanaged network would want to use IPv6 between each other. > > > > Both cases seem very marginal to me. > > > > Hence, I personally don't think it is necessary to include ISATAP > > here. (Remember that so-called [multi-hop] ad-hoc networks, where > > this would possibly be more strongly arguable for, were considered out > > of scope for the v6ops scenarios work, AFAIR.) > > > > And since we're already past WG last call(s), this is probably a moot > > point in any case.. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Fri Jun 4 14:55:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00609 for ; Fri, 4 Jun 2004 14:55:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWJoA-000270-0w for v6ops-data@psg.com; Fri, 04 Jun 2004 18:52:50 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWJo8-00026E-NC for v6ops@ops.ietf.org; Fri, 04 Jun 2004 18:52:48 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i54IqWZ29959; Fri, 4 Jun 2004 11:52:32 -0700 X-mProtect: <200406041852> 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 smtpdV6qxOr; Fri, 04 Jun 2004 11:52:30 PDT Message-ID: <40C0C501.6030101@iprg.nokia.com> Date: Fri, 04 Jun 2004 11:52:49 -0700 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: david.kessens@nokia.com, bwijnen@lucent.com, v6ops@ops.ietf.org Subject: Re: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, Pekka Savola wrote: >On Thu, 3 Jun 2004, Fred Templin wrote: > > >>Not sure what the procedure is here, but I just noticed that this document >>fails to mention [ISATAP] as an applicable automatic tunnel mechanism >>(without NAT traversal) for unmanaged networks. >> >>[ISATAP] is needed for host-to-host and host-to-router interactions >>within unmanaged networks - especially accross bridges, ND proxies, >>multi-link subnets, etc. >> >> > >(without any hats) > >Good point -- I don't think ISATAP has been discussed to be used >*within* an unmanaged network. > Inserting more careful phrasing, I believe there may be two aspects of the question to consider: 1) Near-term implications for connecting hosts and routers within an unmanaged network using [ISATAP]. 2) Somewhat longer-term implications for connecting hosts within an unmanaged network to hosts/routers in the Internet using [ISATAP] over a virtual link extended via ND Proxy, multi-link subnet, hybrid bridge/router, etc. (i.e., with no "traditional" NAT traversal needed). The phrasing in my original message appears to have focused your reply on 1) only, which I think is fine for now since it seems to be the proper scope for the current analysis in [unmaneval-03]. >I personally think this is probably of very marginal applicability, as >the unmanaged networks are very small (typically only one subnet or >link), with about one router. Further, the links almost always used >inside an unmanaged network are able to support IPv6. > >So, it would seem that ISATAP might make sense here either if > >1) the gateway supported IPv6 but the links wouldn't, or > >2) the gateway wouldn't support IPv6, but the nodes in a multi-link >unmanaged network would want to use IPv6 between each other. > > I am not an expert in the unamanged network transition space, but it seems that we are beginning to see heterogeneous link technologies in home/SOHO applications that are not easily bridged. ([unmaneval-03], sections 4.1.1 and 7) provide good analysis and recommendations on extending a subnet to span multiple links, but provide no guidance on mechanisms to connect nodes accross such an extended subnet when link technologies with disparate MAC address formats and/or link MTUs are included. Both of these conditions could be mitigated by IPv6-in-IPv4 encapsulation using ISATAP, but this is not currently stated in the document. >Both cases seem very marginal to me. > Well again, I am no expert, but from a recent trip to Fry's (our local electronics mega-store) it seems that general-purpose computers are now providing features like Digitial Video Recording that were once implemented only in set-top boxes, and home electronics like TV's, cameras, DVDs, etc. are now providing LAN-like interconnects (e.g., IEEE 1394) that were once used only by computers. So, it seems like we may be on the near-term cusp of a fusion of technologies and interconnects within the unmanaged realm that may not be so marginal after all. >Hence, I personally don't think it is necessary to include ISATAP >here. (Remember that so-called [multi-hop] ad-hoc networks, where >this would possibly be more strongly arguable for, were considered out >of scope for the v6ops scenarios work, AFAIR.) > I agree that there is no need to visit the multi-hop ad-hoc paradigm to identify potential near-term use cases. >And since we're already past WG last call(s), this is probably a moot >point in any case... > I'm not so sure; ([unmaneval-03], sections 4.1.1 and 7) give analysis and recommendations on how to _extend_ a subnet to span multiple links but no analysis and recommendations on mechanisms that nodes can use to _traverse_ such an extended subnet. I believe ISATAP fits this space for the near-term at least, with potential for wider applicability in the somewhat longer term as described above. Also FYI, there appears to be a typo in: ([unmaneval-03], section 5), first sentence of the 2nd paragraph. Here, it seems like "case B" should be changed to: "case C". Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Jun 4 15:20:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04478 for ; Fri, 4 Jun 2004 15:20:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWKE5-0007PJ-7S for v6ops-data@psg.com; Fri, 04 Jun 2004 19:19:37 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWKE3-0007Oq-To for v6ops@ops.ietf.org; Fri, 04 Jun 2004 19:19:35 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i54JJ9f02812; Fri, 4 Jun 2004 12:19:09 -0700 X-mProtect: <200406041919> 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 smtpdKPuQpk; Fri, 04 Jun 2004 12:19:08 PDT Message-ID: <40C0CB3F.1020802@iprg.nokia.com> Date: Fri, 04 Jun 2004 12:19:27 -0700 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: Tim Chown CC: Pekka Savola , david.kessens@nokia.com, bwijnen@lucent.com, v6ops@ops.ietf.org Subject: Re: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" References: <40BFB4C3.6040901@iprg.nokia.com> <20040604093150.GI8111@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tim, Tim Chown wrote: >I was just about to post with pretty much what Pekka said. > OK. I just replied to Pekka's message on this. >I would support a comment in the draft saying why ISATAP is not so applicable >here (and unmanaged usally implies single link, and no managed networking >within the SOHO site). > Well, based on my message to Pekka I believe there may be some near-term applicability and also somewhat longer term applicability to be considered for the unmanaged case. (We have also seen the near-term need for a simple host-router mechanism in the 3GPP case, and ISATAP has been mentioned as a candidate there.) >The comment could point to the enterprise analysis >where ISATAP (I hope!) will be soundly included as a tool for disparate nodes >in a large site. > I agree that ISATAP seems like a natual fit for the enterprise, so I believe I can speak for my co-authors in saying that we intend to continue to pursue standards-track status for ISATAP over the somewhat longer term, e.g., as the enterprise analysis evolves. >Otherwise the reader may think "but what about ISATAP?". > Agreed. Fred ftemplin@iprg.nokia.com >Tim > >On Fri, Jun 04, 2004 at 12:13:45PM +0300, Pekka Savola wrote: > > >>On Thu, 3 Jun 2004, Fred Templin wrote: >> >> >>>Not sure what the procedure is here, but I just noticed that this document >>>fails to mention [ISATAP] as an applicable automatic tunnel mechanism >>>(without NAT traversal) for unmanaged networks. >>> >>>[ISATAP] is needed for host-to-host and host-to-router interactions >>>within unmanaged networks - especially accross bridges, ND proxies, >>>multi-link subnets, etc. >>> >>> >>(without any hats) >> >>Good point -- I don't think ISATAP has been discussed to be used >>*within* an unmanaged network. >> >>I personally think this is probably of very marginal applicability, as >>the unmanaged networks are very small (typically only one subnet or >>link), with about one router. Further, the links almost always used >>inside an unmanaged network are able to support IPv6. >> >>So, it would seem that ISATAP might make sense here either if >> >>1) the gateway supported IPv6 but the links wouldn't, or >> >>2) the gateway wouldn't support IPv6, but the nodes in a multi-link >>unmanaged network would want to use IPv6 between each other. >> >>Both cases seem very marginal to me. >> >>Hence, I personally don't think it is necessary to include ISATAP >>here. (Remember that so-called [multi-hop] ad-hoc networks, where >>this would possibly be more strongly arguable for, were considered out >>of scope for the v6ops scenarios work, AFAIR.) >> >>And since we're already past WG last call(s), this is probably a moot >>point in any case.. >> >>-- >>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 Jun 4 15:29: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 PAA05051 for ; Fri, 4 Jun 2004 15:29:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWKMn-0009F5-Dm for v6ops-data@psg.com; Fri, 04 Jun 2004 19:28:37 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWKMm-0009ER-67 for v6ops@ops.ietf.org; Fri, 04 Jun 2004 19:28:36 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i54JS8D16383; Fri, 4 Jun 2004 12:28:08 -0700 X-mProtect: <200406041928> 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 smtpdFd7rQc; Fri, 04 Jun 2004 12:28:06 PDT Message-ID: <40C0CD5A.5010708@iprg.nokia.com> Date: Fri, 04 Jun 2004 12:28:26 -0700 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: "Soininen Jonne (Nokia-NET/Helsinki)" CC: ext Tim Chown , ext Pekka Savola , david.kessens@nokia.com, bwijnen@lucent.com, v6ops@ops.ietf.org Subject: Re: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" References: <40BFB4C3.6040901@iprg.nokia.com> <20040604093150.GI8111@login.ecs.soton.ac.uk> <1086355036.4828.14.camel@essrv103nok15447.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Jonne, for explaining the pragmatic aspects of this 11th-hour input. Fred ftemplin@iprg.nokia.com Soininen Jonne (Nokia-NET/Helsinki) wrote: >Hello everybody, > >(chair hat on) >there has been a lot of time to comment on this draft (years) and this >has not come up. We have concluded that the draft is good enough to go >to the IESG and it has been submitted. I don't think this is such an >important issue that we would recall the draft from the IESG. > >However (ok here we go ;), there is always the IETF last-call. Comments >can be made to the document during the IETF last-call and you are not >too late for that. > >Summary: If you think this is that important issue in the draft that it >really does need changing, you can give the comments during the IETF >last-call. (Well, basically everybody can!) > >Cheers, > >Jonne. > >On Fri, 2004-06-04 at 12:31, ext Tim Chown wrote: > > >>I was just about to post with pretty much what Pekka said. >> >>I would support a comment in the draft saying why ISATAP is not so applicable >>here (and unmanaged usally implies single link, and no managed networking >>within the SOHO site). The comment could point to the enterprise analysis >>where ISATAP (I hope!) will be soundly included as a tool for disparate nodes >>in a large site. >> >>Otherwise the reader may think "but what about ISATAP?". >> >>Tim >> >>On Fri, Jun 04, 2004 at 12:13:45PM +0300, Pekka Savola wrote: >> >> >>>On Thu, 3 Jun 2004, Fred Templin wrote: >>> >>> >>>>Not sure what the procedure is here, but I just noticed that this document >>>>fails to mention [ISATAP] as an applicable automatic tunnel mechanism >>>>(without NAT traversal) for unmanaged networks. >>>> >>>>[ISATAP] is needed for host-to-host and host-to-router interactions >>>>within unmanaged networks - especially accross bridges, ND proxies, >>>>multi-link subnets, etc. >>>> >>>> >>>(without any hats) >>> >>>Good point -- I don't think ISATAP has been discussed to be used >>>*within* an unmanaged network. >>> >>>I personally think this is probably of very marginal applicability, as >>>the unmanaged networks are very small (typically only one subnet or >>>link), with about one router. Further, the links almost always used >>>inside an unmanaged network are able to support IPv6. >>> >>>So, it would seem that ISATAP might make sense here either if >>> >>>1) the gateway supported IPv6 but the links wouldn't, or >>> >>>2) the gateway wouldn't support IPv6, but the nodes in a multi-link >>>unmanaged network would want to use IPv6 between each other. >>> >>>Both cases seem very marginal to me. >>> >>>Hence, I personally don't think it is necessary to include ISATAP >>>here. (Remember that so-called [multi-hop] ad-hoc networks, where >>>this would possibly be more strongly arguable for, were considered out >>>of scope for the v6ops scenarios work, AFAIR.) >>> >>>And since we're already past WG last call(s), this is probably a moot >>>point in any case.. >>> >>>-- >>>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 Jun 4 20:51:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00187 for ; Fri, 4 Jun 2004 20:51:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWPMa-0009T8-QP for v6ops-data@psg.com; Sat, 05 Jun 2004 00:48:44 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWPMZ-0009SU-GJ for v6ops@ops.ietf.org; Sat, 05 Jun 2004 00:48:43 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i550mYS21846; Fri, 4 Jun 2004 17:48:34 -0700 X-mProtect: <200406050048> 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 smtpdXHTkTc; Fri, 04 Jun 2004 17:48:33 PDT Message-ID: <40C11875.6030204@iprg.nokia.com> Date: Fri, 04 Jun 2004 17:48:53 -0700 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: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Going back to a note from several weeks ago, I was wondering if there was any new status to report on the open issues for mech-v2-02. e.g., are the authors maintaing an issue tracker page somewhere? Speaking of the authors, I was wondering if the second author (Bob Gilligan) has been active in the MECH(bis) effort, since it has been some time since I have seen any messages from him on the mailing lists. I am well aware that Bob has made significant past contributions that should be properly honored, but I was wondering what the policy is here? (I.e., will the MECH(bis) document be allowed to advance w/o Bob's active involvement?) Thanks - Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >Hi, > >(co-chair hat on) > >IESG has evaluated draft-ietf-v6ops-mech-v2-02.txt and the comments >are available at the I-D tracker, a direct link: >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1250&filename=draft-ietf-v6ops-mech-v2 > >I'm collecting the most important ones here for feedback and opinions. >I've followed up with most ADs for clarification, and I'm excluding >the trivial issues, misunderstandings, etc. > >Issues 1) and 2) are the most important ones, and I'd appreciate >comments from the WG on those at least. > >1) section 2.2 on DNS result ordering/filtering seems to be considered >inappropriately short, and it would be better to just refer to the >default address selection RFC3484. (Margaret Wasserman). Filtering is >inappropriate (Ted Hardie and Scott Hollenbeck). > >==> possibilities include at least: > a) keeping the current tense of specifying a "simple" address > selection, and referring to RFC3484 for more details, but reword > the text appropriately. Remove filtering but keep ordering. It > might require some convincing to make the IESG accept this > approach. (In other words, a simple dual-stack implementation would > not necessarily have to implement RFC3484 to be > compliant/interoperable with this spec.) > b) remove most of the text, referring to RFC3484. Note that RFC3484 > is PS, and we could not advance to DS if we did that. (In other > words, all the dual-stack implementations compliant with this spec > would also have to implement RFC3484.) > >2) the document appears to say, "just use IPsec", without giving >sufficient details how to do it inappropriately. (Steve Bellovin) > >==> possibilities include at least: > a) adding some detail here how to set up the SA's > b) removing all the references to IPsec and hoping that security AD's > don't cry out. > c) defer to a future document to be written about the details of > secure v6-in-v4 tunneling; this has already started a month ago, > but hasn't produced a -00 draft yet. > >3) security considerations describing isolating different tunnels and >interfaces from each other seems to forbid the implementation >technique of point-to-multipoint (and more, multipoint-to-point) >tunnels. (Alex Zinin) > >==> this is intentional, as we removed automatic tunneling from the >spec, but should probably be spelled out. All the configured tunnels >are expected to be point-to-point. > >4) the spec might consider whether the tunnel end-point is resolvable; >if not, take the tunnel down. (Alex Zinin) > >==> I already agreed with Alex that this is a can full of worms, even >if it's useful, and not something we should open here unless people >insist. (The "resolvability" check is quite non-trivial when you have >e.g., default or aggregate routes in your routing table.) > >5) the doc needs to mention dual-stack security considerations. >(Jon Peterson) > >==> I already agreed with Jon that spelling these out here would be >out of scope, and we'll just defer to another document, >draft-savola-v6ops-security-overview-02.txt, for that (just like for >3GPP analysis doc) > > > > > > From owner-v6ops@ops.ietf.org Sat Jun 5 02:18: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 CAA25988 for ; Sat, 5 Jun 2004 02:18:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWUTN-000Ehw-Ir for v6ops-data@psg.com; Sat, 05 Jun 2004 06:16:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWUTL-000EhQ-IK for v6ops@ops.ietf.org; Sat, 05 Jun 2004 06:16:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i556FxO17949; Sat, 5 Jun 2004 09:15:59 +0300 Date: Sat, 5 Jun 2004 09:15:59 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt In-Reply-To: <40C11875.6030204@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, 4 Jun 2004, Fred Templin wrote: > Going back to a note from several weeks ago, I was wondering if there > was any new status to report on the open issues for mech-v2-02. e.g., > are the authors maintaing an issue tracker page somewhere? Speaking > of the authors, I was wondering if the second author (Bob Gilligan) > has been active in the MECH(bis) effort, since it has been some time > since I have seen any messages from him on the mailing lists. Unfortunately, there is no issue tracker; the issues are described briefly in the 3 week old mail. The most issues are noted below. Additionally, there have been some clarifications on the ingress filtering language. The status is that we're in the process of doing two things: 1) Discussing with Margaret on her requirement that the DNS ordering text be removed, to be replaced with a normative reference to RFC3484, blocking the move to Draft Standard. Erik and I disagree with that approach, and are trying to convince her. 2) Waiting for the submission of an informational document describing how to build secure IPsec v6-in-v4 tunnels. I can send you an edited "working copy" off-list if you're interested; in any case, the draft will probably be posted on the list for short review before moving forward. > I am well aware that Bob has made significant past contributions > that should be properly honored, but I was wondering what the > policy is here? (I.e., will the MECH(bis) document be allowed > to advance w/o Bob's active involvement?) I'm not sure of the policy either, but for most documents, the old authors seem to be kept in even if they don't contribute. Advancement will not be a problem; WG chairs and/or ADs can approve a document at RFC-editor's AUTH48 even if the authors don't respond. > >(co-chair hat on) > > > >IESG has evaluated draft-ietf-v6ops-mech-v2-02.txt and the comments > >are available at the I-D tracker, a direct link: > >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1250&filename=draft-ietf-v6ops-mech-v2 > > > >I'm collecting the most important ones here for feedback and opinions. > >I've followed up with most ADs for clarification, and I'm excluding > >the trivial issues, misunderstandings, etc. > > > >Issues 1) and 2) are the most important ones, and I'd appreciate > >comments from the WG on those at least. > > > >1) section 2.2 on DNS result ordering/filtering seems to be considered > >inappropriately short, and it would be better to just refer to the > >default address selection RFC3484. (Margaret Wasserman). Filtering is > >inappropriate (Ted Hardie and Scott Hollenbeck). > > > >==> possibilities include at least: > > a) keeping the current tense of specifying a "simple" address > > selection, and referring to RFC3484 for more details, but reword > > the text appropriately. Remove filtering but keep ordering. It > > might require some convincing to make the IESG accept this > > approach. (In other words, a simple dual-stack implementation would > > not necessarily have to implement RFC3484 to be > > compliant/interoperable with this spec.) > > b) remove most of the text, referring to RFC3484. Note that RFC3484 > > is PS, and we could not advance to DS if we did that. (In other > > words, all the dual-stack implementations compliant with this spec > > would also have to implement RFC3484.) > > > >2) the document appears to say, "just use IPsec", without giving > >sufficient details how to do it inappropriately. (Steve Bellovin) > > > >==> possibilities include at least: > > a) adding some detail here how to set up the SA's > > b) removing all the references to IPsec and hoping that security AD's > > don't cry out. > > c) defer to a future document to be written about the details of > > secure v6-in-v4 tunneling; this has already started a month ago, > > but hasn't produced a -00 draft yet. > > > >3) security considerations describing isolating different tunnels and > >interfaces from each other seems to forbid the implementation > >technique of point-to-multipoint (and more, multipoint-to-point) > >tunnels. (Alex Zinin) > > > >==> this is intentional, as we removed automatic tunneling from the > >spec, but should probably be spelled out. All the configured tunnels > >are expected to be point-to-point. > > > >4) the spec might consider whether the tunnel end-point is resolvable; > >if not, take the tunnel down. (Alex Zinin) > > > >==> I already agreed with Alex that this is a can full of worms, even > >if it's useful, and not something we should open here unless people > >insist. (The "resolvability" check is quite non-trivial when you have > >e.g., default or aggregate routes in your routing table.) > > > >5) the doc needs to mention dual-stack security considerations. > >(Jon Peterson) > > > >==> I already agreed with Jon that spelling these out here would be > >out of scope, and we'll just defer to another document, > >draft-savola-v6ops-security-overview-02.txt, for that (just like for > >3GPP analysis doc) > > > > > > > > > > > > > > -- 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 Jun 7 00:16:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06074 for ; Mon, 7 Jun 2004 00:16:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXBS3-000Ege-BQ for v6ops-data@psg.com; Mon, 07 Jun 2004 04:09:35 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXBS2-000Eg8-87 for v6ops@ops.ietf.org; Mon, 07 Jun 2004 04:09:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i5749UW4018865; Mon, 7 Jun 2004 04:09:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i5749U4I018862; Mon, 7 Jun 2004 04:09:30 GMT Date: Mon, 7 Jun 2004 04:09:30 +0000 From: bmanning@vacation.karoshi.com To: dnsop-v6conf@nominum.com Cc: dnsop@lists.uoregon.edu, V6OPS WG , DHC WG , IPv6 WG Subject: Re: IPv6 Host Configuration of Recursive DNS Server Message-ID: <20040607040930.GA18426@vacation.karoshi.com.> References: <006d01c44907$92d5a450$c470fe81@etri.re.kr> <004b01c4492d$08626a80$c470fe81@etri.re.kr> <005801c44c43$77d40540$c470fe81@etri.re.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005801c44c43$77d40540$c470fe81@etri.re.kr> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk No. It means: ) there have been over 100 new drafts released ) there are a number of concerns with the approaches taken that have been rasied in past mtgs that are not mentioned or addressed And ... most folks have day jobs that are -not- related to this specific issue. --bill On Mon, Jun 07, 2004 at 12:56:50PM +0900, Jaehoon Paul Jeong wrote: > Hi all, > > For 1 week, there have been no comments on our IPv6 DNS Configuraion. > http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft-ietf-dnsop-ipv6-dns-configuration-00.txt > > Does it mean that there is no problem about this draft and it is ok to request WGLC? :-) > > Paul > > ----- Original Message ----- > From: "Jaehoon Paul Jeong" > To: > Cc: "IPv6 DNS Configuration" > Sent: Thursday, June 03, 2004 2:38 PM > Subject: Re: IPv6 Host Configuration of Recursive DNS Server > > > > There is some problem of column alignment at our draft. > > You can find a fixed version at the following site: > > http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft-ietf-dnsop-ipv6-dns-configuration-00.txt > > > > Thanks. > > > > Paul > > > > ----- Original Message ----- > > From: "Jaehoon Paul Jeong" > > To: > > Cc: "IPv6 DNS Configuration" > > Sent: Thursday, June 03, 2004 10:10 AM > > Subject: IPv6 Host Configuration of Recursive DNS Server > > > > > > > Hello DNSOP members, > > > > > > As you know, a new draft has been published for IPv6 Host Configuration of DNS Server Information Approaches: > > > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configuration-00.txt > > > > > > For a long time, DNS Discovery has been discussed at both IPv6 and DNSOP working groups. > > > The long discussion seems to be resolved through this draft. > > > > > > In this draft, three approaches are suggested: (a) RA option, (b) DHCPv6 option, and > > > (c) Well-known anycast addresses for Recursive DNS Servers. > > > We, authors, used "DNS Configuration" instead of "DNS Discovery" because recursive DNS server address is > > > only configured in IPv6 host, not generating DNS server address like in IPv6 address autoconfiguration. > > > > > > This draft focuses on describing the attributes of three approaches and suggesting four applicable scenarios: > > > (a) ISP network, (b) Enterprise network, (c) 3GPP network, (d) Unmanaged network. > > > > > > Through your review and comments, this will be published as Informational RFC according to our milestones. > > > IMHO, if necessary, the drafts of two other approaches except DHCPv6 option will be developed into separate RFCs. > > > > > > Thanks. > > > > > > Paul, > > > IPv6 DNS Configuration Design Team. > > > > > > ------------------------------------------------------ > > > Jaehoon Paul Jeong (Research Engineer) > > > TEL. +82-42-860-1664 > > > Mobile +82-16-711-1765 > > > 161 Gajeong-dong Yuseong-gu, Daejeon 305-350, Korea > > > NGI Standardization Research Team/PEC/ETRI > > > Homepage: http://www.adhoc.6ants.net/~paul > > > > > From owner-v6ops@ops.ietf.org Mon Jun 7 00:30:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06721 for ; Mon, 7 Jun 2004 00:30:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXBkF-000I68-IJ for v6ops-data@psg.com; Mon, 07 Jun 2004 04:28:23 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXBkC-000I5j-Gv for v6ops@ops.ietf.org; Mon, 07 Jun 2004 04:28:20 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 6 Jun 2004 21:28:19 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sun, 6 Jun 2004 21:28:36 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 06 Jun 2004 21:28:19 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 6 Jun 2004 21:28:30 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 6 Jun 2004 21:28:18 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 6 Jun 2004 21:28:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Host Configuration of Recursive DNS Server Date: Sun, 6 Jun 2004 21:28:14 -0700 Message-ID: Thread-Topic: IPv6 Host Configuration of Recursive DNS Server Thread-Index: AcRMRYQUVUKEAKHKQkWMfI6c5EYsCgAAaPiw From: "Christian Huitema" To: "Jaehoon Paul Jeong" , Cc: "V6OPS WG" , "DHC WG" , "IPv6 DNS Configuration" , "IPv6 WG" X-OriginalArrivalTime: 07 Jun 2004 04:28:36.0546 (UTC) FILETIME=[E66C4220:01C44C47] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Two points: 1) In the disadvantage of DHCPv6 section, you ought to mention that there is a ensure that the DHCP server always returns an up-to-date value for the address of the preferred recursive DNS server. In large networks, this is not trivial: the notion of which server is closest depends on routing configuration and on server status, all of which are dynamic. In contrast, the anycast approach guarantees that the request will reach the closest server. 2) In the unmanaged case, you wrongly assume that case C is "like case A". In fact, it is more like case B: if a gateway provides IPv6 connectivity by managing tunnels, then it is also supposed to provide access to a recursive DNS server. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Jaehoon Paul Jeong > Sent: Sunday, June 06, 2004 8:57 PM > To: dnsop@lists.uoregon.edu > Cc: V6OPS WG; DHC WG; IPv6 DNS Configuration; IPv6 WG > Subject: Re: IPv6 Host Configuration of Recursive DNS Server >=20 > Hi all, >=20 > For 1 week, there have been no comments on our IPv6 DNS Configuraion. > http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft- > ietf-dnsop-ipv6-dns-configuration-00.txt >=20 > Does it mean that there is no problem about this draft and it is ok to > request WGLC? :-) >=20 > Paul >=20 > ----- Original Message ----- > From: "Jaehoon Paul Jeong" > To: > Cc: "IPv6 DNS Configuration" > Sent: Thursday, June 03, 2004 2:38 PM > Subject: Re: IPv6 Host Configuration of Recursive DNS Server >=20 >=20 > > There is some problem of column alignment at our draft. > > You can find a fixed version at the following site: > > http://www.adhoc.6ants.net/~paul/publications/ietf-internet- > draft/draft-ietf-dnsop-ipv6-dns-configuration-00.txt > > > > Thanks. > > > > Paul > > > > ----- Original Message ----- > > From: "Jaehoon Paul Jeong" > > To: > > Cc: "IPv6 DNS Configuration" > > Sent: Thursday, June 03, 2004 10:10 AM > > Subject: IPv6 Host Configuration of Recursive DNS Server > > > > > > > Hello DNSOP members, > > > > > > As you know, a new draft has been published for IPv6 Host > Configuration of DNS Server Information Approaches: > > > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns- > configuration-00.txt > > > > > > For a long time, DNS Discovery has been discussed at both IPv6 and > DNSOP working groups. > > > The long discussion seems to be resolved through this draft. > > > > > > In this draft, three approaches are suggested: (a) RA option, (b) > DHCPv6 option, and > > > (c) Well-known anycast addresses for Recursive DNS Servers. > > > We, authors, used "DNS Configuration" instead of "DNS Discovery" > because recursive DNS server address is > > > only configured in IPv6 host, not generating DNS server address like > in IPv6 address autoconfiguration. > > > > > > This draft focuses on describing the attributes of three approaches > and suggesting four applicable scenarios: > > > (a) ISP network, (b) Enterprise network, (c) 3GPP network, (d) > Unmanaged network. > > > > > > Through your review and comments, this will be published as > Informational RFC according to our milestones. > > > IMHO, if necessary, the drafts of two other approaches except DHCPv6 > option will be developed into separate RFCs. > > > > > > Thanks. > > > > > > Paul, > > > IPv6 DNS Configuration Design Team. > > > > > > ------------------------------------------------------ > > > Jaehoon Paul Jeong (Research Engineer) > > > TEL. +82-42-860-1664 > > > Mobile +82-16-711-1765 > > > 161 Gajeong-dong Yuseong-gu, Daejeon 305-350, Korea > > > NGI Standardization Research Team/PEC/ETRI > > > Homepage: http://www.adhoc.6ants.net/~paul > > > > > From owner-v6ops@ops.ietf.org Mon Jun 7 20:06: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 UAA04131 for ; Mon, 7 Jun 2004 20:06:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXU5C-000Dqm-Qw for v6ops-data@psg.com; Tue, 08 Jun 2004 00:03:14 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXU5A-000Dp2-Ni for v6ops@ops.ietf.org; Tue, 08 Jun 2004 00:03:12 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i58033b16334; Mon, 7 Jun 2004 17:03:03 -0700 X-mProtect: <200406080003> 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 smtpdQSy1dI; Mon, 07 Jun 2004 17:03:01 PDT Message-ID: <40C50233.3000609@iprg.nokia.com> Date: Mon, 07 Jun 2004 17:02:59 -0700 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: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, IMO, the MECH(bis) effort has crept along at a snail's pace for the better part of the past two years, and I don't see it as fair or reasonable to blame others for that. Although I would be equally unsurprised if MECH(bis) were published tomorrow or if it were still creeping along two years from now, the one thing I think we can count on is that we can't count on publication by any specific date. Unfortunately, I was unable to find any assurances in your message that would change my opinion in that regard. Thanks - Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >Hi, > >On Fri, 4 Jun 2004, Fred Templin wrote: > > >>Going back to a note from several weeks ago, I was wondering if there >>was any new status to report on the open issues for mech-v2-02. e.g., >>are the authors maintaing an issue tracker page somewhere? Speaking >>of the authors, I was wondering if the second author (Bob Gilligan) >>has been active in the MECH(bis) effort, since it has been some time >>since I have seen any messages from him on the mailing lists. >> >> > >Unfortunately, there is no issue tracker; the issues are described >briefly in the 3 week old mail. The most issues are noted below. >Additionally, there have been some clarifications on the ingress >filtering language. > >The status is that we're in the process of doing two things: > > 1) Discussing with Margaret on her requirement that the DNS ordering >text be removed, to be replaced with a normative reference to RFC3484, >blocking the move to Draft Standard. Erik and I disagree with that >approach, and are trying to convince her. > > 2) Waiting for the submission of an informational document describing >how to build secure IPsec v6-in-v4 tunnels. > >I can send you an edited "working copy" off-list if you're interested; >in any case, the draft will probably be posted on the list for short >review before moving forward. > > > >>I am well aware that Bob has made significant past contributions >>that should be properly honored, but I was wondering what the >>policy is here? (I.e., will the MECH(bis) document be allowed >>to advance w/o Bob's active involvement?) >> >> > >I'm not sure of the policy either, but for most documents, the old >authors seem to be kept in even if they don't contribute. > >Advancement will not be a problem; WG chairs and/or ADs can approve a >document at RFC-editor's AUTH48 even if the authors don't respond. > > > >>>(co-chair hat on) >>> >>>IESG has evaluated draft-ietf-v6ops-mech-v2-02.txt and the comments >>>are available at the I-D tracker, a direct link: >>>https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1250&filename=draft-ietf-v6ops-mech-v2 >>> >>>I'm collecting the most important ones here for feedback and opinions. >>>I've followed up with most ADs for clarification, and I'm excluding >>>the trivial issues, misunderstandings, etc. >>> >>>Issues 1) and 2) are the most important ones, and I'd appreciate >>>comments from the WG on those at least. >>> >>>1) section 2.2 on DNS result ordering/filtering seems to be considered >>>inappropriately short, and it would be better to just refer to the >>>default address selection RFC3484. (Margaret Wasserman). Filtering is >>>inappropriate (Ted Hardie and Scott Hollenbeck). >>> >>>==> possibilities include at least: >>>a) keeping the current tense of specifying a "simple" address >>> selection, and referring to RFC3484 for more details, but reword >>> the text appropriately. Remove filtering but keep ordering. It >>> might require some convincing to make the IESG accept this >>> approach. (In other words, a simple dual-stack implementation would >>> not necessarily have to implement RFC3484 to be >>> compliant/interoperable with this spec.) >>>b) remove most of the text, referring to RFC3484. Note that RFC3484 >>> is PS, and we could not advance to DS if we did that. (In other >>> words, all the dual-stack implementations compliant with this spec >>> would also have to implement RFC3484.) >>> >>>2) the document appears to say, "just use IPsec", without giving >>>sufficient details how to do it inappropriately. (Steve Bellovin) >>> >>>==> possibilities include at least: >>>a) adding some detail here how to set up the SA's >>>b) removing all the references to IPsec and hoping that security AD's >>> don't cry out. >>>c) defer to a future document to be written about the details of >>> secure v6-in-v4 tunneling; this has already started a month ago, >>> but hasn't produced a -00 draft yet. >>> >>>3) security considerations describing isolating different tunnels and >>>interfaces from each other seems to forbid the implementation >>>technique of point-to-multipoint (and more, multipoint-to-point) >>>tunnels. (Alex Zinin) >>> >>>==> this is intentional, as we removed automatic tunneling from the >>>spec, but should probably be spelled out. All the configured tunnels >>>are expected to be point-to-point. >>> >>>4) the spec might consider whether the tunnel end-point is resolvable; >>>if not, take the tunnel down. (Alex Zinin) >>> >>>==> I already agreed with Alex that this is a can full of worms, even >>>if it's useful, and not something we should open here unless people >>>insist. (The "resolvability" check is quite non-trivial when you have >>>e.g., default or aggregate routes in your routing table.) >>> >>>5) the doc needs to mention dual-stack security considerations. >>>(Jon Peterson) >>> >>>==> I already agreed with Jon that spelling these out here would be >>>out of scope, and we'll just defer to another document, >>>draft-savola-v6ops-security-overview-02.txt, for that (just like for >>>3GPP analysis doc) >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > > From owner-v6ops@ops.ietf.org Tue Jun 8 00:52:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17749 for ; Tue, 8 Jun 2004 00:52:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXYUF-000Mai-5M for v6ops-data@psg.com; Tue, 08 Jun 2004 04:45:23 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXPjT-000NAE-5y for v6ops@ops.ietf.org; Mon, 07 Jun 2004 19:24:31 +0000 Received: from [10.0.1.3] (dsl093-162-248.tus1.dsl.speakeasy.net [66.93.162.248]) by toccata.fugue.com (Postfix) with ESMTP id 742991B2E68; Mon, 7 Jun 2004 14:22:55 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49DF15FA-B8B8-11D8-B212-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: IPv6 DNS Configuration , DHC WG , V6OPS WG , , IPv6 WG , "Jaehoon Paul Jeong" From: Ted Lemon Subject: Re: [dhcwg] RE: IPv6 Host Configuration of Recursive DNS Server Date: Mon, 7 Jun 2004 12:24:26 -0700 To: "Christian Huitema" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jun 6, 2004, at 9:28 PM, Christian Huitema wrote: > 1) In the disadvantage of DHCPv6 section, you ought to mention that > there is a ensure that the DHCP server always returns an up-to-date > value for the address of the preferred recursive DNS server. In large > networks, this is not trivial: the notion of which server is closest > depends on routing configuration and on server status, all of which are > dynamic. In contrast, the anycast approach guarantees that the request > will reach the closest server. > This is really more of an advantage of using an anycast address over using a unicast address, and has nothing to do with DHCPv6. If you want this functionality, you can use DHCPv6 to configure the anycast address, or you can hard-code the anycast address. The question we're trying to address is really how we configure nodes as they come on to the network, not with what we configure them. The reason that anycast has a place in this discussion is that it's the only possible value that you could just hard-code into the client and thereby bypass configuration altogether. We need to be very careful in discussing this draft not to get confused about what the draft does. It does not say "this is the solution." Rather, it is essentially a sales tool which tries to present the advantages and disadvantages of each option, so that the buyer (the IESG, I guess) can make an informed choice between them. So please let us not digress into deep, detailed discussions about why the other guy's choice is wrong - just say what's good about the proposal you favor, and if you want to be honest, discuss any disadvantages of which you're aware. From owner-v6ops@ops.ietf.org Tue Jun 8 04:34:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10352 for ; Tue, 8 Jun 2004 04:34:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXc1Q-000CAH-Ft for v6ops-data@psg.com; Tue, 08 Jun 2004 08:31:52 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BXc0B-000By8-2i for v6ops@ops.ietf.org; Tue, 08 Jun 2004 08:30:35 +0000 Received: (qmail 10129 invoked from network); 8 Jun 2004 08:24:50 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2004 08:24:50 -0000 Message-ID: <40C57A46.2030805@necom830.hpcl.titech.ac.jp> Date: Tue, 08 Jun 2004 17:35:18 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: dnsop-v6conf@nominum.com CC: Jaehoon Paul Jeong , dnsop@lists.uoregon.edu, V6OPS WG , DHC WG , IPv6 WG Subject: WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all; The problem is rather generic than DNS configuration. But... I know ND is wrong. That is, I know it is wrong to have generic link protocols ignoring link specific properties and has been pondering on how such protocols suffer. I just recently noticed that WLAN (802.11*) is not very good at supporting ND (nor DHCP nor any broadcast/multicast protocol). Because WLAN use CSMA/CA, it needs ACK for reliable transmission by confirming that each packet reaches its destination without collision. However, with broadcast/multicast packets, there is no ACK for an obvious reason. If WLAN is lightly loaded, it is not a serious problem. However, if WLAN is heavily loaded, ND (and DHCP and any broadcast/ multicast protocol) works poorly. Note that MIPv6 works poorly too. Still, management beacon frames are transmitted frequently and expected to carry information in a long run. So, it is possible to piggyback broadcast/multicast part of address resolution and autoconfiguration (maybe and routing) in reserved fields of beacon frames. Though it is possible to use some data frame frequently transmitted like beacon frams, it make the already congested WLAN worse. Anyway, the fundamental mistake is to try not to have link specific ways to perform address resolution and autoconfiguration. DHCP simply needs link specific ways of DHCP discover. ND needs, IMHO, a lot more. Note that modifying WLAN protocol to use PIFS is not enough unless combined with frequent transmission. Masataka Ohta From owner-v6ops@ops.ietf.org Tue Jun 8 07:16: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 HAA18828 for ; Tue, 8 Jun 2004 07:16:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXeZe-000HGF-0n for v6ops-data@psg.com; Tue, 08 Jun 2004 11:15:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXeZc-000HFc-MV for v6ops@ops.ietf.org; Tue, 08 Jun 2004 11:15:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i58BF8l03599; Tue, 8 Jun 2004 14:15:08 +0300 Date: Tue, 8 Jun 2004 14:15:08 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: Tim Chown , Subject: compatible address support [Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt In-Reply-To: <40BF52C8.7010309@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Fred Templin wrote: > >The example in 6.1 cites compatible addresses. While these are in use, > >they are being deprecated in draft-ietf-v6ops-mech-v2-02, so I suggest > >the example is reworked a little and that the reference is to the new > >draft and not RFC2893 (reference [4]). > > I agree with Tim about updating the [MECH] reference, but I was also > wondering about when it would be OK for implementations to begin > dropping support for IPv4-compatible addresses? I guess there could > be several alternative approaches, including: > > 1) remove the IPv4-compatible address support code completely? > 2) leave the code, but surround it with compile-time directives? > (default-disabled vs. default-enabled is another decision point) > 3) other? > > I seem to recall seeing some earlier discussion on this, but perhaps > there are more current viewpoints based on the extensive scenarios > and analysis work done by 'v6ops'? IMHO, this is probably an implementation choice, and not something we can or should specify here. Personally, I see very little use for them.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Jun 8 07: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 HAA19316 for ; Tue, 8 Jun 2004 07:29:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXemY-000JP6-2T for v6ops-data@psg.com; Tue, 08 Jun 2004 11:28:42 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXemU-000JOh-MT for v6ops@ops.ietf.org; Tue, 08 Jun 2004 11:28:38 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 7938D5686; Tue, 8 Jun 2004 13:28:37 +0200 (CEST) Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 73859-01-13; Tue, 8 Jun 2004 13:28:35 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 1003) id B4BB85635; Tue, 8 Jun 2004 13:28:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id B24615518; Tue, 8 Jun 2004 13:28:35 +0200 (CEST) Date: Tue, 8 Jun 2004 13:28:35 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Masataka Ohta Cc: dnsop-v6conf@nominum.com, Jaehoon Paul Jeong , dnsop@lists.uoregon.edu, V6OPS WG , DHC WG , IPv6 WG Subject: Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server) In-Reply-To: <40C57A46.2030805@necom830.hpcl.titech.ac.jp> Message-ID: <20040608130454.R73638@mignon.ki.iif.hu> References: <40C57A46.2030805@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at mail.ki.iif.hu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Masataka, On Tue, 8 Jun 2004, Masataka Ohta wrote: > Dear all; > > The problem is rather generic than DNS configuration. But... > > I know ND is wrong. That is, I know it is wrong to have generic > link protocols ignoring link specific properties and has been > pondering on how such protocols suffer. I think ND is not wrong. There is a clear need for better support to discover the link parameters, but it is necessary for mostly to the routing protocols. > > I just recently noticed that WLAN (802.11*) is not very good at > supporting ND (nor DHCP nor any broadcast/multicast protocol). > > Because WLAN use CSMA/CA, it needs ACK for reliable transmission > by confirming that each packet reaches its destination without > collision. > > However, with broadcast/multicast packets, there is no ACK for > an obvious reason. The IPv4 ARP is not better either, as you found. I think the WLAN should be improved some way to support multicast in some form. > > If WLAN is lightly loaded, it is not a serious problem. > > However, if WLAN is heavily loaded, ND (and DHCP and any broadcast/ > multicast protocol) works poorly. Note that MIPv6 works poorly > too. > > Still, management beacon frames are transmitted frequently > and expected to carry information in a long run. > > So, it is possible to piggyback broadcast/multicast part > of address resolution and autoconfiguration (maybe and > routing) in reserved fields of beacon frames. I think autoconfiguration can be treated differently, than address resolution. ND as stand for "Neighbour" Discovery is a very good improvement to ARP and transport specific things... Of course ND can get into trouble if no reply for ND requests (with soliticited node multicast address)... > > Though it is possible to use some data frame frequently > transmitted like beacon frams, it make the already congested > WLAN worse. > > Anyway, the fundamental mistake is to try not to have link > specific ways to perform address resolution and autoconfiguration. > > DHCP simply needs link specific ways of DHCP discover. > > ND needs, IMHO, a lot more. What do you think? > > Note that modifying WLAN protocol to use PIFS is not enough > unless combined with frequent transmission. I agree. Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 From owner-v6ops@ops.ietf.org Tue Jun 8 07:33:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19804 for ; Tue, 8 Jun 2004 07:33:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXer3-000KQV-Fd for v6ops-data@psg.com; Tue, 08 Jun 2004 11:33:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXer2-000KQA-55 for v6ops@ops.ietf.org; Tue, 08 Jun 2004 11:33:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i58BXGd03959; Tue, 8 Jun 2004 14:33:16 +0300 Date: Tue, 8 Jun 2004 14:33:16 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" In-Reply-To: <40C0C501.6030101@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (Trimmed Cc: list) On Fri, 4 Jun 2004, Fred Templin wrote: > >Good point -- I don't think ISATAP has been discussed to be used > >*within* an unmanaged network. > > > > Inserting more careful phrasing, I believe there may be two > aspects of the question to consider: > > 1) Near-term implications for connecting hosts and routers > within an unmanaged network using [ISATAP]. > > 2) Somewhat longer-term implications for connecting hosts > within an unmanaged network to hosts/routers in the Internet > using [ISATAP] over a virtual link extended via ND Proxy, > multi-link subnet, hybrid bridge/router, etc. (i.e., with no > "traditional" NAT traversal needed). > > The phrasing in my original message appears to have focused > your reply on 1) only, which I think is fine for now since it seems > to be the proper scope for the current analysis in [unmaneval-03]. You said '*within* unmanaged networks' (emphasis mine), and as the ISP's network is hopefully managed, I took it to mean you were only referring to 1). I'm not quite sure what you mean by 2). There has been no consensus (as far as I could see) for including ISATAP for 2) in the context of obtaining IPv6 connectivity from the ISP or communicating between the customers of the ISP. But trying to read the issue 2) you note above carefully, I think you're referring to something slightly different (but not sure). If so, could you clarify a bit? > >1) the gateway supported IPv6 but the links wouldn't, or > > > >2) the gateway wouldn't support IPv6, but the nodes in a multi-link > >unmanaged network would want to use IPv6 between each other. > > I am not an expert in the unamanged network transition space, but it > seems that we are beginning to see heterogeneous link technologies > in home/SOHO applications that are not easily bridged. > ([unmaneval-03], sections 4.1.1 and 7) provide good analysis and > recommendations on extending a subnet to span multiple links, but > provide no guidance on mechanisms to connect nodes accross such an > extended subnet when link technologies with disparate MAC address > formats and/or link MTUs are included. Both of these conditions > could be mitigated by IPv6-in-IPv4 encapsulation using ISATAP, but > this is not currently stated in the document. Is there evidence of such heterogenous environments emerging where different link MTUs would be used, or different format of MAC addresses which could not be proxied? I'm not an expert on unmanaged networks either, but I think these are a bit more futuristic scenarios (and all of these non-problems if a router is used instead of a bridge/proxy). But let's step back a bit. How this would be helped by using ISATAP? Link MTU problem could potentially be affected somehow (but that's probably not a big problem in any case), but I don't see how different format of MAC addresses would change the situation -- it wouldn't be possible to interconnect those boxes with IPv4 either, you'd have to have an IPv4 router or NAT box in the middle -- and it wouldn't help. [...] > >And since we're already past WG last call(s), this is probably a moot > >point in any case... > > > > I'm not so sure; ([unmaneval-03], sections 4.1.1 and 7) give analysis and > recommendations on how to _extend_ a subnet to span multiple links > but no analysis and recommendations on mechanisms that nodes can > use to _traverse_ such an extended subnet. I believe ISATAP fits this > space for the near-term at least, with potential for wider applicability > in the somewhat longer term as described above. Traversing such an extended subnet can be done by the same mechanism as extending it, AFAICS -- except if there are disallow traversing with bigger packets than used for extending (1500 bytes for example). But these are addressed e.g., by ND proxies already by sending Pkt Too Big messages, so I'm not sure what is the exact problem here. > Also FYI, there appears to be a typo in: ([unmaneval-03], section 5), > first sentence of the 2nd paragraph. Here, it seems like "case B" > should be changed to: "case C". Good catch -- thanks! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Jun 8 08:47: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 IAA23379 for ; Tue, 8 Jun 2004 08:47:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXfzK-0008kh-Aw for v6ops-data@psg.com; Tue, 08 Jun 2004 12:45:58 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BXfeb-0004Yk-PA for v6ops@ops.ietf.org; Tue, 08 Jun 2004 12:24:33 +0000 Received: (qmail 11203 invoked from network); 8 Jun 2004 12:18:54 -0000 Received: from yahoobb219001188015.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.15) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2004 12:18:54 -0000 Message-ID: <40C5B11F.2000301@necom830.hpcl.titech.ac.jp> Date: Tue, 08 Jun 2004 21:29:19 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mohacsi Janos CC: dnsop-v6conf@nominum.com, Jaehoon Paul Jeong , dnsop@lists.uoregon.edu, V6OPS WG , DHC WG , IPv6 WG Subject: Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server) References: <40C57A46.2030805@necom830.hpcl.titech.ac.jp> <20040608130454.R73638@mignon.ki.iif.hu> In-Reply-To: <20040608130454.R73638@mignon.ki.iif.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL, RCVD_IN_NJABL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mohacsi Janos wrote: >>I know ND is wrong. That is, I know it is wrong to have generic >>link protocols ignoring link specific properties and has been >>pondering on how such protocols suffer. > I think ND is not wrong. ND is wrong, because it was designed to be applicable to all the link types. ND deployed multicast only because some ATM guy said NBMA was capable of not broadcast but multicast, which is totaly denied by the current ND RFC stating that ND may not be applicable to NBMA. > There is a clear need for better support to > discover the link parameters, but it is necessary for mostly to the > routing protocols. If you are talking about QoS, it is a totally different topic. >>However, with broadcast/multicast packets, there is no ACK for >>an obvious reason. > The IPv4 ARP is not better either, as you found. No, ARP is no better, of course. Given the point to multipoint nature of infrastructure WLAN, and given the probability of hidden terminals, ARP is overkill. Just send all the packets to the base station, IP address of which should be piggy-backed in beacon. As for ad-hoc WLAN, it does not work well with multiple link hops that it is a bad idea at L2. > I think the WLAN should > be improved some way to support multicast in some form. It is inherent to CSMA/CA link that broadcast/multicast is unreliable. Our (IETF) approach has been to make IP work over as much link technology as possible. The solution has been never bother to have standard way of address resolution. > I think autoconfiguration can be treated differently, than address > resolution. ND as stand for "Neighbour" Discovery is a very good > improvement to ARP and transport specific things... However, there are people who think ND should take care of everything including DNS configuration. >>ND needs, IMHO, a lot more. > What do you think? Because of its bloated set of features, I think ND hopeless. Masataka Ohta From owner-v6ops@ops.ietf.org Tue Jun 8 09:38:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26192 for ; Tue, 8 Jun 2004 09:38:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXgmy-000IT9-SL for v6ops-data@psg.com; Tue, 08 Jun 2004 13:37:16 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXgmx-000IQO-DY for v6ops@ops.ietf.org; Tue, 08 Jun 2004 13:37:15 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i58DbEAN079520 for ; Tue, 8 Jun 2004 13:37:14 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i58DbD8u188484 for ; Tue, 8 Jun 2004 15:37:13 +0200 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA58712 for ; Tue, 8 Jun 2004 15:37:13 +0200 Message-ID: <40C5C109.2060602@zurich.ibm.com> Date: Tue, 08 Jun 2004 15:37:13 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: compatible address support [Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Thu, 3 Jun 2004, Fred Templin wrote: > >>>The example in 6.1 cites compatible addresses. While these are in use, >>>they are being deprecated in draft-ietf-v6ops-mech-v2-02, so I suggest >>>the example is reworked a little and that the reference is to the new >>>draft and not RFC2893 (reference [4]). >> >>I agree with Tim about updating the [MECH] reference, but I was also >>wondering about when it would be OK for implementations to begin >>dropping support for IPv4-compatible addresses? I guess there could >>be several alternative approaches, including: >> >> 1) remove the IPv4-compatible address support code completely? >> 2) leave the code, but surround it with compile-time directives? >> (default-disabled vs. default-enabled is another decision point) >> 3) other? >> >>I seem to recall seeing some earlier discussion on this, but perhaps >>there are more current viewpoints based on the extensive scenarios >>and analysis work done by 'v6ops'? > > > IMHO, this is probably an implementation choice, and not something we > can or should specify here. Personally, I see very little use for > them.. We had a similar discussion around site local and in the end decided that all the IETF should say is: Existing implementations and deployments MAY continue to use this prefix. In other words, it's not our business how implementors choose to roll back a deprecated feature. Brian From owner-v6ops@ops.ietf.org Tue Jun 8 11:01:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01230 for ; Tue, 8 Jun 2004 11:01:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXi4c-0008yk-4X for v6ops-data@psg.com; Tue, 08 Jun 2004 14:59:34 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXi4Z-0008y9-7M for v6ops@ops.ietf.org; Tue, 08 Jun 2004 14:59:31 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i58ExSnE013752 for ; Tue, 8 Jun 2004 15:59:28 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA24112 for ; Tue, 8 Jun 2004 15:59:24 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i58ExOr09407 for v6ops@ops.ietf.org; Tue, 8 Jun 2004 15:59:24 +0100 Date: Tue, 8 Jun 2004 15:59:24 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: compatible address support [Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt Message-ID: <20040608145924.GE9200@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <40C5C109.2060602@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C5C109.2060602@zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jun 08, 2004 at 03:37:13PM +0200, Brian E Carpenter wrote: > > We had a similar discussion around site local and in the end decided that > all the IETF should say is: > > Existing implementations and deployments MAY continue to use this > prefix. > > In other words, it's not our business how implementors choose to > roll back a deprecated feature. Right. My question was just whether covering compatibles was appropriate in the 6to4 security review. Tim From owner-v6ops@ops.ietf.org Tue Jun 8 20:25:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13353 for ; Tue, 8 Jun 2004 20:25:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXqsR-0007Jt-3K for v6ops-data@psg.com; Wed, 09 Jun 2004 00:23:35 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXqsQ-0007Je-8q for v6ops@ops.ietf.org; Wed, 09 Jun 2004 00:23:34 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i590NGNf027317; Tue, 8 Jun 2004 17:23:17 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i590NDQ04261; Wed, 9 Jun 2004 02:23:13 +0200 (MEST) Date: Tue, 8 Jun 2004 16:43:06 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: compatible address support [Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt To: Pekka Savola Cc: Fred Templin , Tim Chown , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > 1) remove the IPv4-compatible address support code completely? > > 2) leave the code, but surround it with compile-time directives? > > (default-disabled vs. default-enabled is another decision point) > > 3) other? > > > > I seem to recall seeing some earlier discussion on this, but perhaps > > there are more current viewpoints based on the extensive scenarios > > and analysis work done by 'v6ops'? > > IMHO, this is probably an implementation choice, and not something we > can or should specify here. Personally, I see very little use for > them.. Agreed there isn't much use for them based on how folks are deploying or want to deploy IPv6 AFAIK. Trying to address the 1,2,3 above; We don't have data that compatible addresses are harmful though. So I think this means that implementors can remove the support when it is convenient to them. Erik From owner-v6ops@ops.ietf.org Wed Jun 9 15:20: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 PAA12284 for ; Wed, 9 Jun 2004 15:20:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY8Yx-0001JI-Hc for v6ops-data@psg.com; Wed, 09 Jun 2004 19:16:39 +0000 Received: from [61.144.161.40] (helo=huawei.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY6Hg-000Lu0-44 for v6ops@ops.ietf.org; Wed, 09 Jun 2004 16:50:40 +0000 Received: from keshavaak (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HZ100AIZSNX0N@mta1.huawei.com> for v6ops@ops.ietf.org; Wed, 09 Jun 2004 23:35:59 +0800 (CST) Date: Fri, 09 Jul 2004 09:17:05 +0530 From: Keshava Subject: Tunnel6 destination address as Link Local address To: ipv6@ietf.org, snap-users@kame.net, V6OPS WG Cc: keshavaak@huawei.com, surajs@huawei.com Reply-to: Keshava Message-id: <001a01c46567$67cb2560$1604120a@keshavaak> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: multipart/alternative; boundary="Boundary_(ID_Z8eVJP8sFlZRQTw3id2lRA)" X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:82.85147 C:21 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_96_XX, HTML_50_60,HTML_MESSAGE,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_Z8eVJP8sFlZRQTw3id2lRA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Can we allow Ipv6 Tunnel6 destination to be configured as the LinkLocal address.? Since the scope of the LinkLocal is just with in one Link, by specifying the tunnel6 destination address as linklocal we can't get on which link the destination address lies on ? (One of the vendor allowed to configure this ) Should this be allowed to configure like this ? keshava --Boundary_(ID_Z8eVJP8sFlZRQTw3id2lRA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
    Can we allow  Ipv6 Tunnel6  destination to be configured as  the LinkLocal address.?
 
    Since the scope of the LinkLocal is just with in one Link,
    by specifying the tunnel6 destination address as  linklocal we can't get   on which link the destination address lies on ?
 
    (One of the vendor   allowed to configure this )
 
    Should this be allowed to configure like this ?
 
keshava
 
 
--Boundary_(ID_Z8eVJP8sFlZRQTw3id2lRA)-- From owner-v6ops@ops.ietf.org Wed Jun 9 19:42:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04252 for ; Wed, 9 Jun 2004 19:42:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYCfz-000P59-8C for v6ops-data@psg.com; Wed, 09 Jun 2004 23:40:11 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYCfw-000P4a-46 for v6ops@ops.ietf.org; Wed, 09 Jun 2004 23:40:09 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 16:40:06 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Jun 2004 16:40:07 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 16:41:02 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 9 Jun 2004 16:40:06 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 9 Jun 2004 16:40:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: huitema-v6ops-teredo-01 comments Date: Wed, 9 Jun 2004 16:40:05 -0700 Message-ID: Thread-Topic: huitema-v6ops-teredo-01 comments Thread-Index: AcQFD68zYlfdFi3PQ8yODBmLHJbApAAKR7Bw From: "Christian Huitema" To: "Pekka Savola" , "Eiffel Wu" Cc: X-OriginalArrivalTime: 09 Jun 2004 23:40:15.0649 (UTC) FILETIME=[1D862110:01C44E7B] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A long time ago, Pekka sent to the list a detailed review of the Teredo draft. I have just submitted draft-huitema-v6ops-teredo-02.txt that addresses these comments, and also fixes a typo found by Eiffel Wu in the qualification procedure diagram. Thanks to both reviewers. What follows is a detailed reply to Pekka's comments.=20 -- Christian Huitema > substantial > ----------- >=20 > 1) sect 5.2.1, qualification procedure seems to yield either cone NAT, > restricted cone NAT or symmetric NAT. What about port-restricted cone > NATs? Are these implicitly covered in some terminology here? They > don't seem to be explicitly mentioned anywhere! Yes, restricted and port restricted are treated the same way. I will make that explicit in the revision. > 2) security considerations should discuss that MD5 is not anymore > considered "secure" due to better collision-resistance of SHA1. > However, in this specific case, I don't think this is a huge problem. I will rewrite the text to indicate that MD5 is just a convenient default, but that client and servers can agree on a different algorithm. The packet format already allows for variable length authentication checks, and the key has to be provisioned explicitly in the client, so we could conceivably provision both the key and the algorithm, and just leave it a configuration option. But the main threat is a dictionary attack, for which there is no difference between MD5 and SHA1. > 3) I think this document seriously needs an "overview" section, around > section 4, which could be e.g. 2-4 pages, trying to summarize the > whole operation while leaving out the details with figures, etc. -- > whatever appropriate. The spec is rather compact and requires careful > reading to understand its implications. Having such a section (as > there was before, but it was removed, I think) would be very useful > for those who want to get a good overview of how the mechanism works. The problem with the previous version was that it introduced confusion -- implementers were confused as to which part was normative, the overview or the protocol specification. > 4) what's the implementation status? to what degree do the > implementation(s) reflect the current spec? I have a few thoughts for > improvements if certain parts of the spec would not be implemented yet > (e.g., the authentication encapsulation), but if they are, making such > changes might not be feasible. The specification tries to closely reflect the existing implementations. > 5) an interesting deployment model could be deploying a > Teredo-cognizant tunnel broker at the teredo anycast address, > basically "hijacking" all the teredo users as your tunnel broker > customers -- requiring no tunnel broker implementations at the client > side. This would be a rather interesting way to leverage the existing > implementations to provide tunnel broker service :-). There is no Teredo anycast address, but I see the idea: have the client automatically discover whether the Teredo server is willing to act as a tunnel end-point. In that case, the client would go for a classic tunnel mode.=20 > 6) this doc probably needs a bit more applicability etc. work but > that's something that can be inserted a bit later on as well. >=20 > semi-editorial/substatial > ------------------------- >=20 > Abstract >=20 > We propose here a service that enables nodes located behind one or > several IPv4 NATs to obtain IPv6 connectivity by tunneling packets > over UDP; we call this the Teredo service. Running the service > requires the help of "Teredo servers" and "Teredo relays"; the > Teredo servers are stateless, and only have to manage a small > fraction of the traffic between Teredo clients; the Teredo relays > act as IPv6 routers between the Teredo service and the "native" IPv6 > Internet. >=20 > =3D=3D> the last sentence is not accurate when you take also the "6to4 > universe" into account -- needs rewording somehow? OK. > A possible way to solve the problem is to rely on a set of "tunnel > brokers." There are however limits to any solution that is based on > such brokers: the quality of service is not very good, since the > traffic follows a "dog leg" route from the source to the broker and > then the destination; the broker has to provide sufficient > transmission capacity to relay all packets and thus suffers a high > cost. For these two reasons, we tend to prefer solutions that allow > for "automatic tunneling", i.e. let the packets follow a direct path > to the destination. >=20 > =3D=3D> I'd reword this to a bit softer, because tunnel brokers are > actually useful in some contexts: > =3D=3D> s/is not very good/may be limited/ > =3D=3D> s/we tend to prefer/it may be desirable to have/ OK. > 2.8 Teredo service port >=20 > The port through which the Teredo client sends Teredo packets. This > port is attached to one of the client's IPv4 interfaces. The IPv4 > address may or may not be globally routable, as the client may be > located behind one or several NAT. >=20 > =3D=3D> ports are not attached to interfaces. They may be attached to > addresses only. So, maybe rename "Teredo service port" to "Teredo > service address/port" or whatever, and reword the text a bit? I reworded to mention binding to a specific address. > Experience shows that the implementers of NAT devices can adopt > widely different treatments of UDP mappings: >=20 > =3D=3D> if this has been analyzed at more length elsewhere, I'd refer = to > that work for additional information. Later in the document, RFC3489 > is cited as one source, at least. OK, done that. > 3) Instead of keeping just a list of authorized hosts, some NAT > implementations keep a list of authorized host and port pairs. UDP > packets coming from remote addresses are rejected if the internal > host has not yet sent traffic to the outside host and port pair. The > NATs are often called "port-restricted cone NATs" >=20 > =3D=3D> I've always had problems figuring out what this means. I = suggest > adding a new second-to-last sentence: >=20 > That is, as long as the internal host has communicated with a (host, > port) pair, the created NAT mapping (to some other host or port) can > be used to inject incoming packets to the internal host. Replaced by a pointer to STUN/RFC3489. > 3.2.1 When to use Teredo? >=20 > Teredo is designed to robustly enable IPv6 traffic through NATs, and > the price of robustness is a reasonable amount of overhead, due to > UDP encapsulation and transmission of bubbles. Nodes that want to > connect to the IPv6 Internet SHOULD only use the Teredo service as a > "last resort" option: they SHOULD prefer using direct IPv6 > connectivity if it is locally available or if it is provided by a > 6to4 router co-located with the local NAT, and they SHOULD prefer > using the less onerous "6to4" encapsulation if they can use a global > IPv4 address. >=20 > =3D=3D> this doesn't yet describe tunnel service (details TBD at the > moment) at all -- it is also a preferable choice. OK, added text. > 4 Teredo Addresses >=20 > =3D=3D> I'd consider separating this to two subsection, global and > link-local addresses -- as these seem to have slightly different > characteristics. >=20 > - The bits indicated with "z" must be set to zero. >=20 > =3D=3D> s/set to zero/sent as zero and ignored on receipt/ ? OK. > The Teredo relay advertises reachability of the Teredo service > prefix over IPv6. It forwards Teredo IPv6 packets to the appropriate > IPv4 address and UDP port. >=20 > =3D=3D> local relays don't do the first. This has been ignored in a = few > other places in the document as well. OK. > The following 16 bits contain the obfuscated value of the port > number from which the packet was received, in network byte order. > The next 32 bits contain the obfuscated IPv4 address from which the > packet was received, in network byte order. In this format, both the > original "IPv4 address" and "UDP port" of the client are obfuscated. > Each bit in the address and port number is reversed; this can be > done by an exclusive OR of the 16-bit port number with the > hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address > with the hexadecimal value 0xFFFFFFFF. >=20 > For example, if the original UDP port number was 337 (hexadecimal > 0151) and original IPv4 address was 1.2.3.4 (hexadecimal: 01020304), > the origin indication would contain the value "0000FEAEFEFDFCFB". >=20 > =3D=3D> this obfuscation code has been described in two places -- = maybe it > would make sense to put it in a subsection or something, so it could > be referred to more easily when it's used later on in the draft? I find simpler to leave it as is. > The third octet indicates the length of > the client identifier; the fourth octet indicates the length of > the authentication value. >=20 > =3D=3D> is zero client ID OK as well? The same about authentication > value? (these could be useful if you'd only want "return routability" > like anonymous testing, where you'd only want to use nonces. Yes. > =3D=3D> these octets give the length in the units of bytes, correct? = (make > explicit) OK. > In > accordance with [RFC2461], the default time-out value is set to = T=3D4 > seconds, and the maximum number of repetitions is set to N=3D3. >=20 > =3D=3D> this seems quite long, and I don't see how RFC2461 relates = here. > Maybe e.g. T=3D2, N=3D1 would be sufficient? We are performing an RS/RA exchange, so the value in RFC2641 apply. If 4 seconds is a proper value on an Ethernet, why should we pick a lower value on a longer-delay network? > option. This prefix should be a valid Teredo IPv6 server prefix: the > first 32 bits should contain the global Teredo IPv6 service prefix, > and the next 32 bits should contain the server's IPv4 address. If > this is the case, the client learns the Teredo mapped address and >=20 > =3D=3D> "global" --> remove that, could be local as well? Uh, no. Unless we define a brand new /32 that has no global meaning. > If the client has received an RA with the "Cone" bit set to 1, it is > behind a cone NAT and is fully qualified. If the RA is received with > the Cone bit set to 0, the client does not know whether the local > NAT is restricted or symmetric. The client selects a secondary IPv4 > server address, and repeats the procedure, the cone bit remaining to > the value zero. >=20 > =3D=3D> there are multiple places where Cone bit can be set, so maybe > reword like: >=20 > If the client has received an RA with the "Cone" bit in the > advertised prefix set to 1, it is behind a cone NAT and is fully > qualified. If the RA is received with the Cone bit in the > advertised prefix set to 0, the client does not know whether the > local NAT is restricted or symmetric. The client selects a > secondary IPv4 server address, and repeats the procedure, the cone > bit in the link-local address remaining to the value zero. >=20 > .... I checked the text a bit. > indication. The cone bit should be set to the value used to receive > the RA, i.e. 1 if the client is behind a cone NAT, 0 otherwise. The >=20 > =3D=3D> s/to receive the RA/in the RA/ ? Or am I confused about cone = bit > in the prefix vs. link-local address? It is in the address. > When a UDP packet is received over the Teredo service port, the > Teredo client checks that it is encoded according to the packet > encoding rules defined in 5.1.1, and that it contains either a valid > IPv6 packet as specified in [RFC2460], >=20 > =3D=3D> you must spell out what exactly to check, as RFC2460 does not > specify what is a "valid IPv6 packet". The same happens a lot later > in the spec as well. OK. =20 > if an origin indication is > present, the client should perform the "direct IPv6 connectivity > test" described in section 5.2.9. >=20 > =3D=3D> should you use more uppercase keywords, e.g., in here, but in > several other places as well? Matter of taste, I guess... > If the values match, the packet > should be accepted; the date and time of the last reception from the > peer should be updated. >=20 > =3D=3D> s/should be/is/ ? OK. >=20 > 2) If there is an entry for the source IPv6 address in the list of > peers whose status is not trusted, the client checks whether the > packet is an ICMPv6 echo reply. If this is the case, and if the > content of the reply matches the "nonce" stored in the peer entry, > the packet should be accepted; >=20 > =3D=3D> s/content/ICMPv6 data/ OK. > any packet queued for this IPv6 > peer should be de-queued and forwarded to the newly learned IPv4 > address and UDP port. >=20 > =3D=3D> add a pointer to 5.2.4 around queuing? >=20 > 4) If the source IPv6 address is a Teredo address, and the mapped > IPv4 address and mapped port in the source address do not match the > source IPv4 address and source port of the packet, the client checks > whether the is an existing "local" entry for that IPv6 address. If > there is such an entry, and if the local IPv4 address and local port > indicated in that entry match the source IPv4 address and source > port of the packet, the client updates the "local" entry, whose > status should be set to "trusted". If the packet is a bubble, it > should be discarded after this processing; otherwise, the packet > should be accepted. In all cases, the client must de-queue and > forward any packet queued for that destination. >=20 > =3D=3D> and what if there is no such entry? do nothing? Rearranged the order of paragraphs so the "what else" case is clearly described in "6) In the other cases, ..." > 5) If the IPv4 destination address through which the packet was > received is the Teredo IPv4 Discovery Address, the source address is >=20 > =3D=3D> add a note here stating that this procedure is optional. OK. > 2) If the destination is not a Teredo IPv6 address, the packet is > queued, and the client performs the "direct IPv6 connectivity test" > described in section 5.2.8. The packet will be de-queued and >=20 > =3D=3D> s/5.2.8/5.2.9/ OK. > 5.2.6 Sending Teredo Bubbles >=20 > =3D=3D> this section should also discuss "indirect bubbles" (as = introduced > in 5.2.4) and how they're sent. OK. > the client MUST create a new list entry for the address, > setting the last reception date and the last transmission date to 30 > seconds before the current date, and the number of bubbles to zero. >=20 > =3D=3D> umm.. why exactly are you setting the dates to 30 seconds in = the > history?? So we do not engage in futile immediate retransmission... > The secondary port MUST NOT be used for any other purpose than the > interval determination procedure. If a spurious packet is received on > the secondary port, the client SHOULD repeat the maintenance > procedure on this port and reset the date and time of the last > interaction on the secondary port. >=20 > =3D=3D> umm,, this would seem to hint at an implementation technique, > where you'd be continously listening at the secondary port. I fail to > see the need for that -- this is only done when you start up Teredo > (if it's implemented that is). Rather, just specify that the port is > closed when the procedure ends? OK. > A Teredo client who wishes to enable local discovery SHOULD wait for > discovery bubbles to be received on the Teredo IPv4 Discovery > Address, and should send local discovery bubbles to the Teredo IPv4 > Discovery Address at random intervals >=20 > =3D=3D> which -- wait _or_ send? Or both? Make it more explicit. = Maybe > just say that one should join the group. OK. > - IPv6 source: the Teredo IPv6 address of the sender >=20 > =3D=3D> is this the global or link-local address? Global. > 5.3 Teredo Server specification >=20 > =3D=3D> you should really add text here describing the forwarding of > ICMPv6 probes, and bubbles between Teredo and non-Teredo nodes. >=20 > =3D=3D> also, you should mention the requirement about the secondary > address on the server. Done. > Upon reception of a packet on the Teredo port, the Teredo server > will first check that the UDP payload contains a valid IPv6 packet; > if this is not the case, the packet will be silently discarded. >=20 > Before processing the packet, the Teredo server MUST check the > validity of the encapsulated IPv6 source address, the IPv4 source > address and the UDP source port: >=20 > 1) If the UDP content is not a well formed IPv6 packet, the packet > MUST be silently discarded. >=20 > =3D=3D> isn't the first paragraph unnecessary, compared to 1)? > =3D=3D> you don't define well-formed? OK. > 2) If the UDP packet is not a bubble or an ICMPv6 message, it should > be discarded. >=20 > =3D=3D> should probably add a pointer for the definition of a bubble. Replaced by "Teredo bubble", which is defined in section 2. > =3D=3D> should you use upper-case keywords in a place like this? OK. > 4) If the IPv6 source address is an IPv6 link-local address, the > IPv6 destination address is the link-local scope all routers > multicast address (FF02::2), and the packet contains an ICMPv6 > Router Solicitation message, the packet SHOULD be accepted; it > MUST be discarded if the server requires secure qualification and > the authentication encapsulation is absent or cannot be verified. >=20 > =3D=3D> SHOULD be accepted? What's the alternative -- discard them? > Shouldn't this be a mandatory part? (Same later in 5) and 6) > =3D=3D> s/cannot be verified/verification fails/ ? Ok. > The Teredo server will then check the IPv6 destination address of > the encapsulated IPv6 packet. >=20 > =3D=3D> s/./:/ > =3D=3D> maybe the following paragraphs should be similarly separated = to > 1), 2) and 3) for clarity? >=20 > If the IPv6 destination address is a valid Teredo IPv6 address, the > Teredo Server MUST check that the IPv4 address derived from this > IPv6 address is in the format of a global unicast address >=20 > =3D=3D> a link-local address is also a valid Teredo address, right? = But > not applicable here? Maybe needs spelling out which specific address > type? OK, added reference to 2.13. > If the destination IPv6 address is a Teredo client whose address is > serviced by this specific server, the server should insert an origin > indication in the first bytes of the UDP payload, as specified in > section 5.1.1. >=20 > =3D=3D> how can the server know which addresses it's supposed to be > servicing? Or are you really saying, "if received through the Teredo > interface.." ? If the client is served by this server, the server's IPv4 address is copied in bits 32-63 of the client's Teredo IPv6 address. > The IPv6 source address should > be set to a Teredo link-local server address associated to the local > interface. >=20 > =3D=3D> how exactly did you form the LL address on the server? What = about > the C-bit? >=20 > However, Teredo relays do not have to > perform the qualification procedure. >=20 > [...] > In cases 2 and 3, the Teredo relay should create a peer entry for > the IPv6 address; the entry status is marked as trusted in case 2 > (cone NAT), not trusted in case 3. In case 3, if the Teredo relay > happens to be located behind a non-cone NAT, it should also send a > bubble directly to the mapped IPv4 address and mapped port number of > the Teredo destination; this will "open the path" for the return > bubble from the Teredo client. >=20 > =3D=3D> aren't these in conflict? The relay don't know which NAT it's > behind unless it has run qualification procedure? OK, I removed the "do not have" phrase. > 1) If there is an entry for that IPv6 address in the list of peers, > and if the status of the entry is set to "trusted", the IPv6 packet > should be sent over UDP to the mapped IPv4 address and mapped UDP > port of the entry. The client updates the date of last transmission > in the peer entry. >=20 > =3D=3D> hmm.. could the list of peers information be stale, or is it > purged often enough so that if the NAT mapping of a host changes, > there won't be communication with it directly? Are there fallbacks? If the NAT mapping of the host changes, its Teredo address also changes, so the fallback occurs very naturally... >=20 > Then, the Teredo relay examines whether the IPv6 source address is a > valid Teredo address, and if the mapped IPv4 address and mapped port > match the IPv4 source address and port number from which the packet > is received. If this is not the case, the packet is silently > discarded. >=20 > =3D=3D> I've trouble figuring out how this would work -- maybe I'm > confused. I mean, when the Teredo client sends toward different IPv4 > destination addresses, new mappings are created in the NAT for each -- > and this is by definition different from the one which is learned by > the Teredo client from the Teredo Server? No. If the NAT is cone or restricted cone, then the mappings are always the same. They change if the NAT is symmetric, but we do not support that. > Finally, the relay examines the destination IPv6 address. If the > destination is the "all nodes multicast address", the packet should > be processed locally. >=20 > =3D=3D> why this rule? Humm. Unclear. Probably had to do with combining a relay and a client. I removed it. > The dual-role of server and relays implies an additional complexity > for the programming of servers: the processing of incoming packets > should be a combination of the server processing rules defined in > 5.3.1, and the relay processing rules defined in 5.4.2. >=20 > =3D=3D> this text is not clear enough on whether section 5.3 on Teredo > servers already includes all the functionalitty required of Teredo > servers + relays, or whether you need to combine 5.3+5.4 to get > server+relay? OK, added text. >=20 > Most Teredo servers > will not be expected to operate more than a few years, perhaps until > at most 2006. >=20 > =3D=3D> umm, isn't this awfully optimistic? :) Well, we have a time limit of 6/6/6 for the current prefix, don't we? We could indeed make that 6/6/66 if you want... =20 > The very purpose of the Teredo service is to make a machine > reachable through IPv6. By definition, the machine using the > service > will give up whatever "firewall" service was available in the NAT > box; all services declared locally will become potential target of > attacks from the entire IPv6 Internet. This may sound scary, but > there are three mitigating factors. >=20 > =3D=3D> "all services declared locally" is a bit short, maybe spell it > out? Maybe also missing a word or two? OK. >=20 > The first mitigating factor is the possibility to restrict some > services to only accept traffic from one of the limited address > scopes defined in IPv6, e.g. link-local or site-local. >=20 > =3D=3D> using link-locals w/ apps is IMHO pretty bad practice, and > site-locals are gone. please update :) Link local is actually used with some "home network" applications. I have removed the reference to site-local. > There is no > support for such scopes in Teredo, which implies that limited-scope > services will not be accessed through Teredo, and will be > restricted > to whatever other IPv6 connectivity may be available, e.g. direct > traffic with neighbors on the local link, behind the NAT. >=20 > =3D=3D> these also have teredo addresses, which go through the teredo > server, etc. -- not from the same namespace, unless you configure them > manually or using some other process.. >=20 > The third mitigating factor, already noted, is the availability of > end-to-end connectivity, which allows for deployment of IP security > services such as IKE, AH or ESP. Using these services in > conjunction > with Teredo is a good policy, as it will protect the client from > possible attacks in intermediate servers such as the NAT, the > Teredo > server, or the Teredo relay. >=20 > =3D=3D> when you use these magic keywords, one must always ask, "OK, = how > do you do key distribution?" Not practical in many cases, I guess. Well, it depends... But I can certainly use a phrase about key distribution. > Meta-issue here: opportunistic IPsec might leverage DNS records for > storing the keys; I think Teredo doesn't support setting reverse DNS > records at the moment. (Which maybe for the best, considering how > often the addresses would probably change..) Are you proposing using reverse DNS to get a certificate that can be used for IPSEC? Well, I would much rather just say that we need to distribute keys somehow... > The goal of the Teredo service is to provide hosts located behind a > NAT with a globally reachable IPv6 address. There is a possible > class of attacks against this service in which an attacker somehow > intercepts the router solicitation, responds with a spoofed router > advertisement, and provides a Teredo client with an incorrect > address. >=20 > =3D=3D> actually, a more typical attack would be the attacker guessing = the > server address (simple if there are only a few of those), and the IPv4 > address/port of the destination. Then, by appropriate spoofing, a RA > could be injected without getting hold of the RS's. Of course, this > is practically impossible if the Authentication option (just using the > nonces is enough) is included. That's the point. Since we always have a nonce, the attacker needs to intercept the traffic. > The secure qualification procedure described in section 5.2.2 > enables a good protection against attacks in which a third party > tries to spoof the server. >=20 > =3D=3D> how would that secret (if you don't use just nonces) is > distributed? Especially if the server is hosted by someone you don't > have a direct relationship with, you could be in trouble.. The usual. Web services, for example. > protect > against this attack, the secret shared between client and server > should be provisioned by an automatic procedure and contain > sufficient entropy. >=20 > =3D=3D> what are you referring to with "automatic procesdure"? 1) > automatic distribution, or 2) automatic generation of secrets (trying > ot ensure they have good enough entropy, e.g., are subject to e.g., > disctionary attacks) ? >=20 > =3D=3D> I'd again want to note, that using null ID and null > authentication, could still give you the 64bit protection using nonces > -- which is not bad for a use case like this. OK, I wrote text to that effect. > =3D=3D> the authentication encapsulation does not provide replay > protection, at least as specified, but some of this could be fixed I > guess? Actually it does, when combined with the nonce. > 1) Client prepares router solicitation, including authentication > header. >=20 > =3D=3D> s/header/encapsulation/ (or something, to make sure this is = not > IPsec AH) >=20 > 7.3.2 Denial of service by exceeding the number of peers >=20 > A Teredo client manages a cache of recently-used peers, which makes > it stateful. >=20 > =3D=3D> this is a problem of Teredo relay as well, right? Yes, although state can only be initiated from the IPv6 side. > The ICMP Traceback (ITRACE) working group is considering systems > for > "tracing" the source of DOS attacks. According to the proposal, > when > forwarding packets, routers can, with a low probability, generate a > Traceback message that is sent along to the destination; with > enough > Traceback messages from enough routers along the path, the traffic > source and path can be determined. This set up assumes that the > source and destination are both using the same version of IP. In > the > Teredo case, the ICMP Traceback packets will be sent to the Teredo > server, not the final destination. It is conceivable to "map" the > IPv4 traceback to an IPv6 traceback sent by the Teredo server; the > details of the solution should be specified by the ITRACE working > group. >=20 > =3D=3D> unfortunately, the ITRACE WG was closed, and the spec is = pretty > much dead.. so I don't think we can count on this anymore. (The same > issue later in the spec again) >=20 > The exit strategy is facilitated by the nature of Teredo, which > provides an IP level solution. IPv6 aware applications do not have > to be updated to use or not use Teredo. The absence of impact on > the > applications makes it easier to migrate out of Teredo: network > connectivity suffices. >=20 > =3D=3D> The clients migrate out of Teredo, that's correct, but the = actual > problem is how do you retire (host-side, "local") relays? As long as > there are Teredo hosts out there (10 years from now on?) having such a > feature on the box would be useful (with some definition of useful). > What's the exit strategy for these? >=20 OK, added text. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > editorial > --------- >=20 > We propose here a service that enables nodes located behind one or > several IPv4 NATs to obtain IPv6 connectivity by tunneling packets >=20 > =3D=3D> s/one or several/one or more/ (isn't this the more common = usage) ? > (this is in very many places) OK. > several NATs; it also supposes that we can find a way to bypass the > various "per destination protections" that many NATs implement. In >=20 > =3D=3D> add a reference here to section 3.1? Not needed. > The specification is organized as follow. Section 2 contains the >=20 > =3D=3D> s/follow/follows/ >=20 > 2.1 Teredo service >=20 > =3D=3D> 16 subsections, none of which is longer than 1 paragraph, one = for > each term -- they explode the ToC. Maybe remove the subsections and > put these in the body of section 2, otherwise identically? >=20 > A node that has some access to the IPv4 Internet and that wants to > gain access to the IPv6 Internet. >=20 > =3D=3D> remove redundant "that" (the same in a few other examples as = well) > ? >=20 > 2.10 Teredo mapped address and Teredo mapped port >=20 > A global IPv4 address and a UDP port that results from the > translation by one or several NATs of the IPv4 address and UDP port > of a client's Teredo service port. >=20 > =3D=3D> suggest rewording e.g. to be like: >=20 > 2.10 Teredo mapped address and Teredo mapped port >=20 > A global IPv4 address and a UDP port that result from the > translation of the client's IPv4 address and Teredo service port by > one or more NATs. >=20 > ... >=20 > of 30 seconds; a longer value may be determined by local tests, > described in section 5. >=20 > =3D=3D> s/described/as described/ >=20 > Relaying packets over TCP would be possible, but would result in a > very poor quality of service; relaying over UDP is a better choice. >=20 > =3D=3D> s/relaying/encapsulation/ >=20 > on the specified port for a "lifetime" period. The Teredo client > that want to maintain a mapping open in the NAT will have to send >=20 > =3D=3D> s/want/wants/ >=20 > when no traffic is observed is observed on the connection for a >=20 > =3D=3D> remove extra "is observed" >=20 > transition schemes designed by the NGTRANS working group. This >=20 > =3D=3D> v6ops now? >=20 > - Client IPv4: the obfuscated "mapped IPv4 address" of a client >=20 > =3D=3D> s/a client/the client/ >=20 > There are thus two valid values of the Flags field: "0x0000" (all > null) if the cone bit is set to 0, and "0x8000" if the cone bit is > set to 1. >=20 > =3D=3D> remove "valid" or even state like "two currently specified = values" > .. just to spell it out there might be more in the future. >=20 > A third party sends IPv6 packets to a Teredo client by sending these > packets over UDP to the mapped IPv4 address and port of the client > if the cone bit is set, or if the third party has recently received > direct traffic from the client. In the other cases, the third party > will have to first synchronize with the client, by sending an > initial bubble through the server. >=20 > =3D=3D> this seems to be mostly outside the scope of Teredo address > specification, so one should either remove it or add references to the > fuller specification later on in the draft. >=20 > 5.1.1 Teredo IPv6 packets encapsulation >=20 > =3D=3D> s/packets/packet/ >=20 > +--------+--------+--------+--------+ > | 0x00 | 0x01 | ID-len | AU-len | > +--------+--------+--------+--------+ > | Client identifier (ID-len | > +-----------------+-----------------+ > | octets) | Authentication | > +-----------------+--------+--------+ > | value (AU-len octets) | Nonce | > +--------------------------+--------+ > | value (8 octets | > +--------------------------+--------+ > | | Conf. | > +--------------------------+--------+ >=20 > =3D=3D> I'd really try to aim for using the typical "nice" figures = such as > the the ones used in RFC2461, RFC2463, etc. >=20 > the client may use the > Teredo service port to transmit and receive IPv6 packets, according > to the transmission and reception procedures; these procedures use > the "list of recent peers". For each peer, the list contains: >=20 > =3D=3D> s/; t/. T/ ? >=20 > +----+----+ > | Set C=3D1 | > +----+----+ >=20 > =3D=3D> make more explicit that C means Cone bit? >=20 > /---------\ Timer | ^ > |Starting |-------+ N attempts /----------\ Yes | > \---------/------------------->| C =3D=3D 1 ? |-----+ > | Response \----------/ >=20 > =3D=3D> does "N attempts" refer to moving from "Starting" to "Start", = or > to "C =3D=3D 1?" state? Maybe reorganize the text a bit? >=20 > /-----------------\ > | Restricted NAT | > \-----------------/ >=20 > =3D=3D> restricted cone NAT you mean? >=20 > When the interface is initialized, the system first performs the > "start action" by sending a Router Solicitation message, as defined > in [RFC2461]. The client picks a link-local address and uses it as > the IPv6 source of the message; the "cone" bit in the address is set > to 1; >=20 > =3D=3D> maybe refer to sect 4? >=20 > 3) If the source IPv6 address is a Teredo address, the client > compares the mapped IPv4 address and mapped port in the source > address with the source IPv4 address and source port of the packet. >=20 > =3D=3D> s/source address/IPv6 source address/ ? >=20 > and local peer port parameters to reflect the IPv4 source address > and UDP source port of the bubble the last reception date to the >=20 > =3D=3D> s/bubble/bubble,/ >=20 > When it wants to send a packet to an IPv6 node on the IPv6 Internet, > the client should check whether a valid peer entry already exists >=20 > =3D=3D> swap "it" and "the client" here. >=20 > destination. The ICMPv6 packet will then be sent encapsulated in a > UDP packet bound to the local server IPv4 address, and to the Teredo > port. The rules of section 5.2.3 specify how the reception of this > packet will be processed. >=20 >=20 > =3D=3D> s/bound/destined/ ? > =3D=3D> s/local server IPv4/Teredo server/ ? > =3D=3D> s/reception of/reply to/ ? >=20 > It is in many cases possible to work around the limitations of > these >=20 > =3D=3D> s/It is in many cases/In many cases, it is/ ? >=20 > - The source IPv4 address is the server's IPv4 address. >=20 > =3D=3D> s/server's IPv4/Teredo server/ (same in a couple of other = places) >=20 > If the cone bit of the > client's IPv6 address is set to 1, the RA must be sent from a > different IPv4 source address than the server address over which the > RS was received; if the cone bit is set to zero, the response must > be sent back from the same address. >=20 > =3D=3D> this has some operationa requirements (i.e., the server having > more than one address), which should be spelled out (already commented > for section 5.3) >=20 > Teredo relays are IPv6 routers that advertise reachability of the > Teredo service IPv6 prefix through the IPv6 routing protocols. >=20 > =3D=3D> or not, in the case of local relays.. >=20 > When a Teredo relay has to transmit a packet to a Teredo client, it > examines the destination IPv6 address. By definition, the Teredo > relays will only send over UDP IPv6 packets whose IPv6 destination > address is a valid Teredo IPv6 address. Before processing these > packets, the Teredo Server MUST check that the IPv4 destination >=20 > =3D=3D> split a new paragraph before "Before" ? >=20 > It may be desirable in some cases to deploy stateful tunnel servers > instead of the stateless Teredo servers. Tunnels servers generally >=20 > =3D=3D> s/Tunnels/Tunnel/ >=20 > capacity. In summary, the attack is very hard to mount, and the > gain > for the attacker is minimal. >=20 > =3D=3D> s/gain/additional gain/ ? >=20 > its IPv6 traffic, using IPSEC. Even if the IPv4 and UDP headers are > vulnerable, the use of IPSEC will effectively prevent spoofing and >=20 > =3D=3D> s/IPSEC/IPsec/ (everywhere) >=20 > 8.3.1 Denial of service by server spoofing >=20 > In section 8.2, we discussed the use of spoofed router >=20 > =3D=3D> s/8.3/7.3/, s/8.2/7.2/ ? >=20 > non existing IPv4 address or to the IPv4 address of a third party. >=20 > =3D=3D> s/non/non-/ >=20 > 7.4.1 Laundering DOS attacks from IPv4 to IPv4 >=20 > =3D=3D> s/DOS/DoS/ >=20 > on their treatment of UDP; the mappings need to be continuously > refreshed, while the ; and addressing structure may cause some > hosts >=20 > =3D=3D> something missing around ";" >=20 OK, done all that. From owner-v6ops@ops.ietf.org Wed Jun 9 21:57:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11002 for ; Wed, 9 Jun 2004 21:57:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYEnV-000HeN-1w for v6ops-data@psg.com; Thu, 10 Jun 2004 01:56:05 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYEnR-000Hdo-2k for v6ops@ops.ietf.org; Thu, 10 Jun 2004 01:56:01 +0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5A1tf57000757; Wed, 9 Jun 2004 18:55:42 -0700 (PDT) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5A1sjBu018998; Wed, 9 Jun 2004 18:55:34 -0700 (PDT) Received: from NAEX02.qualcomm.com ([129.46.50.141]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 18:55:14 -0700 Received: from mail pickup service by NAEX02.qualcomm.com with Microsoft SMTPSVC; Wed, 9 Jun 2004 18:55:45 -0700 Received: from NAEXFE01.na.qualcomm.com ([172.30.32.17]) by NAEX02.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 16:56:12 -0700 Received: from neophyte.qualcomm.com ([129.46.61.149]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 16:54:51 -0700 Received: from hobbiton.qualcomm.com (hobbiton.qualcomm.com [199.106.114.69]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i59Nsl4K011254; Wed, 9 Jun 2004 16:54:48 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by hobbiton.qualcomm.com (qualnet-external) with ESMTP id i59Nsh1q022816; Wed, 9 Jun 2004 16:54:43 -0700 (PDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYCfz-000P59-8C for v6ops-data@psg.com; Wed, 09 Jun 2004 23:40:11 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYCfw-000P4a-46 for v6ops@ops.ietf.org; Wed, 09 Jun 2004 23:40:09 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 16:40:06 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Jun 2004 16:40:07 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 16:41:02 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 9 Jun 2004 16:40:06 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 9 Jun 2004 16:40:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: huitema-v6ops-teredo-01 comments Date: Wed, 9 Jun 2004 16:40:05 -0700 Message-ID: Thread-Topic: huitema-v6ops-teredo-01 comments Thread-Index: AcQFD68zYlfdFi3PQ8yODBmLHJbApAAKR7Bw From: "Christian Huitema" To: "Pekka Savola" , "Eiffel Wu" Cc: X-OriginalArrivalTime: 09 Jun 2004 23:40:15.0649 (UTC) FILETIME=[1D862110:01C44E7B] X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.6.9.103144 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A long time ago, Pekka sent to the list a detailed review of the Teredo draft. I have just submitted draft-huitema-v6ops-teredo-02.txt that addresses these comments, and also fixes a typo found by Eiffel Wu in the qualification procedure diagram. Thanks to both reviewers. What follows is a detailed reply to Pekka's comments.=20 -- Christian Huitema > substantial > ----------- >=20 > 1) sect 5.2.1, qualification procedure seems to yield either cone NAT, > restricted cone NAT or symmetric NAT. What about port-restricted cone > NATs? Are these implicitly covered in some terminology here? They > don't seem to be explicitly mentioned anywhere! Yes, restricted and port restricted are treated the same way. I will make that explicit in the revision. > 2) security considerations should discuss that MD5 is not anymore > considered "secure" due to better collision-resistance of SHA1. > However, in this specific case, I don't think this is a huge problem. I will rewrite the text to indicate that MD5 is just a convenient default, but that client and servers can agree on a different algorithm. The packet format already allows for variable length authentication checks, and the key has to be provisioned explicitly in the client, so we could conceivably provision both the key and the algorithm, and just leave it a configuration option. But the main threat is a dictionary attack, for which there is no difference between MD5 and SHA1. > 3) I think this document seriously needs an "overview" section, around > section 4, which could be e.g. 2-4 pages, trying to summarize the > whole operation while leaving out the details with figures, etc. -- > whatever appropriate. The spec is rather compact and requires careful > reading to understand its implications. Having such a section (as > there was before, but it was removed, I think) would be very useful > for those who want to get a good overview of how the mechanism works. The problem with the previous version was that it introduced confusion -- implementers were confused as to which part was normative, the overview or the protocol specification. > 4) what's the implementation status? to what degree do the > implementation(s) reflect the current spec? I have a few thoughts for > improvements if certain parts of the spec would not be implemented yet > (e.g., the authentication encapsulation), but if they are, making such > changes might not be feasible. The specification tries to closely reflect the existing implementations. > 5) an interesting deployment model could be deploying a > Teredo-cognizant tunnel broker at the teredo anycast address, > basically "hijacking" all the teredo users as your tunnel broker > customers -- requiring no tunnel broker implementations at the client > side. This would be a rather interesting way to leverage the existing > implementations to provide tunnel broker service :-). There is no Teredo anycast address, but I see the idea: have the client automatically discover whether the Teredo server is willing to act as a tunnel end-point. In that case, the client would go for a classic tunnel mode.=20 > 6) this doc probably needs a bit more applicability etc. work but > that's something that can be inserted a bit later on as well. >=20 > semi-editorial/substatial > ------------------------- >=20 > Abstract >=20 > We propose here a service that enables nodes located behind one or > several IPv4 NATs to obtain IPv6 connectivity by tunneling packets > over UDP; we call this the Teredo service. Running the service > requires the help of "Teredo servers" and "Teredo relays"; the > Teredo servers are stateless, and only have to manage a small > fraction of the traffic between Teredo clients; the Teredo relays > act as IPv6 routers between the Teredo service and the "native" IPv6 > Internet. >=20 > =3D=3D> the last sentence is not accurate when you take also the "6to4 > universe" into account -- needs rewording somehow? OK. > A possible way to solve the problem is to rely on a set of "tunnel > brokers." There are however limits to any solution that is based on > such brokers: the quality of service is not very good, since the > traffic follows a "dog leg" route from the source to the broker and > then the destination; the broker has to provide sufficient > transmission capacity to relay all packets and thus suffers a high > cost. For these two reasons, we tend to prefer solutions that allow > for "automatic tunneling", i.e. let the packets follow a direct path > to the destination. >=20 > =3D=3D> I'd reword this to a bit softer, because tunnel brokers are > actually useful in some contexts: > =3D=3D> s/is not very good/may be limited/ > =3D=3D> s/we tend to prefer/it may be desirable to have/ OK. > 2.8 Teredo service port >=20 > The port through which the Teredo client sends Teredo packets. This > port is attached to one of the client's IPv4 interfaces. The IPv4 > address may or may not be globally routable, as the client may be > located behind one or several NAT. >=20 > =3D=3D> ports are not attached to interfaces. They may be attached to > addresses only. So, maybe rename "Teredo service port" to "Teredo > service address/port" or whatever, and reword the text a bit? I reworded to mention binding to a specific address. > Experience shows that the implementers of NAT devices can adopt > widely different treatments of UDP mappings: >=20 > =3D=3D> if this has been analyzed at more length elsewhere, I'd refer = to > that work for additional information. Later in the document, RFC3489 > is cited as one source, at least. OK, done that. > 3) Instead of keeping just a list of authorized hosts, some NAT > implementations keep a list of authorized host and port pairs. UDP > packets coming from remote addresses are rejected if the internal > host has not yet sent traffic to the outside host and port pair. The > NATs are often called "port-restricted cone NATs" >=20 > =3D=3D> I've always had problems figuring out what this means. I = suggest > adding a new second-to-last sentence: >=20 > That is, as long as the internal host has communicated with a (host, > port) pair, the created NAT mapping (to some other host or port) can > be used to inject incoming packets to the internal host. Replaced by a pointer to STUN/RFC3489. > 3.2.1 When to use Teredo? >=20 > Teredo is designed to robustly enable IPv6 traffic through NATs, and > the price of robustness is a reasonable amount of overhead, due to > UDP encapsulation and transmission of bubbles. Nodes that want to > connect to the IPv6 Internet SHOULD only use the Teredo service as a > "last resort" option: they SHOULD prefer using direct IPv6 > connectivity if it is locally available or if it is provided by a > 6to4 router co-located with the local NAT, and they SHOULD prefer > using the less onerous "6to4" encapsulation if they can use a global > IPv4 address. >=20 > =3D=3D> this doesn't yet describe tunnel service (details TBD at the > moment) at all -- it is also a preferable choice. OK, added text. > 4 Teredo Addresses >=20 > =3D=3D> I'd consider separating this to two subsection, global and > link-local addresses -- as these seem to have slightly different > characteristics. >=20 > - The bits indicated with "z" must be set to zero. >=20 > =3D=3D> s/set to zero/sent as zero and ignored on receipt/ ? OK. > The Teredo relay advertises reachability of the Teredo service > prefix over IPv6. It forwards Teredo IPv6 packets to the appropriate > IPv4 address and UDP port. >=20 > =3D=3D> local relays don't do the first. This has been ignored in a = few > other places in the document as well. OK. > The following 16 bits contain the obfuscated value of the port > number from which the packet was received, in network byte order. > The next 32 bits contain the obfuscated IPv4 address from which the > packet was received, in network byte order. In this format, both the > original "IPv4 address" and "UDP port" of the client are obfuscated. > Each bit in the address and port number is reversed; this can be > done by an exclusive OR of the 16-bit port number with the > hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address > with the hexadecimal value 0xFFFFFFFF. >=20 > For example, if the original UDP port number was 337 (hexadecimal > 0151) and original IPv4 address was 1.2.3.4 (hexadecimal: 01020304), > the origin indication would contain the value "0000FEAEFEFDFCFB". >=20 > =3D=3D> this obfuscation code has been described in two places -- = maybe it > would make sense to put it in a subsection or something, so it could > be referred to more easily when it's used later on in the draft? I find simpler to leave it as is. > The third octet indicates the length of > the client identifier; the fourth octet indicates the length of > the authentication value. >=20 > =3D=3D> is zero client ID OK as well? The same about authentication > value? (these could be useful if you'd only want "return routability" > like anonymous testing, where you'd only want to use nonces. Yes. > =3D=3D> these octets give the length in the units of bytes, correct? = (make > explicit) OK. > In > accordance with [RFC2461], the default time-out value is set to = T=3D4 > seconds, and the maximum number of repetitions is set to N=3D3. >=20 > =3D=3D> this seems quite long, and I don't see how RFC2461 relates = here. > Maybe e.g. T=3D2, N=3D1 would be sufficient? We are performing an RS/RA exchange, so the value in RFC2641 apply. If 4 seconds is a proper value on an Ethernet, why should we pick a lower value on a longer-delay network? > option. This prefix should be a valid Teredo IPv6 server prefix: the > first 32 bits should contain the global Teredo IPv6 service prefix, > and the next 32 bits should contain the server's IPv4 address. If > this is the case, the client learns the Teredo mapped address and >=20 > =3D=3D> "global" --> remove that, could be local as well? Uh, no. Unless we define a brand new /32 that has no global meaning. > If the client has received an RA with the "Cone" bit set to 1, it is > behind a cone NAT and is fully qualified. If the RA is received with > the Cone bit set to 0, the client does not know whether the local > NAT is restricted or symmetric. The client selects a secondary IPv4 > server address, and repeats the procedure, the cone bit remaining to > the value zero. >=20 > =3D=3D> there are multiple places where Cone bit can be set, so maybe > reword like: >=20 > If the client has received an RA with the "Cone" bit in the > advertised prefix set to 1, it is behind a cone NAT and is fully > qualified. If the RA is received with the Cone bit in the > advertised prefix set to 0, the client does not know whether the > local NAT is restricted or symmetric. The client selects a > secondary IPv4 server address, and repeats the procedure, the cone > bit in the link-local address remaining to the value zero. >=20 > .... I checked the text a bit. > indication. The cone bit should be set to the value used to receive > the RA, i.e. 1 if the client is behind a cone NAT, 0 otherwise. The >=20 > =3D=3D> s/to receive the RA/in the RA/ ? Or am I confused about cone = bit > in the prefix vs. link-local address? It is in the address. > When a UDP packet is received over the Teredo service port, the > Teredo client checks that it is encoded according to the packet > encoding rules defined in 5.1.1, and that it contains either a valid > IPv6 packet as specified in [RFC2460], >=20 > =3D=3D> you must spell out what exactly to check, as RFC2460 does not > specify what is a "valid IPv6 packet". The same happens a lot later > in the spec as well. OK. =20 > if an origin indication is > present, the client should perform the "direct IPv6 connectivity > test" described in section 5.2.9. >=20 > =3D=3D> should you use more uppercase keywords, e.g., in here, but in > several other places as well? Matter of taste, I guess... > If the values match, the packet > should be accepted; the date and time of the last reception from the > peer should be updated. >=20 > =3D=3D> s/should be/is/ ? OK. >=20 > 2) If there is an entry for the source IPv6 address in the list of > peers whose status is not trusted, the client checks whether the > packet is an ICMPv6 echo reply. If this is the case, and if the > content of the reply matches the "nonce" stored in the peer entry, > the packet should be accepted; >=20 > =3D=3D> s/content/ICMPv6 data/ OK. > any packet queued for this IPv6 > peer should be de-queued and forwarded to the newly learned IPv4 > address and UDP port. >=20 > =3D=3D> add a pointer to 5.2.4 around queuing? >=20 > 4) If the source IPv6 address is a Teredo address, and the mapped > IPv4 address and mapped port in the source address do not match the > source IPv4 address and source port of the packet, the client checks > whether the is an existing "local" entry for that IPv6 address. If > there is such an entry, and if the local IPv4 address and local port > indicated in that entry match the source IPv4 address and source > port of the packet, the client updates the "local" entry, whose > status should be set to "trusted". If the packet is a bubble, it > should be discarded after this processing; otherwise, the packet > should be accepted. In all cases, the client must de-queue and > forward any packet queued for that destination. >=20 > =3D=3D> and what if there is no such entry? do nothing? Rearranged the order of paragraphs so the "what else" case is clearly described in "6) In the other cases, ..." > 5) If the IPv4 destination address through which the packet was > received is the Teredo IPv4 Discovery Address, the source address is >=20 > =3D=3D> add a note here stating that this procedure is optional. OK. > 2) If the destination is not a Teredo IPv6 address, the packet is > queued, and the client performs the "direct IPv6 connectivity test" > described in section 5.2.8. The packet will be de-queued and >=20 > =3D=3D> s/5.2.8/5.2.9/ OK. > 5.2.6 Sending Teredo Bubbles >=20 > =3D=3D> this section should also discuss "indirect bubbles" (as = introduced > in 5.2.4) and how they're sent. OK. > the client MUST create a new list entry for the address, > setting the last reception date and the last transmission date to 30 > seconds before the current date, and the number of bubbles to zero. >=20 > =3D=3D> umm.. why exactly are you setting the dates to 30 seconds in = the > history?? So we do not engage in futile immediate retransmission... > The secondary port MUST NOT be used for any other purpose than the > interval determination procedure. If a spurious packet is received on > the secondary port, the client SHOULD repeat the maintenance > procedure on this port and reset the date and time of the last > interaction on the secondary port. >=20 > =3D=3D> umm,, this would seem to hint at an implementation technique, > where you'd be continously listening at the secondary port. I fail to > see the need for that -- this is only done when you start up Teredo > (if it's implemented that is). Rather, just specify that the port is > closed when the procedure ends? OK. > A Teredo client who wishes to enable local discovery SHOULD wait for > discovery bubbles to be received on the Teredo IPv4 Discovery > Address, and should send local discovery bubbles to the Teredo IPv4 > Discovery Address at random intervals >=20 > =3D=3D> which -- wait _or_ send? Or both? Make it more explicit. = Maybe > just say that one should join the group. OK. > - IPv6 source: the Teredo IPv6 address of the sender >=20 > =3D=3D> is this the global or link-local address? Global. > 5.3 Teredo Server specification >=20 > =3D=3D> you should really add text here describing the forwarding of > ICMPv6 probes, and bubbles between Teredo and non-Teredo nodes. >=20 > =3D=3D> also, you should mention the requirement about the secondary > address on the server. Done. > Upon reception of a packet on the Teredo port, the Teredo server > will first check that the UDP payload contains a valid IPv6 packet; > if this is not the case, the packet will be silently discarded. >=20 > Before processing the packet, the Teredo server MUST check the > validity of the encapsulated IPv6 source address, the IPv4 source > address and the UDP source port: >=20 > 1) If the UDP content is not a well formed IPv6 packet, the packet > MUST be silently discarded. >=20 > =3D=3D> isn't the first paragraph unnecessary, compared to 1)? > =3D=3D> you don't define well-formed? OK. > 2) If the UDP packet is not a bubble or an ICMPv6 message, it should > be discarded. >=20 > =3D=3D> should probably add a pointer for the definition of a bubble. Replaced by "Teredo bubble", which is defined in section 2. > =3D=3D> should you use upper-case keywords in a place like this? OK. > 4) If the IPv6 source address is an IPv6 link-local address, the > IPv6 destination address is the link-local scope all routers > multicast address (FF02::2), and the packet contains an ICMPv6 > Router Solicitation message, the packet SHOULD be accepted; it > MUST be discarded if the server requires secure qualification and > the authentication encapsulation is absent or cannot be verified. >=20 > =3D=3D> SHOULD be accepted? What's the alternative -- discard them? > Shouldn't this be a mandatory part? (Same later in 5) and 6) > =3D=3D> s/cannot be verified/verification fails/ ? Ok. > The Teredo server will then check the IPv6 destination address of > the encapsulated IPv6 packet. >=20 > =3D=3D> s/./:/ > =3D=3D> maybe the following paragraphs should be similarly separated = to > 1), 2) and 3) for clarity? >=20 > If the IPv6 destination address is a valid Teredo IPv6 address, the > Teredo Server MUST check that the IPv4 address derived from this > IPv6 address is in the format of a global unicast address >=20 > =3D=3D> a link-local address is also a valid Teredo address, right? = But > not applicable here? Maybe needs spelling out which specific address > type? OK, added reference to 2.13. > If the destination IPv6 address is a Teredo client whose address is > serviced by this specific server, the server should insert an origin > indication in the first bytes of the UDP payload, as specified in > section 5.1.1. >=20 > =3D=3D> how can the server know which addresses it's supposed to be > servicing? Or are you really saying, "if received through the Teredo > interface.." ? If the client is served by this server, the server's IPv4 address is copied in bits 32-63 of the client's Teredo IPv6 address. > The IPv6 source address should > be set to a Teredo link-local server address associated to the local > interface. >=20 > =3D=3D> how exactly did you form the LL address on the server? What = about > the C-bit? >=20 > However, Teredo relays do not have to > perform the qualification procedure. >=20 > [...] > In cases 2 and 3, the Teredo relay should create a peer entry for > the IPv6 address; the entry status is marked as trusted in case 2 > (cone NAT), not trusted in case 3. In case 3, if the Teredo relay > happens to be located behind a non-cone NAT, it should also send a > bubble directly to the mapped IPv4 address and mapped port number of > the Teredo destination; this will "open the path" for the return > bubble from the Teredo client. >=20 > =3D=3D> aren't these in conflict? The relay don't know which NAT it's > behind unless it has run qualification procedure? OK, I removed the "do not have" phrase. > 1) If there is an entry for that IPv6 address in the list of peers, > and if the status of the entry is set to "trusted", the IPv6 packet > should be sent over UDP to the mapped IPv4 address and mapped UDP > port of the entry. The client updates the date of last transmission > in the peer entry. >=20 > =3D=3D> hmm.. could the list of peers information be stale, or is it > purged often enough so that if the NAT mapping of a host changes, > there won't be communication with it directly? Are there fallbacks? If the NAT mapping of the host changes, its Teredo address also changes, so the fallback occurs very naturally... >=20 > Then, the Teredo relay examines whether the IPv6 source address is a > valid Teredo address, and if the mapped IPv4 address and mapped port > match the IPv4 source address and port number from which the packet > is received. If this is not the case, the packet is silently > discarded. >=20 > =3D=3D> I've trouble figuring out how this would work -- maybe I'm > confused. I mean, when the Teredo client sends toward different IPv4 > destination addresses, new mappings are created in the NAT for each -- > and this is by definition different from the one which is learned by > the Teredo client from the Teredo Server? No. If the NAT is cone or restricted cone, then the mappings are always the same. They change if the NAT is symmetric, but we do not support that. > Finally, the relay examines the destination IPv6 address. If the > destination is the "all nodes multicast address", the packet should > be processed locally. >=20 > =3D=3D> why this rule? Humm. Unclear. Probably had to do with combining a relay and a client. I removed it. > The dual-role of server and relays implies an additional complexity > for the programming of servers: the processing of incoming packets > should be a combination of the server processing rules defined in > 5.3.1, and the relay processing rules defined in 5.4.2. >=20 > =3D=3D> this text is not clear enough on whether section 5.3 on Teredo > servers already includes all the functionalitty required of Teredo > servers + relays, or whether you need to combine 5.3+5.4 to get > server+relay? OK, added text. >=20 > Most Teredo servers > will not be expected to operate more than a few years, perhaps until > at most 2006. >=20 > =3D=3D> umm, isn't this awfully optimistic? :) Well, we have a time limit of 6/6/6 for the current prefix, don't we? We could indeed make that 6/6/66 if you want... =20 > The very purpose of the Teredo service is to make a machine > reachable through IPv6. By definition, the machine using the > service > will give up whatever "firewall" service was available in the NAT > box; all services declared locally will become potential target of > attacks from the entire IPv6 Internet. This may sound scary, but > there are three mitigating factors. >=20 > =3D=3D> "all services declared locally" is a bit short, maybe spell it > out? Maybe also missing a word or two? OK. >=20 > The first mitigating factor is the possibility to restrict some > services to only accept traffic from one of the limited address > scopes defined in IPv6, e.g. link-local or site-local. >=20 > =3D=3D> using link-locals w/ apps is IMHO pretty bad practice, and > site-locals are gone. please update :) Link local is actually used with some "home network" applications. I have removed the reference to site-local. > There is no > support for such scopes in Teredo, which implies that limited-scope > services will not be accessed through Teredo, and will be > restricted > to whatever other IPv6 connectivity may be available, e.g. direct > traffic with neighbors on the local link, behind the NAT. >=20 > =3D=3D> these also have teredo addresses, which go through the teredo > server, etc. -- not from the same namespace, unless you configure them > manually or using some other process.. >=20 > The third mitigating factor, already noted, is the availability of > end-to-end connectivity, which allows for deployment of IP security > services such as IKE, AH or ESP. Using these services in > conjunction > with Teredo is a good policy, as it will protect the client from > possible attacks in intermediate servers such as the NAT, the > Teredo > server, or the Teredo relay. >=20 > =3D=3D> when you use these magic keywords, one must always ask, "OK, = how > do you do key distribution?" Not practical in many cases, I guess. Well, it depends... But I can certainly use a phrase about key distribution. > Meta-issue here: opportunistic IPsec might leverage DNS records for > storing the keys; I think Teredo doesn't support setting reverse DNS > records at the moment. (Which maybe for the best, considering how > often the addresses would probably change..) Are you proposing using reverse DNS to get a certificate that can be used for IPSEC? Well, I would much rather just say that we need to distribute keys somehow... > The goal of the Teredo service is to provide hosts located behind a > NAT with a globally reachable IPv6 address. There is a possible > class of attacks against this service in which an attacker somehow > intercepts the router solicitation, responds with a spoofed router > advertisement, and provides a Teredo client with an incorrect > address. >=20 > =3D=3D> actually, a more typical attack would be the attacker guessing = the > server address (simple if there are only a few of those), and the IPv4 > address/port of the destination. Then, by appropriate spoofing, a RA > could be injected without getting hold of the RS's. Of course, this > is practically impossible if the Authentication option (just using the > nonces is enough) is included. That's the point. Since we always have a nonce, the attacker needs to intercept the traffic. > The secure qualification procedure described in section 5.2.2 > enables a good protection against attacks in which a third party > tries to spoof the server. >=20 > =3D=3D> how would that secret (if you don't use just nonces) is > distributed? Especially if the server is hosted by someone you don't > have a direct relationship with, you could be in trouble.. The usual. Web services, for example. > protect > against this attack, the secret shared between client and server > should be provisioned by an automatic procedure and contain > sufficient entropy. >=20 > =3D=3D> what are you referring to with "automatic procesdure"? 1) > automatic distribution, or 2) automatic generation of secrets (trying > ot ensure they have good enough entropy, e.g., are subject to e.g., > disctionary attacks) ? >=20 > =3D=3D> I'd again want to note, that using null ID and null > authentication, could still give you the 64bit protection using nonces > -- which is not bad for a use case like this. OK, I wrote text to that effect. > =3D=3D> the authentication encapsulation does not provide replay > protection, at least as specified, but some of this could be fixed I > guess? Actually it does, when combined with the nonce. > 1) Client prepares router solicitation, including authentication > header. >=20 > =3D=3D> s/header/encapsulation/ (or something, to make sure this is = not > IPsec AH) >=20 > 7.3.2 Denial of service by exceeding the number of peers >=20 > A Teredo client manages a cache of recently-used peers, which makes > it stateful. >=20 > =3D=3D> this is a problem of Teredo relay as well, right? Yes, although state can only be initiated from the IPv6 side. > The ICMP Traceback (ITRACE) working group is considering systems > for > "tracing" the source of DOS attacks. According to the proposal, > when > forwarding packets, routers can, with a low probability, generate a > Traceback message that is sent along to the destination; with > enough > Traceback messages from enough routers along the path, the traffic > source and path can be determined. This set up assumes that the > source and destination are both using the same version of IP. In > the > Teredo case, the ICMP Traceback packets will be sent to the Teredo > server, not the final destination. It is conceivable to "map" the > IPv4 traceback to an IPv6 traceback sent by the Teredo server; the > details of the solution should be specified by the ITRACE working > group. >=20 > =3D=3D> unfortunately, the ITRACE WG was closed, and the spec is = pretty > much dead.. so I don't think we can count on this anymore. (The same > issue later in the spec again) >=20 > The exit strategy is facilitated by the nature of Teredo, which > provides an IP level solution. IPv6 aware applications do not have > to be updated to use or not use Teredo. The absence of impact on > the > applications makes it easier to migrate out of Teredo: network > connectivity suffices. >=20 > =3D=3D> The clients migrate out of Teredo, that's correct, but the = actual > problem is how do you retire (host-side, "local") relays? As long as > there are Teredo hosts out there (10 years from now on?) having such a > feature on the box would be useful (with some definition of useful). > What's the exit strategy for these? >=20 OK, added text. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > editorial > --------- >=20 > We propose here a service that enables nodes located behind one or > several IPv4 NATs to obtain IPv6 connectivity by tunneling packets >=20 > =3D=3D> s/one or several/one or more/ (isn't this the more common = usage) ? > (this is in very many places) OK. > several NATs; it also supposes that we can find a way to bypass the > various "per destination protections" that many NATs implement. In >=20 > =3D=3D> add a reference here to section 3.1? Not needed. > The specification is organized as follow. Section 2 contains the >=20 > =3D=3D> s/follow/follows/ >=20 > 2.1 Teredo service >=20 > =3D=3D> 16 subsections, none of which is longer than 1 paragraph, one = for > each term -- they explode the ToC. Maybe remove the subsections and > put these in the body of section 2, otherwise identically? >=20 > A node that has some access to the IPv4 Internet and that wants to > gain access to the IPv6 Internet. >=20 > =3D=3D> remove redundant "that" (the same in a few other examples as = well) > ? >=20 > 2.10 Teredo mapped address and Teredo mapped port >=20 > A global IPv4 address and a UDP port that results from the > translation by one or several NATs of the IPv4 address and UDP port > of a client's Teredo service port. >=20 > =3D=3D> suggest rewording e.g. to be like: >=20 > 2.10 Teredo mapped address and Teredo mapped port >=20 > A global IPv4 address and a UDP port that result from the > translation of the client's IPv4 address and Teredo service port by > one or more NATs. >=20 > ... >=20 > of 30 seconds; a longer value may be determined by local tests, > described in section 5. >=20 > =3D=3D> s/described/as described/ >=20 > Relaying packets over TCP would be possible, but would result in a > very poor quality of service; relaying over UDP is a better choice. >=20 > =3D=3D> s/relaying/encapsulation/ >=20 > on the specified port for a "lifetime" period. The Teredo client > that want to maintain a mapping open in the NAT will have to send >=20 > =3D=3D> s/want/wants/ >=20 > when no traffic is observed is observed on the connection for a >=20 > =3D=3D> remove extra "is observed" >=20 > transition schemes designed by the NGTRANS working group. This >=20 > =3D=3D> v6ops now? >=20 > - Client IPv4: the obfuscated "mapped IPv4 address" of a client >=20 > =3D=3D> s/a client/the client/ >=20 > There are thus two valid values of the Flags field: "0x0000" (all > null) if the cone bit is set to 0, and "0x8000" if the cone bit is > set to 1. >=20 > =3D=3D> remove "valid" or even state like "two currently specified = values" > .. just to spell it out there might be more in the future. >=20 > A third party sends IPv6 packets to a Teredo client by sending these > packets over UDP to the mapped IPv4 address and port of the client > if the cone bit is set, or if the third party has recently received > direct traffic from the client. In the other cases, the third party > will have to first synchronize with the client, by sending an > initial bubble through the server. >=20 > =3D=3D> this seems to be mostly outside the scope of Teredo address > specification, so one should either remove it or add references to the > fuller specification later on in the draft. >=20 > 5.1.1 Teredo IPv6 packets encapsulation >=20 > =3D=3D> s/packets/packet/ >=20 > +--------+--------+--------+--------+ > | 0x00 | 0x01 | ID-len | AU-len | > +--------+--------+--------+--------+ > | Client identifier (ID-len | > +-----------------+-----------------+ > | octets) | Authentication | > +-----------------+--------+--------+ > | value (AU-len octets) | Nonce | > +--------------------------+--------+ > | value (8 octets | > +--------------------------+--------+ > | | Conf. | > +--------------------------+--------+ >=20 > =3D=3D> I'd really try to aim for using the typical "nice" figures = such as > the the ones used in RFC2461, RFC2463, etc. >=20 > the client may use the > Teredo service port to transmit and receive IPv6 packets, according > to the transmission and reception procedures; these procedures use > the "list of recent peers". For each peer, the list contains: >=20 > =3D=3D> s/; t/. T/ ? >=20 > +----+----+ > | Set C=3D1 | > +----+----+ >=20 > =3D=3D> make more explicit that C means Cone bit? >=20 > /---------\ Timer | ^ > |Starting |-------+ N attempts /----------\ Yes | > \---------/------------------->| C =3D=3D 1 ? |-----+ > | Response \----------/ >=20 > =3D=3D> does "N attempts" refer to moving from "Starting" to "Start", = or > to "C =3D=3D 1?" state? Maybe reorganize the text a bit? >=20 > /-----------------\ > | Restricted NAT | > \-----------------/ >=20 > =3D=3D> restricted cone NAT you mean? >=20 > When the interface is initialized, the system first performs the > "start action" by sending a Router Solicitation message, as defined > in [RFC2461]. The client picks a link-local address and uses it as > the IPv6 source of the message; the "cone" bit in the address is set > to 1; >=20 > =3D=3D> maybe refer to sect 4? >=20 > 3) If the source IPv6 address is a Teredo address, the client > compares the mapped IPv4 address and mapped port in the source > address with the source IPv4 address and source port of the packet. >=20 > =3D=3D> s/source address/IPv6 source address/ ? >=20 > and local peer port parameters to reflect the IPv4 source address > and UDP source port of the bubble the last reception date to the >=20 > =3D=3D> s/bubble/bubble,/ >=20 > When it wants to send a packet to an IPv6 node on the IPv6 Internet, > the client should check whether a valid peer entry already exists >=20 > =3D=3D> swap "it" and "the client" here. >=20 > destination. The ICMPv6 packet will then be sent encapsulated in a > UDP packet bound to the local server IPv4 address, and to the Teredo > port. The rules of section 5.2.3 specify how the reception of this > packet will be processed. >=20 >=20 > =3D=3D> s/bound/destined/ ? > =3D=3D> s/local server IPv4/Teredo server/ ? > =3D=3D> s/reception of/reply to/ ? >=20 > It is in many cases possible to work around the limitations of > these >=20 > =3D=3D> s/It is in many cases/In many cases, it is/ ? >=20 > - The source IPv4 address is the server's IPv4 address. >=20 > =3D=3D> s/server's IPv4/Teredo server/ (same in a couple of other = places) >=20 > If the cone bit of the > client's IPv6 address is set to 1, the RA must be sent from a > different IPv4 source address than the server address over which the > RS was received; if the cone bit is set to zero, the response must > be sent back from the same address. >=20 > =3D=3D> this has some operationa requirements (i.e., the server having > more than one address), which should be spelled out (already commented > for section 5.3) >=20 > Teredo relays are IPv6 routers that advertise reachability of the > Teredo service IPv6 prefix through the IPv6 routing protocols. >=20 > =3D=3D> or not, in the case of local relays.. >=20 > When a Teredo relay has to transmit a packet to a Teredo client, it > examines the destination IPv6 address. By definition, the Teredo > relays will only send over UDP IPv6 packets whose IPv6 destination > address is a valid Teredo IPv6 address. Before processing these > packets, the Teredo Server MUST check that the IPv4 destination >=20 > =3D=3D> split a new paragraph before "Before" ? >=20 > It may be desirable in some cases to deploy stateful tunnel servers > instead of the stateless Teredo servers. Tunnels servers generally >=20 > =3D=3D> s/Tunnels/Tunnel/ >=20 > capacity. In summary, the attack is very hard to mount, and the > gain > for the attacker is minimal. >=20 > =3D=3D> s/gain/additional gain/ ? >=20 > its IPv6 traffic, using IPSEC. Even if the IPv4 and UDP headers are > vulnerable, the use of IPSEC will effectively prevent spoofing and >=20 > =3D=3D> s/IPSEC/IPsec/ (everywhere) >=20 > 8.3.1 Denial of service by server spoofing >=20 > In section 8.2, we discussed the use of spoofed router >=20 > =3D=3D> s/8.3/7.3/, s/8.2/7.2/ ? >=20 > non existing IPv4 address or to the IPv4 address of a third party. >=20 > =3D=3D> s/non/non-/ >=20 > 7.4.1 Laundering DOS attacks from IPv4 to IPv4 >=20 > =3D=3D> s/DOS/DoS/ >=20 > on their treatment of UDP; the mappings need to be continuously > refreshed, while the ; and addressing structure may cause some > hosts >=20 > =3D=3D> something missing around ";" >=20 OK, done all that. From owner-v6ops@ops.ietf.org Wed Jun 9 23:38:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16244 for ; Wed, 9 Jun 2004 23:38:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGNG-0001Ij-1y for v6ops-data@psg.com; Thu, 10 Jun 2004 03:37:06 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYDMk-0007ra-9i for v6ops@ops.ietf.org; Thu, 10 Jun 2004 00:24:22 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5A0NYJ13634; Wed, 9 Jun 2004 17:23:34 -0700 (PDT) Message-Id: <200406100023.i5A0NYJ13634@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3789 on Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 09 Jun 2004 17:23:34 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3789 Title: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents Author(s): P. Nesser, II, A. Bergstrom, Ed. Status: Informational Date: June 2004 Mailbox: phil@nesser.com, andreas.bergstrom@hiof.no Pages: 10 Characters: 22842 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv4survey-intro-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3789.txt This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040609172201.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3789 --OtherAccess Content-Type: Message/External-body; name="rfc3789.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040609172201.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 9 23:38:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16262 for ; Wed, 9 Jun 2004 23:38:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGOu-0001Td-6w for v6ops-data@psg.com; Thu, 10 Jun 2004 03:38:48 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYDTe-0008yH-Nv for v6ops@ops.ietf.org; Thu, 10 Jun 2004 00:31:30 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5A0UHJ17466; Wed, 9 Jun 2004 17:30:17 -0700 (PDT) Message-Id: <200406100030.i5A0UHJ17466@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3793 on Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 09 Jun 2004 17:30:17 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3793 Title: Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents Author(s): P. Nesser, II, A. Bergstrom, Ed. Status: Informational Date: June 2004 Mailbox: phil@nesser.com, andreas.bergstrom@hiof.no Pages: 6 Characters: 11624 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv4survey-subip-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3793.txt This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040609172854.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3793 --OtherAccess Content-Type: Message/External-body; name="rfc3793.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040609172854.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 9 23:39: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 XAA16291 for ; Wed, 9 Jun 2004 23:39:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGOg-0001S6-3l for v6ops-data@psg.com; Thu, 10 Jun 2004 03:38:34 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYDRb-0008YX-MN for v6ops@ops.ietf.org; Thu, 10 Jun 2004 00:29:23 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5A0SZJ16504; Wed, 9 Jun 2004 17:28:35 -0700 (PDT) Message-Id: <200406100028.i5A0SZJ16504@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3792 on Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 09 Jun 2004 17:28:35 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3792 Title: Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents Author(s): P. Nesser, II, A. Bergstrom, Ed. Status: Informational Date: June 2004 Mailbox: phil@nesser.com, andreas.bergstrom@hiof.no Pages: 25 Characters: 46398 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv4survey-sec-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3792.txt This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040609172707.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3792 --OtherAccess Content-Type: Message/External-body; name="rfc3792.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040609172707.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 9 23:39:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16323 for ; Wed, 9 Jun 2004 23:39:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGPA-0001WC-A3 for v6ops-data@psg.com; Thu, 10 Jun 2004 03:39:04 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYDVP-0009Gs-VT for v6ops@ops.ietf.org; Thu, 10 Jun 2004 00:33:20 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5A0WEJ18321; Wed, 9 Jun 2004 17:32:14 -0700 (PDT) Message-Id: <200406100032.i5A0WEJ18321@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3794 on Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 09 Jun 2004 17:32:14 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3794 Title: Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents Author(s): P. Nesser, II, A. Bergstrom, Ed. Status: Informational Date: June 2004 Mailbox: phil@nesser.com, andreas.bergstrom@hiof.no Pages: 31 Characters: 60001 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv4survey-trans-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3794.txt This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040609173047.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3794 --OtherAccess Content-Type: Message/External-body; name="rfc3794.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040609173047.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 9 23:39:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16348 for ; Wed, 9 Jun 2004 23:39:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGOD-0001PT-IJ for v6ops-data@psg.com; Thu, 10 Jun 2004 03:38:05 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYDP2-00087J-H5 for v6ops@ops.ietf.org; Thu, 10 Jun 2004 00:26:44 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5A0PIJ14540; Wed, 9 Jun 2004 17:25:18 -0700 (PDT) Message-Id: <200406100025.i5A0PIJ14540@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3790 on Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 09 Jun 2004 17:25:18 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3790 Title: Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents Author(s): C. Mickles, Ed., P. Nesser, II Status: Informational Date: June 2004 Mailbox: cmickles.ee88@gtalumni.org, phil@nesser.com Pages: 49 Characters: 102694 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv4survey-int-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3790.txt This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040609172350.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3790 --OtherAccess Content-Type: Message/External-body; name="rfc3790.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040609172350.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 9 23:39:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16369 for ; Wed, 9 Jun 2004 23:39:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGOS-0001Ql-Uu for v6ops-data@psg.com; Thu, 10 Jun 2004 03:38:20 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYDQd-0008K7-QK for v6ops@ops.ietf.org; Thu, 10 Jun 2004 00:28:23 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5A0QnJ15282; Wed, 9 Jun 2004 17:26:49 -0700 (PDT) Message-Id: <200406100026.i5A0QnJ15282@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3791 on Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 09 Jun 2004 17:26:49 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3791 Title: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents Author(s): C. Olvera, P. Nesser, II Status: Informational Date: June 2004 Mailbox: cesar.olvera@consulintel.es, phil@nesser.com Pages: 15 Characters: 27567 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv4survey-routing-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3791.txt This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040609172537.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3791 --OtherAccess Content-Type: Message/External-body; name="rfc3791.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040609172537.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 9 23:39:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16389 for ; Wed, 9 Jun 2004 23:39:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGPS-0001Zx-83 for v6ops-data@psg.com; Thu, 10 Jun 2004 03:39:22 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYDYK-0009pr-W6 for v6ops@ops.ietf.org; Thu, 10 Jun 2004 00:36:21 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5A0XvJ18914; Wed, 9 Jun 2004 17:33:57 -0700 (PDT) Message-Id: <200406100033.i5A0XvJ18914@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3795 on Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 09 Jun 2004 17:33:57 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3795 Title: Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents Author(s): R. Sofia, P. Nesser, II Status: Informational Date: June 2004 Mailbox: rsofia@zmail.pt, phil@nesser.com Pages: 50 Characters: 92584 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv4survey-apps-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3795.txt This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040609173221.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3795 --OtherAccess Content-Type: Message/External-body; name="rfc3795.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040609173221.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 9 23:39: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 XAA16407 for ; Wed, 9 Jun 2004 23:39:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGPg-0001cV-RW for v6ops-data@psg.com; Thu, 10 Jun 2004 03:39:36 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYDZL-0009vD-2o for v6ops@ops.ietf.org; Thu, 10 Jun 2004 00:37:23 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5A0ZkJ19521; Wed, 9 Jun 2004 17:35:46 -0700 (PDT) Message-Id: <200406100035.i5A0ZkJ19521@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3796 on Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 09 Jun 2004 17:35:46 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3796 Title: Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents Author(s): P. Nesser, II, A. Bergstrom, Ed. Status: Informational Date: June 2004 Mailbox: phil@nesser.com, andreas.bergstrom@hiof.no Pages: 43 Characters: 78400 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv4survey-ops-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3796.txt This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040609173408.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3796 --OtherAccess Content-Type: Message/External-body; name="rfc3796.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040609173408.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jun 11 05:38:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08990 for ; Fri, 11 Jun 2004 05:38:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYiS9-000Mwm-VO for v6ops-data@psg.com; Fri, 11 Jun 2004 09:36:01 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYiS4-000Mw3-MV for v6ops@ops.ietf.org; Fri, 11 Jun 2004 09:35:57 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.0.R) with ESMTP id md50000032237.msg for ; Fri, 11 Jun 2004 11:37:43 +0200 Message-ID: <000b01c44f97$59fa04f0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-palet-v6ops-tun-auto-disc-01.txt Date: Fri, 11 Jun 2004 11:34:53 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 11 Jun 2004 11:37:43 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.135 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Fri, 11 Jun 2004 11:37:47 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, We just submitted this document (Analysis of IPv6 Tunnel End-point Discovery Mechanisms). While officially published, a copy is available at http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-01.txt. Please, provide your feedback on it. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Jun 11 07:19: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 HAA14453 for ; Fri, 11 Jun 2004 07:19:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYk2k-0008UJ-2M for v6ops-data@psg.com; Fri, 11 Jun 2004 11:17:54 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYk2g-0008U3-Jf for v6ops@ops.ietf.org; Fri, 11 Jun 2004 11:17:51 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id BC2338580; Fri, 11 Jun 2004 13:17:45 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 03300-48; Fri, 11 Jun 2004 13:17:27 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E2D077F67; Fri, 11 Jun 2004 13:17:26 +0200 (CEST) Subject: Re: draft-palet-v6ops-tun-auto-disc-01.txt From: Jeroen Massar To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org In-Reply-To: <000b01c44f97$59fa04f0$8700000a@consulintel.es> References: <000b01c44f97$59fa04f0$8700000a@consulintel.es> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k7L/fI243KjDrkp7Ihph" Organization: Unfix Message-Id: <1086952636.21261.1213.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 11 Jun 2004 13:17:16 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-k7L/fI243KjDrkp7Ihph Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-06-11 at 11:34, JORDI PALET MARTINEZ wrote (lines wrapped): > Hi, >=20 > We just submitted this document (Analysis of IPv6 Tunnel End-point Discov= ery Mechanisms). > > While officially published, a copy is available at > > http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-= 01.txt. >=20 > Please, provide your feedback on it. All the scenarios basically can be solved all with existing solutions (TSP for instance). The issue of discovery is not the problem of the communication between the client and the 'server' to negotiate the tunnel parameters but _how_ to discover which is the 'best' service. When a user knows his/her/its/... provider they already know what to configure or it is already configured. The issue which needs to be solved is the case where one doesn't have any configuration data or doesn't want to use the current configuration data and automatically discover the closest/best tunneling solution to get IPv6 connectivity. Basically I see three steps: - Discovery of the 'best' tunneling service - Configuration Currently only TSP (any other takers?) - Tunneling (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...) The text, abstract and actually the complete text mentions "configuring the IPv6 tunnel endpoint on a node." I would change that part to 'tunneling service' instead of 'tunnel endpoint= '. As mentioned in 3.1, the service could consist of multiple servers though there is only one 'endpoint'. A service eg a Tunnel Broker, might even have multiple endpoints etc. Therefor I miss one possible scenario & solution: One could announce a standardized anycast address (eg 192.0.2.6), which can then be hardcoded into clients, maybe better to have something like tunnelautodiscovery.ietf.org as DNS can always be changed, this could then also be combined with the DNS prefixing path search etc. This address, when contacted using UDP returns a packet which contains a list of closest services that can offer tunneling solutions, along with the type of service they provide, thus reference to them, not the final solution. Eg a response could contain: 8<---- www.example.org tunnelbroker tsp.example.org TSP 6to4.example.net 6to4 teredo.example.net teredo ... ---->8 The user will be presented with an optionlist to choose from or alternatively based on properties/policies etc the client could automatically pick the best out of the list and use that. Then either the website, TSP, 6to4, teredo, etc take over on the process. The discovery is really discovery here and nothing else. ISP's which don't announce this service will recieve the prefix from another ISP and of course could simply optional nullroute the prefix if they want to disable this service from other ISP's and when they don't want their users to use this service due to administrative policy etc. Having the above would then be probably better solved with an anycast DNS server to be able to ask that server multiple different questions and maybe directly supply a default DNS server for many hosts solving quite a number of problems. Some nits about the draft: 8<-------- TBD: should this scenario be removed? Third party ISPs may be not economically feasible for free, even if there is some limited deployment of them at the moment. But it could be a registered and paid external service, for example a roaming service agreed among differnt ISPs. -------->8 There are several proven installations that have been around for a number of years that provide free (IPv6) tunneling services. Payment should be out of scope here, but to solve the issue the above suggested scenario could add a 'payed' or 'free' flag to note it. Any service has a AUP or some other form of rules, one of those rules could be payment. The solution in 3.1 is IMHO not doable, as this defines a tunnel endpoint but never mentions how the Tunnel Server knows where/who/what the remote endpoint (client) is, which is autoconfigured to use the anycast address in the first place. How is it going to know which prefix to use and how is the TS going to know where to route packets destined for that prefix? Anycasting a TS is a nice idea, but IMHO in a routing sense will not work unless you embed the IPv4 address into the IPv6 address, which basically leads you to: Teredo & Silkroad like solutions. Also keeping state distributed over several TS's is not likely to be a easy thing, doable of course but still. Greets, Jeroen --=-k7L/fI243KjDrkp7Ihph Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAyZS7KaooUjM+fCMRAiIRAKCEv0zbBG6drxHO0ovCnycP3wqnCACeOMEL JCg1+Y+EvlahdJkI07j7KNI= =/m6F -----END PGP SIGNATURE----- --=-k7L/fI243KjDrkp7Ihph-- From owner-v6ops@ops.ietf.org Fri Jun 11 08:11:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16745 for ; Fri, 11 Jun 2004 08:11:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYkrI-000DUg-O2 for v6ops-data@psg.com; Fri, 11 Jun 2004 12:10:08 +0000 Received: from [194.134.35.141] (helo=smtp0.euronet.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYkrH-000DUU-Nx for v6ops@ops.ietf.org; Fri, 11 Jun 2004 12:10:07 +0000 Received: from ezra (asd-z-144da.mxs.adsl.euronet.nl [81.69.98.218]) by smtp0.euronet.nl (Postfix) with SMTP id E44B324744 for ; Fri, 11 Jun 2004 14:10:06 +0200 (MEST) Message-ID: <001301c44fad$e040dbe0$04000005@ezra> From: "Maurits de Graaf" To: Subject: Status of ISATAP Date: Fri, 11 Jun 2004 14:16:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C44FBE.A39EF260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-0.7 required=5.0 tests=BAYES_10,HTML_50_60, HTML_MESSAGE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C44FBE.A39EF260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As I am quite new to this interesting topic my question is probably = quite simple. What is the status of the ISATAP = http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-22.txt now that the ngtrans working group is closed? Thanks for your answer, Kind regards, Maurits ------=_NextPart_000_0010_01C44FBE.A39EF260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
As I am quite new to this interesting = topic my=20 question is probably quite simple. What is the status of the ISATAP http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-22.txt=
now that the ngtrans working group is=20 closed?
 
Thanks for your answer,
 
Kind regards,
 
Maurits
------=_NextPart_000_0010_01C44FBE.A39EF260-- From owner-v6ops@ops.ietf.org Fri Jun 11 09:59:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28494 for ; Fri, 11 Jun 2004 09:59:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYmXY-000NwH-V6 for v6ops-data@psg.com; Fri, 11 Jun 2004 13:57:52 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYmXV-000Nve-4X for v6ops@ops.ietf.org; Fri, 11 Jun 2004 13:57:49 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5BDvmPA013184 for ; Fri, 11 Jun 2004 15:57:48 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Jun 2004 15:57:48 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4N6LVP; Fri, 11 Jun 2004 15:57:48 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jun 2004 15:57:48 +0200 Message-ID: X-Sybari-Trust: 2608bcb3 100f6658 f47d3ac5 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , juha.wiljakka@nokia.com Cc: peter.grubmair@siemens.com, v6ops@ops.ietf.org Subject: RE: draft-daniel-dhc-ipv6in4-opt-03.txt Date: Fri, 11 Jun 2004 15:57:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 Jun 2004 13:57:48.0135 (UTC) FILETIME=[14022F70:01C44FBC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,DEAR_SOMETHING autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, You keep saying this... In this particular context I would assume that Juha was explicitly referring to 3GPP usage - Could you be so kind as to back you statement up with some hard facts that explains why Isatap deployment is so very problematic in 3GPP environments - ? While draft-daniel-dhc-ipv6in4-opt-03.txt seems to be everything we're looking for in DHCP environments and *could* be used in the 3GPP environment also, it may not be the obvious choice there as addresses are allocated by means of PDP context activation mechanisms and not by means of DHCP. BR, Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Pekka Savola > Sent: Saturday, May 29, 2004 7:51 AM > To: juha.wiljakka@nokia.com > Cc: peter.grubmair@siemens.com; v6ops@ops.ietf.org > Subject: RE: draft-daniel-dhc-ipv6in4-opt-03.txt > > > On Thu, 27 May 2004 juha.wiljakka@nokia.com wrote: > > There is also a simpler, usable mechanism if v6-in-v4 tunneling is > > needed in a 3GPP UE: ISATAP. That does not require DHCP > > implementation in the UE. See Dave's comments here: > > http://ops.ietf.org/lists/v6ops/v6ops.2004/msg00814.html > > While ISATAP may be slightly simpler from the server's implementation > point-of-view, it has problems of its own. > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > > Behalf Of ext Grubmair Peter > > Sent: 27 May, 2004 14:52 > > To: V6ops_Discussion (E-mail) > > Subject: draft-daniel-dhc-ipv6in4-opt-03.txt > > > > > > Dear Sirs, > > I highly appreciated finding your draft > > concerning "DHCP Option for Configuring IPv6-over-IPv4 Tunnels" > > at IETF. > > To my mind this is one of the simplest form of a first transition > > for mobile (GPRS) operators to supply IPv6 to > > their customers. > > After finding the tunnel endpoint via your DHCP option > > a dual stack mobile phone can do autoconfiguration (or DHCPv6) > > accros the tunnel and obtain a globally unique IPv6 address, > > allthough its IPv4 address is only private. > > (no DAD is needed as link-local address is constructed from > > IPv4 address, which is unique within operators area). > > tunnel establishment at operator side could be done with adhoc mode > > as described in >>Simple IPv6-in-IPv4 Tunnel Establishment Procedure > > (STEP)<< > > (draft-savola-v6ops-conftun-setup-02.txt) > > this could be the m > > I hope that your suggestion evolves to an RFC soon. > > Best regards > > Peter Grubmair > > > > -- > 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 Jun 11 20:33:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16861 for ; Fri, 11 Jun 2004 20:33:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYwQr-0003Mn-4g for v6ops-data@psg.com; Sat, 12 Jun 2004 00:31:37 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYwQp-0003MK-6o for v6ops@ops.ietf.org; Sat, 12 Jun 2004 00:31:35 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZ6007016SLH0@mailout3.samsung.com> for v6ops@ops.ietf.org; Sat, 12 Jun 2004 09:31:33 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZ600JEW6SLB6@mailout3.samsung.com> for v6ops@ops.ietf.org; Sat, 12 Jun 2004 09:31:33 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HZ6004YC6SK1S@mmp2.samsung.com> for v6ops@ops.ietf.org; Sat, 12 Jun 2004 09:31:33 +0900 (KST) Date: Sat, 12 Jun 2004 09:32:16 +0900 From: Soohong Daniel Park Subject: RE: Status of ISATAP In-reply-to: <001301c44fad$e040dbe0$04000005@ezra> To: Maurits de Graaf , v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/alternative; boundary="Boundary_(ID_M/xpGtvG6U2ARyNGv/ovvg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_M/xpGtvG6U2ARyNGv/ovvg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT ISATAP: ISR = Independent Submission Review (2004/06/08 - I) Hope this helps - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Maurits de Graaf Sent: Friday, June 11, 2004 9:16 PM To: v6ops@ops.ietf.org Subject: Status of ISATAP Hi, As I am quite new to this interesting topic my question is probably quite simple. What is the status of the ISATAP http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-22.txt now that the ngtrans working group is closed? Thanks for your answer, Kind regards, Maurits --Boundary_(ID_M/xpGtvG6U2ARyNGv/ovvg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
ISATAP: ISR = Independent Submission Review
(2004/06/08 - I)
 
Hope this helps

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Maurits de Graaf
Sent: Friday, June 11, 2004 9:16 PM
To: v6ops@ops.ietf.org
Subject: Status of ISATAP

Hi,
 
As I am quite new to this interesting topic my question is probably quite simple. What is the status of the ISATAP http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-22.txt
now that the ngtrans working group is closed?
 
Thanks for your answer,
 
Kind regards,
 
Maurits
--Boundary_(ID_M/xpGtvG6U2ARyNGv/ovvg)-- From owner-v6ops@ops.ietf.org Sat Jun 12 06:01:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21825 for ; Sat, 12 Jun 2004 06:01:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZ5HI-0008GH-DA for v6ops-data@psg.com; Sat, 12 Jun 2004 09:58:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZ5HG-0008Fp-3Y for v6ops@ops.ietf.org; Sat, 12 Jun 2004 09:58:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5C9w4o04785; Sat, 12 Jun 2004 12:58:06 +0300 Date: Sat, 12 Jun 2004 12:58:04 +0300 (EEST) From: Pekka Savola To: Jeroen Massar cc: JORDI PALET MARTINEZ , Subject: Re: draft-palet-v6ops-tun-auto-disc-01.txt In-Reply-To: <1086952636.21261.1213.camel@segesta.zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for comments.. I think your assumptions are different from those based on which this draft was written. They might warrant spelling out, but in the interests of learning how to enhance the document, it would be best if you could state more clearly which parts of the document you find objectionable (and how to fix the issue, if possible). On Fri, 11 Jun 2004, Jeroen Massar wrote: > On Fri, 2004-06-11 at 11:34, JORDI PALET MARTINEZ wrote (lines wrapped): > > Hi, > > > > We just submitted this document (Analysis of IPv6 Tunnel End-point Discovery Mechanisms). > > > > While officially published, a copy is available at > > > > http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-01.txt. > > > > Please, provide your feedback on it. > > All the scenarios basically can be solved all with existing solutions > (TSP for instance). The issue of discovery is not the problem of the > communication between the client and the 'server' to negotiate the > tunnel parameters but _how_ to discover which is the 'best' service. > When a user knows his/her/its/... provider they already know what to > configure or it is already configured. I disagree with your last sentence, but see below.. > The issue which needs to be solved is the case where one doesn't > have any configuration data or doesn't want to use the current > configuration data and automatically discover the closest/best > tunneling solution to get IPv6 connectivity. You seem to be saying two differnet things here. Above, you mentioned that you seem to assume the user must know what his/her ISP is providing and manually configure it. Here you say there is indeed an issue in automatic discovery of that information. Are you making the assumption that the user learns that the ISP has a tunnel server from somwhere (e.g., a web page) and manually configures it? To make it clear, IMHO, for wide-scale deployment, non-automatic configuration is completely unacceptable. I want to do away with such manual configuration. The main point of the automatic discovery document is to describe mechanisms how the host stacks can run a simple procedure which can lead to a result like, "yes, tunnel service is available, at IPv4 addrexx a.b.c.d", or, "no, tunnel service is not available." > Basically I see three steps: > - Discovery of the 'best' tunneling service > It doesn't have to discovery of the *best* service necessarily, but discovery of the service. There's sufficiently large great gaping gap here... and this is what this document aims to address. > - Configuration > Currently only TSP (any other takers?) > - Tunneling > (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...) These two are out of scope of this document. > The text, abstract and actually the complete text mentions > "configuring the IPv6 tunnel endpoint on a node." > I would change that part to 'tunneling service' instead of 'tunnel endpoint'. > As mentioned in 3.1, the service could consist of multiple servers though > there is only one 'endpoint'. A service eg a Tunnel Broker, might even > have multiple endpoints etc. I'd be reluctant to say 'tunnel service', as you don't configure anything about the service itself, just the tunnel end-point. All other means of configuring (or reconfiguring if there is a broker) are out of scope of this specification. (Later, why you said this becomes clearer: you have the assumption that the service would be used for general purpose service discovery, for multiple tunneling mechanisms. I don't make this assumption -- this method would be mechanism-specific.) > Therefor I miss one possible scenario & solution: > One could announce a standardized anycast address (eg 192.0.2.6), which > can then be hardcoded into clients, maybe better to have something like > tunnelautodiscovery.ietf.org as DNS can always be changed, this could > then also be combined with the DNS prefixing path search etc. There is is mentioned in section 3.1 as so-called "global anycast". > This address, when contacted using UDP returns a packet which contains a > list of closest services that can offer tunneling solutions, along with > the type of service they provide, thus reference to them, not the final > solution. Eg a response could contain: What you're describing is a combination of a global anycast and centralized broker-based system (sect 3.1 & 3.2). > 8<---- > www.example.org tunnelbroker > tsp.example.org TSP > 6to4.example.net 6to4 > teredo.example.net teredo > ... > ---->8 > The user will be presented with an optionlist to choose from or > alternatively based on properties/policies etc the client could > automatically pick the best out of the list and use that. Then > either the website, TSP, 6to4, teredo, etc take over on the process. > The discovery is really discovery here and nothing else. You make the assumption that the discovery process would be common for all the the mechanisms. I don't. Making it common might have an advantage or two, but a lot of disadvantages -- the most important of them is probably that the responder must know of all the services that are supported. > ISP's which don't announce this service will recieve the prefix from > another ISP and of course could simply optional nullroute the prefix if > they want to disable this service from other ISP's and when they don't > want their users to use this service due to administrative policy etc. > > Having the above would then be probably better solved with an anycast > DNS server to be able to ask that server multiple different questions > and maybe directly supply a default DNS server for many hosts solving > quite a number of problems. Global anycast has disadvantages as well, as noted in the draft (maybe not clearly enough). > Some nits about the draft: > 8<-------- > TBD: should this scenario be removed? Third party ISPs may be not > economically feasible for free, even if there is some limited > deployment of them at the moment. But it could be a registered and > paid external service, for example a roaming service agreed among > differnt ISPs. > -------->8 > > There are several proven installations that have been around for a > number of years that provide free (IPv6) tunneling services. > Payment should be out of scope here, but to solve the issue the above > suggested scenario could add a 'payed' or 'free' flag to note it. > Any service has a AUP or some other form of rules, one of those rules > could be payment. IMHO those installations prove only little of more wide-scale deployment, e.g., when there would be over a million users worldwide or the like. That's what we need to aim for .. not for providing services to IPv6 geeks or other techy users -- those will get it in any case so it doesn't matter. > The solution in 3.1 is IMHO not doable, as this defines a tunnel > endpoint but never mentions how the Tunnel Server knows where/who/what > the remote endpoint (client) is, which is autoconfigured to use the > anycast address in the first place. All the solutions assume that the tunneling mechanism -specific means are used to obtain that. E.g., one could have a pseudo-interface which creates tunnels on the receipt of the first packet, or something. This should not be a problem. > How is it going to know which prefix to use and how is the TS going > to know where to route packets destined for that prefix? The client doesn't need to know the prefix but it might. It could just learn the prefix from the TS, similar to the process STEP uses. > Anycasting a TS is a nice idea, but IMHO in a routing sense will not > work unless you embed the IPv4 address into the IPv6 address, which > basically leads you to: Teredo & Silkroad like solutions. > Also keeping state distributed over several TS's is not likely to be > a easy thing, doable of course but still. Embedding the v4 address is one way to achieve this goal, but not the only one. It's probably a requirement for a completely stateless solution, but that's probably not something we need to aim for. -- 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 Jun 14 07:08:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21473 for ; Mon, 14 Jun 2004 07:08:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZpGz-000C6X-Mb for v6ops-data@psg.com; Mon, 14 Jun 2004 11:05:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZpGv-000C4f-Mn for v6ops@ops.ietf.org; Mon, 14 Jun 2004 11:05:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5EB2jZ18742; Mon, 14 Jun 2004 14:02:45 +0300 Date: Mon, 14 Jun 2004 14:02:45 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: juha.wiljakka@nokia.com, , Subject: RE: draft-daniel-dhc-ipv6in4-opt-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Karen E. Nielsen (AH/TED) wrote: > In this particular context I would assume that Juha was explicitly > referring to 3GPP usage - Could you be so kind > as to back you statement up with some hard facts that explains why > Isatap deployment is so very problematic in 3GPP environments - ? I've tried to explain these multiple times without all that much success. I think the worst problem is that everyone in the 3GPP operator's network would be considered "on-link" with yourself is the biggest problem. I.e., direct tunneling between the 3GPP nodes. The analogy of this approach would be connecting all the 3GPP users in the operator's network in a single Ethernet LAN segment, and expecting them to behave themselves with regard to each other (in particular, note that Neighbor Discovery and many, many other protocols consider such an environment "semi-trusted", e.g., by the use of link-local messages and verifying that Hop Limit stays at 255). This approach gives me creeps. Hence, I'd strongly prefer approaches where there would be sufficient "insulation" from everyone else, e.g., by the use of configured, bidirectional tunnels. > While draft-daniel-dhc-ipv6in4-opt-03.txt seems to be everything > we're looking for in DHCP environments and *could* be used in the > 3GPP environment also, it may not be the obvious choice there as > addresses are allocated by means of PDP context activation > mechanisms and not by means of DHCP. Yes, I don't think draft-daniel-dhc-ipv6in4-opt-03.txt is optimal in 3GPP. You could do the discovery using DNS or a number of other means. Configuring the tunnel endpoint at the server's end is a challenge not addressed in dhc-ipv6in4-opt either. There are number of possibilities to do that, though -- one is a pseudo-interface like ISATAP's, the other is creating tunnels dynamically based on the packets you receive, the one another looking up auth/identification data from (3GPP or other) databases. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Jun 15 01:42:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10007 for ; Tue, 15 Jun 2004 01:42:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Ba6fs-000E9l-6q for v6ops-data@psg.com; Tue, 15 Jun 2004 05:39:56 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZqxq-000Nid-RQ for v6ops@ops.ietf.org; Mon, 14 Jun 2004 12:53:27 +0000 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 89234 for v6ops@ops.ietf.org; Mon, 14 Jun 2004 08:51:45 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Mon, 14 Jun 2004 08:53:13 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, A few weeks ago, Pekka Savola sent a summary of IESG comments to the list that included: > 1) section 2.2 on DNS result ordering/filtering seems to > be considered inappropriately short, and it would be better > to just refer to the default address selection RFC3484. > (Margaret Wasserman). Filtering is inappropriate (Ted Hardie > and Scott Hollenbeck). The length of the section doesn't bother me. In fact, following my suggestion would make it shorter :-). My objection to this section is that it contains a simple set of address selection rules, including a simple preference for IPv4 or IPv6, that has several well-understood problems. Those problems were identified and addressed in RFC 3484. So, I believe that we should remove the address selection rules specified in this section and replace them with a normative reference to RFC 3484. > ==> possibilities include at least: > a) keeping the current tense of specifying a "simple" address > selection, and referring to RFC3484 for more details, but reword > the text appropriately. Remove filtering but keep ordering. It > might require some convincing to make the IESG accept this > approach. (In other words, a simple dual-stack implementation > would not necessarily have to implement RFC3484 to be > compliant/interoperable with this spec.) There are several reasons why I do not believe that this is a good choice. We know that the simple address selection (flag to prefer IPv4 or IPv6) does not work properly. For instance, it causes situations where global communication will be initiated using a local source address, even when a global source address is available. It also causes situations where hosts will prefer tunnelled communication over non-tunnelled communication. These problems were identified and fixed in RFC 3484, which is a mandatory part of IPv6. > b) remove most of the text, referring to RFC3484. Note that RFC3484 > is PS, and we could not advance to DS if we did that. (In other > words, all the dual-stack implementations compliant with this spec > would also have to implement RFC3484.) This is my suggestion. IMO, the concern that adding a normative reference to RFC 3484 will prevent promotion to draft standard is misplaced. Before moving to DS, a draft must have two interoperable implementations and "successful operational experience". The whole purpose of the multi-tiered standards process is to identify problems (such as the address selection problems in this draft) and correct them before documents move to higher levels of the standards track. Margaret From owner-v6ops@ops.ietf.org Tue Jun 15 05:28:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06342 for ; Tue, 15 Jun 2004 05:28:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaAD0-000BDd-El for v6ops-data@psg.com; Tue, 15 Jun 2004 09:26:22 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaACy-000BDD-Tr for v6ops@ops.ietf.org; Tue, 15 Jun 2004 09:26:21 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i5F9QJnE000196 for ; Tue, 15 Jun 2004 10:26:20 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA25539 for ; Tue, 15 Jun 2004 10:26:15 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i5F9QFB19444 for v6ops@ops.ietf.org; Tue, 15 Jun 2004 10:26:15 +0100 Date: Tue, 15 Jun 2004 10:26:15 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt Message-ID: <20040615092615.GE18958@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jun 14, 2004 at 08:53:13AM -0400, Margaret Wasserman wrote: > > This is my suggestion. > > IMO, the concern that adding a normative reference > to RFC 3484 will prevent promotion to draft standard > is misplaced. Before moving to DS, a draft must have > two interoperable implementations and "successful > operational experience". The whole purpose of the > multi-tiered standards process is to identify problems > (such as the address selection problems in this draft) > and correct them before documents move to higher > levels of the standards track. This sounds good to me. Tim From owner-v6ops@ops.ietf.org Tue Jun 15 06:29:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08673 for ; Tue, 15 Jun 2004 06:29:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaBAc-000HET-At for v6ops-data@psg.com; Tue, 15 Jun 2004 10:27:58 +0000 Received: from [164.164.31.5] (helo=wiproecmx1.wipro.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaBAR-000HCo-On for v6ops@ops.ietf.org; Tue, 15 Jun 2004 10:27:55 +0000 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i5FARYaf000108 for ; Tue, 15 Jun 2004 15:57:38 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 15 Jun 2004 15:57:34 +0530 Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jun 2004 15:57:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C452C3.5E984724" Subject: RSVP for IPv6 Date: Tue, 15 Jun 2004 15:57:33 +0530 Message-ID: <2BB7146B38D9CA40B215AB3DAAE24C08674B44@blr-m2-msg.wipro.com> Thread-Topic: RSVP for IPv6 Thread-Index: AcRSw10v1MvD0DsUS/e1xpmFbF/Oxg== From: To: X-OriginalArrivalTime: 15 Jun 2004 10:27:33.0324 (UTC) FILETIME=[5EA5C8C0:01C452C3] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_44, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C452C3.5E984724 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I wanted some information on implementation of RSVP (any other signaling protocol) for IPv6. I was looking in the IETF website & got a reference of a draft (draft-berson-rsvp-ipv6-fl-00.ps) which is expired now. I wanted to know if any document (RFC/draft) for RSVP has been standardized for IPv6. =20 Any pointers to support of signaling protocols for IPv6 would be great! =20 Thanks a lot! =20 Regards, Savitha Wipro Technologies, Bommanahalli, Bangalore, INDIA *: +91-80-25732293 Extn: 3126 *: savitha.kumar@wipro.com http:// www.wipro.com The world's first SEI CMM level 5 software services company. =20 ------_=_NextPart_001_01C452C3.5E984724 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I wanted some information on implementation of RSVP = (any other signaling protocol) for IPv6. I was looking in the IETF website = & got a reference of a draft (draft-berson-rsvp-ipv6-fl-00.ps) which= is expired now. I wanted to know if any document (RFC/draft) for RSVP has = been standardized for IPv6.

 

Any pointers to support of signaling = protocols for IPv6 would be great!

 

Thanks a = lot!

 

Regards,

=

Savitha

Wipro = Technologies,

Bommanahalli, Bangalore, INDIA

(: +91-80-25732293 Extn: 3126

http://www.wipro.com

The world's first SEI CMM level 5 = software services company.

 

------_=_NextPart_001_01C452C3.5E984724-- From owner-v6ops@ops.ietf.org Tue Jun 15 15:52: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 PAA12746 for ; Tue, 15 Jun 2004 15:52:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaJsO-0003Ae-Kp for v6ops-data@psg.com; Tue, 15 Jun 2004 19:45:44 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaJsN-0003AM-HM for v6ops@ops.ietf.org; Tue, 15 Jun 2004 19:45:43 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12387; Tue, 15 Jun 2004 15:45:40 -0400 (EDT) Message-Id: <200406151945.PAA12387@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt Date: Tue, 15 Jun 2004 15:45:40 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 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 : Basic Transition Mechanisms for IPv6 Hosts and Routers Author(s) : E. Nordmark, R. Gilligan Filename : draft-ietf-v6ops-mech-v2-03.txt Pages : 32 Date : 2004-6-15 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, 'dual stack' and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-mech-v2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-mech-v2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-15154344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-mech-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-mech-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-15154344.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jun 15 17:19:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17219 for ; Tue, 15 Jun 2004 17:19:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaLFa-000CFj-Hd for v6ops-data@psg.com; Tue, 15 Jun 2004 21:13:46 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaLFZ-000CFM-HT for v6ops@ops.ietf.org; Tue, 15 Jun 2004 21:13:45 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5FLBw53009489 for ; Tue, 15 Jun 2004 15:11:58 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZD00AY2CAW4R@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 15 Jun 2004 15:13:45 -0600 (MDT) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HZD00CC4CAVE4@mail.sun.net> for v6ops@ops.ietf.org; Tue, 15 Jun 2004 15:13:44 -0600 (MDT) Date: Tue, 15 Jun 2004 14:13:42 -0700 From: Alain Durand Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt In-reply-to: To: Margaret Wasserman Cc: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Jun 14, 2004, at 5:53 AM, Margaret Wasserman wrote: >> ==> possibilities include at least: >> a) keeping the current tense of specifying a "simple" address >> selection, and referring to RFC3484 for more details, but reword >> the text appropriately. Remove filtering but keep ordering. It >> might require some convincing to make the IESG accept this >> approach. (In other words, a simple dual-stack implementation >> would not necessarily have to implement RFC3484 to be >> compliant/interoperable with this spec.) > > There are several reasons why I do not believe > that this is a good choice. We know that the simple > address selection (flag to prefer IPv4 or IPv6) does > not work properly. For instance, it causes situations > where global communication will be initiated using a > local source address, even when a global source address > is available. It also causes situations where hosts > will prefer tunnelled communication over non-tunnelled > communication. > > These problems were identified and fixed in RFC 3484, > which is a mandatory part of IPv6. Unfortunately, 3484 does not solve all the problems, see draft-ietf-v6ops-v6onbydefault-02.txt - Alain. From owner-v6ops@ops.ietf.org Wed Jun 16 00:58: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 AAA20436 for ; Wed, 16 Jun 2004 00:58:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaSTP-0006BJ-KX for v6ops-data@psg.com; Wed, 16 Jun 2004 04:56:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaSTM-0006Al-4I for v6ops@ops.ietf.org; Wed, 16 Jun 2004 04:56:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5G4uQ704306 for ; Wed, 16 Jun 2004 07:56:27 +0300 Date: Wed, 16 Jun 2004 07:56:26 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI -- (co-chair hat on) If interested in mech-v2, take a look -- this aims to address all the IESG evaluation comments except what we're currently discussing with Margaret. (co-chair hat off) Btw. if interested in PMTUD/packet size issues, you might also find draft-savola-mtufrag-network-tunneling-00.txt interesting. It's a more generic document describing PMTUD, fragmentation/reassembly, etc. issues in tunneling in the network. ---------- Forwarded message ---------- Date: Tue, 15 Jun 2004 15:45:40 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt 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 : Basic Transition Mechanisms for IPv6 Hosts and Routers Author(s) : E. Nordmark, R. Gilligan Filename : draft-ietf-v6ops-mech-v2-03.txt Pages : 32 Date : 2004-6-15 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, 'dual stack' and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-mech-v2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-mech-v2-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 Wed Jun 16 00:59: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 AAA20542 for ; Wed, 16 Jun 2004 00:59:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaSVq-0006Rh-Ov for v6ops-data@psg.com; Wed, 16 Jun 2004 04:59:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaSVp-0006RM-CZ for v6ops@ops.ietf.org; Wed, 16 Jun 2004 04:59:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5G4wGK04318; Wed, 16 Jun 2004 07:58:16 +0300 Date: Wed, 16 Jun 2004 07:58:16 +0300 (EEST) From: Pekka Savola To: savitha.kumar@wipro.com cc: v6ops@ops.ietf.org Subject: Re: RSVP for IPv6 In-Reply-To: <2BB7146B38D9CA40B215AB3DAAE24C08674B44@blr-m2-msg.wipro.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 15 Jun 2004 savitha.kumar@wipro.com wrote: > I wanted some information on implementation of RSVP (any other signaling > protocol) for IPv6. I was looking in the IETF website & got a reference > of a draft (draft-berson-rsvp-ipv6-fl-00.ps) which is expired now. I > wanted to know if any document (RFC/draft) for RSVP has been > standardized for IPv6. > > Any pointers to support of signaling protocols for IPv6 would be great! RSVP already supports IPv6 from the start. Based on the I-D filename you quote, the I-D probably discussed how to use IPv6 Flow Label field in the header in conjuction with RSVP. There hasn't been work on that AFAIK. -- 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 Jun 16 01:01:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21253 for ; Wed, 16 Jun 2004 01:01:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaSYK-0006lM-2S for v6ops-data@psg.com; Wed, 16 Jun 2004 05:01:36 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaSYI-0006l3-Qc for v6ops@ops.ietf.org; Wed, 16 Jun 2004 05:01:34 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 370AD3F; Wed, 16 Jun 2004 14:01:34 +0900 (JST) To: pekkas@netcore.fi Cc: savitha.kumar@wipro.com, v6ops@ops.ietf.org Subject: Re: RSVP for IPv6 In-Reply-To: Your message of "Wed, 16 Jun 2004 07:58:16 +0300 (EEST)" References: X-Mailer: Cue version 0.8 (040507-1428/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040616050134.370AD3F@coconut.itojun.org> Date: Wed, 16 Jun 2004 14:01:34 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Tue, 15 Jun 2004 savitha.kumar@wipro.com wrote: > > I wanted some information on implementation of RSVP (any other signaling > > protocol) for IPv6. I was looking in the IETF website & got a reference > > of a draft (draft-berson-rsvp-ipv6-fl-00.ps) which is expired now. I > > wanted to know if any document (RFC/draft) for RSVP has been > > standardized for IPv6. > > > > Any pointers to support of signaling protocols for IPv6 would be great! > > RSVP already supports IPv6 from the start. > > Based on the I-D filename you quote, the I-D probably discussed how to > use IPv6 Flow Label field in the header in conjuction with RSVP. > There hasn't been work on that AFAIK. FYI: RFC2205 (RSVP base spec) has FILTER_SPEC for IPv6 flow label field. (but i guess it is outdated as it uses 24bit flow label, not 20bit...) itojun From owner-v6ops@ops.ietf.org Wed Jun 16 10:24:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00526 for ; Wed, 16 Jun 2004 10:24:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BabIn-0008Hr-1n for v6ops-data@psg.com; Wed, 16 Jun 2004 14:22:09 +0000 Received: from [206.123.31.135] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BabIl-0008HU-PD for v6ops@ops.ietf.org; Wed, 16 Jun 2004 14:22:08 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.10+Sun/8.12.10) with ESMTP id i5GELrK7017117; Wed, 16 Jun 2004 10:21:54 -0400 (EDT) Date: Wed, 16 Jun 2004 10:21:53 -0400 From: Florent Parent To: Jeroen Massar cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-01.txt Message-ID: <8DBF8ED3C5AC80ABAFEF500C@blues> In-Reply-To: <1087372347.24446.3035.camel@segesta.zurich.ibm.com> References: <200406151941.PAA12095@ietf.org> <1087372347.24446.3035.camel@segesta.zurich.ibm.com> X-Mailer: Mulberry/3.1.5 (SunOS/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- On Wednesday, June 16, 2004 09:52:28 AM +0200, Jeroen Massar wrote: > On Tue, 2004-06-15 at 21:41, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP) > > > > Things I am wondering about(tm): > > "2.1 NAT Discovery" > It mentions to choose UDP over IPv4, is there a spec of this protocol? > Also it mentions that it will pick 'the most effective protocol even in > dynamic situations when the clients moves', which one is that? If no NAT is in the path, IPv6-over-IPv4 is selected. Otherwise, IPv6 over UDP. > > In: "On the IPv6 layer, if the client uses user authentication, the same > IPv6 address and prefix are kept and re-established. On the IPv6 layer, > there is no change of address." > The last sentence is a duplicate or clarification I assume? Yes, they mean the same thing. Could be merged into the same sentence. > > "If there is no IPv4 NAT is detected in the path by > the TSP server, then IPv6 over IPv4 encapsulation is used." > > Reprase to "If no IPv4 is detected in the path..." I think the original sentence is ok, or I lost you here :) > > Note that there are *many* ISP/transits that blindly filter proto-41 and > then the tunnel will not work. Of course they could also filter UDP for > that matter... Correct. You can let the broker pick the 'best' encapsulation for you, or if you know that ip-proto41 is filtered, one can always explicitly specify IPv6 over UDP encapsulation (or vice-versa). > "2.3 Mobility", would it not be easier and more effective to use > heartbeats here? Renegotiating all the parameters would cause a delay and > cause packets to be dropped. Well, keep-alives do help out here in detecting if you have "moved" *and* keeping the NAT state valid. The delay involved in renegotiating is negligible compared to the time to detect and have the OS adjust to the fact that you have "moved". But yes, the 'heartbeats' would be faster since you send authentication material in every packets. The 'heartbeats' are sent out-of-band, as I recall (w.r.t. the established tunnel), so this doesn't help to keep the NAT state active. We would need to send 'heartbeats' and keep-alives in such a configuration, right? > > "3. Advantages of TSP" Advantages over what? There is no other Tunnel > Setup Protocol defined :) > > For 4.x: What was actually the reason for not picking a full HTTP/1.1 or > SOAP protocol? Implementing clients would then be much easier as many > HTTP clients already exist also that could allow Apache (or IIS ;) for > instance to be used as a server. Good point. I will need to think a bit more on this one. A point that comes to mind is the fact that we require UDP for NAT traversal (not sure we want to do HTTP over UDP?). My knowledge on SOAP is limited, I'll have to readup a bit. My take is that TSP is much closer to BEEP (RFC3080). > > The Security Considerations should note that due to the many spoof-open > networks it is very easy to inject a packet into the network stream of > v6udpv4 packets and pose as the original sender. One could thus easily > disrupt the tunnel. Same for proto-41 tunnels. Also see > http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunne > l-disco.pdf True. But as you state, no different from IPv6-over-IPv4. If securing the transport is important, IPsec seems like the way to go. Thanks for the comments Jeroen! Florent From owner-v6ops@ops.ietf.org Wed Jun 16 10:59: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 KAA03299 for ; Wed, 16 Jun 2004 10:59:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaVV1-000N19-9Y for v6ops-data@psg.com; Wed, 16 Jun 2004 08:10:23 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaVUz-000N0Q-86 for v6ops@ops.ietf.org; Wed, 16 Jun 2004 08:10:21 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 0F48E8580; Wed, 16 Jun 2004 09:52:45 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 04405-31; Wed, 16 Jun 2004 09:52:33 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id F2AC57F67; Wed, 16 Jun 2004 09:52:32 +0200 (CEST) Subject: Re: I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-01.txt From: Jeroen Massar To: v6ops@ops.ietf.org Cc: Marc.Blanchet@hexago.com, Florent.Parent@hexago.com In-Reply-To: <200406151941.PAA12095@ietf.org> References: <200406151941.PAA12095@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cHOr0fgKpIC9xWC9u7+R" Organization: Unfix Message-Id: <1087372347.24446.3035.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Jun 2004 09:52:28 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-cHOr0fgKpIC9xWC9u7+R Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-15 at 21:41, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP) Things I am wondering about(tm): "2.1 NAT Discovery" It mentions to choose UDP over IPv4, is there a spec of this protocol? Also it mentions that it will pick 'the most effective protocol even in dynamic situations when the clients moves', which one is that? In: "On the IPv6 layer, if the client uses user authentication, the same IPv6 address and prefix are kept and re-established. On the IPv6 layer, there is no change of address." The last sentence is a duplicate or clarification I assume? "If there is no IPv4 NAT is detected in the path by the TSP server, then IPv6 over IPv4 encapsulation is used." Reprase to "If no IPv4 is detected in the path..." Note that there are *many* ISP/transits that blindly filter proto-41 and th= en the tunnel will not work. Of course they could also filter UDP for that mat= ter... "2.3 Mobility", would it not be easier and more effective to use heartbeat= s here? Renegotiating all the parameters would cause a delay and cause packets to b= e dropped. "3. Advantages of TSP" Advantages over what? There is no other Tunnel Setu= p Protocol defined :) For 4.x: What was actually the reason for not picking a full HTTP/1.1 or SO= AP protocol? Implementing clients would then be much easier as many HTTP clients already= exist also that could allow Apache (or IIS ;) for instance to be used as a server. The Security Considerations should note that due to the many spoof-open net= works it is very easy to inject a packet into the network stream of v6udpv4 packets and= pose as the original sender. One could thus easily disrupt the tunnel. Same for proto-4= 1 tunnels. Also see http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv= 6-tunnel-disco.pdf Greets, Jeroen --=-cHOr0fgKpIC9xWC9u7+R Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAz/w6KaooUjM+fCMRAs5xAJ9ArUuLoW6bcaH/bM+Ggdy295gCMACgrVyD gHkhR3PCiTf8KHs0Rc7ux44= =BbNF -----END PGP SIGNATURE----- --=-cHOr0fgKpIC9xWC9u7+R-- From owner-v6ops@ops.ietf.org Wed Jun 16 13:05: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 NAA21660 for ; Wed, 16 Jun 2004 13:05:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Badp9-0004rL-65 for v6ops-data@psg.com; Wed, 16 Jun 2004 17:03:43 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Badp7-0004qm-R8 for v6ops@ops.ietf.org; Wed, 16 Jun 2004 17:03:42 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id C5C368580; Wed, 16 Jun 2004 18:04:10 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 06152-96; Wed, 16 Jun 2004 18:03:54 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 584117F67; Wed, 16 Jun 2004 18:03:54 +0200 (CEST) Subject: Re: I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-01.txt From: Jeroen Massar To: Florent Parent Cc: v6ops@ops.ietf.org In-Reply-To: <8DBF8ED3C5AC80ABAFEF500C@blues> References: <200406151941.PAA12095@ietf.org> <1087372347.24446.3035.camel@segesta.zurich.ibm.com> <8DBF8ED3C5AC80ABAFEF500C@blues> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-y8OMFXpcZL8VMVU3sYqy" Organization: Unfix Message-Id: <1087401824.12356.8.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Jun 2004 18:03:45 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-y8OMFXpcZL8VMVU3sYqy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-06-16 at 16:21, Florent Parent wrote: > > > > "If there is no IPv4 NAT is detected in the path by > > the TSP server, then IPv6 over IPv4 encapsulation is used." > > > > Reprase to "If no IPv4 is detected in the path..." >=20 > I think the original sentence is ok, or I lost you here :) There is 'is' twice in the sentence, which doesn't read smoothly IMHO. > > "2.3 Mobility", would it not be easier and more effective to use > > heartbeats here? Renegotiating all the parameters would cause a delay a= nd > > cause packets to be dropped. >=20 > Well, keep-alives do help out here in detecting if you have "moved" *and*= =20 > keeping the NAT state valid. >=20 > The delay involved in renegotiating is negligible compared to the time to= =20 > detect and have the OS adjust to the fact that you have "moved". >=20 > But yes, the 'heartbeats' would be faster since you send authentication=20 > material in every packets. The 'heartbeats' are sent out-of-band, as I=20 > recall (w.r.t. the established tunnel), so this doesn't help to keep the=20 > NAT state active. We would need to send 'heartbeats' and keep-alives in=20 > such a configuration, right? Correct. But the heartbeat draft is for proto-41 tunnels. The AYIYA draft is for anything-over-anything and includes the same heartbeat trick but embedded in the data stream. > > "3. Advantages of TSP" Advantages over what? There is no other Tunnel > > Setup Protocol defined :) > > > > For 4.x: What was actually the reason for not picking a full HTTP/1.1 o= r > > SOAP protocol? Implementing clients would then be much easier as many > > HTTP clients already exist also that could allow Apache (or IIS ;) for > > instance to be used as a server. >=20 > Good point. I will need to think a bit more on this one. A point that com= es=20 > to mind is the fact that we require UDP for NAT traversal (not sure we wa= nt=20 > to do HTTP over UDP?). My knowledge on SOAP is limited, I'll have to read= up=20 > a bit. My take is that TSP is much closer to BEEP (RFC3080). Beep indeed. But with the way you are now handling TSP-over-UDP you have added back the sequence numbers which where missing from UDP. > > The Security Considerations should note that due to the many spoof-open > > networks it is very easy to inject a packet into the network stream of > > v6udpv4 packets and pose as the original sender. One could thus easily > > disrupt the tunnel. Same for proto-41 tunnels. Also see > > http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tun= ne > > l-disco.pdf >=20 > True. But as you state, no different from IPv6-over-IPv4. If securing the= =20 > transport is important, IPsec seems like the way to go. It is not securing the transport, it is making sure that there is no _additional_ spoofing going on. There are a number of ways that make it very easy to abuse tunnels, dossing hosts without them ever being able to trace the traffic. By authenticating the traffic, a hash is maybe only 4 bytes so that is not the issue, you can make sure that at least=20 the traffic upto the Tunnel Server is not spoofed. The IPv4 internet is a wide open place as shown in the above doc, thus adding a bit of resilience for the small price of 4 bytes and a bit of hashing overhead is not so heavy to pay IMHO. Indeed if one wants to make sure that everything works correctly use IPsec, but one of the issues we are trying solving here is that many hosts are behind NAT's, thus they can't use IPv4-IPsec in the first place ;) Greets, Jeroen --=-y8OMFXpcZL8VMVU3sYqy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA0G9gKaooUjM+fCMRAvfOAJwI+bZEzde0wBN3HQdPEINwjEG9gwCgoVHm bAeZwpZtZ2u6yYRLllv/Jwo= =7UvW -----END PGP SIGNATURE----- --=-y8OMFXpcZL8VMVU3sYqy-- From owner-v6ops@ops.ietf.org Wed Jun 16 13:16: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 NAA22218 for ; Wed, 16 Jun 2004 13:16:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bae1R-0006ZH-Ey for v6ops-data@psg.com; Wed, 16 Jun 2004 17:16:25 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bae1P-0006Ys-EW for v6ops@ops.ietf.org; Wed, 16 Jun 2004 17:16:24 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 7008F8580; Wed, 16 Jun 2004 19:16:20 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 06908-50; Wed, 16 Jun 2004 19:15:48 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id EF4797F67; Wed, 16 Jun 2004 19:15:47 +0200 (CEST) Subject: Re: draft-palet-v6ops-tun-auto-disc-01.txt From: Jeroen Massar To: Pekka Savola Cc: JORDI PALET MARTINEZ , v6ops@ops.ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vI9xcH+FEN2G1ZAnKAq0" Organization: Unfix Message-Id: <1087406137.12356.71.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 16 Jun 2004 19:15:37 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-vI9xcH+FEN2G1ZAnKAq0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2004-06-12 at 11:58, Pekka Savola wrote: > Thanks for comments.. >=20 > I think your assumptions are different from those based on which this > draft was written. They might warrant spelling out, but in the > interests of learning how to enhance the document, it would be best if > you could state more clearly which parts of the document you find > objectionable (and how to fix the issue, if possible). No, I think I am looking the issue from a different perspective. The document is talking about 'tunnel endpoints' while IMHO these should be 'tunnel services'. Who provides them and how they are negotiated is not mentioned at all in the document and is up to the various configuration protocols, while this document is targetted solely afaik at the discovery part. > On Fri, 11 Jun 2004, Jeroen Massar wrote: > > On Fri, 2004-06-11 at 11:34, JORDI PALET MARTINEZ wrote (lines wrapped)= : > To make it clear, IMHO, for wide-scale deployment, non-automatic > configuration is completely unacceptable. I want to do away with such > manual configuration. The main point of the automatic discovery > document is to describe mechanisms how the host stacks can run a > simple procedure which can lead to a result like, "yes, tunnel service > is available, at IPv4 addrexx a.b.c.d", or, "no, tunnel service is not > available." Indeed. Non-Automatic doesn't work. It works, but only for a few people who want to invest the time and effort. These are not the random-joe-virus-running-users at which this should be targetted. But I would rather see the discovery part say: The service is available from: - here - there - there too Or when the client only has one choice or thinks it is feasible enough for a certain choice to use that directly. You also note 'host stacks' but wouldn't this be better to place simply as an additional tool. radvd isn't a part of the stack either in most OS's at the moment. Also I am quite sure that there a lot of people who don't want something to automatically configure it for them so anything using this tool would need to either be setup by the user or have enough knowledge to not run in a native network. > > Basically I see three steps: > > - Discovery of the 'best' tunneling service > > >=20 > It doesn't have to discovery of the *best* service necessarily, but=20 > discovery of the service. There's sufficiently large great gaping gap=20 > here... and this is what this document aims to address. 'best' is the one that fits mostly in the situations that the discovery is taking place in. 'best' could thus be the one that is anycasted closest to the host etc and depends totally on the discovery method. This is what the doc should describe. > > - Configuration > > Currently only TSP (any other takers?) I apparently forgot STEP, but that is basically normal RA etc which every host should support. > > - Tunneling > > (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...) >=20 > These two are out of scope of this document. Thus my assumption that this document is targeted at the gap above is correct. Then one should not be finding the best tunnel _endpoint_ but the tunnel _service_ which can provide that endpoint. TSP for instance does its own endpoint negotiation. Having a discovery method do that would thus make TSP either be only for that single Tunnel Server or it would require another step. The 'endpoint' wording thus is wrong IMHO and should be resplaced by 'service'. As the Discovery service can in no way know the load of the Tunnel Service and any other properties that the provider of the service wants to include into the calculation, wouldn't it be better after one has discovered the 'best' service to then hand it over to for instance TSP or STEP? > > The text, abstract and actually the complete text mentions > > "configuring the IPv6 tunnel endpoint on a node." > > I would change that part to 'tunneling service' instead of 'tunnel endp= oint'. > > As mentioned in 3.1, the service could consist of multiple servers thou= gh > > there is only one 'endpoint'. A service eg a Tunnel Broker, might even > > have multiple endpoints etc. >=20 > I'd be reluctant to say 'tunnel service', as you don't configure=20 > anything about the service itself, just the tunnel end-point. All=20 > other means of configuring (or reconfiguring if there is a broker) are=20 > out of scope of this specification. With 'tunnel service' you designate the closest possiblity of giving you the 'service' which is "providing IPv6 connectivity". With a tunnel endpoint one would mean 'exactly that endpoint'. > (Later, why you said this becomes clearer: you have the assumption=20 > that the service would be used for general purpose service discovery,=20 > for multiple tunneling mechanisms. Not entirely, this discovery method _could_ point to multiple tunneling mechanism, but if the IETF reaches concensus one single protocol, then it could be just that. Still it would be better to let the service determine the real endpoint. Based on DNS or anycast this is simply not an option. What if you have a dialin pool for 'low paying' clients and 'high paying' clients, you might want to give a better service to the ones that give you more money, anycast nor DNS will not work here unless one does a lot of tricks. Letting a service decide it, after that that service has been automatically discovered is a better and more flexible option. The service can then also either redirect the user somewhere else or give a nice visual error message through one protocol or another. The mechanisms described in this draft allow no such thing because the endpoint of the tunnel is directly configured. > I don't make this assumption --=20 > this method would be mechanism-specific.) If this document is mechanism specific shouldn't these descriptions then be included in that mechanism ? > > Therefor I miss one possible scenario & solution: > > One could announce a standardized anycast address (eg 192.0.2.6), which > > can then be hardcoded into clients, maybe better to have something like > > tunnelautodiscovery.ietf.org as DNS can always be changed, this could > > then also be combined with the DNS prefixing path search etc. >=20 > There is is mentioned in section 3.1 as so-called "global anycast". Which targets a completely different audience: a local (organisational) network and nothing bigger, eg providing service to a complete IX. > > This address, when contacted using UDP returns a packet which contains = a > > list of closest services that can offer tunneling solutions, along with > > the type of service they provide, thus reference to them, not the final > > solution. Eg a response could contain: >=20 > What you're describing is a combination of a global anycast and=20 > centralized broker-based system (sect 3.1 & 3.2). Almost, because a 'service' would not have to have any of the broker attributes. It could just tell you '6to4 is over there' and done. > > 8<---- > > www.example.org tunnelbroker > > tsp.example.org TSP > > 6to4.example.net 6to4 > > teredo.example.net teredo > > ... > > ---->8 > > The user will be presented with an optionlist to choose from or > > alternatively based on properties/policies etc the client could > > automatically pick the best out of the list and use that. Then > > either the website, TSP, 6to4, teredo, etc take over on the process. > > The discovery is really discovery here and nothing else. >=20 > You make the assumption that the discovery process would be common for > all the the mechanisms. I don't. Making it common might have an > advantage or two, The biggest advantage would be that it is generic and that it will work for all situations and not just a few. If you only want a few, then that would be like designing IPv6 only for the polar caps as there it freezes but nowhere else. I don't see any OS vendor wanting to include a tool then. The scale of Teredo is the target, aka every desktop user pc should have it. And every of the above mechanisms solves a different problem which the others don't. Then if one just says 'always use this' it won't work for a large chunk of the other users and or ISP's who might want to deploy it and they will not adopt it. > but a lot of disadvantages -- the most important of > them is probably that the responder must know of all the services that > are supported. Unless the IETF makes the decision that for instance TSP or STEP becomes the 'standard' protocol for resolving these issues. The problem I see here is that otherwise there will be tens of 'discovery prefixes', one /24 for IPv4, a /32 for IPv6 etc. While these can all be nicely fit into one prefix per protocol. Easy for ISP's to filter and easy for them to setup. > > ISP's which don't announce this service will recieve the prefix from > > another ISP and of course could simply optional nullroute the prefix if > > they want to disable this service from other ISP's and when they don't > > want their users to use this service due to administrative policy etc. > >=20 > > Having the above would then be probably better solved with an anycast > > DNS server to be able to ask that server multiple different questions > > and maybe directly supply a default DNS server for many hosts solving > > quite a number of problems. >=20 > Global anycast has disadvantages as well, as noted in the draft (maybe=20 > not clearly enough). Using anycast for discovery doesn't have any drawbacks as the packet exchange between the client and the 'server' would be minimal. If you want to use anycast as a tunnel _endpoint_ that is a different story, but this was about discovery thus we are hopefully talking services here and not endpoints... > > Some nits about the draft: > > 8<-------- > > TBD: should this scenario be removed? Third party ISPs may be not > > economically feasible for free, even if there is some limited > > deployment of them at the moment. But it could be a registered and > > paid external service, for example a roaming service agreed among > > differnt ISPs. > > -------->8 > > > > There are several proven installations that have been around for a > > number of years that provide free (IPv6) tunneling services. > > Payment should be out of scope here, but to solve the issue the above > > suggested scenario could add a 'payed' or 'free' flag to note it. > > Any service has a AUP or some other form of rules, one of those rules > > could be payment. >=20 > IMHO those installations prove only little of more wide-scale=20 > deployment, e.g., when there would be over a million users worldwide=20 > or the like. That's what we need to aim for .. not for providing=20 > services to IPv6 geeks or other techy users -- those will get it in=20 > any case so it doesn't matter. I think that the end users of these systems will look at that in completely way. Saying that something free and/or public 'is not good enough' is not a smart thing, two words: BSD & Linux (in random order). How many users for instance Freenet6 and Hurricane serve is unknown. That they are not millions is mostly because there is no default tool installed on the common users boxes, also their is no valuable content (yet) for attracting the users to start using it I can also note that I know that the largest amount of those users have no clue at *all* what IPv6 is. Most of them simply get a nice host on IRC and the others have a good newsfeed. They really don't care, they just click a couple of times and run a script or some tool. That these are not standardized by the IETF doesn't say they don't exist and certainly don't mean that they are not used... > > The solution in 3.1 is IMHO not doable, as this defines a tunnel > > endpoint but never mentions how the Tunnel Server knows where/who/what > > the remote endpoint (client) is, which is autoconfigured to use the > > anycast address in the first place. >=20 > All the solutions assume that the tunneling mechanism -specific means=20 > are used to obtain that. E.g., one could have a pseudo-interface=20 > which creates tunnels on the receipt of the first packet, or=20 > something. This should not be a problem. I already see that script kiddy spoofing IPv4 packets with ease and generating a lot of interfaces at random, but how was that configured? Or better said how did you authenticate the user to the tunnel service? Especially when the user is not directly coming from your own IPv4 space, a remote mobile user, a user visiting another ISP's network etc. l2tp / AYIYA / ... etc could be used as those protocols provide authentication inside the protocol stream, but proto-41, which is the most common used setup doesn't work in this case. > > How is it going to know which prefix to use and how is the TS going > > to know where to route packets destined for that prefix? >=20 > The client doesn't need to know the prefix but it might. It could=20 > just learn the prefix from the TS, similar to the process STEP uses. STEP/TSP fall under the "Configuration" header in the 3-phase list. These should IMHO determine the type of protocol for the data being tunneled. STEP though doesn't define any protocol, thus would be limited to the underlying protocol that would be used, which would then make this only applicable in a few scenarios of the many that exist. Which again doesn't make it applicable for the many users and varying setups out around the world. Greets, Jeroen --=-vI9xcH+FEN2G1ZAnKAq0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA0IA5KaooUjM+fCMRApKgAJ9DZXGB4qayteBOsjMc5FSTe94DVgCfTX2U 6ZVMtIZbS5afgDHqsjHQS0I= =rmys -----END PGP SIGNATURE----- --=-vI9xcH+FEN2G1ZAnKAq0-- From owner-v6ops@ops.ietf.org Thu Jun 17 11:13: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 LAA08927 for ; Thu, 17 Jun 2004 11:13:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BayWj-000Brd-Vi for v6ops-data@psg.com; Thu, 17 Jun 2004 15:10:05 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BayWi-000BrO-Qw for v6ops@ops.ietf.org; Thu, 17 Jun 2004 15:10:05 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5HF9ud00884; Thu, 17 Jun 2004 08:09:56 -0700 X-mProtect: <200406171509> 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 smtpdLBxU6m; Thu, 17 Jun 2004 08:09:55 PDT Message-ID: <40D1B44F.5040206@iprg.nokia.com> Date: Thu, 17 Jun 2004 08:10:07 -0700 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: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: >FYI -- > >(co-chair hat on) > >If interested in mech-v2, take a look -- this aims to address all the >IESG evaluation comments except what we're currently discussing with >Margaret. > It seems that section 3.4 of the current mech-v2 draft includes a built-in assumption that ICMPv4 error translation to ICMPv6 is only possible when the ICMPv4 error messages *themselves* include more than the minimum 8 bytes of data beyond the IPv4 header of the packet in error. But, if the encapsulator maintains a small queue of recently-sent packets (indexed, e.g., by the 'ip_id' field of the encapsulating IPv4 headers) then enough state would be available for ICMPv6 error generation in most cases even if the ICMPv4 error messages themselves only return the minimum amount. I suggest the following changes: 1) Section 3.4, 4th paragraph. change to: "The handling of other types of ICMPv4 error messages depends on how much information is available from the encapsulated packet that caused the error." 2) Section 3.4, 6th paragraph, change: "If the offending packet includes enough data, the encapsulator MAY" to: "If the offending packet includes enough data, or if enough data is available in the encapulator's cache, the encapsulator MAY" 3) Section 3.4, 7th paragraph, change: "Also, if sufficient headers are included in the error" to: "Also, if sufficient headers are available" 4) Section 3.4, 8th paragraph, change: "Note that when IPv4 path MTU is exceeded, and ICMPv4 errors of only 8 bytes of payload are generated," to: "Note that when the IPv4 path MTU is exceeded, and sufficient bytes of payload associated with the ICMPv4 errors are not available," >(co-chair hat off) > >Btw. if interested in PMTUD/packet size issues, you might also find >draft-savola-mtufrag-network-tunneling-00.txt interesting. It's a >more generic document describing PMTUD, fragmentation/reassembly, etc. >issues in tunneling in the network. > You appear to be bird-dogging me, Pekka; I have authored a well-publicized series of closely-related documents. See: http://www.geocities.com/osprey67/tunnelmtu-02.txt http://www.geocities.com/osprey67/tunnelmtu-03.txt http://www.geocities.com/osprey67/tunnelmtu-04.txt http://www.geocities.com/osprey67/tunnelmtu-05.txt http://www.geocities.com/osprey67/tunnelmtu-06.txt http://www.geocities.com/osprey67/isatap/iemmei-00.txt http://www.ietf.org/internet-drafts/draft-templin-v6ops-iemmei-01.txt (I could dig up the e-mail announcements for these, if interested.) Fred L. Templin ftemplin@iprg.nokia.com > >---------- Forwarded message ---------- >Date: Tue, 15 Jun 2004 15:45:40 -0400 >From: Internet-Drafts@ietf.org >To: i-d-announce@ietf.org >Cc: v6ops@ops.ietf.org >Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt > >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 : Basic Transition Mechanisms for IPv6 Hosts and Routers > Author(s) : E. Nordmark, R. Gilligan > Filename : draft-ietf-v6ops-mech-v2-03.txt > Pages : 32 > Date : 2004-6-15 > >This document specifies IPv4 compatibility mechanisms that can be > implemented by IPv6 hosts and routers. Two mechanisms are specified, > 'dual stack' and configured tunneling. Dual stack implies providing > complete implementations of both versions of the Internet Protocol > (IPv4 and IPv6) and configured tunneling provides a means to carry > IPv6 packets over unmodified IPv4 routing infrastructures. > > This document obsoletes RFC 2893. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-03.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-v6ops-mech-v2-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-mech-v2-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 Fri Jun 18 01:55: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 BAA14959 for ; Fri, 18 Jun 2004 01:55:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbCJl-0007Ec-6L for v6ops-data@psg.com; Fri, 18 Jun 2004 05:53:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbCJj-0007EE-Mf for v6ops@ops.ietf.org; Fri, 18 Jun 2004 05:53:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5I5rYE03530; Fri, 18 Jun 2004 08:53:34 +0300 Date: Fri, 18 Jun 2004 08:53:34 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: Mohan Parthasarathy , Tschofenig Hannes Subject: I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI -- Comments etc. of course welcome. ---------- Forwarded message ---------- Date: Mon, 14 Jun 2004 15:28:01 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using IPsec to Secure IPv6-over-IPv4 Tunnels Author(s) : H. Tschofenig, et al. Filename : draft-tschofenig-v6ops-secure-tunnels-00.txt Pages : 23 Date : 2004-6-14 This document gives guidance on securing IPv6-in-IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the revised IPsec framework. IKEv2 is extensively used as an authentication and key exchange protocol to cover address configuration procedures, and the usage of the Extensible Authentication Procotol and NAT traversal capabilities is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-tschofenig-v6ops-secure-tunnels-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-tschofenig-v6ops-secure-tunnels-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Fri Jun 18 02:27:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00484 for ; Fri, 18 Jun 2004 02:27:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbCpN-000Adq-7c for v6ops-data@psg.com; Fri, 18 Jun 2004 06:26:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbCpK-000AdR-EP for v6ops@ops.ietf.org; Fri, 18 Jun 2004 06:26:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5I6Pt604431; Fri, 18 Jun 2004 09:25:58 +0300 Date: Fri, 18 Jun 2004 09:25:55 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt In-Reply-To: <20040602160800.GE7083@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I just revised the draft slightly, as the LC ended a couple of days ago. I took about all your comments (also added a note on compatible addressed but with caveat that it's often still supported). A few replies in line.. On Wed, 2 Jun 2004, Tim Chown wrote: [...] > Do we have field reports of 6to4 abuse to date? (Curious if they are > recorded anywhere) Not much has been recorded on this, but there have been a lot of attacks -- through a relay, not *on* the relay (that I know of). > It seems many ISPs (NRENs, usually) simply avoid advertising 2002::/16 > outside their border, or the IPv4 anycast address outsude their border, > to limit their "traffic magnet". I guess this is your model in > Section 6.2, but you talk about 2002::/16 limitation, rather than the > IPv4 anycast limitation? I was referring to both v4 and v6 prefix announcements, clarified. > This is probably why most people see SWITCH's > relay ;) While there are enough "third party relays" (as you call them), > the closed model still appears to work because of the current traffic > levels and available relays like SWITCH's. To some degree of usefulness, yes. I could hardly call that an acceptable level of quality, though -- it's not nice, having to come to Europe from the US (for example) to talk to your US neighbor... > It's not clear how many recommendations in your (very thorough!) draft > are widely implemented - would be very interesting to know... Yes, I'd be interested in that as well.. -- 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 Jun 18 03:20:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02871 for ; Fri, 18 Jun 2004 03:20:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbDdw-000FDf-K9 for v6ops-data@psg.com; Fri, 18 Jun 2004 07:18:32 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbDdv-000FDM-0c for v6ops@ops.ietf.org; Fri, 18 Jun 2004 07:18:31 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 401638580; Fri, 18 Jun 2004 09:18:27 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 18390-72; Fri, 18 Jun 2004 09:18:09 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E22337F67; Fri, 18 Jun 2004 09:18:07 +0200 (CEST) Subject: Re: I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-00.txt (fwd) From: Jeroen Massar To: Pekka Savola Cc: v6ops@ops.ietf.org, Mohan Parthasarathy , Tschofenig Hannes In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-t2u7NtrgpXzeUjRrtZQY" Organization: Unfix Message-Id: <1087543084.21206.50.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 18 Jun 2004 09:18:05 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-t2u7NtrgpXzeUjRrtZQY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-06-18 at 07:53, Pekka Savola wrote: > FYI --=20 >=20 > Comments etc. of course welcome. > This document gives guidance on securing IPv6-in-IPv4 tunnels using > IPsec. No additional protocol extensions are described beyond those > available with the revised IPsec framework. IKEv2 is extensively > used as an authentication and key exchange protocol to cover address > configuration procedures, and the usage of the Extensible > Authentication Procotol and NAT traversal capabilities is also > described. IMHO it is a bit 'late' to start securing proto-41. It has been in use already for too long and by too many people. IPSEC on hosts and routers is near-to-none in existence, notez bien that IPSEC in IPv6 is a mandatory item of IPv6 stacks and that many stacks simply don't have it ;). Setting up an IPSEC connection costs a lot of effort and negotiation. Not even talking about the note about traveling the NAT's ;) Thus this memo does have a good value for people who want to secure it afterall, but I don't think that it will actually happen a lot due to the above three items. I didn't find any content issues in my quick glance. Greets, Jeroen --=-t2u7NtrgpXzeUjRrtZQY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA0pcsKaooUjM+fCMRAg1YAJ9wSuaB/yEJctj/ZeUyFWdT/ADLEgCgnkC4 byLX4lBkoy9crSR0etDrB64= =zvnB -----END PGP SIGNATURE----- --=-t2u7NtrgpXzeUjRrtZQY-- From owner-v6ops@ops.ietf.org Fri Jun 18 03:44:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03673 for ; Fri, 18 Jun 2004 03:44:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbE25-000HDl-P3 for v6ops-data@psg.com; Fri, 18 Jun 2004 07:43:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbE24-000HDX-FG for v6ops@ops.ietf.org; Fri, 18 Jun 2004 07:43:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5I7hOa06410; Fri, 18 Jun 2004 10:43:24 +0300 Date: Fri, 18 Jun 2004 10:43:24 +0300 (EEST) From: Pekka Savola To: Jeroen Massar cc: v6ops@ops.ietf.org, Mohan Parthasarathy , Tschofenig Hannes Subject: Re: I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-00.txt (fwd) In-Reply-To: <1087543084.21206.50.camel@segesta.zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 18 Jun 2004, Jeroen Massar wrote: > IMHO it is a bit 'late' to start securing proto-41. It has been in use > already for too long and by too many people. Just to be clear, this document doesn't intend to say, "OK, let's use IPsec for proto-41, and forget the unsecured version". It's just trying to describe the scenarios and IPsec mechanisms which *could* be used for securing. :) > Thus this memo does have a good value for people who want to secure it > afterall, but I don't think that it will actually happen a lot due to > the above three items. I would be (pleasantly) surprised if it happened to a very large degree, but you never know. :) In any case, this kind of document (or IPsec description in general) was required by the IESG for going forward with draft-ietf-v6ops-mech-v2. -- 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 Jun 18 03:48: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 DAA03876 for ; Fri, 18 Jun 2004 03:48:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbE5w-000HgW-B9 for v6ops-data@psg.com; Fri, 18 Jun 2004 07:47:28 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbE5v-000HgG-5q for v6ops@ops.ietf.org; Fri, 18 Jun 2004 07:47:27 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id EFA408580; Fri, 18 Jun 2004 09:47:24 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 18390-86; Fri, 18 Jun 2004 09:47:14 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id BD4967F67; Fri, 18 Jun 2004 09:47:13 +0200 (CEST) Subject: Re: I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-00.txt (fwd) From: Jeroen Massar To: Pekka Savola Cc: v6ops@ops.ietf.org, Mohan Parthasarathy , Tschofenig Hannes In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zDkg/zeiF/f0NujoZRyw" Organization: Unfix Message-Id: <1087544831.21206.69.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 18 Jun 2004 09:47:11 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-zDkg/zeiF/f0NujoZRyw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-06-18 at 09:43, Pekka Savola wrote: > On Fri, 18 Jun 2004, Jeroen Massar wrote: > > IMHO it is a bit 'late' to start securing proto-41. It has been in use > > already for too long and by too many people. >=20 > Just to be clear, this document doesn't intend to say, "OK, let's use=20 > IPsec for proto-41, and forget the unsecured version". It's just=20 > trying to describe the scenarios and IPsec mechanisms which *could* be=20 > used for securing. :) Ack. > > Thus this memo does have a good value for people who want to secure it > > afterall, but I don't think that it will actually happen a lot due to > > the above three items. >=20 > I would be (pleasantly) surprised if it happened to a very large=20 > degree, but you never know. :) >=20 > In any case, this kind of document (or IPsec description in general)=20 > was required by the IESG for going forward with=20 > draft-ietf-v6ops-mech-v2. I understand that point as the proto-41 stuff and actually any tunneling protocol that doesn't authenticate the sender allows more spoofing to happen and that makes packets untraceable and able to bypass ingress filters etc. which simply is not something that should be condoned. Greets, Jeroen --=-zDkg/zeiF/f0NujoZRyw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA0p3+KaooUjM+fCMRAgnEAJ9J22Fk3+XmfEGJSHuuZmh5t7jg/wCfa6xV 39nLrue6iYWee+x6gnf1yMg= =NFgm -----END PGP SIGNATURE----- --=-zDkg/zeiF/f0NujoZRyw-- From owner-v6ops@ops.ietf.org Fri Jun 18 15:39: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 PAA14501 for ; Fri, 18 Jun 2004 15:39:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbP9g-000Ct5-PP for v6ops-data@psg.com; Fri, 18 Jun 2004 19:36:04 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbP9f-000Csh-98 for v6ops@ops.ietf.org; Fri, 18 Jun 2004 19:36:04 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14395; Fri, 18 Jun 2004 15:36:01 -0400 (EDT) Message-Id: <200406181936.PAA14395@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-isp-scenarios-analysis-03.txt Date: Fri, 18 Jun 2004 15:36:00 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 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 : Scenarios and Analysis for Introducing IPv6 into ISP Networks Author(s) : M. Lind, et al. Filename : draft-ietf-v6ops-isp-scenarios-analysis-03.txt Pages : 27 Date : 2004-6-18 This document first describes different scenarios for the introduction of IPv6 into an existing IPv4 ISP network without disrupting the IPv4 service. Then, this document analyses these scenarios and evaluates the suitability of the already defined transition mechanisms in this context. Known challenges are also identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-isp-scenarios-analysis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-18154843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-isp-scenarios-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-18154843.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jun 18 15:40:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14520 for ; Fri, 18 Jun 2004 15:40:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbP9n-000CuG-5x for v6ops-data@psg.com; Fri, 18 Jun 2004 19:36:11 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbP9m-000Cti-0h for v6ops@ops.ietf.org; Fri, 18 Jun 2004 19:36:10 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14412; Fri, 18 Jun 2004 15:36:07 -0400 (EDT) Message-Id: <200406181936.PAA14412@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-6to4-security-03.txt Date: Fri, 18 Jun 2004 15:36:07 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 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 : Security Considerations for 6to4 Author(s) : P. Savola, C. Patel Filename : draft-ietf-v6ops-6to4-security-03.txt Pages : 40 Date : 2004-6-18 The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 Routers and Relay Routers, which accept and decapsulate IPv4 protocol-41 ('IPv6-in-IPv4') traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using 6to4 relays or routers as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 node. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-6to4-security-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-6to4-security-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-18154851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-6to4-security-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-security-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-18154851.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jun 18 16:43:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20640 for ; Fri, 18 Jun 2004 16:43:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbQB3-000K1Q-UJ for v6ops-data@psg.com; Fri, 18 Jun 2004 20:41:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbQB2-000K18-HE for v6ops@ops.ietf.org; Fri, 18 Jun 2004 20:41:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5IKero22675; Fri, 18 Jun 2004 23:40:53 +0300 Date: Fri, 18 Jun 2004 23:40:53 +0300 (EEST) From: Pekka Savola To: david.kessens@nokia.com cc: bwijnen@lucent.com, , Subject: Request to Advance "Security Considerations for 6to4" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk David, On behalf of the v6ops WG, we'd like to request that the following document be published as Informational RFC: Security Considerations for 6to4 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-03.txt The WG last call was completed on 16th June. The revised version addresses the minor and editorial issues raised during the last call. Thanks, Pekka & Jonne v6ops WG co-chairs From owner-v6ops@ops.ietf.org Fri Jun 18 17:01: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 RAA22102 for ; Fri, 18 Jun 2004 17:01:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbQTq-000MRR-Dk for v6ops-data@psg.com; Fri, 18 Jun 2004 21:00:58 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbQTo-000MQU-PW for v6ops@ops.ietf.org; Fri, 18 Jun 2004 21:00:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5IL0t123239; Sat, 19 Jun 2004 00:00:55 +0300 Date: Sat, 19 Jun 2004 00:00:55 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: fred@cisco.com, , Subject: WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, (co-chair hat on) This is the WG Last Call for comments on sending draft-ietf-v6ops-renumbering-procedure-00.txt, "Procedures for Renumbering an IPv6 Network without a Flag Day" to the IESG for consideration as Informational: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-00.txt Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. Please note that this was originally thought to go for BCP instead of Informational, but the procedure might not yet warrant the BCP "seal of approval", so informational was tentatively chosen instead. If you have preferences about this, please indicate them during the WGLC as well. The last call will end in about 2 weeks, on 4th July. Thanks! From owner-v6ops@ops.ietf.org Fri Jun 18 17:19:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23179 for ; Fri, 18 Jun 2004 17:19:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbQkC-000OUB-V5 for v6ops-data@psg.com; Fri, 18 Jun 2004 21:17:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbQkB-000OTj-O7 for v6ops@ops.ietf.org; Fri, 18 Jun 2004 21:17:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5ILHml23687; Sat, 19 Jun 2004 00:17:48 +0300 Date: Sat, 19 Jun 2004 00:17:48 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: huitema@microsoft.com Subject: Review requested: draft-huitema-v6ops-teredo-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (co-chair hat on) The WG rough consensus, measured in May, was for going forward with Teredo. A revised version of the specification, draft-huitema-v6ops-teredo-02.txt, was recently submitted. There has been little review of it, and it is important to move forward from here. It is (still, unfortunately) open whether such specifications should be adopted as v6ops items (or at some other WG, or...), so as we can't really hold a WGLC on a document which is not yet a WG document, we'll have to improvise... Please review draft-huitema-v6ops-teredo-02.txt by two weeks, 2nd Juldy (just like you would review a document going for WGLC) send the feedback to the list. The current understanding of the category is Proposed Standard, but there has been some debate of this as well. You are also encouraged to review: http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-huitema-v6ops-teredo.txt to see if this is a problem for you. Thanks! (co-chair hat off) -- 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 Sun Jun 20 17:13: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 RAA29791 for ; Sun, 20 Jun 2004 17:13:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bc9aj-0006zX-Sc for v6ops-data@psg.com; Sun, 20 Jun 2004 21:11:05 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bc9ai-0006zC-Id; Sun, 20 Jun 2004 21:11:04 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5KLAJ0A083353; Sun, 20 Jun 2004 23:10:19 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 , Fred Baker From: Iljitsch van Beijnum Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Sun, 20 Jun 2004 23:10:54 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-jun-04, at 23:06, Pekka Savola wrote: > IMHO, making sure that renumbering a network is as simple as it can be > is a subject which is very much related to multi6 designs.. and IMHO > an operational requirement if we wish to deploy a model where we might > envision populating hosts on a site with multiple addresses. > So, review of the v6ops document describing a renumbering procedure > would be very much appreciated. Please send the comments on v6ops > list! Ok, first comment is relevant to multi6: Having two prefixes at the same time lands you squarely inside the domain of draft-huitema-... The draft now assumes that having both old and new addresses works, and this isn't an assumption you can just make. In the case of changing addresses where both address ranges come from the same ISP this could be the case, but I don't see how this would be a regularly occurring event (after the 6bone has been shut down). In the case that both prefixes come from different ISPs, the network essentially becomes multihomed periodically, so it suffers all the ingress filtering trouble that we've been discussing in multi6. The draft only talks about ingress filtering with regard to security, which IMNSHO is stupid because there are no attacks that are possible with spoofed addresses that aren't possible with unspoofed addresses. It's just that tracking the attacks down takes longer. The real issue is that you MUST deliver packets to the ISP that matches the source address or you have no connecitivity. There are three ways this can happen: 1. disable ingress filtering for one ISP and route everything over that ISP 2. use policy routing or some other source address based routing to route packets to the ISP matching the source address 3. have a flag day Talking about flag days: I'm missing a discussion on making use of the possibility of deprecating a prefix when stateless autoconfiguration is used. This mechanism makes it possible to move all new (outgoing) sessions to a new prefix in a couple of minutes. All in all I think this draft is suffering from lack of ambition. Either provide some real guidance rather than a bunch of truisms or drop the whole thing. As I'm feeling generous today here's a partial list of suggestions in the area of renumbering that people usually only get to read after paying $40 or so: - register the new addresses for authorative nameservers with all pertinent registries as soon as the nameservers are reachable over the new addresses - there are two ways to change server addresses fairly painlessly: lower the DNS TTLs and do it at once, or run two addresses side by side for a while. The latter is usually more work but can be done without any interruption at all - log (attempted) use of the old addresses to see whether everything has switched - turn off the old addresses for a while to flush out the last users, then turn them back on again so those last users get to change over without too much network interruption - when the old addresses are removed, do traceroutes in various places to see if they're really gone From owner-v6ops@ops.ietf.org Mon Jun 21 04:18: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 EAA20531 for ; Mon, 21 Jun 2004 04:18:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcJz0-000Mba-DS for v6ops-data@psg.com; Mon, 21 Jun 2004 08:16:50 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJyz-000Mb9-1f; Mon, 21 Jun 2004 08:16:49 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i5L8GmnE022295; Mon, 21 Jun 2004 09:16:48 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA20094; Mon, 21 Jun 2004 09:16:46 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i5L8GkA24667; Mon, 21 Jun 2004 09:16:46 +0100 Date: Mon, 21 Jun 2004 09:16:46 +0100 From: Tim Chown To: v6ops@ops.ietf.org, Multi6 Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Message-ID: <20040621081646.GJ23590@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, Multi6 References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <40D692F9.3000603@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D692F9.3000603@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jun 21, 2004 at 09:49:13AM +0200, Eliot Lear wrote: > > One of us has missed the point. Firewalls today filter packets based on > destination address. While I would agree that filtering on a source > FROM the Internet would be foolish, different hosts on the perimeter may > require different levels of protection. Regardless, those rules exist > today inside firewalls and would need to be changed, and that's what > we're saying. It's probablymuch more common than you'd fear that sites use source address based filtering in firewalls. And of course that's the snag that the firewall rules need updating (or at least reloading/resolving) on remote site firewalls not just on the renumbering site. There's also plenty of examples of source IP based access controls in other places, e.g. in the transport layer in TCP wrapper configuration files, or in the application layer with, e.g., IP-based access control to web resources (publisher material being a common one in academic circles - a big university is granted access by it's whole Class B site block). > Want to make it easier? Great. I'm all ears. Perhaps that will be the > killer app for IPv6, but I doubt it. My motivation was really to make > incremental progress on eliminating the need for site-local and natting. I think the scope and motivation is very good :) Tim From owner-v6ops@ops.ietf.org Mon Jun 21 05:21:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24202 for ; Mon, 21 Jun 2004 05:21:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcKyj-0003SW-Hj for v6ops-data@psg.com; Mon, 21 Jun 2004 09:20:37 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJYS-000Ir7-S2; Mon, 21 Jun 2004 07:49:24 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2004 00:52:38 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5L7nKlq012283; Mon, 21 Jun 2004 00:49:21 -0700 (PDT) Received: from [10.61.124.162] (ams-clip-equant-dhcp-161.cisco.com [10.61.124.162]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id AAA19936; Mon, 21 Jun 2004 00:49:15 -0700 (PDT) Message-ID: <40D692F9.3000603@cisco.com> Date: Mon, 21 Jun 2004 09:49:13 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Pekka Savola , Ralph Droms , v6ops@ops.ietf.org, Multi6 , Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> In-Reply-To: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > Ok, first comment is relevant to multi6: > > Having two prefixes at the same time lands you squarely inside the > domain of draft-huitema-... The draft now assumes that having both old > and new addresses works, and this isn't an assumption you can just make. No, we assume that the network is in a nominal state prior to renumbering. The issue you raise below would indicate that perhaps this *isn't* the case. In which case your problems are bigger than renumbering. > In the case of changing addresses where both address ranges come from > the same ISP this could be the case, but I don't see how this would be a > regularly occurring event (after the 6bone has been shut down). In the > case that both prefixes come from different ISPs, the network > essentially becomes multihomed periodically, so it suffers all the > ingress filtering trouble that we've been discussing in multi6. We make note of the fact that there is a linkage between the upstream ISP and the network. What perhaps we should state is that upstreams may need to know about each other from anti-spoofing mechanism. > The > draft only talks about ingress filtering with regard to security, which > IMNSHO is stupid because there are no attacks that are possible with > spoofed addresses that aren't possible with unspoofed addresses. One of us has missed the point. Firewalls today filter packets based on destination address. While I would agree that filtering on a source FROM the Internet would be foolish, different hosts on the perimeter may require different levels of protection. Regardless, those rules exist today inside firewalls and would need to be changed, and that's what we're saying. > It's > just that tracking the attacks down takes longer. The real issue is that > you MUST deliver packets to the ISP that matches the source address or > you have no connecitivity. There are three ways this can happen: > > 1. disable ingress filtering for one ISP and route everything over that ISP > 2. use policy routing or some other source address based routing to > route packets to the ISP matching the source address > 3. have a flag day This configuration either exists prior to the renumbering events or it doesn't. If it does it would need to be modified to match the new addresses. The renumbering document does not attempt to solve the multi6 problem. > > Talking about flag days: I'm missing a discussion on making use of the > possibility of deprecating a prefix when stateless autoconfiguration is > used. This mechanism makes it possible to move all new (outgoing) > sessions to a new prefix in a couple of minutes. This is a best case scenario that assumes all the appropriate linkages for reverse dns lookups that almost assuredly don't exist, not to mention the TTLs that are present. If what you wrote above was the general case I wouldn't have cared to get involved in such a document. > > All in all I think this draft is suffering from lack of ambition. Either > provide some real guidance rather than a bunch of truisms or drop the > whole thing. This draft's ambition is to document the process, and perhaps point out a few areas for improvement in the standards/development front. I personally think it also shows that the problem is really no less complex than IPv4, and if we add the MULTI6 fun, we could make it moreso. Want to make it easier? Great. I'm all ears. Perhaps that will be the killer app for IPv6, but I doubt it. My motivation was really to make incremental progress on eliminating the need for site-local and natting. Eliot From owner-v6ops@ops.ietf.org Mon Jun 21 06:26: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 GAA28127 for ; Mon, 21 Jun 2004 06:26:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcLzV-000A9u-5c for v6ops-data@psg.com; Mon, 21 Jun 2004 10:25:29 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcLzT-000A9P-A2; Mon, 21 Jun 2004 10:25:27 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5LAOl0A097121; Mon, 21 Jun 2004 12:24:47 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40D692F9.3000603@cisco.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <40D692F9.3000603@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4E3DBBB8-C36D-11D8-96AB-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 , v6ops@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Mon, 21 Jun 2004 12:25:23 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 21-jun-04, at 9:49, Eliot Lear wrote: >> The draft now assumes that having both old and new addresses works, >> and this isn't an assumption you can just make. > No, we assume that the network is in a nominal state prior to > renumbering. The issue you raise below would indicate that perhaps > this *isn't* the case. In which case your problems are bigger than > renumbering. I don't understand what you're getting at. My point is that if you have two prefixes from two ISPs (which I think is the most common situation in renumbering, and it's certainly common enough to be worthy of discussion in a renumbering draft) and both ISPs do ingress filtering (which is also something that can't be discounted) then "turning on" both prefixes at the same time without additional measures is going to lead to problems as packets routed to ISP A may have a source address from the prefix from ISP B (or vice versa) and thus be dropped due to ingress filtering. > We make note of the fact that there is a linkage between the upstream > ISP and the network. What perhaps we should state is that upstreams > may need to know about each other from anti-spoofing mechanism. But what if the ISPs aren't prepared to cooperate? Not everyone is a fortune 1000 company. >> The draft only talks about ingress filtering with regard to security, >> which IMNSHO is stupid because there are no attacks that are possible >> with spoofed addresses that aren't possible with unspoofed addresses. > One of us has missed the point. Firewalls today filter packets based > on destination address. While I would agree that filtering on a > source FROM the Internet would be foolish, different hosts on the > perimeter may require different levels of protection. Regardless, > those rules exist today inside firewalls and would need to be changed, > and that's what we're saying. Yes, but this has very little to do with ingress filtering by ISPs, so the current text obscures the issue rather than illuminate it. >> It's just that tracking the attacks down takes longer. The real issue >> is that you MUST deliver packets to the ISP that matches the source >> address or you have no connecitivity. > This configuration either exists prior to the renumbering events or it > doesn't. If it does it would need to be modified to match the new > addresses. Nonsense. The existence of two prefixes at the same time is exclusively related to renumbering in non-multihomed networks, so it has no relation to the state of the network either before or after renumbering. >> All in all I think this draft is suffering from lack of ambition. >> Either provide some real guidance rather than a bunch of truisms or >> drop the whole thing. > This draft's ambition is to document the process, and perhaps point > out a few areas for improvement in the standards/development front. I > personally think it also shows that the problem is really no less > complex than IPv4, and if we add the MULTI6 fun, we could make it > moreso. Actually it is much less complex unless people extensively use manually configured addresses. The problem with IPv4 is deciding on subnet sizes, merging subnets, avoiding overlap and so on. None of this is an issue with IPv6 since everything fits in a standard issue /64. Obviously there is lots of other stuff that remains the same but what else is new. > Want to make it easier? Great. I'm all ears. There are some pages in my book about renumbering (in IPv4). Feel free to borrow from that (not the literal text, of course). From owner-v6ops@ops.ietf.org Mon Jun 21 12:11:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28208 for ; Mon, 21 Jun 2004 12:11:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcRLj-000MXN-Jp for v6ops-data@psg.com; Mon, 21 Jun 2004 16:08:47 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcRLZ-000MW7-VK for v6ops@ops.ietf.org; Mon, 21 Jun 2004 16:08:38 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5LG9RIv000334; Mon, 21 Jun 2004 18:09:27 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40D6C5BF.8090004@cisco.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <40D692F9.3000603@cisco.com> <4E3DBBB8-C36D-11D8-96AB-000A95CD987A@muada.com> <40D6C5BF.8090004@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00CA7129-C399-11D8-96AB-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Mon, 21 Jun 2004 17:38:11 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [dropping multi6] On 21-jun-04, at 13:25, Eliot Lear wrote: > Okay, the confusion in this exchange stems from which "ingress" we > were talking about. Shame we don't have better terminology here. >>> We make note of the fact that there is a linkage between the >>> upstream ISP and the network. What perhaps we should state is that >>> upstreams may need to know about each other from anti-spoofing >>> mechanism. >> But what if the ISPs aren't prepared to cooperate? Not everyone is a >> fortune 1000 company. > Okay, I follow you. The draft attempts to cover ground in two areas: > 1. That which can be done today; > 2. What needs to be fixed. I believe you're arguing for a fix, and > perhaps some text in the draft would be good. I wasn't arguing for a fix, although an automated way to open up ingress filtering by ISPs would be very useful here. What I am arguing for is acknowledging this issue in the draft so that people know what they can do to work around this problem. >> Actually it is much less complex unless people extensively use >> manually configured addresses. The problem with IPv4 is deciding on >> subnet sizes, merging subnets, avoiding overlap and so on. None of >> this is an issue with IPv6 since everything fits in a standard issue >> /64. > We have saved network managers from requiring a set of spreadsheet > operations. BFD. The level of complexity is substantially the same. Actually this is a big deal, as in IPv4 address management is so problematic that renumbering pretty much requires manual intervention. While I agree that all the other issues, such as the DNS and access filters, are also problematic, it's certainly within the realm of possibility to automate these issues. > IPv6 was billed as a great self-configuring does-everything-but-eat > follow-on to IPv4. Very little of that is true today. Yes, when do we get to discover DNS resolvers automatically? Other than that the situation isn't as bad as you make it seem. > We'd like to identify the mechanisms that would improve matters, at > least for IPv6. Who knows? Maybe for IPv4 as well. For instance, > what you're looking for above is some way for providers to learn about > customers' alternative published connectivity, such as a more robust > and accurate RADB in order to configure ingress access-lists. One > needs to understand who's authoritative for the information, and what > the keys are. Certainly the keys are unlikely to be IP address > prefixes :-( This is pretty much a non-issue as these filters can be created using unicast reverse path forwarding (uRPF). However, I agree that better IP address authorization information would be good, if we get this then we may be able to secure interdomain routing much better. (See S-BGP and soBGP, although neither of those is necessary if vendors implement better mechanisms to upload long prefix filters to routers.) > As to whether the providers are willing to implement such a mechanism, > I can't say. They will look for an easier way, and that easier way > today is a NAT that does source selection (policy routing). I don't see the relation between NAT and policy routing. Both are harmful, though. From owner-v6ops@ops.ietf.org Mon Jun 21 12:40: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 MAA00966 for ; Mon, 21 Jun 2004 12:40:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcRqH-000Ps2-4e for v6ops-data@psg.com; Mon, 21 Jun 2004 16:40:21 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcRqF-000Pqu-Bh; Mon, 21 Jun 2004 16:40:19 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 09:40:17 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 09:40:14 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 09:40:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 21 Jun 2004 09:40:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Mon, 21 Jun 2004 09:40:16 -0700 Message-ID: Thread-Topic: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Thread-Index: AcRXC9V1KF4Dk0vQRh++NXryNVWmCAAoK8ow From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Pekka Savola" Cc: "Ralph Droms" , , "Eliot Lear" , "Multi6" , "Fred Baker" X-OriginalArrivalTime: 21 Jun 2004 16:40:18.0082 (UTC) FILETIME=[6F8F8820:01C457AE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RISK_FREE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Having two prefixes at the same time lands you squarely inside the > domain of draft-huitema-...=20 I actually discussed this point when reviewing an early version of the draft. Fred took the comments into account in section 2.3, "Configuring network elements with the new prefix", and in section 3.3, "Ingress filtering". The text is OK, although it would perhaps be desirable to be a bit more explicit in section 3.3, since there is a way to shoot yourself in the foot. The draft's assumption should be made very clear: * you can shoot yourself in the foot if you route packet to an ISP and that ISP drops them because they fail the ISP ingress filtering test; * we must definitely assume that the new ISP will accept traffic sourced from the old prefix; * the transition works much better if the old ISP accepts traffic from the new prefix, in which case there is no risk of any holes in anyone's foot; * if the old ISP does not accept traffic from the new prefix, then the routing should be updated first: send all the traffic to the new ISP before starting to configure the new addresses. The case that Fred studies is less constrained than the general multi6 problem. Since the goal is to move from a state where all traffic is sent to the old ISP to a state where all traffic is sent to the new one, there is little need to emphasize traffic engineering or load balancing between the two ISP. -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Jun 21 13:25:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08712 for ; Mon, 21 Jun 2004 13:25:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcSWn-0005NL-1T for v6ops-data@psg.com; Mon, 21 Jun 2004 17:24:17 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcSWl-0005N4-L8 for v6ops@ops.ietf.org; Mon, 21 Jun 2004 17:24:16 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 1A7167D; Mon, 21 Jun 2004 13:24:15 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 13:24:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review requested: draft-huitema-v6ops-teredo-02.txt Date: Mon, 21 Jun 2004 13:24:13 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC805@tayexc13.americas.cpqcorp.net> Thread-Topic: Review requested: draft-huitema-v6ops-teredo-02.txt Thread-Index: AcRVekakHcef/wJeTmOiIag9uRSXFACOi9og From: "Bound, Jim" To: "Pekka Savola" , Cc: X-OriginalArrivalTime: 21 Jun 2004 17:24:14.0851 (UTC) FILETIME=[93328D30:01C457B4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable If we accept this we need to move on all mechanisms not just Teredo. I support moving forward on all of them. PS is still unclear to me and I thought we were going to suggest Experimental RFC? Thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Friday, June 18, 2004 5:18 PM > To: v6ops@ops.ietf.org > Cc: huitema@microsoft.com > Subject: Review requested: draft-huitema-v6ops-teredo-02.txt >=20 > (co-chair hat on) >=20 > The WG rough consensus, measured in May, was for going=20 > forward with Teredo. >=20 > A revised version of the specification, > draft-huitema-v6ops-teredo-02.txt, was recently submitted. =20 > There has been little review of it, and it is important to=20 > move forward from here. >=20 > It is (still, unfortunately) open whether such specifications=20 > should be adopted as v6ops items (or at some other WG,=20 > or...), so as we can't really hold a WGLC on a document which=20 > is not yet a WG document, we'll have to improvise... >=20 > Please review draft-huitema-v6ops-teredo-02.txt by two weeks,=20 > 2nd Juldy (just like you would review a document going for=20 > WGLC) send the feedback to the list. >=20 > The current understanding of the category is Proposed=20 > Standard, but there has been some debate of this as well. >=20 > You are also encouraged to review: > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-huitema-v6ops > -teredo.txt > to see if this is a problem for you. >=20 > Thanks! >=20 > (co-chair hat off) >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Jun 21 14:03:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12666 for ; Mon, 21 Jun 2004 14:03:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcT7s-0009ys-CG for v6ops-data@psg.com; Mon, 21 Jun 2004 18:02:36 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcMwg-000H4Z-Jc; Mon, 21 Jun 2004 11:26:38 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2004 04:29:02 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5LBPvgI000870; Mon, 21 Jun 2004 04:25:57 -0700 (PDT) Received: from [10.61.124.162] (ams-clip-equant-dhcp-161.cisco.com [10.61.124.162]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA06709; Mon, 21 Jun 2004 04:25:53 -0700 (PDT) Message-ID: <40D6C5BF.8090004@cisco.com> Date: Mon, 21 Jun 2004 13:25:51 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 , v6ops@ops.ietf.org Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <40D692F9.3000603@cisco.com> <4E3DBBB8-C36D-11D8-96AB-000A95CD987A@muada.com> In-Reply-To: <4E3DBBB8-C36D-11D8-96AB-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Okay, the confusion in this exchange stems from which "ingress" we were talking about. Iljitsch van Beijnum wrote: > My point is that if you have two prefixes from two ISPs (which I think > is the most common situation in renumbering, and it's certainly common > enough to be worthy of discussion in a renumbering draft) and both ISPs > do ingress filtering (which is also something that can't be discounted) > then "turning on" both prefixes at the same time without additional > measures is going to lead to problems as packets routed to ISP A may > have a source address from the prefix from ISP B (or vice versa) and > thus be dropped due to ingress filtering. Right, I agree. >> We make note of the fact that there is a linkage between the upstream >> ISP and the network. What perhaps we should state is that upstreams >> may need to know about each other from anti-spoofing mechanism. > > > But what if the ISPs aren't prepared to cooperate? Not everyone is a > fortune 1000 company. Okay, I follow you. The draft attempts to cover ground in two areas: 1. That which can be done today; 2. What needs to be fixed. I believe you're arguing for a fix, and perhaps some text in the draft would be good. > >> One of us has missed the point. Firewalls today filter packets based >> on destination address. While I would agree that filtering on a >> source FROM the Internet would be foolish, different hosts on the >> perimeter may require different levels of protection. Regardless, >> those rules exist today inside firewalls and would need to be changed, >> and that's what we're saying. > > > Yes, but this has very little to do with ingress filtering by ISPs, so > the current text obscures the issue rather than illuminate it. Two different points. > >>> It's just that tracking the attacks down takes longer. The real issue >>> is that you MUST deliver packets to the ISP that matches the source >>> address or you have no connecitivity. > > >> This configuration either exists prior to the renumbering events or it >> doesn't. If it does it would need to be modified to match the new >> addresses. > > > Nonsense. The existence of two prefixes at the same time is exclusively > related to renumbering in non-multihomed networks, so it has no relation > to the state of the network either before or after renumbering. Except of course for currently multihomed sites. > Actually it is much less complex unless people extensively use manually > configured addresses. The problem with IPv4 is deciding on subnet sizes, > merging subnets, avoiding overlap and so on. None of this is an issue > with IPv6 since everything fits in a standard issue /64. We have saved network managers from requiring a set of spreadsheet operations. BFD. The level of complexity is substantially the same. > > Obviously there is lots of other stuff that remains the same but what > else is new. > >> Want to make it easier? Great. I'm all ears. > > > There are some pages in my book about renumbering (in IPv4). Feel free > to borrow from that (not the literal text, of course). IPv6 was billed as a great self-configuring does-everything-but-eat follow-on to IPv4. Very little of that is true today. We'd like to identify the mechanisms that would improve matters, at least for IPv6. Who knows? Maybe for IPv4 as well. For instance, what you're looking for above is some way for providers to learn about customers' alternative published connectivity, such as a more robust and accurate RADB in order to configure ingress access-lists. One needs to understand who's authoritative for the information, and what the keys are. Certainly the keys are unlikely to be IP address prefixes :-( As to whether the providers are willing to implement such a mechanism, I can't say. They will look for an easier way, and that easier way today is a NAT that does source selection (policy routing). Eliot From owner-v6ops@ops.ietf.org Mon Jun 21 14:39:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15481 for ; Mon, 21 Jun 2004 14:39:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcTg6-000E8v-VV for v6ops-data@psg.com; Mon, 21 Jun 2004 18:37:58 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcTg5-000E8Q-Cx for v6ops@ops.ietf.org; Mon, 21 Jun 2004 18:37:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5LIboS31770; Mon, 21 Jun 2004 21:37:50 +0300 Date: Mon, 21 Jun 2004 21:37:50 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org, Subject: approach to moving forward w/ mechanisms [RE: Review requested: draft-huitema-v6ops-teredo-02.txt] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CC805@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 21 Jun 2004, Bound, Jim wrote: > If we accept this we need to move on all mechanisms not just Teredo. I > support moving forward on all of them. PS is still unclear to me and I > thought we were going to suggest Experimental RFC? ("If we accept this" -- accept what? There has already been consensus for Teredo, so I'm not sure what acceptance you're referring to.) This is really a more generic topic, so changing the subject. The intent all along has been to move on (or work on) the mechanisms with clearly required mainstream scenarios, based on the analysis, etc. -- you know the drill. In other words, there has always been resistance to just moving forward with everything that has been proposed or might be proposed. Now, at IETF59 there was consensus for policy that the authors of those proposed mechanisms, even if there was no consensus or clear need for them, *could* publish them as Experimental or Informational through RFC editor if they so wished (including a very strong note that it is not an IETF activity, etc.). This only applied to the *implemented* protocols, as far as they have been implemented. I.e., a way to document an implemented protocol for interoperability. The question how to move forward with the required mechanisms, for which there has been consensus, (currently, this list includes Teredo and so-called BGP-tunnel), is separate from that. That work could be done as invididual submissions through ADs, through a new WG-to-be-formed, or through v6ops. The category could be PS or maybe experimental. These issues have not become clear yet, unfortunately. -- 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 Jun 21 14:59: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 OAA16943 for ; Mon, 21 Jun 2004 14:59:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcU0E-000Gcn-NJ for v6ops-data@psg.com; Mon, 21 Jun 2004 18:58:46 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcU0B-000GcB-2m for v6ops@ops.ietf.org; Mon, 21 Jun 2004 18:58:43 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8419C62FF; Mon, 21 Jun 2004 14:58:42 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 14:58:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: approach to moving forward w/ mechanisms [RE: Review requested: draft-huitema-v6ops-teredo-02.txt] Date: Mon, 21 Jun 2004 14:58:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC816@tayexc13.americas.cpqcorp.net> Thread-Topic: approach to moving forward w/ mechanisms [RE: Review requested: draft-huitema-v6ops-teredo-02.txt] Thread-Index: AcRXvuBewk6sOF7QQ+yL/a3GeO8DRQAAoIgg From: "Bound, Jim" To: "Pekka Savola" Cc: , X-OriginalArrivalTime: 21 Jun 2004 18:58:42.0720 (UTC) FILETIME=[C582BA00:01C457C1] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable True. My issue is did we agree on Proposed Standard? =20 On the other topic then lets move forward with ISATAP and DSTM. Both should be on the IETF 59 agenda too. I will commit to presenting where we are with DSTM and updated draft is coming now. DSTM authors were under the impression our only option was Experimental. If Teredo can go to PS DSTm may want to ask the WG the same question. It appears the drill has changed. Thanks /jim=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Monday, June 21, 2004 2:38 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org; huitema@microsoft.com > Subject: approach to moving forward w/ mechanisms [RE: Review=20 > requested: draft-huitema-v6ops-teredo-02.txt] >=20 > On Mon, 21 Jun 2004, Bound, Jim wrote: > > If we accept this we need to move on all mechanisms not=20 > just Teredo. =20 > > I support moving forward on all of them. PS is still unclear to me=20 > > and I thought we were going to suggest Experimental RFC? >=20 > ("If we accept this" -- accept what? There has already been=20 > consensus for Teredo, so I'm not sure what acceptance you're=20 > referring to.) >=20 > This is really a more generic topic, so changing the subject. >=20 > The intent all along has been to move on (or work on) the=20 > mechanisms with clearly required mainstream scenarios, based=20 > on the analysis, etc. -- you know the drill. In other words,=20 > there has always been resistance to just moving forward with=20 > everything that has been proposed or might be proposed. >=20 > Now, at IETF59 there was consensus for policy that the=20 > authors of those proposed mechanisms, even if there was no=20 > consensus or clear need for them, *could* publish them as=20 > Experimental or Informational through RFC editor if they so=20 > wished (including a very strong note that it is not an IETF=20 > activity, etc.). This only applied to the > *implemented* protocols, as far as they have been=20 > implemented. I.e., a way to document an implemented protocol=20 > for interoperability. >=20 > The question how to move forward with the required=20 > mechanisms, for which there has been consensus, (currently,=20 > this list includes Teredo and so-called BGP-tunnel), is=20 > separate from that. That work could be done as invididual=20 > submissions through ADs, through a new WG-to-be-formed, or=20 > through v6ops. The category could be PS or maybe=20 > experimental. These issues have not become clear yet, unfortunately. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Jun 21 15:01: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 PAA17124 for ; Mon, 21 Jun 2004 15:01:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcU2S-000Gyq-LY for v6ops-data@psg.com; Mon, 21 Jun 2004 19:01:04 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcU2J-000GvW-JN for v6ops@ops.ietf.org; Mon, 21 Jun 2004 19:00:55 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2901050 for ; Mon, 21 Jun 2004 15:00:55 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 15:00:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C457C2.13CEB328" Subject: DSTM Date: Mon, 21 Jun 2004 15:00:53 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC818@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRXwhO1vR80xYLISAqYf+zIrZhGRQ== From: "Bound, Jim" To: X-OriginalArrivalTime: 21 Jun 2004 19:00:54.0706 (UTC) FILETIME=[142E3120:01C457C2] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C457C2.13CEB328 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does the working group want to accept DSTM as working item? Can you send us mail so we can determine if we should invest time here. It is being deployed and has been implemented on multiple platforms. DSTM effort needs to make a decision how we support our clients that will use it for a mechanism. =20 =20 thanks /jim ------_=_NextPart_001_01C457C2.13CEB328 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Does = the working=20 group want to accept DSTM as working item?  Can you send us mail so = we can=20 determine if we should invest time here.  It is being deployed and = has been=20 implemented on multiple platforms.   DSTM effort needs to make = a=20 decision how we support our clients that will use it for a=20 mechanism.  
 
thanks
/jim
------_=_NextPart_001_01C457C2.13CEB328-- From owner-v6ops@ops.ietf.org Mon Jun 21 18:23:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09817 for ; Mon, 21 Jun 2004 18:22:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcX95-000EPc-Cm for v6ops-data@psg.com; Mon, 21 Jun 2004 22:20:07 +0000 Received: from [4.14.89.246] (helo=tndh.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcX92-000EP3-6y for v6ops@ops.ietf.org; Mon, 21 Jun 2004 22:20:04 +0000 Received: from eaglet (127.0.0.1:4696) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 21 Jun 2004 15:16:21 -0700 From: "Tony Hain" To: "'Bound, Jim'" , "'Pekka Savola'" Cc: , , Subject: RE: approach to moving forward w/ mechanisms [RE: Review requested: draft-huitema-v6ops-teredo-02.txt] Date: Mon, 21 Jun 2004 15:19:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRXvuBewk6sOF7QQ+yL/a3GeO8DRQAAoIggAAXJewA= In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CC816@tayexc13.americas.cpqcorp.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Unfortunately the drill appears to be fluid based on the mood of a few people. According to the IETF chair when he was Ops AD, technologies that will see widespread deployment and need to be interoperable should be on the standards track. The recent discussion about Experimental is an effort at a political side step for the IESG. This appears to take them out of the line of fire rather than accepting the reality that the IESG can't decide what people will be allowed to deploy. No matter how much they want to dictate to the market, there will be technologies shipped and deployed without their blessing. The longer they take to allow any progress, the more likely it is that the technology developers will declare the IETF irrelevant and just start shipping code leaving the consumer to decide. Without interoperability as a basis, the technology selection will become a battle of marketing departments. We have a set of transition technologies that address the needs of various existing deployed environments. There are minor overlaps, but the core of each approach is not discussed in competing proposals. Refusing to publish them all is an attempt to dictate which environments are acceptable and which are not. Clearly that was not done for IPv4, or the environments undesirable to some would not exist. Since they do, someone saw a clear need for it and our job is to migrate the protocol version in that environment. Forcing network managers to change deployment models is explicitly out of scope. Two years ago we stopped work so we could explain the complexity of real networks to the IESG, and now with those documents in hand we still can't move ... The bottom line is that we need automated, brokered, and manually configured tunnels that work with and without IPv4 nat in the path. We also need stateful & stateless translators at various points in the stack, mechanisms for handling IPv4 in IPv6-only networks, as well as the basic transition mechanism of parallel IPv6 & IPv4 packet streams. All of these approaches MUST be on the standards track, or there is no point in bothering with the IETF since that energy should be focused on marketing sooner rather than later. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Bound, Jim > Sent: Monday, June 21, 2004 11:58 AM > To: Pekka Savola > Cc: v6ops@ops.ietf.org; huitema@microsoft.com > Subject: RE: approach to moving forward w/ mechanisms [RE: Review > requested: draft-huitema-v6ops-teredo-02.txt] > > True. My issue is did we agree on Proposed Standard? > > On the other topic then lets move forward with ISATAP and DSTM. Both > should be on the IETF 59 agenda too. I will commit to presenting where > we are with DSTM and updated draft is coming now. DSTM authors were > under the impression our only option was Experimental. If Teredo can go > to PS DSTm may want to ask the WG the same question. It appears the > drill has changed. > > Thanks > /jim > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Monday, June 21, 2004 2:38 PM > > To: Bound, Jim > > Cc: v6ops@ops.ietf.org; huitema@microsoft.com > > Subject: approach to moving forward w/ mechanisms [RE: Review > > requested: draft-huitema-v6ops-teredo-02.txt] > > > > On Mon, 21 Jun 2004, Bound, Jim wrote: > > > If we accept this we need to move on all mechanisms not > > just Teredo. > > > I support moving forward on all of them. PS is still unclear to me > > > and I thought we were going to suggest Experimental RFC? > > > > ("If we accept this" -- accept what? There has already been > > consensus for Teredo, so I'm not sure what acceptance you're > > referring to.) > > > > This is really a more generic topic, so changing the subject. > > > > The intent all along has been to move on (or work on) the > > mechanisms with clearly required mainstream scenarios, based > > on the analysis, etc. -- you know the drill. In other words, > > there has always been resistance to just moving forward with > > everything that has been proposed or might be proposed. > > > > Now, at IETF59 there was consensus for policy that the > > authors of those proposed mechanisms, even if there was no > > consensus or clear need for them, *could* publish them as > > Experimental or Informational through RFC editor if they so > > wished (including a very strong note that it is not an IETF > > activity, etc.). This only applied to the > > *implemented* protocols, as far as they have been > > implemented. I.e., a way to document an implemented protocol > > for interoperability. > > > > The question how to move forward with the required > > mechanisms, for which there has been consensus, (currently, > > this list includes Teredo and so-called BGP-tunnel), is > > separate from that. That work could be done as invididual > > submissions through ADs, through a new WG-to-be-formed, or > > through v6ops. The category could be PS or maybe > > experimental. These issues have not become clear yet, unfortunately. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > From owner-v6ops@ops.ietf.org Tue Jun 22 00:33:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03786 for ; Tue, 22 Jun 2004 00:33:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bccws-0006Lt-Ld for v6ops-data@psg.com; Tue, 22 Jun 2004 04:31:54 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bccwq-0006LZ-TW for v6ops@ops.ietf.org; Tue, 22 Jun 2004 04:31:53 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 6133161F1; Tue, 22 Jun 2004 00:31:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 Jun 2004 00:31:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: approach to moving forward w/ mechanisms [RE: Review requested: draft-huitema-v6ops-teredo-02.txt] Date: Tue, 22 Jun 2004 00:31:49 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC85D@tayexc13.americas.cpqcorp.net> Thread-Topic: approach to moving forward w/ mechanisms [RE: Review requested: draft-huitema-v6ops-teredo-02.txt] Thread-Index: AcRXvuBewk6sOF7QQ+yL/a3GeO8DRQAAoIggAAXJewAADiex0A== From: "Bound, Jim" To: "Tony Hain" , "Pekka Savola" Cc: , , X-OriginalArrivalTime: 22 Jun 2004 04:31:52.0117 (UTC) FILETIME=[D7304650:01C45811] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Very well stated Tony. Everyone of those we have will be deployed and used. We probably still do not have all the mechanisms we need or can possibly know as deployment evolves. And some we believe in strongly within the WG will not be used in all cases either. There is no one size fits all and there never will be.=20 /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tony Hain > Sent: Monday, June 21, 2004 6:20 PM > To: Bound, Jim; 'Pekka Savola' > Cc: v6ops@ops.ietf.org; huitema@microsoft.com; iesg@ietf.org > Subject: RE: approach to moving forward w/ mechanisms [RE:=20 > Review requested: draft-huitema-v6ops-teredo-02.txt] >=20 > Unfortunately the drill appears to be fluid based on the mood=20 > of a few people. According to the IETF chair when he was Ops=20 > AD, technologies that will see widespread deployment and need=20 > to be interoperable should be on the standards track. The=20 > recent discussion about Experimental is an effort at a=20 > political side step for the IESG. This appears to take them=20 > out of the line of fire rather than accepting the reality=20 > that the IESG can't decide what people will be allowed to=20 > deploy. No matter how much they want to dictate to the=20 > market, there will be technologies shipped and deployed=20 > without their blessing. The longer they take to allow any=20 > progress, the more likely it is that the technology=20 > developers will declare the IETF irrelevant and just start=20 > shipping code leaving the consumer to decide. Without=20 > interoperability as a basis, the technology selection will=20 > become a battle of marketing departments.=20 >=20 > We have a set of transition technologies that address the=20 > needs of various existing deployed environments. There are=20 > minor overlaps, but the core of each approach is not=20 > discussed in competing proposals. Refusing to publish them=20 > all is an attempt to dictate which environments are=20 > acceptable and which are not. Clearly that was not done for=20 > IPv4, or the environments undesirable to some would not=20 > exist. Since they do, someone saw a clear need for it and our=20 > job is to migrate the protocol version in that environment. > Forcing network managers to change deployment models is=20 > explicitly out of scope. Two years ago we stopped work so we=20 > could explain the complexity of real networks to the IESG,=20 > and now with those documents in hand we still can't move ... >=20 > The bottom line is that we need automated, brokered, and=20 > manually configured tunnels that work with and without IPv4=20 > nat in the path. We also need stateful & stateless=20 > translators at various points in the stack, mechanisms for=20 > handling IPv4 in IPv6-only networks, as well as the basic=20 > transition mechanism of parallel IPv6 & IPv4 packet streams.=20 > All of these approaches MUST be on the standards track, or=20 > there is no point in bothering with the IETF since that=20 > energy should be focused on marketing sooner rather than later. >=20 > Tony >=20 >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > > Behalf Of Bound, Jim > > Sent: Monday, June 21, 2004 11:58 AM > > To: Pekka Savola > > Cc: v6ops@ops.ietf.org; huitema@microsoft.com > > Subject: RE: approach to moving forward w/ mechanisms [RE: Review > > requested: draft-huitema-v6ops-teredo-02.txt] > >=20 > > True. My issue is did we agree on Proposed Standard? > >=20 > > On the other topic then lets move forward with ISATAP and=20 > DSTM. Both > > should be on the IETF 59 agenda too. I will commit to presenting=20 > > where we are with DSTM and updated draft is coming now. =20 > DSTM authors=20 > > were under the impression our only option was Experimental.=20 > If Teredo=20 > > can go to PS DSTm may want to ask the WG the same question. It=20 > > appears the drill has changed. > >=20 > > Thanks > > /jim > >=20 > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Monday, June 21, 2004 2:38 PM > > > To: Bound, Jim > > > Cc: v6ops@ops.ietf.org; huitema@microsoft.com > > > Subject: approach to moving forward w/ mechanisms [RE: Review > > > requested: draft-huitema-v6ops-teredo-02.txt] > > > > > > On Mon, 21 Jun 2004, Bound, Jim wrote: > > > > If we accept this we need to move on all mechanisms not > > > just Teredo. > > > > I support moving forward on all of them. PS is still=20 > unclear to=20 > > > > me and I thought we were going to suggest Experimental RFC? > > > > > > ("If we accept this" -- accept what? There has already been=20 > > > consensus for Teredo, so I'm not sure what acceptance you're=20 > > > referring to.) > > > > > > This is really a more generic topic, so changing the subject. > > > > > > The intent all along has been to move on (or work on) the=20 > mechanisms=20 > > > with clearly required mainstream scenarios, based on the=20 > analysis,=20 > > > etc. -- you know the drill. In other words, there has always been=20 > > > resistance to just moving forward with everything that has been=20 > > > proposed or might be proposed. > > > > > > Now, at IETF59 there was consensus for policy that the authors of=20 > > > those proposed mechanisms, even if there was no consensus=20 > or clear=20 > > > need for them, *could* publish them as Experimental or=20 > Informational=20 > > > through RFC editor if they so wished (including a very=20 > strong note=20 > > > that it is not an IETF activity, etc.). This only applied to the > > > *implemented* protocols, as far as they have been=20 > implemented. I.e.,=20 > > > a way to document an implemented protocol for interoperability. > > > > > > The question how to move forward with the required=20 > mechanisms, for=20 > > > which there has been consensus, (currently, this list includes=20 > > > Teredo and so-called BGP-tunnel), is separate from that. =20 > That work=20 > > > could be done as invididual submissions through ADs,=20 > through a new=20 > > > WG-to-be-formed, or through v6ops. The category could be PS or=20 > > > maybe experimental. These issues have not become clear yet,=20 > > > unfortunately. > > > > > > -- > > > Pekka Savola "You each name yourselves=20 > king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A=20 > Clash of Kings > > > > > > > > > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jun 22 08:01: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 IAA02803 for ; Tue, 22 Jun 2004 08:01:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcjwm-0007BJ-9N for v6ops-data@psg.com; Tue, 22 Jun 2004 12:00:16 +0000 Received: from [32.97.182.102] (helo=e2.ny.us.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcjwl-0007B2-0d for v6ops@ops.ietf.org; Tue, 22 Jun 2004 12:00:15 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5MC0C7R481724; Tue, 22 Jun 2004 08:00:12 -0400 Received: from cichlid.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5MC1JMT052334; Tue, 22 Jun 2004 08:01:20 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.12.10/8.12.5) with ESMTP id i5MBxq9o022180; Tue, 22 Jun 2004 07:59:52 -0400 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.12.10/8.12.10/Submit) with ESMTP id i5MBxpw3022175; Tue, 22 Jun 2004 07:59:51 -0400 Message-Id: <200406221159.i5MBxpw3022175@cichlid.raleigh.ibm.com> To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: Re: DSTM In-Reply-To: Message from jim.bound@hp.com of "Mon, 21 Jun 2004 15:00:53 EDT." <9C422444DE99BC46B3AD3C6EAFC9711B067CC818@tayexc13.americas.cpqcorp.net> Date: Tue, 22 Jun 2004 07:59:51 -0400 From: Thomas Narten X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim. Which of the scernarios that the WG has developed call for DSTM (or something like DSTM)? Thomas From owner-v6ops@ops.ietf.org Tue Jun 22 11:05: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 LAA14792 for ; Tue, 22 Jun 2004 11:05:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcmon-0006HK-Nl for v6ops-data@psg.com; Tue, 22 Jun 2004 15:04:13 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcmok-0006GA-9G for v6ops@ops.ietf.org; Tue, 22 Jun 2004 15:04:10 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CAC394F49; Tue, 22 Jun 2004 11:04:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 Jun 2004 11:04:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DSTM Date: Tue, 22 Jun 2004 11:04:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC88A@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRYUHzBNpBxL/OAQ+SKTdl9Gyox4wAF13GA From: "Bound, Jim" To: "Thomas Narten" Cc: X-OriginalArrivalTime: 22 Jun 2004 15:04:09.0516 (UTC) FILETIME=[2BA3F6C0:01C4586A] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Thomas, In ISP and Enterprise scenarios where client/user has determined that IPv6 will be dominant routing deployed backbone and node protocol and reducing use of IPv4 applications except where it must be supported as legacy (e.g. port has not happened, or port planned later of app). In addition the user/client does not want to use any protocol transition that requires architecturally defined prefix within the IPv6 network (e.g. 6to4, Teredo). Users will get IPv4 address for temporary use only on DSTM hybrid-stack machines and Tunnel End Points to get to router at the edge. DSTM tech leaders do not believe this is useful for unmanaged networks at this time. DSTM clients can use tunnel-broker client interface or DHCPv6. This is spelled out we feel in our draft but will have additional statements in the draft applicable to the scenarios in draft which will be sent in a few weeks. Also see: http://www.dstm.info/ Folks can download on Linux or XP and test it. We have PHD research engineer doing scalability testing now and should have reports completed by end of the summer maybe some preliminary data for San Diego too from two large IPv6 operational pilot networks. It also will work with Tunnel Broker product on the market today for IPv6 and is being deployed in Enterprise pre-production network currently. All these mechanisms require robust testing and for security to operationally verify implementation. The current specs for 6to4, ISATAP, DSTM, Tunnel Broker, NAT-PT, are being verified now with implementations. Be good to get RFCs in some form for guidance besides just 6to4 which will not be used we have learned by all enterprises. Also Silkroad is now on the radar screen of implementors too with no IPR requirements at this point in time. Some are looking at BIA and Socks too but not as widely. 6over4 appears to be dead because IPv4 multicast was not widely deployed in the first place. Regards, /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com]=20 > Sent: Tuesday, June 22, 2004 8:00 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: DSTM=20 >=20 > Hi Jim. >=20 > Which of the scernarios that the WG has developed call for=20 > DSTM (or something like DSTM)? >=20 > Thomas >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jun 23 01:49: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 BAA04123 for ; Wed, 23 Jun 2004 01:49:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd0aV-0007ix-R3 for v6ops-data@psg.com; Wed, 23 Jun 2004 05:46:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd0aU-0007ic-2n for v6ops@ops.ietf.org; Wed, 23 Jun 2004 05:46:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5N5kIE11804; Wed, 23 Jun 2004 08:46:18 +0300 Date: Wed, 23 Jun 2004 08:46:18 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt (fwd) In-Reply-To: <40D1B44F.5040206@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Fred Templin wrote: > It seems that section 3.4 of the current mech-v2 draft includes a built-in > assumption that ICMPv4 error translation to ICMPv6 is only possible > when the ICMPv4 error messages *themselves* include more than the > minimum 8 bytes of data beyond the IPv4 header of the packet in error. > > But, if the encapsulator maintains a small queue of recently-sent packets > (indexed, e.g., by the 'ip_id' field of the encapsulating IPv4 headers) > then enough state would be available for ICMPv6 error generation > in most cases even if the ICMPv4 error messages themselves only > return the minimum amount. The current spec AFAIK doesn't have anything which would prohibit from doing so, so this seems like spelling out a possible different approach to solve the same problem (an editorial fix). On the other hand, by introducing a new feature, we would also create a requirement that there must be two interoperable implementations of this feature when going for DS, and that would seem undesirable. Do you know of such implementations? If not, I'm thinking that all the suggestions except item 2) are generalizing enough not to cause any trouble, so I could adopt them. > I suggest the following changes: > > 1) Section 3.4, 4th paragraph. change to: > > "The handling of other types of ICMPv4 error messages depends > on how much information is available from the encapsulated packet > that caused the error." > > 2) Section 3.4, 6th paragraph, change: > > "If the offending packet includes enough data, the encapsulator MAY" > > to: > > "If the offending packet includes enough data, or if enough data is > available in the encapulator's cache, the encapsulator MAY" > > 3) Section 3.4, 7th paragraph, change: > > "Also, if sufficient headers are included in the error" > > to: > > "Also, if sufficient headers are available" > > 4) Section 3.4, 8th paragraph, change: > > "Note that when IPv4 path MTU is exceeded, and ICMPv4 errors of only 8 > bytes of payload are generated," > > to: > > "Note that when the IPv4 path MTU is exceeded, and sufficient bytes > of payload associated with the ICMPv4 errors are not available," > > >(co-chair hat off) > > > >Btw. if interested in PMTUD/packet size issues, you might also find > >draft-savola-mtufrag-network-tunneling-00.txt interesting. It's a > >more generic document describing PMTUD, fragmentation/reassembly, etc. > >issues in tunneling in the network. > > > > You appear to be bird-dogging me, Pekka; I have authored a > well-publicized series of closely-related documents. See: > > http://www.geocities.com/osprey67/tunnelmtu-02.txt > http://www.geocities.com/osprey67/tunnelmtu-03.txt > http://www.geocities.com/osprey67/tunnelmtu-04.txt > http://www.geocities.com/osprey67/tunnelmtu-05.txt > http://www.geocities.com/osprey67/tunnelmtu-06.txt > http://www.geocities.com/osprey67/isatap/iemmei-00.txt > http://www.ietf.org/internet-drafts/draft-templin-v6ops-iemmei-01.txt I think the difference here is that I was more interested in only documenting the operational problems, you went a step ahead (or took a different step) and started figuring out the modified mechanisms. I'm not so interested on that work, just getting the problems on the table. -- 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 Jun 23 07:38:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20382 for ; Wed, 23 Jun 2004 07:38:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd63Q-0000H5-AG for v6ops-data@psg.com; Wed, 23 Jun 2004 11:36:36 +0000 Received: from [32.97.110.129] (helo=e31.co.us.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd63P-0000Go-B0 for v6ops@ops.ietf.org; Wed, 23 Jun 2004 11:36:35 +0000 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5NBaWtf418414; Wed, 23 Jun 2004 07:36:32 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NBaW56171472; Wed, 23 Jun 2004 05:36:32 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i5NBaYI4027814; Wed, 23 Jun 2004 07:36:34 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i5NBaYix027810; Wed, 23 Jun 2004 07:36:34 -0400 Message-Id: <200406231136.i5NBaYix027810@rotala.raleigh.ibm.com> To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: Re: DSTM In-Reply-To: Message from jim.bound@hp.com of "Tue, 22 Jun 2004 11:04:08 EDT." <9C422444DE99BC46B3AD3C6EAFC9711B067CC88A@tayexc13.americas.cpqcorp.net> Date: Wed, 23 Jun 2004 07:36:34 -0400 From: Thomas Narten X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > In ISP and Enterprise scenarios where client/user has determined that > IPv6 will be dominant routing deployed backbone and node protocol and > reducing use of IPv4 applications except where it must be supported as > legacy (e.g. port has not happened, or port planned later of app). This seems to me to be something that won't be compelling scenario for quite some time. In other words, not something we need to focus on in the short term. Let me repeat the question I asked previously: Which of the scernarios that the WG has developed call for DSTM (or something like DSTM)? One of the purposes of the scenario analysis was to understand which transition mechanisms were really important so that we could focus on them. Also, understanding which are the core pieces would help us label the RFCs more appropriately (e.g., Standards track vs. experimental). > In addition the user/client does not want to use any protocol > transition that requires architecturally defined prefix within the > IPv6 network (e.g. 6to4, Teredo). I don't understand this. What is the _technical_ requirement here?_ Thomas From owner-v6ops@ops.ietf.org Wed Jun 23 09:00:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28581 for ; Wed, 23 Jun 2004 09:00:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd7Kd-0009hG-9V for v6ops-data@psg.com; Wed, 23 Jun 2004 12:58:27 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd7Kb-0009gr-Vd for v6ops@ops.ietf.org; Wed, 23 Jun 2004 12:58:26 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 909654F7A; Wed, 23 Jun 2004 08:58:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 08:58:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DSTM Date: Wed, 23 Jun 2004 08:57:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC8FC@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRZFlm+jrs1/AMeT3y0E2Bnu+67OwACjCJw From: "Bound, Jim" To: "Thomas Narten" Cc: X-OriginalArrivalTime: 23 Jun 2004 12:58:22.0946 (UTC) FILETIME=[C3F28420:01C45921] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > This seems to me to be something that won't be compelling=20 > scenario for quite some time. In other words, not something=20 > we need to focus on in the short term. It is now and in the short term. I can go offline with you and get into details if you like as sharing who and where is not acceptable here for any deployment scenario uman, ISP, or enterprise. But, as IESG member I could take you into confidence if that is possible but I have seen no one disclose anything other than general deployment scenarios and DSTM should not have to either. I think whether we work on it is up to the working group not you, or I, or the chairs. >=20 > Let me repeat the question I asked previously: >=20 > Which of the scernarios that the WG has developed call for DSTM (or > something like DSTM)? >=20 > One of the purposes of the scenario analysis was to=20 > understand which transition mechanisms were really important=20 > so that we could focus on them. Also, understanding which are=20 > the core pieces would help us label the RFCs more=20 > appropriately (e.g., Standards track vs. experimental). I responded to that see the Enterprise Scenarios draft. >=20 > > In addition the user/client does not want to use any protocol=20 > > transition that requires architecturally defined prefix within the > > IPv6 network (e.g. 6to4, Teredo). >=20 > I don't understand this. What is the _technical_ requirement here?_ Some enterprises will not want 2002:: or any hard coded prefix in their sites network addresses only IPv6 aggregatable address prefixes assigned to the site. Transition will use IPv6 or IPv4 addresses not Transition prefixes and DSTM supports that operational model. Regards, /jim >=20 > Thomas >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jun 23 09:06: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 JAA29017 for ; Wed, 23 Jun 2004 09:06:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd7SW-000Bd8-MT for v6ops-data@psg.com; Wed, 23 Jun 2004 13:06:36 +0000 Received: from [210.155.141.200] (helo=mango.itojun.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd7SV-000Bct-NJ for v6ops@ops.ietf.org; Wed, 23 Jun 2004 13:06:35 +0000 Received: by mango.itojun.org (Postfix, from userid 1001) id 29D8E10D38E; Wed, 23 Jun 2004 22:06:35 +0900 (JST) To: jim.bound@hp.com Cc: v6ops@ops.ietf.org Subject: RE: DSTM In-Reply-To: Your message of "Wed, 23 Jun 2004 08:57:58 -0400" <9C422444DE99BC46B3AD3C6EAFC9711B067CC8FC@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC8FC@tayexc13.americas.cpqcorp.net> X-Mailer: Cue version 0.8 (040620-0417/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040623130635.29D8E10D38E@mango.itojun.org> Date: Wed, 23 Jun 2004 22:06:35 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > In addition the user/client does not want to use any protocol > > > transition that requires architecturally defined prefix within the > > > IPv6 network (e.g. 6to4, Teredo). > > > > I don't understand this. What is the _technical_ requirement here?_ > > Some enterprises will not want 2002:: or any hard coded prefix in their > sites network addresses only IPv6 aggregatable address prefixes assigned > to the site. Transition will use IPv6 or IPv4 addresses not Transition > prefixes and DSTM supports that operational model. transition technology other than DSTM can support the operational model. so my question is, why DSTM is given special treatment here? itojun From owner-v6ops@ops.ietf.org Wed Jun 23 09:31: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 JAA00592 for ; Wed, 23 Jun 2004 09:31:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd7ph-000GWo-CR for v6ops-data@psg.com; Wed, 23 Jun 2004 13:30:33 +0000 Received: from [210.155.141.200] (helo=mango.itojun.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd7pg-000GWM-CC for v6ops@ops.ietf.org; Wed, 23 Jun 2004 13:30:32 +0000 Received: by mango.itojun.org (Postfix, from userid 1001) id DBCCC10D38B; Wed, 23 Jun 2004 22:30:31 +0900 (JST) To: jim.bound@hp.com Cc: v6ops@ops.ietf.org Subject: RE: DSTM In-Reply-To: Your message of "Wed, 23 Jun 2004 09:27:37 -0400" <9C422444DE99BC46B3AD3C6EAFC9711B067CC903@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC903@tayexc13.americas.cpqcorp.net> X-Mailer: Cue version 0.8 (040620-0417/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040623133031.DBCCC10D38B@mango.itojun.org> Date: Wed, 23 Jun 2004 22:30:31 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > Some enterprises will not want 2002:: or any hard coded prefix in > > > their sites network addresses only IPv6 aggregatable > > address prefixes > > > assigned to the site. Transition will use IPv6 or IPv4 > > addresses not > > > Transition prefixes and DSTM supports that operational model. > > > > transition technology other than DSTM can support the operational > > model. so my question is, why DSTM is given special treatment here? > > DSTM is not asking for special treatment here and I don't understand why > you say that can you please provide more context why you use the phrase > "special treatment"? Thanks. i was under impression that you're asking DSTM to be published without wait finishing scenario/analysis document, or if DSTM being mentioned in the documents. is my impression incorrrect? itojun From owner-v6ops@ops.ietf.org Wed Jun 23 09:35:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00646 for ; Wed, 23 Jun 2004 09:35:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd7uA-000HQK-NE for v6ops-data@psg.com; Wed, 23 Jun 2004 13:35:10 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd7u9-000HPj-IX for v6ops@ops.ietf.org; Wed, 23 Jun 2004 13:35:09 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 32DA0C036; Wed, 23 Jun 2004 09:27:40 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 09:27:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DSTM Date: Wed, 23 Jun 2004 09:27:37 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC903@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRZIu4jcQChS/5gRV6iKhqgpWrNFAAAJM5g From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 23 Jun 2004 13:27:40.0074 (UTC) FILETIME=[DB46F8A0:01C45925] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > > Some enterprises will not want 2002:: or any hard coded prefix in=20 > > their sites network addresses only IPv6 aggregatable=20 > address prefixes=20 > > assigned to the site. Transition will use IPv6 or IPv4=20 > addresses not=20 > > Transition prefixes and DSTM supports that operational model. >=20 > transition technology other than DSTM can support the=20 > operational > model. so my question is, why DSTM is given special=20 > treatment here? DSTM is not asking for special treatment here and I don't understand why you say that can you please provide more context why you use the phrase "special treatment"? Thanks. Imagine an IPv6 production network made up of multiple links. Only some of the links contain legacy IPv4 applications and for this conversation lets say they are servers. The users policy is that IPv6 traffic is only permitted on the majority of links and on all mission critical links. DSTM permits providing temporary addresses to nodes that are required to communicate with legacy IPv4 nodes and networks by tunneling the packet to a router that can then decap and forward IPv4 packets and also receive them and encap them in IPv6 back to the orginating node. Operational requirements by the user: 1. IPv4 is not permitted to be routed on most IPv6 links or sites thus tunneling IPv4 in IPv6 is the only option. 2. Any address IPv6 or IPv4 must be within those assigned to the site by operations, and all IPv6 addresses must be of the aggregate assigned by IPv6 for any node. This eliminates 6to4 and Teredo as two examples.=20 3. The use of IPv4 addresses for legacy communications should be temporary IPv4 addresses for a specific time. The objective is to use IPv6 as the dominant protocol and treat IPv4 as legacy completely. What other mechanism do this? This is the strategy now by several large entities doing pre-production network pilots and DSTM has been called out as required. The technical and business reasons for this operational model are not topics of the IETF. It is simply a requirement today as others for IPv6 deployment. Regards, /jim From owner-v6ops@ops.ietf.org Wed Jun 23 10:22:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02405 for ; Wed, 23 Jun 2004 10:22:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd8cb-000OVJ-1U for v6ops-data@psg.com; Wed, 23 Jun 2004 14:21:05 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd8cZ-000OV3-PC for v6ops@ops.ietf.org; Wed, 23 Jun 2004 14:21:04 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5F2A19F; Wed, 23 Jun 2004 10:21:03 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 10:20:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DSTM Date: Wed, 23 Jun 2004 10:21:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC91A@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRZJkgl+Q2QAeV1QvG43s9N6BDUowABfrNQ From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 23 Jun 2004 14:20:53.0714 (UTC) FILETIME=[4AD5C320:01C4592D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 >=20 > i was under impression that you're asking DSTM to be=20 > published without > wait finishing scenario/analysis document, or if DSTM=20 > being mentioned=20 > in the documents. is my impression incorrrect? Not what I want at all. I agree with you and agreed to the process. =20 So here is question to the chairs. First I support Teredo as a required technology as individual and within Industry roles have requested that Teredo be part of the Moonv6 site testing which is a growing large native IPv6 network pilot (which will also support production IPv6 access at some sites soon) and will be worldwide. I also supported Teredo moving forward as WG item when asked (not clear for standards track yet though). But when I saw the mail Teredo was going to move without doing finishing all scenarios/analysis docs I thought we were opening the flood gates for all mechanisms. I could be wrong? But all mechanisms should be applied to that entire set of work efforts. So I want to ask the Chairs what is the justification to work on Teredo here and not the other mechanisms? All this being said I do agree with Tony Hain's mail that we really may want to revisit our process per scenarios/analysis per that note to the WG and IESG and believe that is another discussion we must have here too as a logic check. Thanks I now see what you mean't by special treatment and that is not what I ask for or support I just want all things to be fair to all engineers that support different mechanisms for our users we see requirements for in the industry and DSTM is one of them. Regards, /jim From owner-v6ops@ops.ietf.org Wed Jun 23 10:22: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 KAA02455 for ; Wed, 23 Jun 2004 10:22:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd8dy-000Ohn-7m for v6ops-data@psg.com; Wed, 23 Jun 2004 14:22:30 +0000 Received: from [210.155.141.200] (helo=mango.itojun.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd8dx-000OhR-2N for v6ops@ops.ietf.org; Wed, 23 Jun 2004 14:22:29 +0000 Received: by mango.itojun.org (Postfix, from userid 1001) id 9891F10D389; Wed, 23 Jun 2004 23:22:28 +0900 (JST) To: jim.bound@hp.com Cc: v6ops@ops.ietf.org Subject: RE: DSTM In-Reply-To: Your message of "Wed, 23 Jun 2004 22:30:31 +0900 (JST)" <20040623133031.DBCCC10D38B@mango.itojun.org> References: <20040623133031.DBCCC10D38B@mango.itojun.org> X-Mailer: Cue version 0.8 (040620-0417/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040623142228.9891F10D389@mango.itojun.org> Date: Wed, 23 Jun 2004 23:22:28 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > > Some enterprises will not want 2002:: or any hard coded prefix in > > > > their sites network addresses only IPv6 aggregatable > > > address prefixes > > > > assigned to the site. Transition will use IPv6 or IPv4 > > > addresses not > > > > Transition prefixes and DSTM supports that operational model. > > > > > > transition technology other than DSTM can support the operational > > > model. so my question is, why DSTM is given special treatment here? > > > > DSTM is not asking for special treatment here and I don't understand why > > you say that can you please provide more context why you use the phrase > > "special treatment"? Thanks. > > i was under impression that you're asking DSTM to be published without > wait finishing scenario/analysis document, or if DSTM being mentioned > in the documents. is my impression incorrrect? i stand corrrected. Teredo is receiving special treatment from chairs and Jim is upset about it, and asking for the same treatment as Teredo. i think neither Teredo nor DSTM should receive special treatment, they have to wait till analysis/scenario finishes. otherwise, it's unfair to promote a/some mechanism picked by chairs. and chairs has to spell out why they thought Teredo is special. (even if the special treatment is withdrawn) itojun From owner-v6ops@ops.ietf.org Wed Jun 23 10:31: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 KAA02845 for ; Wed, 23 Jun 2004 10:31:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd8mX-000Pob-0h for v6ops-data@psg.com; Wed, 23 Jun 2004 14:31:21 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd8mV-000PoI-NC for v6ops@ops.ietf.org; Wed, 23 Jun 2004 14:31:20 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4DA8A668B; Wed, 23 Jun 2004 10:31:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 10:31:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DSTM Date: Wed, 23 Jun 2004 10:31:16 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC91D@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRZLYoqPxjRgJH+Tgmc3oLqu/6qNwAAKU+Q From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 23 Jun 2004 14:31:08.0722 (UTC) FILETIME=[B9688920:01C4592E] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I support this mail from Itojun. DSTM does not want special treatment only to be treated fairly. But I do want to point out to the WG that we face a delima in the market that some of these mechanisms like DSTM are being deployed, implemented, and shipped as product and users are using them. Out of the IETF we have to do something and it could be a transition consortia to get more expedient agreement on transition deployment that would request vendor and ISP support in such a consortia. Clearly that could evolve direct conflict of views with this body for deployment. It is just to slow here folks and also some are not getting Ipv6 native deployment and I will start a separate thread on that for discussion to bring that out too. /jim=20 > -----Original Message----- > From: Jun-ichiro itojun Hagino [mailto:itojun@itojun.org]=20 > Sent: Wednesday, June 23, 2004 10:22 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: DSTM=20 >=20 > > > > > Some enterprises will not want 2002:: or any hard=20 > coded prefix=20 > > > > > in their sites network addresses only IPv6 aggregatable > > > > address prefixes > > > > > assigned to the site. Transition will use IPv6 or IPv4 > > > > addresses not > > > > > Transition prefixes and DSTM supports that operational model. > > > >=20 > > > > transition technology other than DSTM can=20 > support the operational > > > > model. so my question is, why DSTM is given=20 > special treatment here? > > >=20 > > > DSTM is not asking for special treatment here and I don't=20 > understand=20 > > > why you say that can you please provide more context why=20 > you use the=20 > > > phrase "special treatment"? Thanks. > >=20 > > i was under impression that you're asking DSTM to be=20 > published without > > wait finishing scenario/analysis document, or if DSTM=20 > being mentioned=20 > > in the documents. is my impression incorrrect? >=20 > i stand corrrected. Teredo is receiving special=20 > treatment from chairs > and Jim is upset about it, and asking for the same=20 > treatment as Teredo. >=20 > i think neither Teredo nor DSTM should receive special=20 > treatment, > they have to wait till analysis/scenario finishes. =20 > otherwise, it's > unfair to promote a/some mechanism picked by chairs. >=20 > and chairs has to spell out why they thought Teredo is special. > (even if the special treatment is withdrawn) >=20 > itojun >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jun 23 10:49:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04709 for ; Wed, 23 Jun 2004 10:49:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd93G-0002vI-KN for v6ops-data@psg.com; Wed, 23 Jun 2004 14:48:38 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd93F-0002uq-AZ for v6ops@ops.ietf.org; Wed, 23 Jun 2004 14:48:37 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id F010660AD for ; Wed, 23 Jun 2004 10:48:36 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 10:48:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Dominant IPv6 Network deployment for Transition by Users Date: Wed, 23 Jun 2004 10:48:34 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC921@tayexc13.americas.cpqcorp.net> Thread-Topic: Dominant IPv6 Network deployment for Transition by Users Thread-Index: AcRZMSjoJLa0NummSUytBg6s6SYffg== From: "Bound, Jim" To: X-OriginalArrivalTime: 23 Jun 2004 14:48:29.0075 (UTC) FILETIME=[2581CE30:01C45931] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Many of us here working in industry with users are seeing that enough users and entities within the Enterprise and ISP scenarios see a very good cost justification to move to native IPv6 dominant LAN/WAN networks for deployment for multiple reasons. 1. Moving to dominant IPv6 networks reduces cost over long transition of supporting both IPv4 and IPv6. 2. Many believe the only real way to deliver true Mobile IP "Roaming" across an Internet network is with IPv6 and Mobile IPv6. =20 3. It is far easier to control the operation of transition to IPv6 once IPv6 networks are dominant and IPv4 is treated as legacy. It will take several years to achieve a strategy but the network pilots and planning is underway today as I type this mail. The hybrid-stack (dual stack is a misnomer in the context of this mail) deployment model will work well with this type of deployment for legacy requirements. The technology questions to discuss to support the above are as follows: 1. What are the differentials regarding technology requirements for a gradual IPv4-IPv6 versus agressive IPv6 transition for deployment to use a dominant IPv6 network deployment strategy? 2. What are the Internet infrastructure requirements for that which we have dominion over within the IETF regarding "protocols" and "operational procedures" we specify to suppport a dominant IPv6 network deployment strategy? 3. What are the technical limitations from IETF protocol suite perspective? 4. What are the security limitations from IETF protocol suite perspective? What else needs to be on the above list? Things we should not discuss here and not in our control within the IETF: 1. Vendor product delivery roadmaps of IPv6 infrastructure we specify in the IETF and in other bodies, consortias, and forums. 2. Application vendor product delivery roadmaps. 3. Infrastructure software to support IPv6 like Network Management and PKI products. 4. User policies for deployment which will vary as much as the opinions on this list. 5. How IPv6 will be provided as a business by service providers either public or private. regards, /jim From owner-v6ops@ops.ietf.org Wed Jun 23 12:16:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11189 for ; Wed, 23 Jun 2004 12:16:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdAOw-000Ge0-67 for v6ops-data@psg.com; Wed, 23 Jun 2004 16:15:06 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdAOu-000GdF-5f for v6ops@ops.ietf.org; Wed, 23 Jun 2004 16:15:04 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Wed, 23 Jun 2004 09:15:04 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 09:14:30 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 09:14:49 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 23 Jun 2004 09:14:31 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DSTM Date: Wed, 23 Jun 2004 09:14:27 -0700 Message-ID: Thread-Topic: DSTM thread-index: AcRZJkgl+Q2QAeV1QvG43s9N6BDUowABfrNQAAPXuKA= From: "Christian Huitema" To: "Bound, Jim" , "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 23 Jun 2004 16:14:31.0204 (UTC) FILETIME=[2A602E40:01C4593D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > But when I saw the mail Teredo was going to move without doing finishing > all scenarios/analysis docs I thought we were opening the flood gates > for all mechanisms. I could be wrong? But all mechanisms should be > applied to that entire set of work efforts. I have two issues with this statement. First, I don't think we should wait until *all* scenario documents are completed before we standardize or publish *any* new transition technology. The bar ought to be lower: we should progress a transition technology if we agree that it is clearly needed by at least one scenario. Otherwise, we could keep inventing new scenarios, and we would always have to wait until yet another scenario analysis is completed. Second, we have to define what "completed" means. What is the decision point? We have actually all but completed the "unmanaged networks" evaluation: we went through the working group last call, and the document is now on the IESG plate. Based on this scenario, doing work on Teredo is not spurious. Now, for the record, I am a strong believer in letting a thousand RFC bloom and letting the market decide. The IETF WG should not be in the business of evaluating business cases. We should definitely work on Teredo, and also ISATAP, DSTM, and tunnel brokers. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Jun 23 12:59:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13309 for ; Wed, 23 Jun 2004 12:59:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdB4r-000My0-VM for v6ops-data@psg.com; Wed, 23 Jun 2004 16:58:25 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdB4q-000Mwh-Hn for v6ops@ops.ietf.org; Wed, 23 Jun 2004 16:58:24 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i5NGwBvI027903; Wed, 23 Jun 2004 12:58:11 -0400 (EDT) Date: Wed, 23 Jun 2004 12:57:58 -0400 From: Marc Blanchet To: "Bound, Jim" , Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: RE: DSTM Message-ID: <639E11D7917E6F01823E8CC4@classic.viagenie.qc.ca> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CC91D@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC91D@tayexc13.americas.cpqc orp.net> X-Mailer: Mulberry/3.1.4 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit speaking about v4 in v6 encapsulation for v6 only networks, DSTM has two variations for address assignment: one using DHCPv6 (here named DSTM-DHCPv6) and one with TSP (here named (DSTM-TSP). So the TSP tunnel broker is a solution that covers both v6 in v4, v6 in udp v4 (i.e. nat traversal) and v4 in v6 (DSTM-TSP). This is very appealing to many large sites that need the three cases to be handled. Some markets are telling us that v4 in v6 encap is important and key. It will be very bad if the IETF does not consider solutions in this space. >From Thomas comment about when, the danger again is that non-interoperable implementations will come out, just because the spec is not stable (i.e. RFC number), this is really bad for the whole community, including IETF. I guess that a subset of the wg is interested in v4 in v6 encap (DSTM) and we could probably work in a small design group to do the final work and then have the wg review and publish. This won't consume much of wg work and will accomplish something important. My 2 cents. Marc. -- Wednesday, June 23, 2004 10:31:16 -0400 "Bound, Jim" wrote/a ecrit: > I support this mail from Itojun. DSTM does not want special treatment > only to be treated fairly. > > But I do want to point out to the WG that we face a delima in the market > that some of these mechanisms like DSTM are being deployed, implemented, > and shipped as product and users are using them. Out of the IETF we > have to do something and it could be a transition consortia to get more > expedient agreement on transition deployment that would request vendor > and ISP support in such a consortia. Clearly that could evolve direct > conflict of views with this body for deployment. It is just to slow > here folks and also some are not getting Ipv6 native deployment and I > will start a separate thread on that for discussion to bring that out > too. > > /jim > >> -----Original Message----- >> From: Jun-ichiro itojun Hagino [mailto:itojun@itojun.org] >> Sent: Wednesday, June 23, 2004 10:22 AM >> To: Bound, Jim >> Cc: v6ops@ops.ietf.org >> Subject: RE: DSTM >> >> > > > > Some enterprises will not want 2002:: or any hard >> coded prefix >> > > > > in their sites network addresses only IPv6 aggregatable >> > > > address prefixes >> > > > > assigned to the site. Transition will use IPv6 or IPv4 >> > > > addresses not >> > > > > Transition prefixes and DSTM supports that operational model. >> > > > >> > > > transition technology other than DSTM can >> support the operational >> > > > model. so my question is, why DSTM is given >> special treatment here? >> > > >> > > DSTM is not asking for special treatment here and I don't >> understand >> > > why you say that can you please provide more context why >> you use the >> > > phrase "special treatment"? Thanks. >> > >> > i was under impression that you're asking DSTM to be >> published without >> > wait finishing scenario/analysis document, or if DSTM >> being mentioned >> > in the documents. is my impression incorrrect? >> >> i stand corrrected. Teredo is receiving special >> treatment from chairs >> and Jim is upset about it, and asking for the same >> treatment as Teredo. >> >> i think neither Teredo nor DSTM should receive special >> treatment, >> they have to wait till analysis/scenario finishes. >> otherwise, it's >> unfair to promote a/some mechanism picked by chairs. >> >> and chairs has to spell out why they thought Teredo is special. >> (even if the special treatment is withdrawn) >> >> itojun >> >> > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Jun 23 13:06:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13741 for ; Wed, 23 Jun 2004 13:06:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdBCG-000Oeh-KF for v6ops-data@psg.com; Wed, 23 Jun 2004 17:06:04 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdBCD-000OdS-BI for v6ops@ops.ietf.org; Wed, 23 Jun 2004 17:06:01 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.1.R) with ESMTP id md50000066104.msg for ; Wed, 23 Jun 2004 19:08:12 +0200 Message-ID: <16e301c45944$59279130$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC91D@tayexc13.americas.cpqc orp.net> <639E11D7917E6F01823E8CC4@classic.viagenie.qc.ca> Subject: Re: DSTM Date: Wed, 23 Jun 2004 19:05:54 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 23 Jun 2004 19:08:12 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 138.4.0.14 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 23 Jun 2004 19:08:14 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable If we really believe, as a group, that IPv6 is being deployed (and this is actually my personal experience about the market situation), we MUST provide standard mechanism to allow the "backwards transition" stage: when we have some IPv6 only networks and we want to reach IPv4 only networks. Otherwise it will not make any sense to keep deploying IPv6. Regards, Jordi PS: Only my 0,2 cents ----- Original Message -----=20 From: "Marc Blanchet" To: "Bound, Jim" ; "Jun-ichiro itojun Hagino" Cc: Sent: Wednesday, June 23, 2004 6:57 PM Subject: RE: DSTM > speaking about v4 in v6 encapsulation for v6 only networks, DSTM has two > variations for address assignment: one using DHCPv6 (here named > DSTM-DHCPv6) and one with TSP (here named (DSTM-TSP). So the TSP tunnel > broker is a solution that covers both v6 in v4, v6 in udp v4 (i.e. nat > traversal) and v4 in v6 (DSTM-TSP). This is very appealing to many large > sites that need the three cases to be handled.=20 >=20 > Some markets are telling us that v4 in v6 encap is important and key. It > will be very bad if the IETF does not consider solutions in this space. > >From Thomas comment about when, the danger again is that non-interoperable > implementations will come out, just because the spec is not stable (i.e. > RFC number), this is really bad for the whole community, including IETF.=20 >=20 > I guess that a subset of the wg is interested in v4 in v6 encap (DSTM) and > we could probably work in a small design group to do the final work and > then have the wg review and publish. This won't consume much of wg work and > will accomplish something important. >=20 > My 2 cents. >=20 > Marc. >=20 > -- Wednesday, June 23, 2004 10:31:16 -0400 "Bound, Jim" > wrote/a ecrit: >=20 > > I support this mail from Itojun. DSTM does not want special treatment > > only to be treated fairly. > >=20 > > But I do want to point out to the WG that we face a delima in the market > > that some of these mechanisms like DSTM are being deployed, implemented, > > and shipped as product and users are using them. Out of the IETF we > > have to do something and it could be a transition consortia to get more > > expedient agreement on transition deployment that would request vendor > > and ISP support in such a consortia. Clearly that could evolve direct > > conflict of views with this body for deployment. It is just to slow > > here folks and also some are not getting Ipv6 native deployment and I > > will start a separate thread on that for discussion to bring that out > > too. > >=20 > > /jim=20 > >=20 > >> -----Original Message----- > >> From: Jun-ichiro itojun Hagino [mailto:itojun@itojun.org]=20 > >> Sent: Wednesday, June 23, 2004 10:22 AM > >> To: Bound, Jim > >> Cc: v6ops@ops.ietf.org > >> Subject: RE: DSTM=20 > >>=20 > >> > > > > Some enterprises will not want 2002:: or any hard=20 > >> coded prefix=20 > >> > > > > in their sites network addresses only IPv6 aggregatable > >> > > > address prefixes > >> > > > > assigned to the site. Transition will use IPv6 or IPv4 > >> > > > addresses not > >> > > > > Transition prefixes and DSTM supports that operational model. > >> > > >=20 > >> > > > transition technology other than DSTM can=20 > >> support the operational > >> > > > model. so my question is, why DSTM is given=20 > >> special treatment here? > >> > >=20 > >> > > DSTM is not asking for special treatment here and I don't=20 > >> understand=20 > >> > > why you say that can you please provide more context why=20 > >> you use the=20 > >> > > phrase "special treatment"? Thanks. > >> >=20 > >> > i was under impression that you're asking DSTM to be=20 > >> published without > >> > wait finishing scenario/analysis document, or if DSTM=20 > >> being mentioned=20 > >> > in the documents. is my impression incorrrect? > >>=20 > >> i stand corrrected. Teredo is receiving special=20 > >> treatment from chairs > >> and Jim is upset about it, and asking for the same=20 > >> treatment as Teredo. > >>=20 > >> i think neither Teredo nor DSTM should receive special=20 > >> treatment, > >> they have to wait till analysis/scenario finishes. =20 > >> otherwise, it's > >> unfair to promote a/some mechanism picked by chairs. > >>=20 > >> and chairs has to spell out why they thought Teredo is special. > >> (even if the special treatment is withdrawn) > >>=20 > >> itojun > >>=20 > >>=20 > >=20 >=20 >=20 >=20 > ------------------------------------------ > Marc Blanchet > Hexago > tel: +1-418-266-5533x225 > ------------------------------------------ > http://www.freenet6.net: IPv6 connectivity > ------------------------------------------ >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Jun 23 13:16:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14368 for ; Wed, 23 Jun 2004 13:16:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdBM2-0000xk-6C for v6ops-data@psg.com; Wed, 23 Jun 2004 17:16:10 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdBM1-0000xE-2d for v6ops@ops.ietf.org; Wed, 23 Jun 2004 17:16:09 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5NHG0q09377; Wed, 23 Jun 2004 10:16:00 -0700 X-mProtect: <200406231716> 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 smtpdATtEnq; Wed, 23 Jun 2004 10:15:58 PDT Message-ID: <40D9BAD5.8050105@iprg.nokia.com> Date: Wed, 23 Jun 2004 10:16:05 -0700 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: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, See below: Pekka Savola wrote: >On Thu, 17 Jun 2004, Fred Templin wrote: > > >>It seems that section 3.4 of the current mech-v2 draft includes a built-in >>assumption that ICMPv4 error translation to ICMPv6 is only possible >>when the ICMPv4 error messages *themselves* include more than the >>minimum 8 bytes of data beyond the IPv4 header of the packet in error. >> >>But, if the encapsulator maintains a small queue of recently-sent packets >>(indexed, e.g., by the 'ip_id' field of the encapsulating IPv4 headers) >>then enough state would be available for ICMPv6 error generation >>in most cases even if the ICMPv4 error messages themselves only >>return the minimum amount. >> >> > >The current spec AFAIK doesn't have anything which would prohibit from >doing so, so this seems like spelling out a possible different >approach to solve the same problem (an editorial fix). > >On the other hand, by introducing a new feature, we would also create >a requirement that there must be two interoperable implementations of >this feature when going for DS, and that would seem undesirable. > >Do you know of such implementations? > Well, if we are talking about actions taken by the encapsulator, it seems like the strategy is somewhat up to the individual implementation so long as it is consistent with normative references, e.g., RFC 1122. The feature is asymmetric in that it is implemented in the encapsulator and does not require corresponding modifications in the decapsulator. So, interoperability is based on whether modified encapsulator A still interoperates with unmodified decapsulator B, i.e., we don't need both A and B to implement the modification - right? >If not, I'm thinking that all the suggestions except item 2) are >generalizing enough not to cause any trouble, so I could adopt them. > See below for alternate wording suggestion on 2). >>I suggest the following changes: >> >>1) Section 3.4, 4th paragraph. change to: >> >> "The handling of other types of ICMPv4 error messages depends >> on how much information is available from the encapsulated packet >> that caused the error." >> >>2) Section 3.4, 6th paragraph, change: >> >> "If the offending packet includes enough data, the encapsulator MAY" >> >>to: >> >> "If the offending packet includes enough data, or if enough data is >> available in the encapulator's cache, the encapsulator MAY" >> To be more consistent with the other suggestions, could change this to: "If sufficient data bytes from the offending packet are available, the encapsulator MAY" Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Jun 23 13:54: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 NAA21180 for ; Wed, 23 Jun 2004 13:54:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdBwF-0006ye-Ru for v6ops-data@psg.com; Wed, 23 Jun 2004 17:53:35 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdBwC-0006xz-Ay for v6ops@ops.ietf.org; Wed, 23 Jun 2004 17:53:32 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i5NHrVnE025228 for ; Wed, 23 Jun 2004 18:53:31 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA21546 for ; Wed, 23 Jun 2004 18:53:29 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i5NHrT025052 for v6ops@ops.ietf.org; Wed, 23 Jun 2004 18:53:29 +0100 Date: Wed, 23 Jun 2004 18:53:29 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: DSTM Message-ID: <20040623175329.GN17875@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jun 23, 2004 at 09:14:27AM -0700, Christian Huitema wrote: > > Second, we have to define what "completed" means. What is the decision > point? We have actually all but completed the "unmanaged networks" > evaluation: we went through the working group last call, and the > document is now on the IESG plate. Based on this scenario, doing work on > Teredo is not spurious. Well, we saw recently in the discussion on the enterprise scenarios draft that I proposed 4 scenarios to be considered, one of which lends itself to be addressed by DSTM. Pekka objected that this was a "minority case", and I don't know what happened after that. So we can easily write in a scenario for DSTM in the enterprise draft, and Jim has expanded already on what that is. Likewise we can do so for ISATAP. Everything hangs on what the WG chair then dictates. But the fact is that there are networks out there wanting to run IPv6 only infrastructure with IPv4 apps/data to be served, so as Marc and Jordi say, this is a real requirement now. As such I believe we should work on it in the IETF. The question from "on high" is where do we put the focus? How wide is our net to be? > Now, for the record, I am a strong believer in letting a thousand RFC > bloom and letting the market decide. The IETF WG should not be in the > business of evaluating business cases. We should definitely work on > Teredo, and also ISATAP, DSTM, and tunnel brokers. The beauty of the transition toolbox is that everyone can reach in and pick out a different tool (or tools) for their situation. Even in similar scenarios, ISPs may take different paths, e.g. in a recent European NREN survey, 75% offered a 6to4 relay for their users, 25% tunnel broker(s). ISPs in Asian networks will also likely deploy different solutions because they appear more keen to move to IPv6 only infrastructure earlier (e.g. CERNET in China) - do we let them make up their own solutions just because the WG chair thinks China is a fringe case? (Ok those were not Pekka's words, but they're kind of implied ;) I agree the scenario work needs to be wrapped up, but I think we should cast a wide net, not a narrow one. Tim From owner-v6ops@ops.ietf.org Wed Jun 23 14:56:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04829 for ; Wed, 23 Jun 2004 14:56:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdCtL-000Fdm-5P for v6ops-data@psg.com; Wed, 23 Jun 2004 18:54:39 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdCt4-000FZl-Hh for v6ops@ops.ietf.org; Wed, 23 Jun 2004 18:54:22 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5NIsBaK002656 for ; Wed, 23 Jun 2004 14:54:11 -0400 Received: from nist.gov (itg-03.antd.nist.gov [129.6.50.182]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i5NIrT4A000165 for ; Wed, 23 Jun 2004 14:53:31 -0400 (EDT) Message-ID: <40D9D1A9.7D79826F@nist.gov> Date: Wed, 23 Jun 2004 14:53:29 -0400 From: "M-K. Shin" Organization: ETRI/NIST X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,ko MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: DSTM References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC91D@tayexc13.americas.cpqc orp.net> <639E11D7917E6F01823E8CC4@classic.viagenie.qc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: mshin@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree on Marc's point. Also, some enterprise scenarios (i.e., dominant IPv6 network deployment, - it is certainly in the short term) need DSTM. Thanks, -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Myung-Ki Shin, Ph.D.| mshin@nist.gov ETRI/NIST | 820 West Diamond Avenue | Gaithersburg, MD 20899 Marc Blanchet wrote: > speaking about v4 in v6 encapsulation for v6 only networks, DSTM has two > variations for address assignment: one using DHCPv6 (here named > DSTM-DHCPv6) and one with TSP (here named (DSTM-TSP). So the TSP tunnel > broker is a solution that covers both v6 in v4, v6 in udp v4 (i.e. nat > traversal) and v4 in v6 (DSTM-TSP). This is very appealing to many large > sites that need the three cases to be handled. > > Some markets are telling us that v4 in v6 encap is important and key. It > will be very bad if the IETF does not consider solutions in this space. > >From Thomas comment about when, the danger again is that non-interoperable > implementations will come out, just because the spec is not stable (i.e. > RFC number), this is really bad for the whole community, including IETF. > > I guess that a subset of the wg is interested in v4 in v6 encap (DSTM) and > we could probably work in a small design group to do the final work and > then have the wg review and publish. This won't consume much of wg work and > will accomplish something important. > > My 2 cents. > > Marc. > > -- Wednesday, June 23, 2004 10:31:16 -0400 "Bound, Jim" > wrote/a ecrit: > > > I support this mail from Itojun. DSTM does not want special treatment > > only to be treated fairly. > > > > But I do want to point out to the WG that we face a delima in the market > > that some of these mechanisms like DSTM are being deployed, implemented, > > and shipped as product and users are using them. Out of the IETF we > > have to do something and it could be a transition consortia to get more > > expedient agreement on transition deployment that would request vendor > > and ISP support in such a consortia. Clearly that could evolve direct > > conflict of views with this body for deployment. It is just to slow > > here folks and also some are not getting Ipv6 native deployment and I > > will start a separate thread on that for discussion to bring that out > > too. > > > > /jim > > > >> -----Original Message----- > >> From: Jun-ichiro itojun Hagino [mailto:itojun@itojun.org] > >> Sent: Wednesday, June 23, 2004 10:22 AM > >> To: Bound, Jim > >> Cc: v6ops@ops.ietf.org > >> Subject: RE: DSTM > >> > >> > > > > Some enterprises will not want 2002:: or any hard > >> coded prefix > >> > > > > in their sites network addresses only IPv6 aggregatable > >> > > > address prefixes > >> > > > > assigned to the site. Transition will use IPv6 or IPv4 > >> > > > addresses not > >> > > > > Transition prefixes and DSTM supports that operational model. > >> > > > > >> > > > transition technology other than DSTM can > >> support the operational > >> > > > model. so my question is, why DSTM is given > >> special treatment here? > >> > > > >> > > DSTM is not asking for special treatment here and I don't > >> understand > >> > > why you say that can you please provide more context why > >> you use the > >> > > phrase "special treatment"? Thanks. > >> > > >> > i was under impression that you're asking DSTM to be > >> published without > >> > wait finishing scenario/analysis document, or if DSTM > >> being mentioned > >> > in the documents. is my impression incorrrect? > >> > >> i stand corrrected. Teredo is receiving special > >> treatment from chairs > >> and Jim is upset about it, and asking for the same > >> treatment as Teredo. > >> > >> i think neither Teredo nor DSTM should receive special > >> treatment, > >> they have to wait till analysis/scenario finishes. > >> otherwise, it's > >> unfair to promote a/some mechanism picked by chairs. > >> > >> and chairs has to spell out why they thought Teredo is special. > >> (even if the special treatment is withdrawn) > >> > >> itojun > >> > >> > > > > ------------------------------------------ > Marc Blanchet > Hexago > tel: +1-418-266-5533x225 > ------------------------------------------ > http://www.freenet6.net: IPv6 connectivity > ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Jun 23 15:08:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06501 for ; Wed, 23 Jun 2004 15:08:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdD5M-000I4S-P7 for v6ops-data@psg.com; Wed, 23 Jun 2004 19:07:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdD53-000Hxs-M7 for v6ops@ops.ietf.org; Wed, 23 Jun 2004 19:06:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5NJ6Cg28115; Wed, 23 Jun 2004 22:06:14 +0300 Date: Wed, 23 Jun 2004 22:06:12 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Jun-ichiro itojun Hagino , Subject: dynamic v4 addresses over v4-in-v6 tunnel [RE: DSTM] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CC903@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 23 Jun 2004, Bound, Jim wrote: > Operational requirements by the user: [...] > 3. The use of IPv4 addresses for legacy communications should be > temporary IPv4 addresses for a specific time. I'm not sure I personally buy the other requirements, but for the argument's sake.. What kind of requirement is this? How is this different for a site currently deploying v4? In other words: if we need IPv4-in-IPv6 tunneling, let's discuss that. If we need something more than the existing IPv4 mechanisms for making the v4 addresses used over such tunnels more dynamic (e.g., if DHCPv4 with short leases is not enough), let's discuss that separately as well. But let's not get these two features mixed up, having to sacrifice a baby to get the bathwater :) I have the impression that a lot of people have "IPv6-in-IPv4 == DSTM" in their head. I want to break that assumption, as DSTM seems to offer a lot more than that, because specifying a solution without clearly defining its components seems unwise. -- 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 Jun 23 17:11:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18410 for ; Wed, 23 Jun 2004 17:11:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdF0E-000BnN-0B for v6ops-data@psg.com; Wed, 23 Jun 2004 21:09:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdEzv-000BkN-V4 for v6ops@ops.ietf.org; Wed, 23 Jun 2004 21:09:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5NL9Re30914; Thu, 24 Jun 2004 00:09:27 +0300 Date: Thu, 24 Jun 2004 00:09:27 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: Re: Dominant IPv6 Network deployment for Transition by Users In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CC921@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 23 Jun 2004, Bound, Jim wrote: > 1. Moving to dominant IPv6 networks reduces cost over long transition of > supporting both IPv4 and IPv6. I think you assume that having to support one dominant protocol (IPv6) and one less dominant (but still a MUST work protocol, IPv4), through mechanisms more complex than just deploying IPv4 (or keeping it deployed) requires a smaller amount of support in total? This seems dubious to me. > 2. Many believe the only real way to deliver true Mobile IP "Roaming" > across an Internet network is with IPv6 and Mobile IPv6. Sure, why not. This is no argument for dominant IPv6 networks though. It's an argument for deploying IPv6. > 3. It is far easier to control the operation of transition to IPv6 once > IPv6 networks are dominant and IPv4 is treated as legacy. Do we (and the customers, or at least the majority of them) actually want to control the operation of transition to IPv6-only at this point? I imagine most would want to deploy IPv6 because it brings them a benefit they want. Until a significant portion of the Internet has adopted IPv6, an easy strategy could be to postpone the decision on when to move to IPv6-only. You're assuming that it's useful to make the decision at this point, as a "future investment" and a hope that IPv6 will actually be globally deployed soon enough to warrant doing it now. This might not hold. At least in many circles, where IPv6 is *NOT* a "religious" or political topic (but operational one, as it should be, in the end -- we're not deploying IPv6 for its own sake, but to make the users happier by giving them better means to achieve X, Y and Z!), it's much easier to control the operation of transition by deploying IPv6, but not by taking away what's already in there (IPv4). Then IPv6 will fly when there is use (X, Y, or Z, above) for it. > The technology questions to discuss to support the above are as follows: > > 1. What are the differentials regarding technology requirements for a > gradual IPv4-IPv6 versus agressive IPv6 transition for deployment to use > a dominant IPv6 network deployment strategy? Good question, even though I'd personally want to question the latter strategy in the first place. > 2. What are the Internet infrastructure requirements for that which we > have dominion over within the IETF regarding "protocols" and > "operational procedures" we specify to suppport a dominant IPv6 network > deployment strategy? Regarding the previous question, I'd be interested in hearing more opinions on whether this is a priority work item for us? I.e., I'm sure that (provided that IPv6 will kick off in a major way) some years in the future the IETF will be specifying how to deal with a lot of issues regarding IPv6-only or dominant IPv6, but doing so *NOW* seems premature (especially as we have as little real operational experience from that), when we could be using that energy to solve the problems with the more generic approach, dual-stack. -- 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 Jun 23 17:27: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 RAA19886 for ; Wed, 23 Jun 2004 17:27:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdFFq-000EOC-UX for v6ops-data@psg.com; Wed, 23 Jun 2004 21:26:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdFFc-000EKl-Kf for v6ops@ops.ietf.org; Wed, 23 Jun 2004 21:25:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5NLNfb31245; Thu, 24 Jun 2004 00:23:44 +0300 Date: Thu, 24 Jun 2004 00:23:41 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Eliot Lear , Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) In-Reply-To: <4E3DBBB8-C36D-11D8-96AB-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 21 Jun 2004, Iljitsch van Beijnum wrote: > > No, we assume that the network is in a nominal state prior to > > renumbering. The issue you raise below would indicate that perhaps > > this *isn't* the case. In which case your problems are bigger than > > renumbering. > > My point is that if you have two prefixes from two ISPs (which I think > is the most common situation in renumbering, and it's certainly common > enough to be worthy of discussion in a renumbering draft) and both ISPs > do ingress filtering (which is also something that can't be discounted) > then "turning on" both prefixes at the same time without additional > measures is going to lead to problems as packets routed to ISP A may > have a source address from the prefix from ISP B (or vice versa) and > thus be dropped due to ingress filtering. I think the document as it is has two assumptions about this: (1) you either renumber inside an ISP, or (2) you multihome to at least two different ISPs, and may be: a) switching from the first to the second ("transitional multihoming") b) switching from the first to the third, but keeping the second (1) requires no ingress filtering magic. Either of options in (2) *already* require that there is a mechanism in place, like draft-huitema-multi6-xxx (e.g., source-based routing at the edges), to ensure the right packets go to the right place. This requirement would exist without renumbering as well. In your earlier mail, you wrote: > The draft only talks about ingress filtering with regard to > security, which IMNSHO is stupid because there are no attacks that > are possible with spoofed addresses that aren't possible with > unspoofed addresses. Not quite so, or at least requiring a clarification. Remember that the *sites* should also check that no packets with their IP addresses are coming from the Internet to them, using their addresses. This is also called "ingress filtering", but was probably not the nuance mentioned in the draft. I think the point you're making is subtle, and I'm not sure if I understand it myself. Doesn't ingress filtering by the ISP block the site from performing e.g., certain kinds of 3rd party bombing DoS attacks? This is something that's prevented (from a particular direction) with ingress filtering. -- 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 Jun 23 17:41: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 RAA20490 for ; Wed, 23 Jun 2004 17:41:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdFUE-000Gu8-N7 for v6ops-data@psg.com; Wed, 23 Jun 2004 21:40:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdFU0-000Gr1-Im for v6ops@ops.ietf.org; Wed, 23 Jun 2004 21:40:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5NLeQh31601; Thu, 24 Jun 2004 00:40:26 +0300 Date: Thu, 24 Jun 2004 00:40:26 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: "Bound, Jim" , Jun-ichiro itojun Hagino , Subject: moving when all the scenarios are not yet complete [RE: DSTM] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A new topic to better suit the subject.. On Wed, 23 Jun 2004, Christian Huitema wrote: > > But when I saw the mail Teredo was going to move without doing > finishing > > all scenarios/analysis docs I thought we were opening the flood gates > > for all mechanisms. I could be wrong? But all mechanisms should be > > applied to that entire set of work efforts. > > I have two issues with this statement. > > First, I don't think we should wait until *all* scenario documents are > completed before we standardize or publish *any* new transition > technology. The bar ought to be lower: we should progress a transition > technology if we agree that it is clearly needed by at least one > scenario. Otherwise, we could keep inventing new scenarios, and we would > always have to wait until yet another scenario analysis is completed. > > Second, we have to define what "completed" means. What is the decision > point? We have actually all but completed the "unmanaged networks" > evaluation: we went through the working group last call, and the > document is now on the IESG plate. Based on this scenario, doing work on > Teredo is not spurious. What Christian said. The analysis of 3GPP, Unmanaged and ISP have all already left this WG (with rough consensus) and are at IESG evaluation, or beyond the IESG evaluation (and none of documents got IESG pushback on Teredo/BGPtunnel/etc.). I fail to see what more one could expect here. Does it matter what we decide e.g. in the Enterprise document, if Unmanaged, ISP, or 3GPP already requires a certain kind of mechanism? There is, however, an argument to be made if a mechanism would be required in multiple scenarios, where one or more of the scenarios was not finished yet -- then the question would be what would be the basis on where to evolve the specification? (for example, let's consider ISATAP in 3GPP: one could remove direct tunneling support, but then it might become useless (at least to some) in Enterprise -- for mechanisms which dependencies it might be worth a bit more of wait-and-see, but e.g. Teredo has only been proposed in the Unmanaged scenario. So IMHO this is an argument for moving forward (if there is consensus, as there seems to be in Unmanaged and ISP) in all the scenarios which are already at the IESG (read: when there is consensus in the WG, and there is no objection at the IESG). The mechanisms required by scenarios which are not done yet IMHO cannot go forward at this point. -- 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 Jun 23 23:41: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 XAA13709 for ; Wed, 23 Jun 2004 23:41:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdL5P-000ATe-1T for v6ops-data@psg.com; Thu, 24 Jun 2004 03:39:39 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdL5E-000ASz-UD for v6ops@ops.ietf.org; Thu, 24 Jun 2004 03:39:29 +0000 Received: from [24.61.30.237] (account margaret HELO [10.0.0.39]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 93738; Wed, 23 Jun 2004 23:37:30 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <20040623175329.GN17875@login.ecs.soton.ac.uk> References: <20040623175329.GN17875@login.ecs.soton.ac.uk> Date: Wed, 23 Jun 2004 23:37:02 -0400 To: Tim Chown , v6ops@ops.ietf.org From: Margaret Wasserman Subject: Re: DSTM Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Tim, At 6:53 PM +0100 6/23/04, Tim Chown wrote: >> Now, for the record, I am a strong believer in letting a thousand RFC >> bloom and letting the market decide. The IETF WG should not be in the >> business of evaluating business cases. We should definitely work on >> Teredo, and also ISATAP, DSTM, and tunnel brokers. > >The beauty of the transition toolbox is that everyone can reach in and pick >out a different tool (or tools) for their situation. Even in similar >scenarios, ISPs may take different paths, e.g. in a recent European NREN >survey, 75% offered a 6to4 relay for their users, 25% tunnel broker(s). This is also the biggest problem with having a large tool-box of transition mechanisms -- everyone can reach in and pick out a different tool... So, in order for a given host implementation or piece of networking equipment to operate properly on multiple networks, it will need to implement or interoperate with _all_ of the tools. This leads to increased complexity, more security issues, more points of failure, larger code sizes, higher costs for networking infrastructure, etc. One of the points of standardization, IMO, is to promote small, simple, interoperable implementations. I think that there is a clear need for a (single, standard) mechanism that solves the problem that Teredo solves, and the Teredo approach (which was updated over time based on a lot of feedback from security people, IAB folks, etc.) is, IMO, a pretty good way to meet that need. I am less certain that there is a real need for DSTM today. Jim Bound and a few others have indicated that they have customers who need this, but they won't say who those customers are or what is driving them towards this choice. Without knowing the details of those deployment scenarios, I can't have an informed opinion about whether DSTM is the best way to meet those customers' needs. I have not personally heard any ISP or Enterprise operators indicate their intention to run IPv6-only backbones any time soon. I believe that this will happen at some point in the future, but I am not certain (from my own experience or any direct communication) that this is a widespread need today. If this won't be needed until later, I think that we should wait until later to provide it -- when we will know more about how IPv6 has been deployed. However, even if I accept that there is a need for a solution in this space now, I have some serious reservations about the DSTM solution as it is currently documented. In particular, I don't know why we would want to standardize a solution in this space that includes multiple non-interoperable options for how a dual-stack host can obtain a temporary IPv4 address (DHCPv6 and TSP). Would a client need to implement both to work on different networks? And how would a client know which one to use in any particular situation? Would it try one and then fail over to the other? I'm also not sure how/why we need a specific DSTM server at all... How is DSTM superior to using a DHCPv6 option to get the configuration information needed to set-up a configured IPv4-in-IPv6 tunnel and then using DHCPv4 over that tunnel? Margaret From owner-v6ops@ops.ietf.org Thu Jun 24 02:44:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07624 for ; Thu, 24 Jun 2004 02:44:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdNvR-0005q0-2q for v6ops-data@psg.com; Thu, 24 Jun 2004 06:41:33 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdNvG-0005oV-8L for v6ops@ops.ietf.org; Thu, 24 Jun 2004 06:41:22 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7A28C4E08; Thu, 24 Jun 2004 02:41:21 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 02:41:21 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: dynamic v4 addresses over v4-in-v6 tunnel [RE: DSTM] X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 24 Jun 2004 02:41:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC992@tayexc13.americas.cpqcorp.net> Thread-Topic: dynamic v4 addresses over v4-in-v6 tunnel [RE: DSTM] Thread-Index: AcRZVTRjn/uFbCMGTyWKiWcSEsuASwAX6GlQ From: "Bound, Jim" To: "Pekka Savola" Cc: "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 24 Jun 2004 06:41:21.0260 (UTC) FILETIME=[42C8EAC0:01C459B6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > On Wed, 23 Jun 2004, Bound, Jim wrote: > > Operational requirements by the user: > [...] > > 3. The use of IPv4 addresses for legacy communications should be=20 > > temporary IPv4 addresses for a specific time. >=20 > I'm not sure I personally buy the other requirements, but for=20 > the argument's sake.. Are you calling the authors liars? >=20 > What kind of requirement is this? How is this different for=20 > a site currently deploying v4? It is strictly enforced with DSTM and quite critical for its use. Whether that is true all the time in networks today is unclear to me anyway. I keep my IPv4 address all day in most places on Intranets I visit. =20 >=20 > In other words: if we need IPv4-in-IPv6 tunneling, let's=20 > discuss that.=20 Thats fine but I want to discuss Dominant IPv6 networks and it appears others do too. =20 We can clearly start another thread for that I believe too. =20 > If we need something more than the existing IPv4 mechanisms=20 > for making the v4 addresses used over such tunnels more=20 > dynamic (e.g., if DHCPv4 with short leases is not enough),=20 > let's discuss that separately as well. Please read DSTM it presents in this case the user does not want to add IPv4 infrastructure to the IPv6 dominant network so DHCPv4 is not an option in the spec and clearly stated for some time. This is core rationale within DSTM.=20 > But let's not get=20 > these two features mixed up, having to sacrifice a baby to=20 > get the bathwater :) Not sure what this means at all? >=20 > I have the impression that a lot of people have "IPv6-in-IPv4=20 > =3D=3D DSTM" =20 I think you mean IPv4-in-IPv6 ? > in their head. I want to break that assumption, as DSTM=20 > seems to offer a lot more than that, because specifying a=20 > solution without clearly defining its components seems unwise. We believe the spec does that and why we keep sending update if you want to add input to the spec please comment directly on the spec and that would be helpful. thanks /jim >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Jun 24 03:03: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 DAA08780 for ; Thu, 24 Jun 2004 03:03:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdOG9-0008Lv-8O for v6ops-data@psg.com; Thu, 24 Jun 2004 07:02:57 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdOFY-0008HK-7H for v6ops@ops.ietf.org; Thu, 24 Jun 2004 07:02:20 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D8D074F76; Thu, 24 Jun 2004 03:02:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 03:02:19 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Dominant IPv6 Network deployment for Transition by Users X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 24 Jun 2004 03:02:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC994@tayexc13.americas.cpqcorp.net> Thread-Topic: Dominant IPv6 Network deployment for Transition by Users Thread-Index: AcRZZmg7eDOkOzf/Swua/DdEmRVerAAT9sgA From: "Bound, Jim" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 24 Jun 2004 07:02:19.0693 (UTC) FILETIME=[30DE8DD0:01C459B9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > On Wed, 23 Jun 2004, Bound, Jim wrote: > > 1. Moving to dominant IPv6 networks reduces cost over long=20 > transition=20 > > of supporting both IPv4 and IPv6. >=20 > I think you assume that having to support one dominant=20 > protocol (IPv6) and one less dominant (but still a MUST work=20 > protocol, IPv4), through mechanisms more complex than just=20 > deploying IPv4 (or keeping it > deployed) requires a smaller amount of support in total? That is not the issue at all. The user does not want IPv4 on the network at all. But they require it at times when Legacy IPv4 is required. >=20 > This seems dubious to me. > =20 > > 2. Many believe the only real way to deliver true Mobile IP=20 > "Roaming" > > across an Internet network is with IPv6 and Mobile IPv6. =20 >=20 > Sure, why not. This is no argument for dominant IPv6=20 > networks though. =20 > It's an argument for deploying IPv6. In addition in the use case for DSTM its also a result of deploying dominant IPv6 network and wanting to reduce any use of IPv4 as soon as possible. > =20 > > 3. It is far easier to control the operation of transition to IPv6=20 > > once > > IPv6 networks are dominant and IPv4 is treated as legacy. >=20 > Do we (and the customers, or at least the majority of them)=20 This is not about a majority ok. Its about a use case. If one customer will spend 1 billion dollars on something it is as significant or more so than 20 that only spend 200 million. So I reject the cocept of majority in this particular discussion. > actually want to control the operation of transition to=20 > IPv6-only at this point? Yes and that is the case. > I imagine most would want to deploy=20 > IPv6 because it brings them a benefit they want. Until a=20 > significant portion of the Internet has adopted IPv6 Wrong assumption in your process above. Many users deploy IP on their own private Internet only using the public Internet for web services that exist etc. =20 Assuming IPv6 deployment within the Enterprise is dependent on the public Internet supporting IPv6 is an invalid and wrong assumption for many enterprises. >, an easy=20 > strategy could be to postpone the decision on when to move to=20 > IPv6-only.=20 I think that is an invalid discussion here in the IPv6 WG and in the IETF. We do not control or own what users do and when they do it at all. Please re-read Christian Huitema's response on this that we really have no business being involved with the business decisions of any entity and telling them postpone your transition strategy is absurd and the users/market will never listen to us with such input. Please lets not even go there. =20 > You're assuming that it's useful to make the=20 > decision at this point, as a "future investment" and a hope=20 > that IPv6 will actually be globally deployed soon enough to=20 > warrant doing it now. I am assuming nothing. I am hearing users and deployment requirements for dominant IPv6 networks to be deployed. Again Ipv6 does not have to be globally deployed for Enterprises to use IPv6 dominant networks (e.g. NTT, KDDI, GM, Military Organizations worldwide, Security Forces World Wide) they all have their own Internets. >=20 > This might not hold. At least in many circles, where IPv6 is=20 > *NOT* a "religious" or political topic (but operational one,=20 > as it should be, in the end -- we're not deploying IPv6 for=20 > its own sake, but to make the users happier by giving them=20 > better means to achieve X, Y and Z!), This is exactly what users are telling me and others and that they want IPv6 for its operational benefits it has nothing to do with religion or politics. I do not think your mail above is relevant to the technical or deployment operational discussion. > it's much easier to=20 > control the operation of transition by deploying IPv6, but=20 > not by taking away what's already in there (IPv4). Then > IPv6 will fly when there is use (X, Y, or Z, above) for it. In some cases it is in fact easier to deploy IPv6 but that is not our issue here at all. > =20 > > The technology questions to discuss to support the above=20 > are as follows: > >=20 > > 1. What are the differentials regarding technology=20 > requirements for a=20 > > gradual IPv4-IPv6 versus agressive IPv6 transition for=20 > deployment to=20 > > use a dominant IPv6 network deployment strategy? >=20 > Good question, even though I'd personally want to question=20 > the latter strategy in the first place. You can question it but the users I know really don't care what you think personally but do care we discuss this in the working group. They have a strategy and will deploy dominant IPv6 and that is not open for discussion it is a business decision. What we have to do here or we can go do it elsewhere is determine how we support that and DSTM is one mechanism that will support that form of deployment. > =20 > > 2. What are the Internet infrastructure requirements for=20 > that which=20 > > we have dominion over within the IETF regarding "protocols" and=20 > > "operational procedures" we specify to suppport a dominant IPv6=20 > > network deployment strategy? >=20 > Regarding the previous question, I'd be interested in hearing=20 > more opinions on whether this is a priority work item for us? I think it gets into the entire discussion of talking about any scenarios. We have many on this list that believe we need to discuss transition mechanisms. Except for you, Thomas, and Margaret no one else agrees with you three this is not important or that dominant Ipv6 networks are important. So I think for now the discussion is required and we see where the WG goes. >=20 > I.e., I'm sure that (provided that IPv6 will kick off in a=20 > major way) some years in the future the IETF will be=20 > specifying how to deal with a lot of issues regarding=20 > IPv6-only or dominant IPv6, but doing so > *NOW* seems premature (especially as we have as little real=20 > operational experience from that), when we could be using=20 > that energy to solve the problems with the more generic=20 > approach, dual-stack. Well I and others on this list do not agree with you and from the names that support working on DSTM I know we all have far more technical and deployment experience to justify this conversation and opposition to your opinion. =20 And by the way Tony Hain was right and correct in his mail. I will be watching this process carefully and so are some of the users I speak of on this list. Your treading on thin ice here the IETF is not a monarchy or dictatorship and your just one person even as Chair or Margaret as IESG. So be careful is my input and permit the open process to continue as Chair or you can publicly give us all permission to go elsewhere and compete directly with the IETF and I don't want to see that happen. But appreciate the individual input and views you provide and they are not new and either are mine and lets hear from the working group. That is what an open standards process is all about here. Regards, /jim >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Jun 24 03:25: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 DAA10253 for ; Thu, 24 Jun 2004 03:25:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdObY-000At7-6i for v6ops-data@psg.com; Thu, 24 Jun 2004 07:25:04 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdObL-000AqT-Mr for v6ops@ops.ietf.org; Thu, 24 Jun 2004 07:24:52 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 2EF2EB81B; Thu, 24 Jun 2004 03:24:51 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 03:24:51 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: DSTM Date: Thu, 24 Jun 2004 03:24:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC996@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRZnUO4BPIBP+NEQkWeQyVBO1uupAAHC0EQ From: "Bound, Jim" To: "Margaret Wasserman" , "Tim Chown" , X-OriginalArrivalTime: 24 Jun 2004 07:24:51.0012 (UTC) FILETIME=[56517840:01C459BC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Margaret, I am sure Tim will respond to your entire mail thread but I want to respond to a few of your assumptions and questions below.=20 > This is also the biggest problem with having a large tool-box=20 > of transition mechanisms -- everyone can reach in and pick=20 > out a different tool... So, in order for a given host=20 > implementation or piece of networking equipment to operate=20 > properly on multiple networks, it will need to implement or=20 > interoperate with _all_ of the tools. This is simply invalid logic and it is none of yours, mine, or the IETF's business what a free enterprise systems does at all. The more tools the better. >=20 > This leads to increased complexity, more security issues,=20 > more points of failure, larger code sizes, higher costs for=20 > networking infrastructure, etc. I don't agree at all. Each mechanism will be used for a solution not all mechanisms in one network. I don't know of any user that is that stupid to use 5 mechanisms at once. The point you continue to miss is that there could be 5 different usrs with 5 different needs for transition and each of the 5 mechanisms are useful to them each individually as one tool. Forcing all users to use only X, Y, and Z is absurd and the market, implementers, and users will reject that IETF view and will simply ignore the IETF regarding transition and seek the solutions they need elsewhere. if that happens we have failed here in the IETF and it will be recorded as so for sure. >=20 > One of the points of standardization, IMO, is to promote=20 > small, simple, interoperable implementations. And because there are 6 or 8 transitiion mechanisms that do not duplicate each other does not prevent your statement above. What the IETF cannot do is try to dictate the policy for deployment in the market at all. That is absurd and will be rejected by the people in the IETF and the market. It will also cause serious discussions with the IETF's higher authority for sure. =20 > I have not personally heard any ISP or Enterprise operators=20 > indicate their intention to run IPv6-only backbones any time=20 > soon. =20 Well they do exist because you have not heard of them does not mean they don't exist. =20 Or are you calling us who say this liars? >I believe that this will happen at some point in the=20 > future, but I am not certain (from my own experience or any=20 > direct communication) that this is a widespread need today. =20 > If this won't be needed until later, I think that we should=20 > wait until later to provide it -- when we will know more=20 > about how IPv6 has been deployed. It is needed now as much as any mechanism is needed now. >=20 > However, even if I accept that there is a need for a solution=20 > in this space now, I have some serious reservations about the=20 > DSTM solution as it is currently documented. In particular,=20 > I don't know why we would want to standardize a solution in=20 > this space that includes multiple non-interoperable options=20 > for how a dual-stack host can obtain a temporary IPv4 address=20 > (DHCPv6 and TSP).=20 You should comment on the spec then rather than taking general pot-shots at engineers work in the IETF. And by the way they are interoperable across multiple OSs and platforms and in fact saw them running today in a network lab. Go read the DSTM web page pointer I sent and download the implementations and test it for your self. It works. > Would a client need to implement both to=20 > work on different networks? And how would a client know=20 > which one to use in any particular situation? Would it try=20 > one and then fail over to the other? >=20 > I'm also not sure how/why we need a specific DSTM server at all...=20 > How is DSTM superior to using a DHCPv6 option to get the=20 > configuration information needed to set-up a configured=20 > IPv4-in-IPv6 tunnel and then using DHCPv4 over that tunnel? We should take these questions to specific DSTM thread and I think they are implementation questions not standards questions, but we could debate that on such a thread. Regarding divulging who the users are? I and no one here has to do that and no one has done that other than generically for Teredo, 6to4, or any mechanism. DSTM should not be treated unfairly because you, Pekka, or Thomas are uninformed of this deploymet. So please don't use that argument here its a valuing difference issue and I don't want to have to go there. I will say the users who are wanting DSTM are Military, Security Defense Concerns, and Provider type users and world wide and not in just one geography. I am sure you realize myself or other DSTM team members, and others on this list cannot share with you who exactly they are for confidence reasons. DSTM will be deployed as priority on Moonv6 as transition mechanism and across North American, European, and Asian geogrpahys as Moonv6 is now an International Network Pilot in process for your information. So we are not talking about a little lab in the corner of the world or a mom and pop small business wanting the benefits of DSTM and more importantly moving to dominant IPv6 backbone networks. And a network does not mean just the public Internet.=20 Regards, /jim >=20 > Margaret >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Jun 24 05:23: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 FAA18530 for ; Thu, 24 Jun 2004 05:23:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdQQU-000OWq-4I for v6ops-data@psg.com; Thu, 24 Jun 2004 09:21:46 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdQQF-000OVc-D7 for v6ops@ops.ietf.org; Thu, 24 Jun 2004 09:21:31 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5O9Mx2r067999; Thu, 24 Jun 2004 11:23:00 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <20040623175329.GN17875@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: DSTM Date: Thu, 24 Jun 2004 11:21:30 +0200 To: Margaret Wasserman X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 24-jun-04, at 5:37, Margaret Wasserman wrote: > I am less certain that there is a real need for DSTM today. Good! So we have the chance to be proactive. > I have not personally heard any ISP or Enterprise operators indicate > their intention to run IPv6-only backbones any time soon. Probably because the notion that this could be a viable option hasn't entered the brains of the decision makers yet. If you consider the complexities of building a large IPv4 network, especially if you want to avoid NAT but don't have a lot of address space, versus the simplicity of building a similar network using IPv6, it makes sense that people will want to run an IPv6-only network and tunnel IPv4 over it where needed as soon as the necessary mechanisms (IPv4-in-IPv6 tunneling, IPv6 DNS resolver discovery) are available and all the hardware can handle IPv6 in the fast path. (I had a few conversations with vendors at the summit thing last week and many still do IPv6 in software.) > I'm also not sure how/why we need a specific DSTM server at all... How > is DSTM superior to using a DHCPv6 option to get the configuration > information needed to set-up a configured IPv4-in-IPv6 tunnel and then > using DHCPv4 over that tunnel? I for one am not in favor of making DHCPv6 a dependency. I also have another problem with DSTM as it is: it depends on a single gateway. That's not good. We need redundancy. It might be better to create an IPv4-in-IPv6 tunneling mechanism that treats the IPv6 network as an IPv4 link layer and run standard IPv4 protocols such as ARP and DHCP over that. (Similar to 6over4 but the other way around.) This should work very well in networks that support site-wide multicast. (There are some security issues with rogue DHCPv4 servers but those can be mitigated by filtering broad/multicasts.) However, we may also want to consider the situation where a user is roaming on a standard issue IPv6 network far away, and wants to tunnel back home. There are already various VPN solutions that do this for IPv4 over IPv4, though, so hopefully we don't have to reinvent the wheel here. One remark about the draft: there are some serious line length issues, please fix as this makes some parts very hard to read. From owner-v6ops@ops.ietf.org Thu Jun 24 06:08:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20943 for ; Thu, 24 Jun 2004 06:08:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdR8O-0003l1-Pn for v6ops-data@psg.com; Thu, 24 Jun 2004 10:07:08 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdR8C-0003jc-6m for v6ops@ops.ietf.org; Thu, 24 Jun 2004 10:06:57 +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 i5OA6oV17118; Thu, 24 Jun 2004 12:06:50 +0200 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 i5OA6oSj037758; Thu, 24 Jun 2004 12:06:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241006.i5OA6oSj037758@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: "Bound, Jim" , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: dynamic v4 addresses over v4-in-v6 tunnel [RE: DSTM] In-reply-to: Your message of Wed, 23 Jun 2004 22:06:12 +0300. Date: Thu, 24 Jun 2004 12:06:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > 3. The use of IPv4 addresses for legacy communications should be > temporary IPv4 addresses for a specific time. I'm not sure I personally buy the other requirements, but for the argument's sake.. What kind of requirement is this? How is this different for a site currently deploying v4? => one advantage of DSTM is you no more need to manage an IPv4 infrastructure (no IPv4 routers, etc). And of course all features provided in your IPv6 are inherited. In other words: if we need IPv4-in-IPv6 tunneling, let's discuss that. If we need something more than the existing IPv4 mechanisms for making the v4 addresses used over such tunnels more dynamic (e.g., if DHCPv4 with short leases is not enough), let's discuss that separately as well. But let's not get these two features mixed up, having to sacrifice a baby to get the bathwater :) => the whole is more than the addition of all parts. I have the impression that a lot of people have "IPv6-in-IPv4 == DSTM" => IPv4-over-IPv6 == DSTM ? in their head. I want to break that assumption, as DSTM seems to offer a lot more than that, because specifying a solution without clearly defining its components seems unwise. => I agree. To come back to the real point IMHO this is like to make the same for DHCPv4 itself: DHCPv4 can allocate temporary addresses for a specific time but it can do more (BTW not only DSTM can use the same mechanisms than DHCPv4 but my old implementation of DSTM exactly reuse the code of a well known open source DHCPv4 server :-). Thanks Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Thu Jun 24 06:20:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21615 for ; Thu, 24 Jun 2004 06:19:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdRKK-0004y4-Ma for v6ops-data@psg.com; Thu, 24 Jun 2004 10:19:28 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdRJw-0004wC-Ui for v6ops@ops.ietf.org; Thu, 24 Jun 2004 10:19:05 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5OAKX2r069040 for ; Thu, 24 Jun 2004 12:20:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: <20040623175329.GN17875@login.ecs.soton.ac.uk> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-243479942; protocol="application/pkcs7-signature" Message-Id: From: Iljitsch van Beijnum Subject: Re: DSTM Date: Thu, 24 Jun 2004 12:19:05 +0200 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-5-243479942 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 24-jun-04, at 11:21, Iljitsch van Beijnum wrote: > It might be better to create an IPv4-in-IPv6 tunneling mechanism that > treats the IPv6 network as an IPv4 link layer and run standard IPv4 > protocols such as ARP and DHCP over that. This also has the advantage that hosts within the same site don't have to go through a tunnel server in order to reach eachother. From owner-v6ops@ops.ietf.org Thu Jun 24 06:39:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23368 for ; Thu, 24 Jun 2004 06:39:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdRcd-0006vY-5r for v6ops-data@psg.com; Thu, 24 Jun 2004 10:38:23 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdRcP-0006uJ-4U for v6ops@ops.ietf.org; Thu, 24 Jun 2004 10:38:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5OAdZ2r069373; Thu, 24 Jun 2004 12:39:35 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <951B1D8A-C5CA-11D8-A349-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Dominant IPv6 Network deployment for Transition by Users Date: Thu, 24 Jun 2004 12:38:08 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-jun-04, at 23:09, Pekka Savola wrote: > I think you assume that having to support one dominant protocol (IPv6) > and one less dominant (but still a MUST work protocol, IPv4), through > mechanisms more complex than just deploying IPv4 (or keeping it > deployed) requires a smaller amount of support in total? > This seems dubious to me. There are many cases where IPv4 is quite troublesome. For instance, if you organize an event where lots of ad-hoc users show up, you need a lot of IPv4 address space that's hard to get if you don't already have it. And any time you build a network that has significant growth, you end up with very fragmented address usage, which in turn can make it necessary to have huge broadcast/flooding domains with all the trouble that entails. With IPv6, none of this is an issue, so it's much easier to design a network and then deploy it without having to change much later. Now obviously supporting v4 connectivity over tunnels brings back some of the v4 complexity, but I expect there will still be significant advantages in many deployments. Note though that I wouldn't expect each and every host to have an IPv4 address in such a scenario: hosts that only use simple client/server protocols can either use address translation or proxies. >> 3. It is far easier to control the operation of transition to IPv6 >> once >> IPv6 networks are dominant and IPv4 is treated as legacy. > Do we (and the customers, or at least the majority of them) actually > want to control the operation of transition to IPv6-only at this > point? That's not the point Jim was making. If you want to run both IPv4 and IPv6 there are several ways to do this: run v4 first and add v6 where needed (this is how it's done most of the time today), run them as equals side by side, or build an infrastructure that's optimized for IPv6 and then bring back IPv4 where needed the same way legacy protocols are generally supported. Whether IPv4 is actually legacy or not is pretty much an eye of the beholder thing, what counts is the way you design a network. Building a significant NAT-less IPv4 network is very challenging, much more so than building an equivalent IPv6 network. Then adding back IPv4 through tunneling has the advantage that the address usage is no longer tied to the network topology so it's much easier to meet RIR policy requirements. > I imagine most would want to deploy IPv6 because it brings > them a benefit they want. Simple network design and operation is what many people want. :-) > Until a significant portion of the Internet > has adopted IPv6, an easy strategy could be to postpone the decision > on when to move to IPv6-only. Sure. But note that enterprise users usually talk much more amongst themselves than with the internet at large. The issues are different from ISP networks or home networks, where connectivity to the rest of the world is the most important thing. Also note that this isn't a question of running IPv6-only hosts, the hosts will still be dual stack. It's a question of how to provide dual stack connectivity to a large number of hosts in the way that's most efficient. From owner-v6ops@ops.ietf.org Thu Jun 24 07:58: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 HAA29924 for ; Thu, 24 Jun 2004 07:58:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdSq2-000FGS-OW for v6ops-data@psg.com; Thu, 24 Jun 2004 11:56:18 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdSpn-000FEa-EZ for v6ops@ops.ietf.org; Thu, 24 Jun 2004 11:56:04 +0000 Received: from [24.61.30.237] (account margaret HELO [10.0.0.39]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 93823; Thu, 24 Jun 2004 07:54:03 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CC996@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC996@tayexc13.americas.cpqcorp.net> Date: Thu, 24 Jun 2004 07:52:44 -0400 To: "Bound, Jim" , "Tim Chown" , From: Margaret Wasserman Subject: RE: DSTM Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, I did not mean anything that I said in my previous note as a personal attack on you or anyone else involved in the DSTM work. I think it is possible for well-intentioned, reasonable people to have a difference of opinion, and I think that is the case here. In particular, I think that we have a difference of opinion regarding three things (1) the effect on the market of having multiple solutions/mechanisms to resolve overlapping problems, and (2) the purpose and effect of IETF standardization, and (3) whether DSTM is a solution that should be standardized in the IETF. At 3:24 AM -0400 6/24/04, Bound, Jim wrote: >> This leads to increased complexity, more security issues, >> more points of failure, larger code sizes, higher costs for >> networking infrastructure, etc. > >I don't agree at all. Each mechanism will be used for a solution not >all mechanisms in one network. I don't know of any user that is that >stupid to use 5 mechanisms at once. The point you continue to miss is >that there could be 5 different usrs with 5 different needs for >transition and each of the 5 mechanisms are useful to them each >individually as one tool. Many stack vendors attempt to write generic implementations that will work properly in a wide range of environments. So, even though each network administrator would choose a single mechanism, if there are five different mechanisms in widespread use some vendors will need to implement all five. Since one of the good features of IPv6 is that it requires no client-side IP stack configuration, there shouldn't be a need (and there may be no opportunity) to configure each client to know which transition mechanisms are in use on a given network. So, if there are five (or more) different mechanisms by which a client could obtain an IPv4 or IPv6 connectivity, the client will need to know (1) which mechanisms to try in which order, (2) whether to continue trying new mechanisms when IP (v4 or v6) connectivity has (apparently) been obtained through one of them, and (3) which IP address/connectivity mechanism to use for each communication if it has obtained connectivity via more than one mechanism. >Forcing all users to use only X, Y, and Z is absurd and the market, >implementers, and users will reject that IETF view and will simply >ignore the IETF regarding transition and seek the solutions they need >elsewhere. if that happens we have failed here in the IETF and it will >be recorded as so for sure. I do not believe that the IETF has the power to force anyone to do anything, nor do I think we should try. I think that it is our role to put forth what we think are technically and architecturally sound, useful, interoperable standards that make the Internet work better and promote our shared IETF values like the openness of the Internet, end-to-end security, privacy and end-user empowerment. If people find our standards to be valuable, relevant and trustworthy they will use them. Lots of other groups also develop standards, or de facto standards, for the Internet (the W3C, 3GPP, the IEEE, Microsoft...) and more power to them! >What the IETF cannot do is try to dictate the policy for deployment in >the market at all. I agree, and I don't think that we try to do this. By choosing to standardize one thing and not another, or by publishing documents as Information or BCP RFCs, we do offer our advice to the market regarding what we (the IETF) consider to be sound, useful and interoperable solutions. But, we certainly don't try to dictate what vendors can or cannot implement, nor do we have any means to dictate what users will/will not deploy. >> I have not personally heard any ISP or Enterprise operators >> indicate their intention to run IPv6-only backbones any time >> soon. > >Well they do exist because you have not heard of them does not mean they >don't exist. > >Or are you calling us who say this liars? Jim, I did not mean to imply that the people you have talked to do not exist! And, I don't think that you are a liar. I merely said that I can't assess the needs of users that I don't know in scenarios that have not been described to me in detail. I have not (personally) talked to someone who has told me that they are deploying a large IPv6-only network. >> However, even if I accept that there is a need for a solution >> in this space now, I have some serious reservations about the >> DSTM solution as it is currently documented. In particular, >> I don't know why we would want to standardize a solution in >> this space that includes multiple non-interoperable options >> for how a dual-stack host can obtain a temporary IPv4 address >> (DHCPv6 and TSP). > >You should comment on the spec then rather than taking general pot-shots >at engineers work in the IETF. I believe that the paragraph above is a comment on the spec... The specification for DSTM includes two separate mechanisms to obtain an IPv4 address -- DHCPv6 and TSP. There doesn't seem to be a mandatory-to-implement mechanism on either end, and the two mechanisms are not interoperable with each other. So, it is quite possible to build a TSP-only DSTM client and a DHCPv6-only DSTM server (or vice versa) that are both fully compliant with the DSTM spec but which will not interoperate with each other. So, for example, if a vendor wants to write a client implementation that can work in both types of DSTM environment, it will need to include client support for both flavors of DSTM. How will it know which one to try first? Should it try both, even if the first one seems to work? If they both work and provide different configuration information, which information should the node use? If it uses both sets of information, how will it decide which connectivity path to use for each communication? Even if you were to remove one of the mechanisms from the DSTM draft, it won't resolve the larger issue that we're creating regarding how an IPv6 host comes up on the network and how it chooses between the multiple methods of IPv6 connectivity and address configuration that may be available. >> I'm also not sure how/why we need a specific DSTM server at all... >> How is DSTM superior to using a DHCPv6 option to get the >> configuration information needed to set-up a configured >> IPv4-in-IPv6 tunnel and then using DHCPv4 over that tunnel? > >We should take these questions to specific DSTM thread and I think they >are implementation questions not standards questions, but we could >debate that on such a thread. Since the subject of this thread is "Re: DSTM", I am not sure that it can get more DSTM-specific than that! :-) >DSTM will be deployed as priority on Moonv6 as transition mechanism and >across North American, European, and Asian geogrpahys as Moonv6 is now >an International Network Pilot in process for your information. So we >are not talking about a little lab in the corner of the world or a mom >and pop small business wanting the benefits of DSTM and more importantly >moving to dominant IPv6 backbone networks. And a network does not mean >just the public Internet. I am very happy for you and for others that have worked so hard on DSTM that people are using it. It isn't necessarily the case, though, that the IETF should standardize everything that people choose to use. Nor, is it the case that people should only use things that are standardized in the IETF. Please note that I don't consider it my decision (alone) whether DSTM is or is not standardized by the IETF. It is my personal opinion that we should not standardize DSTM (at least as currently documented) because of the technical/deployment issues that I have stated above and in my earlier message. However, it is quite possible that the consensus of the v6ops WG will not agree with me. Before we can fruitfully make that decision, though, we need to document the expected deployment scenarios in an enterprise scenario document, and we need to reach WG consensus on that document. Then we can talk about whether DSTM applies to one or more of the expected scenarios and whether it is the best solution, technically and architecturally, to address any of those scenarios. Margaret From owner-v6ops@ops.ietf.org Thu Jun 24 08:47:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06468 for ; Thu, 24 Jun 2004 08:47:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdTcJ-000LDt-U7 for v6ops-data@psg.com; Thu, 24 Jun 2004 12:46:11 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdTc8-000LC8-RP for v6ops@ops.ietf.org; Thu, 24 Jun 2004 12:46:01 +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 i5OCjmB05103; Thu, 24 Jun 2004 14:45:48 +0200 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 i5OCjmSj038414; Thu, 24 Jun 2004 14:45:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241245.i5OCjmSj038414@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Iljitsch van Beijnum cc: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: DSTM In-reply-to: Your message of Thu, 24 Jun 2004 11:21:30 +0200. Date: Thu, 24 Jun 2004 14:45:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: It might be better to create an IPv4-in-IPv6 tunneling mechanism that treats the IPv6 network as an IPv4 link layer and run standard IPv4 protocols such as ARP and DHCP over that. (Similar to 6over4 but the other way around.) => "4over6" won't solve the same kind of problems, for instance it couldn't help to communicate with an old IPv4-only-for-ever printer. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Thu Jun 24 09:16: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 JAA09712 for ; Thu, 24 Jun 2004 09:16:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdU3J-000PQW-O8 for v6ops-data@psg.com; Thu, 24 Jun 2004 13:14:05 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdU1q-000PAQ-CU for v6ops@ops.ietf.org; Thu, 24 Jun 2004 13:12:34 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5ODDI2r072050; Thu, 24 Jun 2004 15:13:18 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200406241245.i5OCjmSj038414@givry.rennes.enst-bretagne.fr> References: <200406241245.i5OCjmSj038414@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0EBF304A-C5E0-11D8-A349-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: DSTM Date: Thu, 24 Jun 2004 15:11:51 +0200 To: Francis Dupont X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 24-jun-04, at 14:45, Francis Dupont wrote: >> It might be better to create an IPv4-in-IPv6 tunneling mechanism >> that >> treats the IPv6 network as an IPv4 link layer and run standard IPv4 >> protocols such as ARP and DHCP over that. (Similar to 6over4 but >> the >> other way around.) > => "4over6" won't solve the same kind of problems, for instance > it couldn't help to communicate with an old IPv4-only-for-ever printer. So how does DSTM solve this? I was assuming there would be a v4-over-tunnel cloud and a native v4 cloud, and obviously some kind of connection between both clouds. In DSTM there is a single place where this happens: the gateway where the tunnels terminate. "4over6" could be more flexible as packets don't necessarily flow through a single gateway. We may even provide for some kind of "proxy 4over6" tunneling so that IPv4-only hosts in otherwise IPv6-only networks may enjoy connectivity. From owner-v6ops@ops.ietf.org Thu Jun 24 10:05:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14343 for ; Thu, 24 Jun 2004 10:05:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdUpS-0005EG-34 for v6ops-data@psg.com; Thu, 24 Jun 2004 14:03:50 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdUp7-0005Bb-4T for v6ops@ops.ietf.org; Thu, 24 Jun 2004 14:03:29 +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 i5OE2tT17061; Thu, 24 Jun 2004 16:03:00 +0200 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 i5OE2iSj038778; Thu, 24 Jun 2004 16:02:44 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241402.i5OE2iSj038778@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Iljitsch van Beijnum cc: v6ops@ops.ietf.org Subject: Re: DSTM In-reply-to: Your message of Thu, 24 Jun 2004 15:11:51 +0200. <0EBF304A-C5E0-11D8-A349-000A95CD987A@muada.com> Date: Thu, 24 Jun 2004 16:02:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => "4over6" won't solve the same kind of problems, for instance > it couldn't help to communicate with an old IPv4-only-for-ever printer. So how does DSTM solve this? => yes, your remark that 4over6 is more oriented to direct communication between dual-stack nodes is in the same kind of ideas... I was assuming there would be a v4-over-tunnel cloud and a native v4 cloud, and obviously some kind of connection between both clouds. => in DSTM there is no need to add this kind of gateways between the two clouds, i.e., it is built in. In DSTM there is a single place where this happens: the gateway where the tunnels terminate. => there is no requirement to have only one gateway. In fact the only constraint is when the gateway gets automatically the IPv6/IPv4 address mapping packets from the legacy IPv4 world come back through the same gateway. "4over6" could be more flexible as packets don't necessarily flow through a single gateway. We may even provide for some kind of "proxy 4over6" tunneling so that IPv4-only hosts in otherwise IPv6-only networks may enjoy connectivity. => I really liked 6over4 so I should like 4over6 too but I am afraid the arguments against 6over4 apply too to 4over6. And the DSTM space was already explored: there is nothing that 4over6 can do and DSTM can't. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Thu Jun 24 10:11: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 KAA15236 for ; Thu, 24 Jun 2004 10:11:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdUvr-0006Dn-3J for v6ops-data@psg.com; Thu, 24 Jun 2004 14:10:27 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdUve-0006B2-5R for v6ops@ops.ietf.org; Thu, 24 Jun 2004 14:10:14 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id ADA7D6158; Thu, 24 Jun 2004 10:03:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 10:03:39 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: DSTM Date: Thu, 24 Jun 2004 10:03:36 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC9B2@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRZ7XewTMrNlUkwSaeQ95spLtWzYQABWrWg From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Francis Dupont" Cc: X-OriginalArrivalTime: 24 Jun 2004 14:03:39.0493 (UTC) FILETIME=[0CCDE950:01C459F4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > In DSTM there is a single place where this happens: the=20 > gateway where the tunnels terminate. "4over6" could be more=20 > flexible as packets don't necessarily flow through a single=20 > gateway. We may even provide for some kind of "proxy 4over6"=20 > tunneling so that IPv4-only hosts in otherwise IPv6-only=20 > networks may enjoy connectivity. Multiple TEPs can be provided to the client for redundancy and router failover deploying dual rail routers supports the mission critical case, and if the link is cut or blown up there is custom software to inform clients of that etc. I see your point it is worth discussion and we need to say something about this in our next draft. Thanks Note I believe your concern applys to all transition mechanisms and do we need to put this health warning on all transition mechanisms and in our scenarios as we do security? Again is this just picking on DSTM or should the question be applied to all mechanisms (not mean't as negative question just a question)? As a question of fair and open process? I don't think we can solve this problem in specs but implementation will resolve it is my view today but listening to the list. In DSTM it is assumed that an IPv4 address from the DNS returned which begins the DSTM client the TSP or DHCPv6 or RPC to the server will match correct TEP and CIDR or IPv4 high order bits of address for network route. Regards, /jim From owner-v6ops@ops.ietf.org Thu Jun 24 10:46: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 KAA18832 for ; Thu, 24 Jun 2004 10:46:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdVTX-000B0A-3M for v6ops-data@psg.com; Thu, 24 Jun 2004 14:45:15 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdVS0-000Ani-Qc for v6ops@ops.ietf.org; Thu, 24 Jun 2004 14:43:41 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 64340B8EF; Thu, 24 Jun 2004 10:43:40 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 10:43:40 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: DSTM Date: Thu, 24 Jun 2004 10:43:36 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CC9C2@tayexc13.americas.cpqcorp.net> Thread-Topic: DSTM Thread-Index: AcRZ4jvfswU3lLmyTb2TOKTdt9qJYQAEdL5w From: "Bound, Jim" To: "Margaret Wasserman" , "Tim Chown" , X-OriginalArrivalTime: 24 Jun 2004 14:43:40.0103 (UTC) FILETIME=[A3ADED70:01C459F9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Margaret,=20 > I did not mean anything that I said in my previous note as a=20 > personal attack on you or anyone else involved in the DSTM=20 > work. I think it is possible for well-intentioned,=20 > reasonable people to have a difference of opinion, and I=20 > think that is the case here. OK. I will accept that and move on. Thanks. >=20 > In particular, I think that we have a difference of opinion=20 > regarding three things=20 >(1) the effect on the market of having=20 > multiple solutions/mechanisms to resolve overlapping=20 > problems,=20 Clearly this is the case completely for difference. But how does that influence the IETF actual work. I don't think it does just us as thinking individuals. Probably good to separate deployment evolution from solutions to be specified. All here may not want to hear this or are we now in a technology area of discussion where we has technology persons must discuss this aspect of IPv6? >and (2) the purpose and effect of IETF=20 > standardization,=20 The IETF specifies standards that is all. It is not a consulting body for deployment to the market (individuals in the IETF may be connsultants for sure). People who spend 90% of their day job on IETF mail lists and debating architecture often do it to long and begin to think they have a larger mission to inflate their ego, justify their time here, and their importance in the scheme of things. The IPv6 Forum and NAv6TF are in fact this for IPv6 and do it full time and full time focus, and you have seen that input to private enterprise and governments and they do affect deployment. IETF is a place to build the specs. Implementation verification are the trials with real running code ergo like Moonv6, 6NET, CNGI, et al. all running IPv6 and the IPv6 Forum Logo certification. =20 >and (3) whether DSTM is a solution that=20 > should be standardized in the IETF. I think standardized is too a broad term. Should it be experimental, informational, or standards track. IETF provides venue for all three. >=20 > At 3:24 AM -0400 6/24/04, Bound, Jim wrote: > >> This leads to increased complexity, more security issues, more=20 > >> points of failure, larger code sizes, higher costs for networking=20 > >> infrastructure, etc. > > > >I don't agree at all. Each mechanism will be used for a=20 > solution not=20 > >all mechanisms in one network. I don't know of any user=20 > that is that=20 > >stupid to use 5 mechanisms at once. The point you continue=20 > to miss is=20 > >that there could be 5 different usrs with 5 different needs for=20 > >transition and each of the 5 mechanisms are useful to them each=20 > >individually as one tool. >=20 > Many stack vendors attempt to write generic implementations=20 > that will work properly in a wide range of environments. So,=20 > even though each network administrator would choose a single=20 > mechanism, if there are five different mechanisms in=20 > widespread use some vendors will need to implement all five. I don't believe most vendors will at all but that again is another point to add to difference. It is none of my business or in the IETF regarding the systems view of implementation and out of scope for defining a spec. It is clearly possible for an implementation to implement all five or whatever the number is to be. What will prevent this is cost in engineering and IT box vendors and ISVs selecting markets and strategy, not IETF deliberations. If hardware or softwarwe messes up a user it will die in the market. This is not within our scope at all. =20 > Since one of the good features of IPv6 is that it requires no=20 > client-side IP stack configuration,=20 The above is incomplete I believe. It requires no server in stateless is more accurate the stack is still configured at boot. >there shouldn't be a need=20 > (and there may be no opportunity) to configure each client to=20 > know which transition mechanisms are in use on a given=20 > network. That is one model but all models do not have to support this. And all our mechanisms require this and esp. where tunnels are required to be set up from user space to kernel space in the network subsystem. > So, if there are five (or more) different mechanisms=20 > by which a client could obtain an IPv4 or IPv6 connectivity,=20 > the client will need to know (1) which mechanisms to try in=20 > which order, (2) whether to continue trying new mechanisms=20 > when IP (v4 or v6) connectivity has > (apparently) been obtained through one of them, and (3) which=20 > IP address/connectivity mechanism to use for each=20 > communication if it has obtained connectivity via more than=20 > one mechanism. None of this is required we will implement policy knobs for the user to select and as I said they will not select all of them and 99% of the time only one of them. This is like saying I can't support TCP, UDP, SCTP, and all the loadable modules available to a user at boot config because there are to many. That is simply not valid and we all do this today very well thank you :--) >=20 > >Forcing all users to use only X, Y, and Z is absurd and the market,=20 > >implementers, and users will reject that IETF view and will simply=20 > >ignore the IETF regarding transition and seek the solutions=20 > they need=20 > >elsewhere. if that happens we have failed here in the IETF=20 > and it will=20 > >be recorded as so for sure. >=20 > I do not believe that the IETF has the power to force anyone=20 > to do anything, nor do I think we should try. Good. Tell Pekka :--) >=20 > I think that it is our role to put forth what we think are=20 > technically and architecturally sound, useful, interoperable=20 > standards that make the Internet work better and promote our=20 > shared IETF values like the openness of the Internet,=20 > end-to-end security, privacy and end-user empowerment. If=20 > people find our standards to be valuable, relevant and=20 > trustworthy they will use them. Agree. >=20 > Lots of other groups also develop standards, or de facto=20 > standards, for the Internet (the W3C, 3GPP, the IEEE,=20 > Microsoft...) and more power to them! Add Ipv6 Forum to that list and for transition if things don't work out here in the IETF for transition all the vendors are sick of the game here in v6ops and we are having to ship mechanisms and can no longer wait on the IETF if it don't figure it out. This has been stated publicly and the market has said fine if that is what must be done. I would rather see it work out in the IETF quite frankly or I fear a Internet Standars schism could happen and that will make all of our work more difficult. >=20 > >What the IETF cannot do is try to dictate the policy for=20 > deployment in=20 > >the market at all. >=20 > I agree, and I don't think that we try to do this. By=20 > choosing to standardize one thing and not another, or by=20 > publishing documents as Information or BCP RFCs, we do offer=20 > our advice to the market regarding what we (the IETF)=20 > consider to be sound, useful and interoperable solutions. Change solutions to specifications. IETF does not work on solutions. =20 > But, we certainly don't try to dictate what vendors can or=20 > cannot implement, nor do we have any means to dictate what=20 > users will/will not deploy. That is correct and I agree. >=20 > >> I have not personally heard any ISP or Enterprise operators =20 > >> indicate their intention to run IPv6-only backbones any time soon. > > > >Well they do exist because you have not heard of them does not mean=20 > >they don't exist. > > > >Or are you calling us who say this liars? >=20 > Jim, I did not mean to imply that the people you have talked=20 > to do not exist! And, I don't think that you are a liar. Good. >=20 > I merely said that I can't assess the needs of users that I=20 > don't know in scenarios that have not been described to me in=20 > detail. I have not (personally) talked to someone who has=20 > told me that they are deploying a large IPv6-only network. Once we wrap up the Enterprise Scenarios we will position DSTM across all of them to apply or not apply being UMAN, 3GPP, ISP, and Enterprise. Already started that discussion in DSTM community. As one individual I do not believe it applies to UMAN but clearly does to 3GPP, ISP, and Enterprise scenarios. >=20 > >> However, even if I accept that there is a need for a solution in=20 > >> this space now, I have some serious reservations about the DSTM=20 > >> solution as it is currently documented. In particular, I=20 > don't know=20 > >> why we would want to standardize a solution in this space that=20 > >> includes multiple non-interoperable options for how a dual-stack=20 > >> host can obtain a temporary IPv4 address > >> (DHCPv6 and TSP). > > > >You should comment on the spec then rather than taking general=20 > >pot-shots at engineers work in the IETF. >=20 > I believe that the paragraph above is a comment on the spec... Again a user on the same network is not going to use DHCPv6 and TSP for providing the addresses that is just stupid.=20 Its like PKI for IPsec. There will be multiple PKI servers for IPsec and users will deploy one of them for their networks with client daemon interfaces to PKI then to IKE and then to IPsec. This is simply reality. >=20 > The specification for DSTM includes two separate mechanisms=20 > to obtain an IPv4 address -- DHCPv6 and TSP. There doesn't=20 > seem to be a mandatory-to-implement mechanism on either end,=20 > and the two mechanisms are not interoperable with each other.=20 > So, it is quite possible to build a TSP-only DSTM client and=20 > a DHCPv6-only DSTM server (or vice versa) that are both fully=20 > compliant with the DSTM spec but which will not interoperate=20 > with each other. They do not have to interoperate with each other anymore than a PKI client will for IPsec. But this is a valid discussion for DSTM I agree. >=20 > So, for example, if a vendor wants to write a client=20 > implementation that can work in both types of DSTM=20 > environment, it will need to include client support for both=20 > flavors of DSTM. That is true. > How will it know which one to try first? =20 By the user selecting it as they do any layered network software product on a platform. > Should it try both, even if the first one seems to work? If=20 > they both work and provide different configuration=20 > information, which information should the node use? If it=20 > uses both sets of information, how will it decide which=20 > connectivity path to use for each communication? It will never use both and we will add that to the spec as a requirement and we should have already. >=20 > Even if you were to remove one of the mechanisms from the=20 > DSTM draft, it won't resolve the larger issue that we're=20 > creating regarding how an IPv6 host comes up on the network=20 > and how it chooses between the multiple methods of IPv6=20 > connectivity and address configuration that may be available. Your applying user daemons to stateless and that is never going to happen for a long time. But only permitting one at a time on a network removes the problem. The objective is to provide the user a choice and I am always for lots of choices and for networking. I also am an engineer and architect and know that can work in implementation and operationally for deployment. >=20 > >> I'm also not sure how/why we need a specific DSTM server at all... > >> How is DSTM superior to using a DHCPv6 option to get the =20 > >> configuration information needed to set-up a configured > >> IPv4-in-IPv6 tunnel and then using DHCPv4 over that tunnel? > > > >We should take these questions to specific DSTM thread and I=20 > think they=20 > >are implementation questions not standards questions, but we could=20 > >debate that on such a thread. >=20 > Since the subject of this thread is "Re: DSTM", I am not sure=20 > that it can get more DSTM-specific than that! :-) Fair. We really should not be going this far but it is useful discussion. >=20 > >DSTM will be deployed as priority on Moonv6 as transition=20 > mechanism and=20 > >across North American, European, and Asian geogrpahys as=20 > Moonv6 is now=20 > >an International Network Pilot in process for your=20 > information. So we=20 > >are not talking about a little lab in the corner of the=20 > world or a mom=20 > >and pop small business wanting the benefits of DSTM and more=20 > >importantly moving to dominant IPv6 backbone networks. And a network=20 > >does not mean just the public Internet. >=20 > I am very happy for you and for others that have worked so=20 > hard on DSTM that people are using it. >=20 > It isn't necessarily the case, though, that the IETF should=20 > standardize everything that people choose to use. Nor, is it=20 > the case that people should only use things that are=20 > standardized in the IETF. Well this gets political. But I agree. >=20 > Please note that I don't consider it my decision (alone)=20 > whether DSTM is or is not standardized by the IETF. It is my=20 > personal opinion that we should not standardize DSTM (at=20 > least as currently > documented) because of the technical/deployment issues that I=20 > have stated above and in my earlier message. However, it is=20 > quite possible that the consensus of the v6ops WG will not=20 > agree with me. Thanks for saying this and that is good to hear as your an IESG member and it demonstrates your leadership views. I wish more IESG members and one of our Chairs for v6ops would make such statements periodically to reinforce this to the WG. Not all are as persistent as some of us and may back off becuase of title in the IETF. That is not cool. Esp. new people to the IETF could get the wrong impression. >=20 > Before we can fruitfully make that decision, though, we need=20 > to document the expected deployment scenarios in an=20 > enterprise scenario document, and we need to reach WG=20 > consensus on that document. Then we can talk about whether=20 > DSTM applies to one or more of the expected scenarios and=20 > whether it is the best solution, technically and=20 > architecturally, to address any of those scenarios. 100% agree. The question of this is on the WG table as question and how we proceed now and the fairness issue. Regards, /jim >=20 > Margaret >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Jun 24 10:47: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 KAA18948 for ; Thu, 24 Jun 2004 10:47:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdVVg-000BBQ-Hq for v6ops-data@psg.com; Thu, 24 Jun 2004 14:47:28 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdVVM-000BA1-Nj for v6ops@ops.ietf.org; Thu, 24 Jun 2004 14:47:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5OEmV2r073894; Thu, 24 Jun 2004 16:48:31 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CC9B2@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC9B2@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5C5398EE-C5ED-11D8-A349-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: DSTM Date: Thu, 24 Jun 2004 16:47:05 +0200 To: "Bound, Jim" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 24-jun-04, at 16:03, Bound, Jim wrote: > Multiple TEPs can be provided to the client for redundancy and router > failover deploying dual rail routers supports the mission critical > case, > and if the link is cut or blown up there is custom software to inform > clients of that etc. This sounds awfully complex to me... I'd rather take advantage of existing redundancy features such as VRRP. > Note I believe your concern applys to all transition mechanisms and do > we need to put this health warning on all transition mechanisms and in > our scenarios as we do security? We are engineers; we build reliable networks from unreliable parts. So much goes without saying, or at least without saying it over and over untill we're all sick of hearing it... :-) With security, every little thing must be secure. With redundancy, it's acceptable to have unreliable parts as long as you have several of them and switching from one to the other isn't too fatal. So I think those two issues are in different categories. I'm not very comfortable with the phrase "all transition mechanisms" as most of the transition mechanisms that were created at one time or another turned out to be fairly useless ("automatich tunneling", 6over4, isatap). There is some risk that this will happen again now that we're looking at the other side of the coin (tunneling 6 over 4) unless we're very careful. > Again is this just picking on DSTM or > should the question be applied to all mechanisms (not mean't as > negative > question just a question)? As a question of fair and open process? I guess it depends. If there is stuff that's clearly useful and maybe even deployed, but there is no good way to add redundancy, so be it. On the other hand, if we have the choice between solving a problem in a way that allows for redundancy and in a way that doesn't, then it makes sense to go with the redundancy-friendly way. With regard to DSTM: I applaud the goal, but I'm doubtful if the way to get there is the optimal one, for the reasons listed earlier, and also because having some special purpose software handling all kinds of details isn't very attractive (to me at least), as opposed to having a more generic encapsulation mechanism over which we can run a variety of existing mechanisms such as ARP, DHCP and VRRP. But I understand you guys already have code. I guess the best way forward would be to deploy this code and see how well it behaves in the real world. If it turns out it works very well, we should probably standardize it, even if there are theoretical flaws. On the other hand, if the issues I pointed out and/or others turn out to be of concern in practice, we may want to start from scratch at some point in the future, heeding the lessons learned. > In DSTM it is assumed that an IPv4 address from the DNS returned which > begins the DSTM client the TSP or DHCPv6 or RPC to the server will > match > correct TEP and CIDR or IPv4 high order bits of address for network > route. ??? I don't understand. If I connect to more than one IPv4 destination, do I talk to more than one tunnel endpoint? That doesn't make sense. From owner-v6ops@ops.ietf.org Thu Jun 24 10:58:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19602 for ; Thu, 24 Jun 2004 10:58:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdVfR-000Cea-RF for v6ops-data@psg.com; Thu, 24 Jun 2004 14:57:33 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdVco-000CC4-V6 for v6ops@ops.ietf.org; Thu, 24 Jun 2004 14:54:51 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i5OEsonE021701 for ; Thu, 24 Jun 2004 15:54:50 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA22445 for ; Thu, 24 Jun 2004 15:54:47 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i5OEslk20966 for v6ops@ops.ietf.org; Thu, 24 Jun 2004 15:54:47 +0100 Date: Thu, 24 Jun 2004 15:54:47 +0100 From: Tim Chown To: "" Subject: Re: DSTM Message-ID: <20040624145447.GF18044@login.ecs.soton.ac.uk> Mail-Followup-To: "" References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC9B2@tayexc13.americas.cpqcorp.net> <5C5398EE-C5ED-11D8-A349-000A95CD987A@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C5398EE-C5ED-11D8-A349-000A95CD987A@muada.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Jun 24, 2004 at 04:47:05PM +0200, Iljitsch van Beijnum wrote: > > I'm not very comfortable with the phrase "all transition mechanisms" as > most of the transition mechanisms that were created at one time or > another turned out to be fairly useless ("automatich tunneling", > 6over4, isatap). I'm not sure I agree with that sentiment for ISATAP (though I have not found a use for it in my own deployment environment). Tim From owner-v6ops@ops.ietf.org Thu Jun 24 11:09:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20259 for ; Thu, 24 Jun 2004 11:09:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdVqJ-000EOi-L6 for v6ops-data@psg.com; Thu, 24 Jun 2004 15:08:47 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdVpR-000ECg-GD for v6ops@ops.ietf.org; Thu, 24 Jun 2004 15:07:53 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5OF7mWR012220 for ; Thu, 24 Jun 2004 17:07:52 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 17:07:53 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MFZ5LNSL; Thu, 24 Jun 2004 17:07:48 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jun 2004 17:07:48 +0200 Message-ID: X-Sybari-Trust: 3fcc5e18 100f6658 4c164cb9 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Tim Chown'" , "" Subject: RE: DSTM Date: Thu, 24 Jun 2004 17:07:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Jun 2004 15:07:53.0775 (UTC) FILETIME=[0622ABF0:01C459FD] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Agree. There is a strong usecase for Isatap in the 3GPP environment. Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Tim Chown > Sent: Thursday, June 24, 2004 4:55 PM > To: > Subject: Re: DSTM > > > On Thu, Jun 24, 2004 at 04:47:05PM +0200, Iljitsch van Beijnum wrote: > > > > I'm not very comfortable with the phrase "all transition > mechanisms" as > > most of the transition mechanisms that were created at one time or > > another turned out to be fairly useless ("automatich tunneling", > > 6over4, isatap). > > I'm not sure I agree with that sentiment for ISATAP (though I have not > found a use for it in my own deployment environment). > > Tim > From owner-v6ops@ops.ietf.org Thu Jun 24 11:27:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21392 for ; Thu, 24 Jun 2004 11:27:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdW7u-000Gmy-04 for v6ops-data@psg.com; Thu, 24 Jun 2004 15:26:58 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdW6u-000Gek-VY for v6ops@ops.ietf.org; Thu, 24 Jun 2004 15:25:57 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.1.R) with ESMTP id md50000068719.msg for ; Thu, 24 Jun 2004 17:27:46 +0200 Message-ID: <222301c459ff$74673570$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC996@tayexc13.americas.cpqcorp.net> Subject: Re: DSTM Date: Thu, 24 Jun 2004 17:25:14 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 24 Jun 2004 17:27:46 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 138.4.0.34 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Thu, 24 Jun 2004 17:27:50 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Margaret, all, Regarding your comment on the different mechanisms selection, please see http://www.watersprings.org/pub/id/draft-palet-v6ops-auto-trans-00.txt (and provide inputs !). By the way this document has disappeared from the RFC editor, not sure why ! (someone can provide some hint or what to do about it ?). Regarding this thread in general, I've customers asking for only IPv6 deployment. If this is a solution I buy it ;-) I must recognize I've not played myself with DSTM, but it seems so, and clearly a fair decision needs to be taken with any transition mechanism if is the available solution for any identified scenario. We can't rely in only a few 100% perfect mechanisms, or it will be too late. Similarly we can't rely in just 3, 4 or 5 mechanisms if they don't cover all the identified scenarios. I agree that as less mechanism we have, as better, but it seems that the 4 already identified are not enough ? Then what we are waiting for ? Deploying non-standard mechanisms ? No thanks, if we can avoid it. I asked this in the last meetings ... What the rest believe ? Regards, Jordi ----- Original Message -----=20 From: "Margaret Wasserman" To: "Bound, Jim" ; "Tim Chown" ; Sent: Thursday, June 24, 2004 1:52 PM Subject: RE: DSTM >=20 > Hi Jim, >=20 > I did not mean anything that I said in my previous note as a personal=20 > attack on you or anyone else involved in the DSTM work. I think it=20 > is possible for well-intentioned, reasonable people to have a=20 > difference of opinion, and I think that is the case here. >=20 > In particular, I think that we have a difference of opinion regarding=20 > three things (1) the effect on the market of having multiple=20 > solutions/mechanisms to resolve overlapping problems, and (2) the=20 > purpose and effect of IETF standardization, and (3) whether DSTM is a=20 > solution that should be standardized in the IETF. >=20 > At 3:24 AM -0400 6/24/04, Bound, Jim wrote: > >> This leads to increased complexity, more security issues, > >> more points of failure, larger code sizes, higher costs for > >> networking infrastructure, etc. > > > >I don't agree at all. Each mechanism will be used for a solution not > >all mechanisms in one network. I don't know of any user that is that > >stupid to use 5 mechanisms at once. The point you continue to miss is > >that there could be 5 different usrs with 5 different needs for > >transition and each of the 5 mechanisms are useful to them each > >individually as one tool. >=20 > Many stack vendors attempt to write generic implementations that will=20 > work properly in a wide range of environments. So, even though each=20 > network administrator would choose a single mechanism, if there are=20 > five different mechanisms in widespread use some vendors will need to=20 > implement all five. Since one of the good features of IPv6 is that=20 > it requires no client-side IP stack configuration, there shouldn't be=20 > a need (and there may be no opportunity) to configure each client to=20 > know which transition mechanisms are in use on a given network. So,=20 > if there are five (or more) different mechanisms by which a client=20 > could obtain an IPv4 or IPv6 connectivity, the client will need to=20 > know (1) which mechanisms to try in which order, (2) whether to=20 > continue trying new mechanisms when IP (v4 or v6) connectivity has=20 > (apparently) been obtained through one of them, and (3) which IP=20 > address/connectivity mechanism to use for each communication if it=20 > has obtained connectivity via more than one mechanism. >=20 > >Forcing all users to use only X, Y, and Z is absurd and the market, > >implementers, and users will reject that IETF view and will simply > >ignore the IETF regarding transition and seek the solutions they need > >elsewhere. if that happens we have failed here in the IETF and it will > >be recorded as so for sure. >=20 > I do not believe that the IETF has the power to force anyone to do=20 > anything, nor do I think we should try. >=20 > I think that it is our role to put forth what we think are=20 > technically and architecturally sound, useful, interoperable=20 > standards that make the Internet work better and promote our shared=20 > IETF values like the openness of the Internet, end-to-end security,=20 > privacy and end-user empowerment. If people find our standards to be=20 > valuable, relevant and trustworthy they will use them. >=20 > Lots of other groups also develop standards, or de facto standards,=20 > for the Internet (the W3C, 3GPP, the IEEE, Microsoft...) and more=20 > power to them! >=20 > >What the IETF cannot do is try to dictate the policy for deployment in > >the market at all. >=20 > I agree, and I don't think that we try to do this. By choosing to=20 > standardize one thing and not another, or by publishing documents as=20 > Information or BCP RFCs, we do offer our advice to the market=20 > regarding what we (the IETF) consider to be sound, useful and=20 > interoperable solutions. But, we certainly don't try to dictate what=20 > vendors can or cannot implement, nor do we have any means to dictate=20 > what users will/will not deploy. >=20 > >> I have not personally heard any ISP or Enterprise operators > >> indicate their intention to run IPv6-only backbones any time > >> soon. > > > >Well they do exist because you have not heard of them does not mean they > >don't exist. > > > >Or are you calling us who say this liars? >=20 > Jim, I did not mean to imply that the people you have talked to do=20 > not exist! And, I don't think that you are a liar. >=20 > I merely said that I can't assess the needs of users that I don't=20 > know in scenarios that have not been described to me in detail. I=20 > have not (personally) talked to someone who has told me that they are=20 > deploying a large IPv6-only network. >=20 > >> However, even if I accept that there is a need for a solution > >> in this space now, I have some serious reservations about the > >> DSTM solution as it is currently documented. In particular, > >> I don't know why we would want to standardize a solution in > >> this space that includes multiple non-interoperable options > >> for how a dual-stack host can obtain a temporary IPv4 address > >> (DHCPv6 and TSP). > > > >You should comment on the spec then rather than taking general pot-shots > >at engineers work in the IETF. >=20 > I believe that the paragraph above is a comment on the spec... >=20 > The specification for DSTM includes two separate mechanisms to obtain=20 > an IPv4 address -- DHCPv6 and TSP. There doesn't seem to be a=20 > mandatory-to-implement mechanism on either end, and the two=20 > mechanisms are not interoperable with each other. So, it is quite=20 > possible to build a TSP-only DSTM client and a DHCPv6-only DSTM=20 > server (or vice versa) that are both fully compliant with the DSTM=20 > spec but which will not interoperate with each other. >=20 > So, for example, if a vendor wants to write a client implementation=20 > that can work in both types of DSTM environment, it will need to=20 > include client support for both flavors of DSTM. How will it know=20 > which one to try first? Should it try both, even if the first one=20 > seems to work? If they both work and provide different configuration=20 > information, which information should the node use? If it uses both=20 > sets of information, how will it decide which connectivity path to=20 > use for each communication? >=20 > Even if you were to remove one of the mechanisms from the DSTM draft,=20 > it won't resolve the larger issue that we're creating regarding how=20 > an IPv6 host comes up on the network and how it chooses between the=20 > multiple methods of IPv6 connectivity and address configuration that=20 > may be available. >=20 > >> I'm also not sure how/why we need a specific DSTM server at all... > >> How is DSTM superior to using a DHCPv6 option to get the > >> configuration information needed to set-up a configured > >> IPv4-in-IPv6 tunnel and then using DHCPv4 over that tunnel? > > > >We should take these questions to specific DSTM thread and I think they > >are implementation questions not standards questions, but we could > >debate that on such a thread. >=20 > Since the subject of this thread is "Re: DSTM", I am not sure that it=20 > can get more DSTM-specific than that! :-) >=20 > >DSTM will be deployed as priority on Moonv6 as transition mechanism and > >across North American, European, and Asian geogrpahys as Moonv6 is now > >an International Network Pilot in process for your information. So we > >are not talking about a little lab in the corner of the world or a mom > >and pop small business wanting the benefits of DSTM and more importantly > >moving to dominant IPv6 backbone networks. And a network does not mean > >just the public Internet. >=20 > I am very happy for you and for others that have worked so hard on=20 > DSTM that people are using it. >=20 > It isn't necessarily the case, though, that the IETF should=20 > standardize everything that people choose to use. Nor, is it the=20 > case that people should only use things that are standardized in the=20 > IETF. >=20 > Please note that I don't consider it my decision (alone) whether DSTM=20 > is or is not standardized by the IETF. It is my personal opinion=20 > that we should not standardize DSTM (at least as currently=20 > documented) because of the technical/deployment issues that I have=20 > stated above and in my earlier message. However, it is quite=20 > possible that the consensus of the v6ops WG will not agree with me. >=20 > Before we can fruitfully make that decision, though, we need to=20 > document the expected deployment scenarios in an enterprise scenario=20 > document, and we need to reach WG consensus on that document. Then=20 > we can talk about whether DSTM applies to one or more of the expected=20 > scenarios and whether it is the best solution, technically and=20 > architecturally, to address any of those scenarios. >=20 > Margaret >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Jun 24 12:38:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27276 for ; Thu, 24 Jun 2004 12:38:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXCY-0000Z7-3H for v6ops-data@psg.com; Thu, 24 Jun 2004 16:35:50 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXBT-0000RT-HR for v6ops@ops.ietf.org; Thu, 24 Jun 2004 16:34:43 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Thu, 24 Jun 2004 09:34:42 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 09:34:14 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 24 Jun 2004 09:34:10 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 24 Jun 2004 09:34:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: ISATAP (Was RE: DSTM) Date: Thu, 24 Jun 2004 09:34:08 -0700 Message-ID: Thread-Topic: ISATAP (Was RE: DSTM) thread-index: AcRZ/FFCtTbDYKodQNaBZHre/6dt+wADEvXg From: "Christian Huitema" To: "Tim Chown" , X-OriginalArrivalTime: 24 Jun 2004 16:34:06.0282 (UTC) FILETIME=[11309AA0:01C45A09] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I'm not sure I agree with that sentiment for ISATAP (though I have not > found a use for it in my own deployment environment). For the record, we are using ISATAP as the default IPv6 connectivity on the Microsoft campus, enabling every computer in our network to get IPv6 connectivity. It is particularly useful in those buildings where native IPv6 routers have not yet been deployed. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Jun 24 12:40: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 MAA27550 for ; Thu, 24 Jun 2004 12:40:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXGt-00014x-Ce for v6ops-data@psg.com; Thu, 24 Jun 2004 16:40:19 +0000 Received: from [62.189.30.6] (helo=tortoise.webcentre.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXGZ-00011f-A4 for v6ops@ops.ietf.org; Thu, 24 Jun 2004 16:39:59 +0000 Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by tortoise.webcentre.net (8.9.3/8.9.3) with ESMTP id RAA16380 for ; Thu, 24 Jun 2004 17:38:48 +0100 (BST) Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i5OGdtnE024788 for ; Thu, 24 Jun 2004 17:39:55 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA29304 for ; Thu, 24 Jun 2004 17:39:50 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i5OGdoD24083 for v6ops@ops.ietf.org; Thu, 24 Jun 2004 17:39:50 +0100 Date: Thu, 24 Jun 2004 17:39:50 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: ISATAP (Was RE: DSTM) Message-ID: <20040624163950.GS18044@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Jun 24, 2004 at 09:34:08AM -0700, Christian Huitema wrote: > > I'm not sure I agree with that sentiment for ISATAP (though I have not > > found a use for it in my own deployment environment). > > For the record, we are using ISATAP as the default IPv6 connectivity on > the Microsoft campus, enabling every computer in our network to get IPv6 > connectivity. It is particularly useful in those buildings where native > IPv6 routers have not yet been deployed. I think that is a very valid scenario, as is Karen's. Our own site deployment has been achieved by using VLANs (I'll update my draft on this) and we found that we can tag many different VLANs on routed packets for a single interface on a BSD router. We then split the real interfaces (and routers) as and when v6 traffic grows. This leaves us with congruent IPv4/IPv6 subnets/links and IPv6 on the wire everywhere. This is the common method used by universities in the 6NET project, and I suspect elsewhere, until capable L2/L3 equipment emerges from Cisco/etc. Tim From owner-v6ops@ops.ietf.org Thu Jun 24 12:49:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28263 for ; Thu, 24 Jun 2004 12:49:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXOF-0002H9-70 for v6ops-data@psg.com; Thu, 24 Jun 2004 16:47:55 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXNo-0002DN-NJ for v6ops@ops.ietf.org; Thu, 24 Jun 2004 16:47:28 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5OGlDC00327; Thu, 24 Jun 2004 09:47:13 -0700 X-mProtect: <200406241647> 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 smtpdvSlaXX; Thu, 24 Jun 2004 09:47:11 PDT Message-ID: <40DB059D.1080003@iprg.nokia.com> Date: Thu, 24 Jun 2004 09:47:25 -0700 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: Iljitsch van Beijnum CC: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: DSTM References: <20040623175329.GN17875@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > IPv4 over it where needed as soon as the necessary mechanisms > (IPv4-in-IPv6 tunneling, IPv6 DNS resolver discovery) are available > and all the hardware can handle IPv6 in the fast path. (I had a few > conversations with vendors at the summit thing last week and many > still do IPv6 in software.) IPv6 flows are identified by the 3-tuple of (src, dst, flow_id), i.e., there are 128+128+20=276 bits needed for handling IPv6 in the fast path. Is anyone making CAMs that wide? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Jun 24 12:53:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28637 for ; Thu, 24 Jun 2004 12:53:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXTA-0003DV-Bi for v6ops-data@psg.com; Thu, 24 Jun 2004 16:53:00 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXSi-000383-TW for v6ops@ops.ietf.org; Thu, 24 Jun 2004 16:52:33 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8430060A0; Thu, 24 Jun 2004 12:52:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 12:52:31 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: ISATAP (Was RE: DSTM) Date: Thu, 24 Jun 2004 12:52:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCA0B@tayexc13.americas.cpqcorp.net> Thread-Topic: ISATAP (Was RE: DSTM) Thread-Index: AcRZ/FFCtTbDYKodQNaBZHre/6dt+wADEvXgAACp+mA= From: "Bound, Jim" To: "Christian Huitema" , "Tim Chown" , X-OriginalArrivalTime: 24 Jun 2004 16:52:31.0908 (UTC) FILETIME=[A431BE40:01C45A0B] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable HP Hat on: Same at HP we are using ISATAP. HP hat off. I also see it for 3G and for ISPs deploying mobility for IPv6. ISATAP is absolutely required in the scenarios. ISATAP will run on Moonv6 too (all of them will actually). I will stop and respond to mail to me as best I can. But important we also understand why 6over4 did not fly. it was because Ipv4 multicast is not widely deployed that is all. /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Christian Huitema > Sent: Thursday, June 24, 2004 12:34 PM > To: Tim Chown; v6ops@ops.ietf.org > Subject: ISATAP (Was RE: DSTM) >=20 > > I'm not sure I agree with that sentiment for ISATAP (though=20 > I have not=20 > > found a use for it in my own deployment environment). >=20 > For the record, we are using ISATAP as the default IPv6=20 > connectivity on the Microsoft campus, enabling every computer=20 > in our network to get IPv6 connectivity. It is particularly=20 > useful in those buildings where native > IPv6 routers have not yet been deployed. >=20 > -- Christian Huitema >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Jun 24 12:55:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28943 for ; Thu, 24 Jun 2004 12:55:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXV8-0003eE-Oh for v6ops-data@psg.com; Thu, 24 Jun 2004 16:55:02 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXUq-0003ZN-8L for v6ops@ops.ietf.org; Thu, 24 Jun 2004 16:54:44 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5OGsZB10555; Thu, 24 Jun 2004 09:54:35 -0700 X-mProtect: <200406241654> 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 smtpdVE789b; Thu, 24 Jun 2004 09:54:33 PDT Message-ID: <40DB0757.10609@iprg.nokia.com> Date: Thu, 24 Jun 2004 09:54:47 -0700 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: Christian Huitema CC: Tim Chown , v6ops@ops.ietf.org Subject: Re: ISATAP (Was RE: DSTM) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, Christian Huitema wrote: >>I'm not sure I agree with that sentiment for ISATAP (though I have not >>found a use for it in my own deployment environment). >> >> > >For the record, we are using ISATAP as the default IPv6 connectivity on >the Microsoft campus, enabling every computer in our network to get IPv6 >connectivity. It is particularly useful in those buildings where native >IPv6 routers have not yet been deployed. > Are you using ISATAP to carry all IPv6 traffic, or just the control plane messages for tunnel setup? Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Jun 24 13:05:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29897 for ; Thu, 24 Jun 2004 13:05:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXea-0005ef-5G for v6ops-data@psg.com; Thu, 24 Jun 2004 17:04:48 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXcZ-0005Es-MB for v6ops@ops.ietf.org; Thu, 24 Jun 2004 17:02:43 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5OH442r076515; Thu, 24 Jun 2004 19:04:05 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40DB059D.1080003@iprg.nokia.com> References: <20040623175329.GN17875@login.ecs.soton.ac.uk> <40DB059D.1080003@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4CC5D460-C600-11D8-A349-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: DSTM Date: Thu, 24 Jun 2004 19:02:39 +0200 To: Fred Templin X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 24-jun-04, at 18:47, Fred Templin wrote: > Iljitsch van Beijnum wrote: >> IPv4 over it where needed as soon as the necessary mechanisms >> (IPv4-in-IPv6 tunneling, IPv6 DNS resolver discovery) are available >> and all the hardware can handle IPv6 in the fast path. (I had a few >> conversations with vendors at the summit thing last week and many >> still do IPv6 in software.) > IPv6 flows are identified by the 3-tuple of (src, dst, flow_id), i.e., > there are 128+128+20=276 bits needed for handling IPv6 in the > fast path. Is anyone making CAMs that wide? Wouldn't just src + flowid be enough? And not everyone supports initializing the flow label to something else than 0... So it's back to port numbers in that case. But you are assuming the fast path would be some kind of flow switching. I wish you wouldn't, as this doesn't work in ISP environments where the number of new flows per second is just too high, not to mention what happens when worms spit out packets with random destinations at high speed. From owner-v6ops@ops.ietf.org Thu Jun 24 13:09: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 NAA00311 for ; Thu, 24 Jun 2004 13:09:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXic-0006Lk-Rk for v6ops-data@psg.com; Thu, 24 Jun 2004 17:08:58 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXiL-0006Ia-Md for v6ops@ops.ietf.org; Thu, 24 Jun 2004 17:08:41 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5OH8YS31811; Thu, 24 Jun 2004 10:08:34 -0700 X-mProtect: <200406241708> 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 smtpdJcjZCe; Thu, 24 Jun 2004 10:08:33 PDT Message-ID: <40DB0A9E.5080804@iprg.nokia.com> Date: Thu, 24 Jun 2004 10:08:46 -0700 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: Iljitsch van Beijnum CC: v6ops@ops.ietf.org Subject: Re: DSTM References: <20040623175329.GN17875@login.ecs.soton.ac.uk> <40DB059D.1080003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 24-jun-04, at 18:47, Fred Templin wrote: > >> Iljitsch van Beijnum wrote: > > >>> IPv4 over it where needed as soon as the necessary mechanisms >>> (IPv4-in-IPv6 tunneling, IPv6 DNS resolver discovery) are available >>> and all the hardware can handle IPv6 in the fast path. (I had a few >>> conversations with vendors at the summit thing last week and many >>> still do IPv6 in software.) >> > >> IPv6 flows are identified by the 3-tuple of (src, dst, flow_id), i.e., >> there are 128+128+20=276 bits needed for handling IPv6 in the >> fast path. Is anyone making CAMs that wide? > > > Wouldn't just src + flowid be enough? And not everyone supports > initializing the flow label to something else than 0... So it's back > to port numbers in that case. Dunno, but I don't think it can be assumed that port numbers will be accessible (other than at the endpoints, that is). Fred ftemplin@iprg.nokia.com > But you are assuming the fast path would be some kind of flow > switching. I wish you wouldn't, as this doesn't work in ISP > environments where the number of new flows per second is just too > high, not to mention what happens when worms spit out packets with > random destinations at high speed. > From owner-v6ops@ops.ietf.org Thu Jun 24 13:44: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 NAA04719 for ; Thu, 24 Jun 2004 13:44:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdYEq-000BBG-V9 for v6ops-data@psg.com; Thu, 24 Jun 2004 17:42:16 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdYDm-000B15-8R for v6ops@ops.ietf.org; Thu, 24 Jun 2004 17:41:10 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Thu, 24 Jun 2004 10:40:47 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 10:40:34 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 10:41:22 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 24 Jun 2004 10:40:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ISATAP (Was RE: DSTM) Date: Thu, 24 Jun 2004 10:40:30 -0700 Message-ID: Thread-Topic: ISATAP (Was RE: DSTM) thread-index: AcRaC+sRq6CP+EPYRZSWPC0OgGh6pwAAUOhQ From: "Christian Huitema" To: "Fred Templin" Cc: "Tim Chown" , X-OriginalArrivalTime: 24 Jun 2004 17:40:26.0686 (UTC) FILETIME=[55B20DE0:01C45A12] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > >For the record, we are using ISATAP as the default IPv6 connectivity on > >the Microsoft campus, enabling every computer in our network to get IPv6 > >connectivity. It is particularly useful in those buildings where native > >IPv6 routers have not yet been deployed. > > >=20 > Are you using ISATAP to carry all IPv6 traffic, or just > the control plane messages for tunnel setup? What control plane? The packets are encapsulated in IPv4, either on a direct path between two ISATAP client, or through a relay router to a native IPv6 client. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Jun 24 13:52: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 NAA04998 for ; Thu, 24 Jun 2004 13:52:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdYNb-000CVA-2P for v6ops-data@psg.com; Thu, 24 Jun 2004 17:51:19 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdYNG-000CRF-KI for v6ops@ops.ietf.org; Thu, 24 Jun 2004 17:50:58 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5OHooa17553; Thu, 24 Jun 2004 10:50:50 -0700 X-mProtect: <200406241750> 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 smtpdz9MKRc; Thu, 24 Jun 2004 10:50:48 PDT Message-ID: <40DB1486.3020709@iprg.nokia.com> Date: Thu, 24 Jun 2004 10:51:02 -0700 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: Christian Huitema CC: Tim Chown , v6ops@ops.ietf.org Subject: Re: ISATAP (Was RE: DSTM) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Never mind. Fred ftemplin@iprg.noka.com Christian Huitema wrote: >>>For the record, we are using ISATAP as the default IPv6 connectivity >>> >>> >on > > >>>the Microsoft campus, enabling every computer in our network to get >>> >>> >IPv6 > > >>>connectivity. It is particularly useful in those buildings where >>> >>> >native > > >>>IPv6 routers have not yet been deployed. >>> >>> >>> >>Are you using ISATAP to carry all IPv6 traffic, or just >>the control plane messages for tunnel setup? >> >> > >What control plane? The packets are encapsulated in IPv4, either on a >direct path between two ISATAP client, or through a relay router to a >native IPv6 client. > >-- Christian Huitema > > > From owner-v6ops@ops.ietf.org Fri Jun 25 00:01:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19529 for ; Fri, 25 Jun 2004 00:01:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bdhrl-000AXm-Ij for v6ops-data@psg.com; Fri, 25 Jun 2004 03:59:05 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdhrG-000AUX-9Q for v6ops@ops.ietf.org; Fri, 25 Jun 2004 03:58:34 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i5P3wIvK001328; Thu, 24 Jun 2004 23:58:21 -0400 (EDT) Date: Thu, 24 Jun 2004 13:18:54 -0400 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: Dominant IPv6 Network deployment for Transition by Users Message-ID: <082BC52319FCEEABD5DAA31A@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.4 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Thursday, June 24, 2004 00:09:27 +0300 Pekka Savola wrote/a ecrit: > On Wed, 23 Jun 2004, Bound, Jim wrote: > >> 3. It is far easier to control the operation of transition to IPv6 once >> IPv6 networks are dominant and IPv4 is treated as legacy. > > Do we (and the customers, or at least the majority of them) actually > want to control the operation of transition to IPv6-only at this > point? I imagine most would want to deploy IPv6 because it brings > them a benefit they want. Until a significant portion of the Internet > has adopted IPv6, which Internet are you talking about? The IPv4 one or the IPv6 one. This is important. If you look around, new kind of applications are driving IPv6, because of its feature. Those applications won't be deployed on IPv4. So, the point here is there is two Internet: IPv4 Internet and IPv6 Internet. Now, with this in mind, some applications providers are deploying IPv6 networks, just because their application won't be deployed on IPv4. Now, back to your statement: "Until a significant portion of the Internet has adopted IPv6". This is very dangerous, since it assumes that services and applications are moved to ipv6. No one will move to Ipv6 just for a better "web" service. So, what we are seeing, is a new Internet based on IPv6 with new applications. This is _very_ significant to the whole purpose of IPv6. These applications and networks, IPv6 only, might not be as big as IPv4 now, but they are going to make the paradigm shift. In summary, are we throwing away the applications and networks that are _really_ using IPv6 features, just because they do not seem to appear in some people radar while they connect to the current Internet? > an easy strategy could be to postpone the decision > on when to move to IPv6-only. it is happening right now. And it is very important for the immediate future of IPv6. These applications and networks are driving IPv6. Waiting until some narrow radar screen see IPv6 in your neighborhood is very dangerous. > You're assuming that it's useful to > make the decision at this point, as a "future investment" and a hope > that IPv6 will actually be globally deployed soon enough to warrant > doing it now. > > This might not hold. At least in many circles, where IPv6 is *NOT* a > "religious" or political topic (but operational one, as it should be, > in the end -- we're not deploying IPv6 for its own sake, but to make > the users happier by giving them better means to achieve X, Y and Z!), > it's much easier to control the operation of transition by deploying > IPv6, but not by taking away what's already in there (IPv4). Then > IPv6 will fly when there is use (X, Y, or Z, above) for it. > >> The technology questions to discuss to support the above are as follows: >> >> 1. What are the differentials regarding technology requirements for a >> gradual IPv4-IPv6 versus agressive IPv6 transition for deployment to use >> a dominant IPv6 network deployment strategy? not the right question. For applications that are IPv6 only because they can't run over IPv4, what is the requirement to deploy an IPv4 network? > > Good question, even though I'd personally want to question the latter > strategy in the first place. > >> 2. What are the Internet infrastructure requirements for that which we >> have dominion over within the IETF regarding "protocols" and >> "operational procedures" we specify to suppport a dominant IPv6 network >> deployment strategy? > > Regarding the previous question, I'd be interested in hearing more > opinions on whether this is a priority work item for us? > > I.e., I'm sure that (provided that IPv6 will kick off in a major way) > some years in the future the IETF will be specifying how to deal with > a lot of issues regarding IPv6-only or dominant IPv6, but doing so > *NOW* seems premature (especially as we have as little real > operational experience from that), when we could be using that energy > to solve the problems with the more generic approach, dual-stack. I'm confused about this argument that is restated all the time. - from ngtrans to v6ops, we have spent years (I don't recall, it is so far now). During that timeframe, we could have published many transition mechanisms and then have the market/community/... pick and choose. Then, right now, we would be fixing issues with _real_ deployment experience, and then in a position to move forward to another level the mechanisms that have no issues, are well deployed, etc... We now get the argument of "priority" and wg time. I made a suggestion in this thread: have a small design team work on the dstm spec, come back to wg with a final proposal, and then move it. The "work load" for the wg won,t be significant and we have a spec out for implementations to interop and deploy. Same argument/suggestion stands for the other mechanisms. Instead of "fighting" on one or the other mechanism, questioning some variation of some requirement, where we spend a lot of "wg important time and priority", we could instead work on protocol design and publish. I'm pretty sure we could reach concensus on a set of mechanisms that some of us have implemented and then publish them. This won't be that difficult. and will be useful for IETF, for the IPv6 community and market, and will leave this infinite loop we have started years ago with the ngtrans-2-v6ops "transition"... my 2 canadian cents... Marc. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Fri Jun 25 00:01:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19610 for ; Fri, 25 Jun 2004 00:01:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdhrU-000AWD-KQ for v6ops-data@psg.com; Fri, 25 Jun 2004 03:58:48 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdhrE-000AUC-Od for v6ops@ops.ietf.org; Fri, 25 Jun 2004 03:58:33 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i5P3wIvM001328; Thu, 24 Jun 2004 23:58:22 -0400 (EDT) Date: Thu, 24 Jun 2004 13:24:27 -0400 From: Marc Blanchet To: Iljitsch van Beijnum cc: v6ops@ops.ietf.org Subject: Re: DSTM Message-ID: <3F445D8ED68729C203DF5E17@classic.viagenie.qc.ca> In-Reply-To: References: <20040623175329.GN17875@login.ecs.soton.ac.uk> X-Mailer: Mulberry/3.1.4 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Thursday, June 24, 2004 11:21:30 +0200 Iljitsch van Beijnum wrote/a ecrit: > On 24-jun-04, at 5:37, Margaret Wasserman wrote: > > >> I have not personally heard any ISP or Enterprise operators indicate >> their intention to run IPv6-only backbones any time soon. - in which part of the planet you talk to? - in which market are you talking to? > > Probably because the notion that this could be a viable option hasn't > entered the brains of the decision makers yet. > > If you consider the complexities of building a large IPv4 network, > especially if you want to avoid NAT but don't have a lot of address > space, versus the simplicity of building a similar network using IPv6, it > makes sense that people will want to run an IPv6-only network and tunnel > IPv4 over it where needed as soon as the necessary mechanisms > (IPv4-in-IPv6 tunneling, available now. implemented. I can show you a demo. > IPv6 DNS resolver discovery) are available and > all the hardware can handle IPv6 in the fast path. (I had a few > conversations with vendors at the summit thing last week and many still > do IPv6 in software.) > >> I'm also not sure how/why we need a specific DSTM server at all... How >> is DSTM superior to using a DHCPv6 option to get the configuration >> information needed to set-up a configured IPv4-in-IPv6 tunnel and then >> using DHCPv4 over that tunnel? > > I for one am not in favor of making DHCPv6 a dependency. > > I also have another problem with DSTM as it is: it depends on a single > gateway. That's not good. We need redundancy. sorry. don't agree. - many ways to acheive redundancy: anycast discovery, vrrp, etc... - other mechanisms do not have any redundancy: i.e. 6to4 border gateway. Marc. > > It might be better to create an IPv4-in-IPv6 tunneling mechanism that > treats the IPv6 network as an IPv4 link layer and run standard IPv4 > protocols such as ARP and DHCP over that. (Similar to 6over4 but the > other way around.) This should work very well in networks that support > site-wide multicast. (There are some security issues with rogue DHCPv4 > servers but those can be mitigated by filtering broad/multicasts.) > > However, we may also want to consider the situation where a user is > roaming on a standard issue IPv6 network far away, and wants to tunnel > back home. There are already various VPN solutions that do this for IPv4 > over IPv4, though, so hopefully we don't have to reinvent the wheel here. > > One remark about the draft: there are some serious line length issues, > please fix as this makes some parts very hard to read. > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Fri Jun 25 05:51:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20538 for ; Fri, 25 Jun 2004 05:51:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdnIk-0000Nl-HY for v6ops-data@psg.com; Fri, 25 Jun 2004 09:47:18 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdnIW-0000MO-42 for v6ops@ops.ietf.org; Fri, 25 Jun 2004 09:47:04 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5P9l2WR018996 for ; Fri, 25 Jun 2004 11:47:03 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 11:46:42 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MFZ5QZGL; Fri, 25 Jun 2004 11:47:02 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jun 2004 11:47:02 +0200 Message-ID: X-Sybari-Trust: 0cbc1f2b 100f6658 80bc4c27 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org, "'Fred Templin'" , Mohit Talwar , tgleeson@cisco.com, "'Dave Thaler'" Subject: Security issues of Isatap usage in 3GPP networks WAS : RE: moving when all the scenarios are not yet complete [RE: DSTM] Date: Fri, 25 Jun 2004 11:47:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Jun 2004 09:46:42.0691 (UTC) FILETIME=[52165D30:01C45A99] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, > There is, however, an argument to be made if a mechanism would be > required in multiple scenarios, where one or more of the scenarios was > not finished yet -- then the question would be what would be the basis > on where to evolve the specification? (for example, let's consider > ISATAP in 3GPP: one could remove direct tunneling support, but then it > might become useless (at least to some) in Enterprise -- for > mechanisms which dependencies it might be worth a bit more of > wait-and-see, Although I may agree with the above argument in principle, I do not agree with the exemplification. Let me try (once more) to address the expressed concerns with the direct tunnelling functionality of Isatap. The problem hinted at, I assume, is the SEND security threats as detailed in 3756 (....or are there others ?) In 3GPP networks it should be possible to assume the following: * Intrasite IPv4 source spoofing isn't possible. * Site is Protocol-41 perimeter guarded. - or it should be acceptable to recommended the above to be enforced by the 3GPP operator as a mechanism to prevent potential SEND security threats of Isatap. Given the above, the SEND security threats either do not apply to Isatap or can be prevented by careful implementation. In particular by implementing the following additional security check on Isatap interfaces: * RA messages are only accepted from PRL routers. We have implemented this with no problems and I would like to see it recommended for Isatap. Indeed: 4.1.1. Link-layer addresses in potential Neighbour Cache Entries maintained on Isatap Interfaces are not relevant. The Link-layer address (IPv4 address) is deduced from IPv6 destination address. An implementation that uses a different link-layer address than the IPv4 address embedded within the IPv6 destination address isn't compliant. DAD sub-clause: Why you would ever want to implement DAD on an Isatap Interface I really don't know. The uniqueness of the address is inherited from the uniqueness of the IPv4 address. The latter which is ensured by the network (at least in enterprise and 3GPP networks). 4.1.2: This could be a valid DoS threat. This is however only applicable if NUD is performed on the interface. NUD over Isatap only really work if carefully implemented anyway - Hence it should be reasonable to assume careful behaviour of an implementation which performs NUD on an Isatap interface. For example by implementing the following additional validity check: * Unless sourced from the link-local address of a PRL router (e.g. for proxy ND) the target address of the NS message should be identical to the source address of the packet. (We haven't implemented the mentioned check as we do not support NUD on isatap interfaces) 4.1.3: Non-applicable if DAD is omitted 4.2.1: Non-applicable given that a trust worthy PRL population mechanism is deployed. 4.2.2+4.2.3 Isn't related to the direct tunnelling functionality of Isatap. Is limited by the usage of/and management of a trust worthy PRL population mechanism. 4.2.4 Non-applicable as Isatap's source address checks combined with IPv4 source address proof implies IPv6 source address proof. I.e. the IPv6 link-local address of a PRL router cannot be spoofed. 4.2.5+4.2.6+4.2.7: Non-applicable given IPv4 source address spoofing prevention, if trustworthy PRL population mechanism is deployed. 4.3.1: Non-applicable by IPv4 source address spoofing prevention. 4.3.2 Not related to the direct tunnelling functionality of Isatap. Not applicable if address resolution is based on static resolution only. BR, Karen From owner-v6ops@ops.ietf.org Fri Jun 25 10:06: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 KAA01588 for ; Fri, 25 Jun 2004 10:06:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdrIL-0002xV-3N for v6ops-data@psg.com; Fri, 25 Jun 2004 14:03:09 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdrI2-0002uR-Cg for v6ops@ops.ietf.org; Fri, 25 Jun 2004 14:02:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00912; Fri, 25 Jun 2004 10:02:47 -0400 (EDT) Message-Id: <200406251402.KAA00912@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-application-transition-03.txt Date: Fri, 25 Jun 2004 10:02:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 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 : Application Aspects of IPv6 Transition Author(s) : M. Shin, et al. Filename : draft-ietf-v6ops-application-transition-03.txt Pages : 30 Date : 2004-6-24 As IPv6 networks are deployed and the network transition discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and what is the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-application-transition-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-application-transition-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-25102511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-application-transition-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-application-transition-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-25102511.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jun 25 20: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 UAA23154 for ; Fri, 25 Jun 2004 20:36:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Be19I-0000lJ-Qd for v6ops-data@psg.com; Sat, 26 Jun 2004 00:34:28 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Be18z-0000it-Nr for v6ops@ops.ietf.org; Sat, 26 Jun 2004 00:34:10 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZW00J0148SZ0@mailout1.samsung.com> for v6ops@ops.ietf.org; Sat, 26 Jun 2004 09:34:05 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZW005L048SZP@mailout1.samsung.com> for v6ops@ops.ietf.org; Sat, 26 Jun 2004 09:34:04 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HZW00ABD48SCC@mmp1.samsung.com> for v6ops@ops.ietf.org; Sat, 26 Jun 2004 09:34:04 +0900 (KST) Date: Sat, 26 Jun 2004 09:34:55 +0900 From: Soohong Daniel Park Subject: RE: ISATAP (Was RE: DSTM) In-reply-to: To: v6ops@ops.ietf.org, Tim Chown , Christian Huitema Cc: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > For the record, we are using ISATAP as the default IPv6 connectivity on > the Microsoft campus, enabling every computer in our network to get IPv6 > connectivity. It is particularly useful in those buildings where native > IPv6 routers have not yet been deployed. Just reference. We are using a DHCP for enabling IPv6 connectivity in our IPv4 offices with simple option. Regards. - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. From owner-v6ops@ops.ietf.org Sun Jun 27 16:44:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05393 for ; Sun, 27 Jun 2004 16:44:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BegS9-0009nq-9L for v6ops-data@psg.com; Sun, 27 Jun 2004 20:40:41 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BegS2-0009mm-Mm for v6ops@ops.ietf.org; Sun, 27 Jun 2004 20:40:35 +0000 Received: (qmail 85675 invoked by uid 1007); 27 Jun 2004 20:40:32 -0000 Date: Sun, 27 Jun 2004 22:40:32 +0200 From: Gert Doering To: v6ops@ops.ietf.org Subject: Re: ISATAP (Was RE: DSTM) Message-ID: <20040627204032.GC67702@Space.Net> References: <20040624163950.GS18044@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040624163950.GS18044@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, Jun 24, 2004 at 05:39:50PM +0100, Tim Chown wrote: > [VLAN method using dedicated v6 VLAN router to get v6 on every wire] > > This is the common method used by universities in the 6NET project, and I > suspect elsewhere, until capable L2/L3 equipment emerges from Cisco/etc. Same here (ISP environment) for the hosting customers with v6 connectivity. IPv4 connectivity is provided by "fast" L3 switches with no v6 support. v6 is routed over an old Cisco 4700 with v6+VLAN trunking, easily fast enough for now, and no "client transition methods" needed. Very convenient for the machines, and easy to debug. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Mon Jun 28 01:40:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25991 for ; Mon, 28 Jun 2004 01:40:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Beopg-000NBy-1j for v6ops-data@psg.com; Mon, 28 Jun 2004 05:37:32 +0000 Received: from [193.252.22.28] (helo=mwinf0301.wanadoo.fr) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeVpp-000DUQ-ID for v6ops@ops.ietf.org; Sun, 27 Jun 2004 09:20:26 +0000 Received: from ALille-251-1-9-43.w82-127.abo.wanadoo.fr (ALille-251-1-9-43.w82-127.abo.wanadoo.fr [82.127.151.43]) by mwinf0301.wanadoo.fr (SMTP Server) with ESMTP id 3F2DD40060D; Sun, 27 Jun 2004 11:20:24 +0200 (CEST) Received: from 192.168.1.64 by charlie.simphalempin.com with esmtp (masqmail 0.2.20) id 1BeVpn-0Ye-00; Sun, 27 Jun 2004 11:20:23 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: VIA Centrale =?iso-8859-1?q?R=E9seaux?= To: v6ops@ops.ietf.org Subject: Issues with draft-huitema-v6ops-teredo-02.txt Date: Sun, 27 Jun 2004 11:20:22 +0200 User-Agent: KMail/1.6.2 Cc: huitema@microsoft.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200406271120.22808.rdenis@simphalempin.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, I've got a few questions regarding draft-huitema-v6ops-teredo-02.txt > 5.1.2 Maximum Transmission Unit >=20 > The default link MTU assumed by a host, and the link MTU supplied by > a Teredo server during router advertisement SHOULD normally be set > to the minimum IPv6 MTU size of 1280 bytes [RFC2460]. Should the server embed a MTU in its RA? > 5.2.1 Qualification procedure (...) > The client selects a secondary IPv4 server address, and > repeats the procedure, the cone bit remaining to the value zero. How is the secondary IPv4 server address determined? The implementation currently shipped with Windows XP seems to increment=20 the primary server address by one, but that behavior is not documented=20 in the spec. > 5.3 Teredo Server specification (...) > The Teredo server > waits for incoming UDP packets at the Teredo Port, using the IPv4=20 > address that has been selected for the service. In addition, the > server is able to receive and transmit some packets using a > different IPv4 address and a different port number. I thought the port number was 3544 in both cases. Is that not the case,=20 and, if so, how is the port determined by the client? > 5.4.1 Transmission by relays to Teredo clients (...) > Before processing these packets, the Teredo Server MUST check that > the IPv4 destination address embedded in the Teredo IPv6 address is > in the format of a global unicast address; if this is not the case, > the packet MUST be silently discarded. I'm fairly confused there: Is it the server's or the relay's job to=20 check the "IPv4 destination address embedded in the Teredo IPv6=20 address" ? I admit servers should do the check, as they should not blindly trust=20 packets from relays. But as I read the following sentence: > The relay then checks if there is an entry for this IPv6 address in > the list of recent Teredo peers, and if the entry is still valid. I assume it is the relay's job. Doesn't that need a bit of=20 clarification? Sincerely, =2D-=20 R=E9mi Denis-Courmont From owner-v6ops@ops.ietf.org Mon Jun 28 03:56: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 DAA15221 for ; Mon, 28 Jun 2004 03:56:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Beqye-000Alj-Uj for v6ops-data@psg.com; Mon, 28 Jun 2004 07:54:56 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeqyR-000Ak2-HM for v6ops@ops.ietf.org; Mon, 28 Jun 2004 07:54:44 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5S7scWR013720 for ; Mon, 28 Jun 2004 09:54:42 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 09:54:38 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MATPJB58; Mon, 28 Jun 2004 09:54:38 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jun 2004 09:54:38 +0200 Message-ID: X-Sybari-Trust: 6dc0f7ed 2335e436 8e9d3762 00000139 From: "Karen E. Nielsen (AH/TED)" To: "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Cc: v6ops@ops.ietf.org, "'Fred Templin'" , Mohit Talwar , tgleeson@cisco.com, "'Dave Thaler'" Subject: RE: Security issues of Isatap usage in 3GPP networks WAS : RE: mo ving when all the scenarios are not yet complete [RE: DSTM] Date: Mon, 28 Jun 2004 09:54:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 28 Jun 2004 07:54:38.0922 (UTC) FILETIME=[29A5E2A0:01C45CE5] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Clarification inserted below. Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Karen E. Nielsen (AH/TED) > Sent: Friday, June 25, 2004 11:47 AM > To: 'Pekka Savola' > Cc: v6ops@ops.ietf.org; 'Fred Templin'; Mohit Talwar; > tgleeson@cisco.com; 'Dave Thaler' > Subject: Security issues of Isatap usage in 3GPP networks WAS : RE: > moving when all the scenarios are not yet complete [RE: DSTM] > > > Hi Pekka, > > > There is, however, an argument to be made if a mechanism would be > > required in multiple scenarios, where one or more of the > scenarios was > > not finished yet -- then the question would be what would > be the basis > > on where to evolve the specification? (for example, let's consider > > ISATAP in 3GPP: one could remove direct tunneling support, > but then it > > might become useless (at least to some) in Enterprise -- for > > mechanisms which dependencies it might be worth a bit more of > > wait-and-see, > > Although I may agree with the above argument in principle, > I do not agree with the exemplification. > > Let me try (once more) to address the expressed concerns with > the direct tunnelling functionality of Isatap. > > The problem hinted at, I assume, is the SEND security threats > as detailed in 3756 (....or are there others ?) > > In 3GPP networks it should be possible to assume the following: > > * Intrasite IPv4 source spoofing isn't possible. > * Site is Protocol-41 perimeter guarded. > > - or it should be acceptable to recommended the above to be > enforced by the 3GPP operator as a mechanism to prevent > potential SEND security threats of Isatap. > > Given the above, the SEND security threats either do not apply to > Isatap or can be prevented by careful implementation. In particular > by implementing the following additional security check on > Isatap interfaces: > > * RA messages are only accepted from PRL routers. > > We have implemented this with no problems and I would > like to see it recommended for Isatap. > Fred has pointed out that this is indeed mandated on Isatap interfaces. So much the better. > Indeed: > > 4.1.1. Link-layer addresses in potential > Neighbour Cache Entries maintained on Isatap Interfaces > are not relevant. The Link-layer address (IPv4 address) is deduced > from IPv6 destination address. An implementation that uses a > different link-layer address > than the IPv4 address embedded within the IPv6 destination > address isn't compliant. > > DAD sub-clause: > Why you would ever want to implement DAD on an Isatap > Interface I really don't know. > The uniqueness of the address is inherited from the > uniqueness of the IPv4 address. > The latter which is ensured by the network (at least in > enterprise and 3GPP networks). > > 4.1.2: This could be a valid DoS threat. > This is however only applicable if NUD is performed on the interface. > NUD over Isatap only really work if carefully implemented anyway - > Hence it should be reasonable to assume careful behaviour of > an implementation which performs > NUD on an Isatap interface. For example by implementing the > following additional validity > check: > * Unless sourced from the link-local address of a PRL router > (e.g. for proxy ND) the target address > of the NS message should be identical to the source address > of the packet. > > (We haven't implemented the mentioned check as we > do not support NUD on isatap interfaces) > > 4.1.3: Non-applicable if DAD is omitted > > 4.2.1: Non-applicable given that a trust worthy PRL population > mechanism is deployed. > > 4.2.2+4.2.3 > Isn't related to the direct tunnelling functionality of Isatap. > Is limited by the usage of/and management of > a trust worthy PRL population mechanism. > > 4.2.4 > Non-applicable as Isatap's source address checks combined > with IPv4 source address > proof implies IPv6 source address proof. I.e. the IPv6 > link-local address of > a PRL router cannot be spoofed. > > 4.2.5+4.2.6+4.2.7: > Non-applicable given IPv4 source address spoofing prevention, > if trustworthy PRL population mechanism is deployed. > > 4.3.1: > Non-applicable by IPv4 source address spoofing prevention. > > 4.3.2 > Not related to the direct tunnelling functionality of Isatap. > Not applicable if address resolution is based on static > resolution only. > > BR, Karen > From owner-v6ops@ops.ietf.org Mon Jun 28 11:30: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 LAA11555 for ; Mon, 28 Jun 2004 11:30:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bey3G-0008Iu-Ha for v6ops-data@psg.com; Mon, 28 Jun 2004 15:28:10 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bey0O-000816-Bo for v6ops@ops.ietf.org; Mon, 28 Jun 2004 15:25:12 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5SFP6J07052; Mon, 28 Jun 2004 18:25:06 +0300 (EET DST) X-Scanned: Mon, 28 Jun 2004 18:24:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5SFOLLO020840; Mon, 28 Jun 2004 18:24:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00AkyoBN; Mon, 28 Jun 2004 18:24:19 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5SFOJH04644; Mon, 28 Jun 2004 18:24:19 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 18:24:17 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 172.21.154.20 172.21.154.20 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15420.ntc.nokia.com by ESEBE024.noe.nokia.com; 28 Jun 2004 18:24:16 +0300 Subject: Re: moving when all the scenarios are not yet complete [RE: DSTM] From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Pekka Savola , Christian Huitema , "Bound, Jim" , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1088436256.5908.49.camel@essrv103nok15420.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Mon, 28 Jun 2004 18:24:16 +0300 X-OriginalArrivalTime: 28 Jun 2004 15:24:17.0758 (UTC) FILETIME=[FA498FE0:01C45D23] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I generally agree with Pekka. The original idea was to have the scenarios/analysis documents stabilized before moving forward. Most of the documents have stabilized (are at the IESG). I don't believe we need RFC numbers before going forward. I don't think the IESG will have that strong objections that the WGs technological choices will be totally overruled. And if there are (and they have valid points) we'll take care of them case-by-case. We (chairs - Pekka and I) are in dialog to find out from our ADs what is the correct way forward with this. I hope we'll get a proposal for the way forward from them quite soon. However, I don't think anything will change in the original way forward: When the scenarios/analysis documents are done, the work on the solutions can move forward. I hope and believe that we are getting close to that time. I'm sorry it took longer than expected. Anyways, I don't think it is in our (the chairs) interest or in the interest of the IESG to be unfair in this (or in any other) point. Let's be patient for a day or two and let's make sure our scenarios/analysis documents go forward as planned. Cheers, Jonne. On Thu, 2004-06-24 at 00:40, ext Pekka Savola wrote: > A new topic to better suit the subject.. > > On Wed, 23 Jun 2004, Christian Huitema wrote: > > > But when I saw the mail Teredo was going to move without doing > > finishing > > > all scenarios/analysis docs I thought we were opening the flood gates > > > for all mechanisms. I could be wrong? But all mechanisms should be > > > applied to that entire set of work efforts. > > > > I have two issues with this statement. > > > > First, I don't think we should wait until *all* scenario documents are > > completed before we standardize or publish *any* new transition > > technology. The bar ought to be lower: we should progress a transition > > technology if we agree that it is clearly needed by at least one > > scenario. Otherwise, we could keep inventing new scenarios, and we would > > always have to wait until yet another scenario analysis is completed. > > > > Second, we have to define what "completed" means. What is the decision > > point? We have actually all but completed the "unmanaged networks" > > evaluation: we went through the working group last call, and the > > document is now on the IESG plate. Based on this scenario, doing work on > > Teredo is not spurious. > > What Christian said. The analysis of 3GPP, Unmanaged and ISP have all > already left this WG (with rough consensus) and are at IESG > evaluation, or beyond the IESG evaluation (and none of documents got > IESG pushback on Teredo/BGPtunnel/etc.). I fail to see what more one > could expect here. Does it matter what we decide e.g. in the > Enterprise document, if Unmanaged, ISP, or 3GPP already requires a > certain kind of mechanism? > > There is, however, an argument to be made if a mechanism would be > required in multiple scenarios, where one or more of the scenarios was > not finished yet -- then the question would be what would be the basis > on where to evolve the specification? (for example, let's consider > ISATAP in 3GPP: one could remove direct tunneling support, but then it > might become useless (at least to some) in Enterprise -- for > mechanisms which dependencies it might be worth a bit more of > wait-and-see, but e.g. Teredo has only been proposed in the Unmanaged > scenario. > > So IMHO this is an argument for moving forward (if there is consensus, > as there seems to be in Unmanaged and ISP) in all the scenarios which > are already at the IESG (read: when there is consensus in the WG, and > there is no objection at the IESG). The mechanisms required by > scenarios which are not done yet IMHO cannot go forward at this point. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Mon Jun 28 11:32:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11629 for ; Mon, 28 Jun 2004 11:32:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bey6l-0008kK-BJ for v6ops-data@psg.com; Mon, 28 Jun 2004 15:31:47 +0000 Received: from [208.54.60.54] (helo=blue.fries.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bey6K-0008gw-Tq for v6ops@ops.ietf.org; Mon, 28 Jun 2004 15:31:30 +0000 Received: from [IPv6:::1] (todd@localhost.fries.net [IPv6:::1]) by blue.fries.net (8.13.0/8.12.11) with ESMTP id i5SFPG7N009504; Mon, 28 Jun 2004 10:25:21 -0500 (CDT) Subject: Re: DSTM From: "Todd T. Fries" Reply-To: todd@fries.net To: Iljitsch van Beijnum Cc: "Bound, Jim" , "" In-Reply-To: <5C5398EE-C5ED-11D8-A349-000A95CD987A@muada.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC9B2@tayexc13.americas.cpqcorp.net> <5C5398EE-C5ED-11D8-A349-000A95CD987A@muada.com> Content-Type: text/plain Organization: Free Daemon Consulting, LLC Date: Mon, 28 Jun 2004 15:25:16 +0000 Message-Id: <1088436316.17109.15.camel@blue.fries.net> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.2 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It seems strange to me that VRRP is mentioned on a v6ops mailing list when, as far as I have been lead to believe, VRRP does not support V6. CARP, on the other hand, does. On Thu, 2004-06-24 at 16:47 +0200, Iljitsch van Beijnum wrote: > On 24-jun-04, at 16:03, Bound, Jim wrote: > > > Multiple TEPs can be provided to the client for redundancy and router > > failover deploying dual rail routers supports the mission critical > > case, > > and if the link is cut or blown up there is custom software to inform > > clients of that etc. > > This sounds awfully complex to me... I'd rather take advantage of > existing redundancy features such as VRRP. > > > Note I believe your concern applys to all transition mechanisms and do > > we need to put this health warning on all transition mechanisms and in > > our scenarios as we do security? > > We are engineers; we build reliable networks from unreliable parts. So > much goes without saying, or at least without saying it over and over > untill we're all sick of hearing it... :-) > > With security, every little thing must be secure. With redundancy, it's > acceptable to have unreliable parts as long as you have several of them > and switching from one to the other isn't too fatal. So I think those > two issues are in different categories. > > I'm not very comfortable with the phrase "all transition mechanisms" as > most of the transition mechanisms that were created at one time or > another turned out to be fairly useless ("automatich tunneling", > 6over4, isatap). There is some risk that this will happen again now > that we're looking at the other side of the coin (tunneling 6 over 4) > unless we're very careful. > > > Again is this just picking on DSTM or > > should the question be applied to all mechanisms (not mean't as > > negative > > question just a question)? As a question of fair and open process? > > I guess it depends. If there is stuff that's clearly useful and maybe > even deployed, but there is no good way to add redundancy, so be it. On > the other hand, if we have the choice between solving a problem in a > way that allows for redundancy and in a way that doesn't, then it makes > sense to go with the redundancy-friendly way. > > With regard to DSTM: I applaud the goal, but I'm doubtful if the way to > get there is the optimal one, for the reasons listed earlier, and also > because having some special purpose software handling all kinds of > details isn't very attractive (to me at least), as opposed to having a > more generic encapsulation mechanism over which we can run a variety of > existing mechanisms such as ARP, DHCP and VRRP. > > But I understand you guys already have code. I guess the best way > forward would be to deploy this code and see how well it behaves in the > real world. If it turns out it works very well, we should probably > standardize it, even if there are theoretical flaws. On the other hand, > if the issues I pointed out and/or others turn out to be of concern in > practice, we may want to start from scratch at some point in the > future, heeding the lessons learned. > > > In DSTM it is assumed that an IPv4 address from the DNS returned which > > begins the DSTM client the TSP or DHCPv6 or RPC to the server will > > match > > correct TEP and CIDR or IPv4 high order bits of address for network > > route. > > ??? I don't understand. If I connect to more than one IPv4 destination, > do I talk to more than one tunnel endpoint? That doesn't make sense. > From owner-v6ops@ops.ietf.org Mon Jun 28 12:13: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 MAA13511 for ; Mon, 28 Jun 2004 12:13:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Beyk4-000E8p-U3 for v6ops-data@psg.com; Mon, 28 Jun 2004 16:12:24 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeyjO-000E3c-15 for v6ops@ops.ietf.org; Mon, 28 Jun 2004 16:11:42 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i5SGBeDW005554 for ; Mon, 28 Jun 2004 18:11:40 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i5SGBeO1012351 for v6ops@ops.ietf.org; Mon, 28 Jun 2004 18:11:40 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 28 Jun 2004 18:11:40 +0200 From: Stig Venaas To: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) Message-ID: <20040628161140.GA12315@sverresborg.uninett.no> References: <20040517155721.GQ8946@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040517155721.GQ8946@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, May 17, 2004 at 04:57:21PM +0100, Tim Chown wrote: > On Fri, May 14, 2004 at 09:47:46AM -0700, Erik Nordmark wrote: > > > > Since this is an operational WG, have we received requests from folks operating > > IPv6 that they are running into this particular problem? > > We operate IPv4 and IPv6 multicast. If we want bridging between the two > protocols we use Stig's gateway (which sadly wasn't adopted by the mboned > WG, despite evidence of its utility). Thanks for the plug Tim. I wrote a draft on a gateway translating between IPv4 and IPv6 multicast. It's expired now, but you can find it at http://www.uninett.no/testnett/multicast/mcgw/draft-venaas-mboned-v4v6mcastgw-00.txt This solution was implemented 18 months ago, and has been in daily use by several people since then. Is there any interest in working in this area in v6ops? I know several people that are interested in the solution and would like to see it properly documented. There was some related work in ngtrans, see the expired draft-ietf-ngtrans-mtp-03.txt. IMHO my solution is better. Are there more appropriate places to take it? Stig From owner-v6ops@ops.ietf.org Mon Jun 28 13:03:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16441 for ; Mon, 28 Jun 2004 13:03:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BezWE-000JKU-Jn for v6ops-data@psg.com; Mon, 28 Jun 2004 17:02:10 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BezVx-000JHk-HG for v6ops@ops.ietf.org; Mon, 28 Jun 2004 17:01:54 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 273C98580; Mon, 28 Jun 2004 19:01:51 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 02035-30; Mon, 28 Jun 2004 19:01:41 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id BA3857F67; Mon, 28 Jun 2004 19:01:25 +0200 (CEST) Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) From: Jeroen Massar To: Stig Venaas Cc: v6ops@ops.ietf.org In-Reply-To: <20040628161140.GA12315@sverresborg.uninett.no> References: <20040517155721.GQ8946@login.ecs.soton.ac.uk> <20040628161140.GA12315@sverresborg.uninett.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OhbqMZ4V2CFrD/Vhqbsr" Organization: Unfix Message-Id: <1088442083.20311.44.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 28 Jun 2004 19:01:24 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-OhbqMZ4V2CFrD/Vhqbsr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-06-28 at 18:11, Stig Venaas wrote: > On Mon, May 17, 2004 at 04:57:21PM +0100, Tim Chown wrote: > > On Fri, May 14, 2004 at 09:47:46AM -0700, Erik Nordmark wrote: > > >=20 > > > Since this is an operational WG, have we received requests from folks= operating > > > IPv6 that they are running into this particular problem?=20 > >=20 > > We operate IPv4 and IPv6 multicast. If we want bridging between the t= wo > > protocols we use Stig's gateway (which sadly wasn't adopted by the mbon= ed > > WG, despite evidence of its utility). >=20 > Thanks for the plug Tim. I wrote a draft on a gateway translating > between IPv4 and IPv6 multicast. It's expired now, but you can find it > at > http://www.uninett.no/testnett/multicast/mcgw/draft-venaas-mboned-v4v6mca= stgw-00.txt >=20 > This solution was implemented 18 months ago, and has been in daily use > by several people since then. >=20 > Is there any interest in working in this area in v6ops? I know several > people that are interested in the solution and would like to see it > properly documented. There was some related work in ngtrans, see the > expired draft-ietf-ngtrans-mtp-03.txt. IMHO my solution is better. > Are there more appropriate places to take it? I also support seeing this work, just like Teredo, DSTM and the others, to be properly documented and archived. There are many users of these mechanisms and they are very useful. Google should not be the way to search for them... Greets, Jeroen --=-OhbqMZ4V2CFrD/Vhqbsr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA4E7jKaooUjM+fCMRAgmuAJ9JJvrfIwoTlx5lRrJ+2zxQ4wPsbwCgrOFt FDdq7io5QHbcdp/7/YqKT/U= =Kc0V -----END PGP SIGNATURE----- --=-OhbqMZ4V2CFrD/Vhqbsr-- From owner-v6ops@ops.ietf.org Mon Jun 28 13:21:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17089 for ; Mon, 28 Jun 2004 13:21:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BeznV-000LWM-Br for v6ops-data@psg.com; Mon, 28 Jun 2004 17:20:01 +0000 Received: from [132.246.162.10] (helo=ryouko.imsb.nrc.ca) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bezmh-000LQF-Pi for v6ops@ops.ietf.org; Mon, 28 Jun 2004 17:19:12 +0000 Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.13.0/8.13.0) with ESMTP id i5SHJAWA021105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jun 2004 13:19:10 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.13.0/8.12.10/Submit) with ESMTP id i5SHJAYo021102 for ; Mon, 28 Jun 2004 13:19:10 -0400 Date: Mon, 28 Jun 2004 13:19:10 -0400 (EDT) From: "William F. Maton" Reply-To: wmaton@ryouko.imsb.nrc.ca To: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) In-Reply-To: <20040628161140.GA12315@sverresborg.uninett.no> Message-ID: References: <20040517155721.GQ8946@login.ecs.soton.ac.uk> <20040628161140.GA12315@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 28 Jun 2004, Stig Venaas wrote: [snip] > Thanks for the plug Tim. I wrote a draft on a gateway translating > between IPv4 and IPv6 multicast. It's expired now, but you can find it > at > http://www.uninett.no/testnett/multicast/mcgw/draft-venaas-mboned-v4v6mcastgw-00.txt > > This solution was implemented 18 months ago, and has been in daily use > by several people since then. [snip] > Are there more appropriate places to take it? As someone who is interested in both IPv6 and multicast, yes, this would be good to see in a document. This group might be the best place for it. Though I wonder why mboned didn't do anything with it... wfms From owner-v6ops@ops.ietf.org Mon Jun 28 15:33:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25699 for ; Mon, 28 Jun 2004 15:33:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bf1qf-000BPK-SG for v6ops-data@psg.com; Mon, 28 Jun 2004 19:31:25 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bf1qO-000BO9-IM for v6ops@ops.ietf.org; Mon, 28 Jun 2004 19:31:08 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25555; Mon, 28 Jun 2004 15:31:05 -0400 (EDT) Message-Id: <200406281931.PAA25555@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Mon, 28 Jun 2004 15:31:05 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-03.txt Pages : 16 Date : 2004-6-28 This document describes the scenarios for IPv6 deployment within Enterprise networks. It will focus upon an Enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of Enterprise solutions in a later document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ent-scenarios-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-28151221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-scenarios-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151221.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Jun 28 15:33: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 PAA25760 for ; Mon, 28 Jun 2004 15:33:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bf1rK-000BSi-Ri for v6ops-data@psg.com; Mon, 28 Jun 2004 19:32:06 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bf1r4-000BQr-II for v6ops@ops.ietf.org; Mon, 28 Jun 2004 19:31:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25593; Mon, 28 Jun 2004 15:31:47 -0400 (EDT) Message-Id: <200406281931.PAA25593@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-00.txt Date: Mon, 28 Jun 2004 15:31:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 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 : Requirements for assisted tunneling Author(s) : A.Durand, F. Parent Filename : draft-ietf-v6ops-assisted-tunneling-requirements-00.txt Pages : 0 Date : 2004-6-28 This document defines requirements for a tunnel set-up protocol that could be used by an ISP to jumpstart its IPv6 offering to its customers by providing them IPv6 connectivity without having to upgrade its access network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-assisted-tunneling-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-28151226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-assisted-tunneling-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151226.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jun 29 00:34:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06010 for ; Tue, 29 Jun 2004 00:34:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfAGR-000Jyl-Da for v6ops-data@psg.com; Tue, 29 Jun 2004 04:30:35 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfAGL-000Jy6-8U for v6ops@ops.ietf.org; Tue, 29 Jun 2004 04:30:29 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C5A629F for ; Tue, 29 Jun 2004 00:30:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 00:30:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C45D91.CDE9B88D" Subject: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Tue, 29 Jun 2004 00:30:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCBD8@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Thread-Index: AcRdRtOczLdxq1pISuS6JVCjUMQJcwASnAEw From: "Bound, Jim" To: X-OriginalArrivalTime: 29 Jun 2004 04:30:28.0588 (UTC) FILETIME=[CE4B02C0:01C45D91] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C45D91.CDE9B88D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG, Chairs asked me to send this note to you. Updated spec below. First error below I am just the editor see authors in the spec. What we did and I as editor is took 100% Alain's and Pekka's input as best we could for additional clarity. But, in section 4 we put additional note that this section is more of an overview that the reader must look at as components and all the components would fill up many pages (as all scenarios) and more of that is analysis as opposed to defining a scenario, and analysis is the next step. We also added normative references we felt were applicable to the spec that exist and talk about the general subject (e.g. DNS, Applications). I as one author may not be able to respond to mail this week as I am abroad in Europe, but will do my best. =20 Regards, /jim -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 28, 2004 3:31 PM To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-03.txt Pages : 16 Date : 2004-6-28 =09 This document describes the scenarios for IPv6 deployment within Enterprise networks. It will focus upon an Enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of Enterprise solutions in a later document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03.tx t To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ent-scenarios-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C45D91.CDE9B88D Content-Type: application/octet-stream; name="ATT506499.TXT" Content-Description: ATT506499.TXT Content-Disposition: attachment; filename="ATT506499.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDA0LTYtMjgxNTEyMjEuSS1EQGlldGYub3JnPg0KDQpF TkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi12Nm9wcy1lbnQt c2NlbmFyaW9zLTAzLnR4dA0K ------_=_NextPart_001_01C45D91.CDE9B88D Content-Type: application/octet-stream; name="draft-ietf-v6ops-ent-scenarios-03.URL" Content-Description: draft-ietf-v6ops-ent-scenarios-03.URL Content-Disposition: attachment; filename="draft-ietf-v6ops-ent-scenarios-03.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXY2b3BzLWVudC1zY2VuYXJpb3MtMDMudHh0DQo= ------_=_NextPart_001_01C45D91.CDE9B88D-- From owner-v6ops@ops.ietf.org Tue Jun 29 02:09: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 CAA18732 for ; Tue, 29 Jun 2004 02:09:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfBlj-0004Ak-Bl for v6ops-data@psg.com; Tue, 29 Jun 2004 06:06:59 +0000 Received: from [132.151.6.71] (helo=megatron.ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bf46R-000DGR-Be for v6ops@ops.ietf.org; Mon, 28 Jun 2004 21:55:53 +0000 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Bf3up-0000Dx-GJ; Mon, 28 Jun 2004 17:43:51 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , v6ops mailing list , v6ops chair , v6ops chair Subject: Document Action: 'Evaluation of Transition Mechanisms for Unmanaged Networks' to Informational RFC Message-Id: Date: Mon, 28 Jun 2004 17:43:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The IESG has approved the following document: - 'Evaluation of Transition Mechanisms for Unmanaged Networks ' as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary This document is an analysis of "unmanaged networks" [rfc3750] which typically correspond to home networks or small office networks. The document starts with an analysis and then evaluates the suitability of mechanisms that have already been specified, proposed or deployed. Working Group Summary This document is a product of the v6ops working group. Protocol Quality David Kessens reviewed this document for the IESG. From owner-v6ops@ops.ietf.org Tue Jun 29 04:04:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29618 for ; Tue, 29 Jun 2004 04:04:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfDZw-000Jm3-JG for v6ops-data@psg.com; Tue, 29 Jun 2004 08:02:56 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfDZc-000Jij-8g for v6ops@ops.ietf.org; Tue, 29 Jun 2004 08:02:36 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T82YJ13512; Tue, 29 Jun 2004 11:02:34 +0300 (EET DST) X-Scanned: Tue, 29 Jun 2004 11:01:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5T81BMt027519; Tue, 29 Jun 2004 11:01:11 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00Y0IU2k; Tue, 29 Jun 2004 11:01:09 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T819H27624; Tue, 29 Jun 2004 11:01:09 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 29 Jun 2004 11:01:09 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 172.21.154.20 172.21.154.20 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15420.ntc.nokia.com by ESEBE024.noe.nokia.com; 29 Jun 2004 11:01:08 +0300 Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt From: "Soininen Jonne (Nokia-NET/Helsinki)" To: "ext Bound, Jim" Cc: v6ops@ops.ietf.org In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CCBD8@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCBD8@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1088496068.5353.34.camel@essrv103nok15420.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Tue, 29 Jun 2004 11:01:08 +0300 X-OriginalArrivalTime: 29 Jun 2004 08:01:09.0136 (UTC) FILETIME=[3CA59100:01C45DAF] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, if nobody cries very loudly within ca. 24 hours. This is going to the IESG. Cheers, Jonne. On Tue, 2004-06-29 at 07:30, ext Bound, Jim wrote: > WG, > > Chairs asked me to send this note to you. Updated spec below. First > error below I am just the editor see authors in the spec. What we did > and I as editor is took 100% Alain's and Pekka's input as best we could > for additional clarity. But, in section 4 we put additional note that > this section is more of an overview that the reader must look at as > components and all the components would fill up many pages (as all > scenarios) and more of that is analysis as opposed to defining a > scenario, and analysis is the next step. We also added normative > references we felt were applicable to the spec that exist and talk about > the general subject (e.g. DNS, Applications). I as one author may not > be able to respond to mail this week as I am abroad in Europe, but will > do my best. > > Regards, > /jim > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, June 28, 2004 3:31 PM > To: i-d-announce@ietf.org > Cc: v6ops@ops.ietf.org > Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : IPv6 Enterprise Network Scenarios > Author(s) : J. Bound > Filename : draft-ietf-v6ops-ent-scenarios-03.txt > Pages : 16 > Date : 2004-6-28 > > This document describes the scenarios for IPv6 deployment within > Enterprise networks. It will focus upon an Enterprise set of network > base scenarios with assumptions, coexistence with legacy IPv4 nodes, > networks, and applications, and network infrastructure requirements. > These requirements will be used to provide analysis to determine a set > of Enterprise solutions in a later document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03.tx > t > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-v6ops-ent-scenarios-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-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. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Tue Jun 29 04:18:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00694 for ; Tue, 29 Jun 2004 04:18:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfDno-000Lks-2b for v6ops-data@psg.com; Tue, 29 Jun 2004 08:17:16 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfDnd-000Ljd-L4 for v6ops@ops.ietf.org; Tue, 29 Jun 2004 08:17:06 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 12CEC8580; Tue, 29 Jun 2004 10:17:03 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 08392-06; Tue, 29 Jun 2004 10:16:38 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 229027F67; Tue, 29 Jun 2004 10:16:38 +0200 (CEST) Subject: Re: I-D ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-00.txt From: Jeroen Massar To: Alain Durand , Florent Parent Cc: v6ops@ops.ietf.org In-Reply-To: <200406281931.PAA25593@ietf.org> References: <200406281931.PAA25593@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IkXJFRu8G5LlAUQObrBY" Organization: Unfix Message-Id: <1088496993.20311.133.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 29 Jun 2004 10:16:34 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-IkXJFRu8G5LlAUQObrBY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-06-28 at 21:31, Internet-Drafts@ietf.org wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-r= equirements-00.txt My comments: Section 1. 8<--------- "Assisted tunneling" is used in this document to described a transition mechanism where the parameters" --------->8 Should be 'describe'. Section 2. 8<--------- dual stack UE connecting to IPv6 nodes through a 3GPP network that --------->8 What is the definition of a "UE" ? User Endpoint I assume or this more likely to be some 3GPP term of which I am not familiar with. Section 4.1 8<--------- Assignment of an IPv6 address (/128) to the end-node must be supported in both modes. --------->8 Shouldn't we suggest assigning a /64 over 'links'? Tunnels are 'tunnel-link= s' between the TunnelServer and the TunnelClient. Also what if the client moves to a native link. There could be the case whe= re a ISP only can't provision the last mile, eg because the router directly facing the customers doesn't support IPv6 yet. In this and some other cases when the router and the CPE does support IPv6 they can simply lay the /64 tunnel space on the native link and the user nor the ISP have to change muc= h. Also mentioning that ISP's can pass out /128's will cause them to do so and also will have them have a word saying 'see that RFC they say give out /128= 's. Giving out a /64 for a link doesn't mean one can't filter everything except ::1 and ::2 of that /64 btw (or just set a /128 only to the remote side). Read: with /128's IPv6 NAT will happen.... Section 4.4 This could refer to draft-palet-v6ops-tun-auto-disc Section 4.7 Isn't this all out of scope for the setup protocol ? It is good to mention them nevertheless of course but still. Also "not _an_ exhaustive list" which it indeed is as many things can be added. Section 4.8 Though no direct solutions are refered to, this could also mention that proto-41 should not be used as it doesn't get authenticated per packet and thus can easily be spoofed when the access network (client<->server) isn't completely under ingress/egress filtering control, aka when the IPv4 or outer when talking about IPv6-in-IPv6 etc, addresses can be spoofed= . A mention of shaping tunnels, eg ratelimiting per /24 destination IPv4 could also help in cases where somebody tries to DDoS, of course these are preventive measures that can be circumvented, by ddossing the router upstream etc. Section 5.1 How big is a 'typical broadband ISP'. Is this 100 sites? 10k? 100k ? Section 5.2 Like 4.4, this could refer to draft-palet-v6ops-tun-auto-disc Prolly the 'best' is to have: - dns prefix search (tunnelsetup.example.net) - globaly known single anycast address where the setup protocol connects to and asks for service. This anycast address could either say 'see http://www.example.net/ipv6/' or it could say 'no service' or 'get your setup info from host tunnelset= up.example.net' Section 5.3 This basically boils down to using UDP, as I think it should be a requireme= nt to demand per-packet authentication of these tunnels packets to work agains= t spoofing, proto-41 is really a no-go. This also saves for the overhead of figuring out 'are you behind a nat' and 'are you behind a firewall'. If an administator is filtering certain ports/protocols then that should ne= ver be tried to be circumvented. Section 5.4 Some NAT boxes will force-timeout mappings or have a very short timeout. The tunneling or the setup protocol used should be able to recover thus from both endpoint address and port changes without loosing packets. Section 5.5 The latency issue for the config protocol basically means that any tunnel s= etup protocol employing command/response should be able to support some mechanis= m similar to SMTP pipelining. SASL auth defeats the initial setup of course. As can be learned from TSP the overhead is not that large at all thus this should be mostly ignorable. Good to note nevertheless. Section 5.6 8<------- The tunnel set-up protocol must not introduce any new vulnerability to the network. -------->8 Shouldn't that read: 8<--------- The tunnel set-up, nor the tunneling protocol must not introduce any new vulnerability to the network. --------->8 When you only 'secure' the set-up, then people will simply abuse the tunneling protocol. To also mitigate attacks based on 'knowledge' of endpoint information eg by sniffing setup information packets it should be IMHO that the tunnel setup protocol is able to use some form of SSL/TLS mode thus making sure that the interaction between client and server is not readable maybe disclosing information that can be useful to attack the tunnel. Section 5.8 Additionally the protocol should have the generic possiblity of returning a URL. This can be used in many cases: - signup page - help page - explaination page - 'this service is closed' - etc. It could also explain the user how to disable the client program. The client-program might also want to ask the user if it wants to use nativ= e or tunneled connectivity maybe in case where the native connectivity is misconfigured, and thus not working. Section 5.10 Fortunatly this is a should, typically, from what I have seen at least, most ISP's don't allow their customers to change reverse DNS entries. Also, tunnels should be seen as 'transit networks', the /48 routed to the client should have a means of registering dns servers though. Appendix A "The registered mode:" "- implementation SHOULD turn it off by default" Shouldn't asking the client once be a good option? "- MUST support single address assignment" /128 or /64 ? Remember, that when learning people they can give /128's there will be NAT again for IPv6 and why oh why did all these nice people invent IPv6 ? :) See also above at section 4.1 "- MUST support prefix delegation...." As there was a mention of not reinventing the wheel, should this be using DHCPv6 or RA's ? Also the client-utility can't know what the network of the user looks like. Must a prefix also always be a /48? We might want to suggest that here to make sure ISP's adhere to that (yup trying to=20 technically enforce a political policy ;) Next to that, as I see a number of items that do not directly relate to TSP= , is there a totally revamped TSP draft or a totally new protocol in the pipe= ? Greets, Jeroen --=-IkXJFRu8G5LlAUQObrBY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA4SVhKaooUjM+fCMRAuraAJ95PWVdS0i7onRgegsv54P02T4/YgCgvn3D He8vWRb9qdMB2R41epy9r08= =l04s -----END PGP SIGNATURE----- --=-IkXJFRu8G5LlAUQObrBY-- From owner-v6ops@ops.ietf.org Tue Jun 29 05:22:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05222 for ; Tue, 29 Jun 2004 05:22:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfEnD-000394-J3 for v6ops-data@psg.com; Tue, 29 Jun 2004 09:20:43 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfEmr-000361-S9 for v6ops@ops.ietf.org; Tue, 29 Jun 2004 09:20:22 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i5T9KLnE014022 for ; Tue, 29 Jun 2004 10:20:21 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA14753 for ; Tue, 29 Jun 2004 10:20:18 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i5T9KIa31798 for v6ops@ops.ietf.org; Tue, 29 Jun 2004 10:20:18 +0100 Date: Tue, 29 Jun 2004 10:20:18 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) Message-ID: <20040629092018.GF30845@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20040517155721.GQ8946@login.ecs.soton.ac.uk> <20040628161140.GA12315@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I, of course as a user of it, agree also. It's a shame mboned didn't want to pick it up. I don't understand why. Failing that, lets do the work here. Tim On Mon, Jun 28, 2004 at 01:19:10PM -0400, William F. Maton wrote: > On Mon, 28 Jun 2004, Stig Venaas wrote: > > [snip] > >Thanks for the plug Tim. I wrote a draft on a gateway translating > >between IPv4 and IPv6 multicast. It's expired now, but you can find it > >at > >http://www.uninett.no/testnett/multicast/mcgw/draft-venaas-mboned-v4v6mcastgw-00.txt > > > >This solution was implemented 18 months ago, and has been in daily use > >by several people since then. > [snip] > >Are there more appropriate places to take it? > > As someone who is interested in both IPv6 and multicast, yes, this would > be good to see in a document. This group might be the best place for it. > Though I wonder why mboned didn't do anything with it... > > wfms From owner-v6ops@ops.ietf.org Tue Jun 29 07:07: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 HAA11232 for ; Tue, 29 Jun 2004 07:07:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfGQ0-000FCJ-DL for v6ops-data@psg.com; Tue, 29 Jun 2004 11:04:52 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfGPo-000FAo-SD for v6ops@ops.ietf.org; Tue, 29 Jun 2004 11:04:41 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i5TAnoDW005752 for ; Tue, 29 Jun 2004 12:49:50 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i5TAnorL014024 for v6ops@ops.ietf.org; Tue, 29 Jun 2004 12:49:50 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 29 Jun 2004 12:49:50 +0200 From: Stig Venaas To: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) Message-ID: <20040629104950.GA14009@sverresborg.uninett.no> References: <20040517155721.GQ8946@login.ecs.soton.ac.uk> <20040628161140.GA12315@sverresborg.uninett.no> <20040629092018.GF30845@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629092018.GF30845@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jun 29, 2004 at 10:20:18AM +0100, Tim Chown wrote: > I, of course as a user of it, agree also. > > It's a shame mboned didn't want to pick it up. I don't understand why. > Failing that, lets do the work here. If I remember correctly they simply thought it would be better to have the work done here. I think it would be good to document the solution as an informational RFC. Both describing how it can be done, and also possible issues that one should be aware of. Stig From owner-v6ops@ops.ietf.org Tue Jun 29 07:53:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13713 for ; Tue, 29 Jun 2004 07:53:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfHAQ-000M3a-UL for v6ops-data@psg.com; Tue, 29 Jun 2004 11:52:50 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfHAC-000M1p-Q7 for v6ops@ops.ietf.org; Tue, 29 Jun 2004 11:52:37 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i5TBqanE017637 for ; Tue, 29 Jun 2004 12:52:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA23907 for ; Tue, 29 Jun 2004 12:52:35 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i5TBqZE02865 for v6ops@ops.ietf.org; Tue, 29 Jun 2004 12:52:35 +0100 Date: Tue, 29 Jun 2004 12:52:35 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: IPv4-IPv6 multicast gateway WG adoption? Message-ID: <20040629115235.GQ30845@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20040517155721.GQ8946@login.ecs.soton.ac.uk> <20040628161140.GA12315@sverresborg.uninett.no> <20040629092018.GF30845@login.ecs.soton.ac.uk> <20040629104950.GA14009@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629104950.GA14009@sverresborg.uninett.no> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk OK, that's good. Subject line made more relevant... On Tue, Jun 29, 2004 at 12:49:50PM +0200, Stig Venaas wrote: > On Tue, Jun 29, 2004 at 10:20:18AM +0100, Tim Chown wrote: > > I, of course as a user of it, agree also. > > > > It's a shame mboned didn't want to pick it up. I don't understand why. > > Failing that, lets do the work here. > > If I remember correctly they simply thought it would be better to have > the work done here. > > I think it would be good to document the solution as an informational > RFC. Both describing how it can be done, and also possible issues that > one should be aware of. > > Stig From owner-v6ops@ops.ietf.org Tue Jun 29 11:50:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27773 for ; Tue, 29 Jun 2004 11:50:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfKps-000NQo-Lu for v6ops-data@psg.com; Tue, 29 Jun 2004 15:47:52 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfKpT-000NOi-1V for v6ops@ops.ietf.org; Tue, 29 Jun 2004 15:47:27 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Tue, 29 Jun 2004 08:47:28 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 08:46:59 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 08:46:59 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 08:46:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issues with draft-huitema-v6ops-teredo-02.txt Date: Tue, 29 Jun 2004 08:46:53 -0700 Message-ID: Thread-Topic: Issues with draft-huitema-v6ops-teredo-02.txt thread-index: AcRc0ycJ8LosRo6vTL+FaHlULYaIiQBHALTQ From: "Christian Huitema" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , X-OriginalArrivalTime: 29 Jun 2004 15:46:56.0230 (UTC) FILETIME=[4E69B060:01C45DF0] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I've got a few questions regarding draft-huitema-v6ops-teredo-02.txt >=20 > > 5.1.2 Maximum Transmission Unit > > > > The default link MTU assumed by a host, and the link MTU supplied by > > a Teredo server during router advertisement SHOULD normally be set > > to the minimum IPv6 MTU size of 1280 bytes [RFC2460]. >=20 > Should the server embed a MTU in its RA? Yes, that is what the spec says. On the other hand, the server must not = advertise a value different from 1280, and the clients should ignore any = advertisement different from 1280. The server is not on the path of most = communications, and thus has no idea of what the proper MTU would be on = the path between two nodes.=20 The flip part of the requirement is that Teredo nodes must have adequate = reassembly buffers to handle a 1280 byte IPv6 payload in an IPv4/UDP = packet. > > 5.2.1 Qualification procedure > (...) > > The client selects a secondary IPv4 server address, and > > repeats the procedure, the cone bit remaining to the value zero. >=20 > How is the secondary IPv4 server address determined? > The implementation currently shipped with Windows XP seems to = increment > the primary server address by one, but that behavior is not documented > in the spec. The implementation in Windows XP reads the secondary IP address from the = DNS.=20 > > 5.3 Teredo Server specification > (...) > > The Teredo server > > waits for incoming UDP packets at the Teredo Port, using the IPv4 > > address that has been selected for the service. In addition, the > > server is able to receive and transmit some packets using a > > different IPv4 address and a different port number. >=20 > I thought the port number was 3544 in both cases. Is that not the = case, > and, if so, how is the port determined by the client? Correct. The server must listen on port 3544 on the secondary address = for the qualification procedure to work. > > 5.4.1 Transmission by relays to Teredo clients > (...) > > Before processing these packets, the Teredo Server MUST check that > > the IPv4 destination address embedded in the Teredo IPv6 address is > > in the format of a global unicast address; if this is not the case, > > the packet MUST be silently discarded. >=20 > I'm fairly confused there: Is it the server's or the relay's job to > check the "IPv4 destination address embedded in the Teredo IPv6 > address" ? The text should read "Teredo Relay" instead of "Teredo Server." Sorry = about that. Thanks for the review. I will correct these points in the next version = of the draft. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Jun 29 12:41:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00917 for ; Tue, 29 Jun 2004 12:41:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfLe1-0003q3-Vi for v6ops-data@psg.com; Tue, 29 Jun 2004 16:39:41 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfLdq-0003oP-VU for v6ops@ops.ietf.org; Tue, 29 Jun 2004 16:39:31 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5TGdUil009997 for ; Tue, 29 Jun 2004 10:39:30 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I0200K76WXT8G@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 29 Jun 2004 10:39:30 -0600 (MDT) Received: from sun.com ([129.146.11.151]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPS id <0I02003ZXWXTL5@mail.sun.net> for v6ops@ops.ietf.org; Tue, 29 Jun 2004 10:39:29 -0600 (MDT) Date: Tue, 29 Jun 2004 09:39:28 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-00.txt In-reply-to: <1088496993.20311.133.camel@segesta.zurich.ibm.com> To: Jeroen Massar Cc: Florent Parent , v6ops@ops.ietf.org Message-id: <40E19B40.4090005@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 References: <200406281931.PAA25593@ietf.org> <1088496993.20311.133.camel@segesta.zurich.ibm.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Jeroen, Thank you for your comments. I'll get back to them later this week I'm on a businees trip. Jeroen Massar wrote: >Next to that, as I see a number of items that do not directly relate to TSP, >is there a totally revamped TSP draft or a totally new protocol in the pipe? > > The later. - Alain. From owner-v6ops@ops.ietf.org Tue Jun 29 13:49:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04788 for ; Tue, 29 Jun 2004 13:48:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfMfy-000CXx-S5 for v6ops-data@psg.com; Tue, 29 Jun 2004 17:45:46 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfMeb-000CNH-9q for v6ops@ops.ietf.org; Tue, 29 Jun 2004 17:44:21 +0000 Received: from [207.31.248.169] (account margaret HELO [10.0.0.41]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 96105; Tue, 29 Jun 2004 13:42:13 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Tue, 29 Jun 2004 13:44:16 -0400 To: "Soininen Jonne (Nokia-NET/Helsinki)" From: Margaret Wasserman Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Cc: v6ops@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jonne, In general, I think this document looks good. There are two small issues that I think should be addressed before it goes to the IESG, though. (1) There are several lines in the document that are longer than 80 characters and there may be other I-D Checklist violations (I didn't do a complete check). Is it safe to assume that the WG chairs will do an I-D Checklist review and get any issues fixed before sending this to the IESG? (2) The abstract doesn't seem very clear to me... It says: This document describes the scenarios for IPv6 deployment within enterprise networks. It will focus upon an enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of enterprise solutions in a later document. How about this? This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. Margaret From owner-v6ops@ops.ietf.org Wed Jun 30 02:08: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 CAA02187 for ; Wed, 30 Jun 2004 02:08:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfYCL-000DdS-Ge for v6ops-data@psg.com; Wed, 30 Jun 2004 06:03:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfYCJ-000Dcx-Ja for v6ops@ops.ietf.org; Wed, 30 Jun 2004 06:03:56 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5U63kQ24108; Wed, 30 Jun 2004 09:03:46 +0300 Date: Wed, 30 Jun 2004 09:03:46 +0300 (EEST) From: Pekka Savola To: "Soininen Jonne (Nokia-NET/Helsinki)" cc: "ext Bound, Jim" , Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt In-Reply-To: <1088496068.5353.34.camel@essrv103nok15420.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 29 Jun 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote: > if nobody cries very loudly within ca. 24 hours. This is going to the > IESG. I don't think this addresses my personal comments. The most important of them, an applicability statement about a security defence network (supported by Richard Graveman at least), hasn't been included. There are also some others which I'm not sure why they weren't included, I think Yanick's reply on the list OK'ed some of them. BTW, wrt. Margaret's comment, there are no too long lines in the draft, but some lines have been wrapped due to being too long (that's what she was referring to, I think), and should be fixed. > On Tue, 2004-06-29 at 07:30, ext Bound, Jim wrote: > > WG, > > > > Chairs asked me to send this note to you. Updated spec below. First > > error below I am just the editor see authors in the spec. What we did > > and I as editor is took 100% Alain's and Pekka's input as best we could > > for additional clarity. But, in section 4 we put additional note that > > this section is more of an overview that the reader must look at as > > components and all the components would fill up many pages (as all > > scenarios) and more of that is analysis as opposed to defining a > > scenario, and analysis is the next step. We also added normative > > references we felt were applicable to the spec that exist and talk about > > the general subject (e.g. DNS, Applications). I as one author may not > > be able to respond to mail this week as I am abroad in Europe, but will > > do my best. > > > > Regards, > > /jim > > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Monday, June 28, 2004 3:31 PM > > To: i-d-announce@ietf.org > > Cc: v6ops@ops.ietf.org > > Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IPv6 Operations Working Group of the > > IETF. > > > > Title : IPv6 Enterprise Network Scenarios > > Author(s) : J. Bound > > Filename : draft-ietf-v6ops-ent-scenarios-03.txt > > Pages : 16 > > Date : 2004-6-28 > > > > This document describes the scenarios for IPv6 deployment within > > Enterprise networks. It will focus upon an Enterprise set of network > > base scenarios with assumptions, coexistence with legacy IPv4 nodes, > > networks, and applications, and network infrastructure requirements. > > These requirements will be used to provide analysis to determine a set > > of Enterprise solutions in a later document. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-03.tx > > t > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-v6ops-ent-scenarios-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-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. > -- 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 Jun 30 03:27: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 DAA28542 for ; Wed, 30 Jun 2004 03:27:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfZSo-000P66-1O for v6ops-data@psg.com; Wed, 30 Jun 2004 07:25:02 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfZSk-000P52-7h for v6ops@ops.ietf.org; Wed, 30 Jun 2004 07:24:58 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4B06AB922; Wed, 30 Jun 2004 03:24:54 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 03:24:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Wed, 30 Jun 2004 03:24:53 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCC89@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Thread-Index: AcReaBW0/TdoHXy/R5CHboBxQTGEZAACwnkg From: "Bound, Jim" To: "Pekka Savola" , "Soininen Jonne (Nokia-NET/Helsinki)" Cc: X-OriginalArrivalTime: 30 Jun 2004 07:24:54.0123 (UTC) FILETIME=[56A6ABB0:01C45E73] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, All of your comments were addressed. We are not removing the Seucrity Defense scenarios it is important the market. No one but you complained you were out voted essentially. So forget that aspect of your input answer is NO. =20 Regarding other comments please relay what you think we missed. But no one else is complaining but you. /jim=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Wednesday, June 30, 2004 2:04 AM > To: Soininen Jonne (Nokia-NET/Helsinki) > Cc: Bound, Jim; v6ops@ops.ietf.org > Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt >=20 > On Tue, 29 Jun 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > if nobody cries very loudly within ca. 24 hours. This is=20 > going to the=20 > > IESG. >=20 > I don't think this addresses my personal comments. The most=20 > important of them, an applicability statement about a=20 > security defence network (supported by Richard Graveman at=20 > least), hasn't been included. >=20 > There are also some others which I'm not sure why they=20 > weren't included, I think Yanick's reply on the list OK'ed=20 > some of them. >=20 > BTW, wrt. Margaret's comment, there are no too long lines in=20 > the draft, but some lines have been wrapped due to being too=20 > long (that's what she was referring to, I think), and should be fixed. >=20 > > On Tue, 2004-06-29 at 07:30, ext Bound, Jim wrote: > > > WG, > > >=20 > > > Chairs asked me to send this note to you. Updated spec=20 > below. First=20 > > > error below I am just the editor see authors in the spec.=20 > What we=20 > > > did and I as editor is took 100% Alain's and Pekka's=20 > input as best=20 > > > we could for additional clarity. But, in section 4 we put=20 > > > additional note that this section is more of an overview that the=20 > > > reader must look at as components and all the components=20 > would fill=20 > > > up many pages (as all > > > scenarios) and more of that is analysis as opposed to defining a=20 > > > scenario, and analysis is the next step. We also added normative=20 > > > references we felt were applicable to the spec that exist=20 > and talk=20 > > > about the general subject (e.g. DNS, Applications). I as=20 > one author=20 > > > may not be able to respond to mail this week as I am abroad in=20 > > > Europe, but will do my best. > > >=20 > > > Regards, > > > /jim > > >=20 > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On=20 > > > Behalf Of Internet-Drafts@ietf.org > > > Sent: Monday, June 28, 2004 3:31 PM > > > To: i-d-announce@ietf.org > > > Cc: v6ops@ops.ietf.org > > > Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt > > >=20 > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > directories. > > > This draft is a work item of the IPv6 Operations Working Group of=20 > > > the IETF. > > >=20 > > > Title : IPv6 Enterprise Network Scenarios > > > Author(s) : J. Bound > > > Filename : draft-ietf-v6ops-ent-scenarios-03.txt > > > Pages : 16 > > > Date : 2004-6-28 > > > =09 > > > This document describes the scenarios for IPv6 deployment within=20 > > > Enterprise networks. It will focus upon an Enterprise set of=20 > > > network base scenarios with assumptions, coexistence with legacy=20 > > > IPv4 nodes, networks, and applications, and network=20 > infrastructure requirements. > > > These requirements will be used to provide analysis to=20 > determine a=20 > > > set of Enterprise solutions in a later document. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-0 > > > 3.tx > > > t > > >=20 > > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > > i-d-announce-request@ietf.org with the word unsubscribe=20 > in the body=20 > > > of the message. > > > You can also visit=20 > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > >=20 > > >=20 > > > Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > > > username "anonymous" and a password of your e-mail address. After=20 > > > logging in, type "cd internet-drafts" and then > > > "get draft-ietf-v6ops-ent-scenarios-03.txt". > > >=20 > > > A list of Internet-Drafts directories can be found in=20 > > > http://www.ietf.org/shadow.html or=20 > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >=20 > > >=20 > > > Internet-Drafts can also be obtained by e-mail. > > >=20 > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-03.txt". > > > =09 > > > 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=20 > > > 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. > > > =09 > > > =09 > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the=20 > > > Internet-Draft. > >=20 >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jun 30 03:27:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28560 for ; Wed, 30 Jun 2004 03:27:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfZUC-000PDC-Qh for v6ops-data@psg.com; Wed, 30 Jun 2004 07:26:28 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfZUB-000PCy-KV for v6ops@ops.ietf.org; Wed, 30 Jun 2004 07:26:27 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 54F0C1A50; Wed, 30 Jun 2004 03:26:27 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 03:26:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Date: Wed, 30 Jun 2004 03:26:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCC8A@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Thread-Index: AcReAW/Wgq1UpPwqStmYYTSzvIU5/AAchTYg From: "Bound, Jim" To: "Margaret Wasserman" , "Soininen Jonne (Nokia-NET/Helsinki)" Cc: X-OriginalArrivalTime: 30 Jun 2004 07:26:27.0077 (UTC) FILETIME=[8E0E5350:01C45E73] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This looks good to me if others are fine with it. Thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Margaret Wasserman > Sent: Tuesday, June 29, 2004 1:44 PM > To: Soininen Jonne (Nokia-NET/Helsinki) > Cc: v6ops@ops.ietf.org > Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt >=20 >=20 > Hi Jonne, >=20 > In general, I think this document looks good. >=20 > There are two small issues that I think should be addressed=20 > before it goes to the IESG, though. >=20 > (1) There are several lines in the document that are longer=20 > than 80 characters and there may be other I-D Checklist=20 > violations (I didn't do a complete check). Is it safe to=20 > assume that the WG chairs will do an I-D Checklist review and=20 > get any issues fixed before sending this to the IESG? >=20 > (2) The abstract doesn't seem very clear to me... >=20 > It says: >=20 > This document describes the scenarios for IPv6 deployment within > enterprise networks. It will focus upon an enterprise=20 > set of network > base scenarios with assumptions, coexistence with legacy=20 > IPv4 nodes, > networks, and applications, and network infrastructure=20 > requirements. > These requirements will be used to provide analysis to determine a > set of enterprise solutions in a later document. >=20 > How about this? >=20 > This document describes the scenarios for IPv6 deployment within > enterprise networks. It defines a small set of basic enterprise > scenarios and includes pertinent questions to allow enterprise > administrators to further refine their deployment=20 > scenarios. Enterprise > deployment requirements are discussed in terms of coexistence with > IPv4 nodes, networks and applications, and in terms of=20 > basic network > infrastructure requirements for IPv6 deployment. The=20 > scenarios and > requirements described in this document will be the basis=20 > for further > analysis to determine what coexistence techniques and mechanisms > are needed for enterprise IPv6 deployment. The results=20 > of that analysis > will be published in a separate document. >=20 > Margaret >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jun 30 04:08: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 EAA00676 for ; Wed, 30 Jun 2004 04:08:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfa7h-0003q6-Sw for v6ops-data@psg.com; Wed, 30 Jun 2004 08:07:17 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfa7g-0003pj-N1 for v6ops@ops.ietf.org; Wed, 30 Jun 2004 08:07:17 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U87EJ04389 for ; Wed, 30 Jun 2004 11:07:15 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 11:06:54 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5U86smA012339 for ; Wed, 30 Jun 2004 11:06:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00eVk70K; Wed, 30 Jun 2004 11:06:52 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U86qH06191 for ; Wed, 30 Jun 2004 11:06:52 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 11:06:51 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 172.21.154.20 172.21.154.20 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15420.ntc.nokia.com by ESEBE024.noe.nokia.com; 30 Jun 2004 11:06:49 +0300 Subject: On vacation: back on July 26th From: "Soininen Jonne (Nokia-NET/Helsinki)" Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1088582809.5448.7.camel@essrv103nok15420.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Wed, 30 Jun 2004 11:06:49 +0300 X-OriginalArrivalTime: 30 Jun 2004 08:06:51.0985 (UTC) FILETIME=[3369EC10:01C45E79] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I will be away on vacation until July 26th. Alas, I will not have mail connection during at least a part of that time. Good summer for everybody! Cheers, Jonne. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Wed Jun 30 14:24:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03259 for ; Wed, 30 Jun 2004 14:24:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfjj4-000IYP-0T for v6ops-data@psg.com; Wed, 30 Jun 2004 18:22:30 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfjiz-000IXk-JL for v6ops@ops.ietf.org; Wed, 30 Jun 2004 18:22:26 +0000 Received: from [207.31.248.169] (account margaret HELO [10.0.0.41]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 96657; Wed, 30 Jun 2004 13:50:13 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CCC8A@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCC8A@tayexc13.americas.cpqcorp.net> Date: Wed, 30 Jun 2004 13:52:12 -0400 To: "Bound, Jim" , "Soininen Jonne (Nokia-NET/Helsinki)" From: Margaret Wasserman Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, [Private note, just because no one else cares... :-)] My contact information is wrong in this document. If you are going to re-spin it for other reasons, please change my contact information to: Margaret Wasserman ThingMagic One Broadway Cambridge, MA 02142 (617) 758-4177 margaret@thingmagic.com Don't bother with an update just to change this, though. We could always do it in AUTH48. BTW, I think that you have done a good job of bringing this document together, and the results are excellent. Margaret From owner-v6ops@ops.ietf.org Wed Jun 30 14:24: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 OAA03279 for ; Wed, 30 Jun 2004 14:24:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfjjA-000IZH-TG for v6ops-data@psg.com; Wed, 30 Jun 2004 18:22:36 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfjj1-000IXk-Lh for v6ops@ops.ietf.org; Wed, 30 Jun 2004 18:22:28 +0000 Received: from [207.31.248.169] (account margaret HELO [10.0.0.41]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 96668; Wed, 30 Jun 2004 14:00:34 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: Date: Wed, 30 Jun 2004 14:02:39 -0400 To: Pekka Savola , "Soininen Jonne (Nokia-NET/Helsinki)" From: Margaret Wasserman Subject: Re: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt Cc: "ext Bound, Jim" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, At 9:03 AM +0300 6/30/04, Pekka Savola wrote: >I don't think this addresses my personal comments. The most important >of them, an applicability statement about a security defence network >(supported by Richard Graveman at least), hasn't been included. I apologize, but I think I missed what you suggested for an applicability statement for the Security Defense network... Could you summarize? I believe that this scenario is an interesting and important scenario to explore. How will people who are running highly secure/mobile networks today transition to IPv6? I do not want us to head down a rat hole of defining how things could be done in IPv6 that cannot be done in IPv4 today, but if you have a secure, highly mobile IPv4 network today (and some enterprises do, particularly in the defense space), I do think it is interesting and important to talk about how to deploy IPv6 into that type of network without compromising security or mobility for IPv4, IPv6 or dual-stack nodes. At least within the U.S. Department of Defense there has been some resistance to deploying IPv6 on "operational" networks, because of uncertainty about the security implications of doing so. It would be good for us to explore those implications, dispell any myths, and close any holes that do exist. Margaret From owner-v6ops@ops.ietf.org Wed Jun 30 17:48:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22626 for ; Wed, 30 Jun 2004 17:48:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfmtN-000GyT-Fd for v6ops-data@psg.com; Wed, 30 Jun 2004 21:45:21 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfmtM-000Gxr-0P for v6ops@ops.ietf.org; Wed, 30 Jun 2004 21:45:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5ULjF2r035275; Wed, 30 Jun 2004 23:45:15 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1088436316.17109.15.camel@blue.fries.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B067CC9B2@tayexc13.americas.cpqcorp.net> <5C5398EE-C5ED-11D8-A349-000A95CD987A@muada.com> <1088436316.17109.15.camel@blue.fries.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9213B6C0-CADE-11D8-9359-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: DSTM Date: Wed, 30 Jun 2004 23:43:48 +0200 To: todd@fries.net X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-jun-04, at 17:25, Todd T. Fries wrote: > It seems strange to me that VRRP is mentioned on a v6ops mailing list > when, as far as I have been lead to believe, VRRP does not support V6. We were discussing providing IPv4 service over native IPv6 networks. In today's IPv4 networks routers acting as default gateway for a number of hosts are often "clustered" using HSRP or VRRP. This works very well, it would be a shame if this functionality wouldn't be available when running IPv4 over IPv6. Note that in IPv6 the need for VRRP isn't as acute as in IPv4 as there isn't much reliance on statically configured default gateways. From owner-v6ops@ops.ietf.org Wed Jun 30 20:05:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01359 for ; Wed, 30 Jun 2004 20:05:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfp2m-0007AL-Um for v6ops-data@psg.com; Thu, 01 Jul 2004 00:03:12 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfp2k-00079m-Ug for v6ops@ops.ietf.org; Thu, 01 Jul 2004 00:03:11 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i61039600505 for ; Thu, 1 Jul 2004 03:03:09 +0300 (EET DST) X-Scanned: Thu, 1 Jul 2004 03:03:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i61034kj010753 for ; Thu, 1 Jul 2004 03:03:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 002BiqMK; Thu, 01 Jul 2004 03:03:02 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6102vH13006 for ; Thu, 1 Jul 2004 03:02:57 +0300 (EET DST) Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 19:02:56 -0500 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id i6102tje011853 for ; Wed, 30 Jun 2004 17:02:55 -0700 Received: (from kessens@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id i6102s0Q011851 for v6ops@ops.ietf.org; Wed, 30 Jun 2004 17:02:54 -0700 Date: Wed, 30 Jun 2004 17:02:54 -0700 From: David Kessens To: v6ops@ops.ietf.org Subject: Moving forward Message-ID: <20040701000254.GA11822@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 01 Jul 2004 00:02:56.0152 (UTC) FILETIME=[C31F2980:01C45EFE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The v6ops working group is getting closer to finishing all it's work items. This obviously means that an old question is rightfully surfacing again: which proposed solutions do we need for which scenario, and the follow up question, will we standarize this solution and where ? All this hard work has helped to have a better understanding on which minimum set of mechanisms need standarization. It is pretty clear that it is now getting time that we start to move from the analysis phase to standarization. As you all know, in general the Operations area doesn't design new protocols. This means we cannot standarize the solutions in the v6ops working group. However, the ADs would like to hear officially from the working group what protocols need standarization for which scenario. After that, the IESG can decide to accept that work in an existing working group in another area, a new working group can be formed or the work can proceed without the need for a working group. It is not going to be an easy task to reach consensus on each and every scenario and which solution(s) is/are most appropriate. In the interest of making progress it seems best in cases where no quick consensus can be reached to document the disagreement with pros and cons and move on. I expect to have results ready fairly soon after the IETF in San Diego. This process should result in a recommendation from the working group on which minimum set of protocols need to be standarized and which proposals didn't reach consensus but could be useful. Criteria used should involve (among others): simplicity, can this problem already be solved with a different solution that can be used in multiple cases?, security and proven to work in practise (running code). Most likely, there will be a group of proposals for solutions that are not going to be choosen by the working group due to lack of consensus on the need for standarization or the fact that they are not the preferred solution. In such cases, I would nevertheless like to get them published through the rfc-editor as an informational or experimental rfc. However, if there is significant support for the document, it got quite some review in the IETF and/or multiple implementations exist, the ADs might decide to propose to the IESG to use a modified to-be-developed boilerplate that takes the above in consideration. I hope this helps, David Kessens ---