From owner-v6ops@ops.ietf.org Sun Dec 1 08:39:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04340 for ; Sun, 1 Dec 2002 08:39:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IUL9-0003fp-00 for v6ops-data@psg.com; Sun, 01 Dec 2002 05:40:55 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18IUL7-0003eq-00 for v6ops@ops.ietf.org; Sun, 01 Dec 2002 05:40:53 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA16479; Sun, 1 Dec 2002 05:39:56 -0800 (PST) Message-Id: <5.1.0.14.0.20021201081253.0314dc08@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 01 Dec 2002 08:29:32 -0500 To: Fred Templin From: Margaret Wasserman Subject: Re: isatap-07 draft offered as last-call Cc: v6ops@ops.ietf.org In-Reply-To: <20021121140230.95412.qmail@web13001.mail.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Fred, >Specifically, Harald's message states: > > > There are several ways around this if you want things published: > > - Publish through other mechanisms than the RFC process > > - Publish as Experimental RFC > > - Plead with the ADs to sponsor the mechanisms for standards track > based on their obvious merits >(identifying the mechanisms they obsolete) > >Thus, I am seeking to publish as an Experimental RFC and also pleading >with the ADs to >sponsor the mechanism for standards track based on obsoleting RFC 2529 >(6over4). I'm not quite sure what Harald meant in his message, and you may want to ask him for a clarification. Although the standards are lower for publishing a document as experimental, I think that experimental documents basically go through the same process (with somewhat less review, perhaps) as standards track document. This WG is not chartered to work anything (informational, experimental, BCP or standards track) that isn't explicitly in our charter... ISATAP is not currently in our charter, and won't be added to our charter unless/until it is identified as a necessary transition mechanism as part of our deployment scenarios/analysis work. So, at this particular point in time, discussion of ISATAP (and any publication of this document, experimental or otherwise) is out-of-scope for the v6ops WG. I know that folks aren't happy with this situation, and I realize that there are several documents stuck in a similar state (Teredo, DSTM, etc.). The best way to get the necessary transition mechanisms un-stuck is to work on the deployment scenario/analysis documents (by reviewing them and providing detailed feedback, submitting text, etc.), and to help drive them to completion as soon as possible. Of course, as part of this process, we may also find that some of our mechanisms (either the ones that have been published as RFCs or the ones that haven't) are not necessary and/or require updates to meet the needs of the expected transition scenarios. There are also some other publication options available outside the v6ops WG, including: - Publishing these documents elsewhere (through an industry consortium, another standards body, or your own website). - Submitting them to the RFC editor as individual submissions. However, this path may just lead to the documents being referred to the IESG and referred back to the v6ops WG, where we will be unable to make a determination regarding their merit until we have completed our deployment scenarios and analysis work... BTW, pleading with ADs (for anything) is probably more likely to be effective if you discuss your issue with them directly, rather than expecting them to find your request on the mailing list. Margaret From owner-v6ops@ops.ietf.org Sun Dec 1 11:35:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09904 for ; Sun, 1 Dec 2002 11:35:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IX2x-0009Aw-00 for v6ops-data@psg.com; Sun, 01 Dec 2002 08:34:19 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18IX2u-0009Aj-00 for v6ops@ops.ietf.org; Sun, 01 Dec 2002 08:34:16 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id C14717E37; Sun, 1 Dec 2002 17:34:03 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id B60F4782B; Sun, 1 Dec 2002 17:33:57 +0100 (CET) From: "Jeroen Massar" To: , <6bone@ISI.EDU> Cc: , , , , , , , , , Subject: Ghost Route Hunter Date: Sun, 1 Dec 2002 17:34:52 +0100 Organization: Unfix Message-ID: <000301c29957$93938bc0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=0.6 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09904 I am proud to present a smallish analytical tool we've developed for tracking down Ghost Routes. The tool is called: Ghost Route Hunter and can be found at: https://www.sixxs.net/tools/grh/ It analyzes routing table dumps and filters out all 'good' ASpaths. The remaining ASpaths are too long and are so called 'ghost routes'. These Ghost Routes cause the blackholing effect seen many times before when upgrading RIR space from a /35 to a /32. We've just conducted a small test by announcing the Easynet prefix 2001:6f8:e000::/35, which wasn't used and announced before. Easynet only announces 2001:6f8::/35 at this moment due to the danger of ghostroutes when upgrading it to a /32. At 14:30* it wasn't visible yet as a ghost route, at the next table collection at 14:45 it was visible as a ghost route in both the routers of Tilab and Noris. At 15:00 it was only visible on the Intouch router but it had spread quite rapidly already around the world creating a long ASpath. Then we retracted the route again and at 15:20 it fortunatly vanished. Would this been a real announcement, eg by upgrading a /35 to a /32 this would have caused a blackhole for the complete /32 unless the /35 would have been announced forever. One very important thing we saw with this small test was the fact that VERAT where originating the prefix at one moment. Also DFN (JOIN) which appears in about 90%+ of all the ghost routes should check up their equipment. Another possible important player in this could be AS10318 (Cablevision S.A.) which isn't even in the european continent nor peering directly with the ghosted prefixes. Currently there are still 4 big ghost routes floating around: - 3ffe:100::/24 netname: TELEBIT descr: pTLA delegation for the 6bone Which dropped of the internet around tuesday when looking at the latency graphs*. ipv6telebit.tbit.dk is unreachable over IPv4. The graphs also show that it was only reachable from two out six sites. - 3ffe:1400::/24 netname: UNI-C descr: pTLA delegation for the 6bone remarks: *************************************** remarks: * * * * no longer operational * * * * remarks: *************************************** But still visible and ghosted and not officially retracted! Last changed line: changed: Anders.Bandholm@uni-c.dk 20010420 This would mean that the route would have been gone for over a year and a half! This route is currently announced by VERAT and Deutsche Telekom though. - 3ffe:1e00::/24 ipv6-site: SWISSCOM origin: AS3303 descr: Swisscom Innovations No netname available apparently. But it is currently announced by: source: APNIC aut-num: AS4697 as-name: NTTV6NET descr: NTT Software Laboratories I have already contacted these people seperatly, no response as yet. Nothing in their 6bone object seems reachable. - 3ffe:8010::/28 ipv6-site: ICM-PL origin: AS8664 descr: Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University, Poland Origin is currently ICM-PL and ICP-AS. 6bone-gw.6bone.pl is unreachable over IPv4 and IPv6 http://www.6bone.net/6bone_pTLA_list.html doesn't show that NL-BIT6/NL was returned. Apparently 3ffe:1400::/24 should say that too. * direct links: 14:30 https://www.sixxs.net/tools/grh/ghosts/?year=2002&month=12&day=01&time=1 43017 15:00 https://www.sixxs.net/tools/grh/ghosts/?year=2002&month=12&day=01&time=1 50009 15:20 https://www.sixxs.net/tools/grh/ghosts/?year=2002&month=12&day=01&time=1 52013 Latency graphs: https://www.sixxs.net/misc/latency/ Companies mentioned have been CC'd. This goes to both v6ops and 6bone as it causes many effects in both RIR and 6bone space. Greets, Jeroen From owner-v6ops@ops.ietf.org Sun Dec 1 18:16:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17818 for ; Sun, 1 Dec 2002 18:16:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IdKF-000Kia-00 for v6ops-data@psg.com; Sun, 01 Dec 2002 15:16:35 -0800 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 18IdKC-000KiN-00 for v6ops@ops.ietf.org; Sun, 01 Dec 2002 15:16:33 -0800 Received: (qmail 96660 invoked by uid 1007); 1 Dec 2002 23:16:25 -0000 Date: Mon, 2 Dec 2002 00:16:25 +0100 From: Gert Doering To: Jeroen Massar Cc: v6ops@ops.ietf.org, 6bone@ISI.EDU, dnofal@CVTCI.COM.AR, radovic@net.yu, stana@verat.net, awl@verat.net, wlf@verat.net, noc@noc.dfn.de, kukl@tbit.dk, hha@tbit.dk, Anders.Bandholm@uni-c.dk, Ole.Kjaergaard@uni-c.dk Subject: Re: Ghost Route Hunter Message-ID: <20021202001625.F15927@Space.Net> References: <000301c29957$93938bc0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000301c29957$93938bc0$210d640a@unfix.org>; from jeroen@unfix.org on Sun, Dec 01, 2002 at 05:34:52PM +0100 X-NCC-RegID: de.space X-Spam-Status: No, hits=-5.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Sun, Dec 01, 2002 at 05:34:52PM +0100, Jeroen Massar wrote: > At 14:30* it wasn't visible yet as a ghost route, at the > next table collection at 14:45 it was visible as a ghost route > in both the routers of Tilab and Noris. > At 15:00 it was only visible on the Intouch router but it had > spread quite rapidly already around the world creating a long ASpath. > Then we retracted the route again and at 15:20 it fortunatly vanished. I just want to point out that this is mostly normal BGP behaviour in the face of highly meshed topologies and/or participating routers with a slow CPU. The way BGP works upon withdraw (figure out what's the "second best path", and happily announce that path to all your neighbors, and do not announce the next update before minute has passed!) it's pretty normal for a route to "ghost around" for 30 minutes or even longer after a full withdraw. If you look at a BGP table in that time, the path will be changing every few minutes. You can observe this in the IPv4 world as well - if you withdraw a prefix completely, and then do traceroutes on that route, you'll see that it will be routed for quite a while before it finally is dropped from the DFZ. It usually takes 15-20 minutes, but the IPv4 world is much less tightly meshed due to policitical reasons. (This behaviour is also known from RIP, and from there it's also called "count to infinity" for BGP) The thing that I have called "Ghost Routes" was something different - one of the routers involved not properly propagating the withdraw to all his neighbors. After all other paths have disappeared, this prefix is still seen by the neighbor (no regular "full sync" in BGP) and believed until the next session clear. This can be seen in the routing table as a static BGP path that isn't changing over many hours or in some cases even over many days or weeks. [..] > Would this been a real announcement, eg by upgrading a /35 to a /32 > this would have caused a blackhole for the complete /32 unless > the /35 would have been announced forever. ... for those 75 minutes, yes. > One very important thing we saw with this small test was the fact > that VERAT where originating the prefix at one moment. > Also DFN (JOIN) which appears in about 90%+ of all the ghost routes > should check up their equipment. Another possible important player > in this could be AS10318 (Cablevision S.A.) which isn't even in the > european continent nor peering directly with the ghosted prefixes. I wouldn't point fingers at ASes and equipment yet (not without evidence that the prefix really gets stuck for a longer time). But it is strong evidence that the "6mess" needs to cleaned up Real Soon Now, i.e.: don't give everybody *and the whole world behind him* transit everyhwere. [..] > Currently there are still 4 big ghost routes floating around: > - 3ffe:100::/24 > netname: TELEBIT Seconded, this looks very much like a ghost. The paths that I observe are completely unchanged since over 24 hrs. From a cursory view, it seems to be stuck in 1275 or between 1275 and 2603. > - 3ffe:1400::/24 > netname: UNI-C I don't have that prefix. > - 3ffe:1e00::/24 > ipv6-site: SWISSCOM Seconded. Overly long AS paths, static since > 24 hrs. > - 3ffe:8010::/28 > ipv6-site: ICM-PL Seconded. Overly long AS paths, static since > 24 hrs. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54136 (50279) 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 Sun Dec 1 23:27:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23380 for ; Sun, 1 Dec 2002 23:27:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IiCE-0002Yr-00 for v6ops-data@psg.com; Sun, 01 Dec 2002 20:28:38 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18IiCC-0002Yf-00 for v6ops@ops.ietf.org; Sun, 01 Dec 2002 20:28:37 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 09:58:23 +0530 Message-ID: From: "Thakur, Anand" To: itojun@iijlab.net Cc: "V6ops (E-mail)" Subject: RE: on NAT-PT Date: Mon, 2 Dec 2002 10:04:31 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk i once read in an article (probably by nokia) that mobile ipv6 has been mandated for 3gpp.is it true? anand thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 From owner-v6ops@ops.ietf.org Mon Dec 2 00:44:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25115 for ; Mon, 2 Dec 2002 00:44:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IjPd-0004KQ-00 for v6ops-data@psg.com; Sun, 01 Dec 2002 21:46:33 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18IjPb-0004KD-00 for v6ops@ops.ietf.org; Sun, 01 Dec 2002 21:46:31 -0800 Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16757 for ; Sun, 1 Dec 2002 22:46:30 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H6H006CQ9DGKR@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Sun, 01 Dec 2002 22:46:30 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H6H00JGE9DFVE@mail.sun.net> for v6ops@ops.ietf.org; Sun, 01 Dec 2002 22:46:28 -0700 (MST) Date: Sun, 01 Dec 2002 21:47:03 -0800 From: Alain Durand Subject: Re: on NAT-PT In-reply-to: <3DE5DEE3.10B63AFB@hursley.ibm.com> To: Brian E Carpenter Cc: itojun@iijlab.net, v6ops@ops.ietf.org Message-id: <7BD30663-05B9-11D7-A06E-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.548) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Thursday, November 28, 2002, at 01:16 AM, Brian E Carpenter wrote: > I think we need an RFC which discusses the issues with NAT-PT > that are discussed for NAT-v4 in RFC 2993 and RFC 3027. > Maybe it could be quite short, if the issues are the same, > but it needs to be written. As NAT-PT stand, in the v6 to v4 translation, it is worse than regular NAT, because of side effects introduce by the DNS ALG part. In the v4 to v6 translation, it is problematic because of the possibility for DOS attack. As described, NAT-PT does not scale as regular NAT, this is bad, especially when people (like 3G) have been discussing using it massively! (I'm not saying it is a good thing to use NAT massively, and although the current RFC tries to somehow limit its domain of use, the statements are not strong enough and side effects need to be documented) NAT-PT needs to be revisited: It needs to remove the DNS-ALG part in the v6 tov4 case, it needs to limit the DOS thread and need to scale better, at least as well/bad as NAT. A new RFC needs to define the tradeoff when to use it compare to using dual stack. - Alain. From owner-v6ops@ops.ietf.org Mon Dec 2 03:15:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07137 for ; Mon, 2 Dec 2002 03:15:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Illf-0007WR-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 00:17:27 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #2) id 18Illd-0007WF-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 00:17:25 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB28IT612035 for ; Mon, 2 Dec 2002 10:18:29 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 10:17:22 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 10:17:22 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Mon, 2 Dec 2002 10:17:21 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC35D8@esebe005.ntc.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcKZvCCf2SURot2YQvq1yvsWD7oJngAGyTUQ From: To: Cc: , X-OriginalArrivalTime: 02 Dec 2002 08:17:22.0333 (UTC) FILETIME=[3D3164D0:01C299DB] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA07137 Hello! What comes to 3GPP specifications, Mobile IPv6 is *not* a mandatory part of 3GPP architecture in Release 99, Release 4 and Release 5. Mobility is handled by Layer 2 mechanisms: GPRS Tunneling Protocol (GTP) handles the global (macro) mobility and the UE can be attached to the same GGSN all the time. But it is possible to use MIPv6 starting from Release 99, i.e. nothing prevents you. What comes to 3GPP Release 6 (that is currently being specified), Mobile IPv6 is discussed there. A good use case for Mobile IPv6 would be handling GPRS / WLAN mobility. However, one thing that is needed is frozen MIPv6 specification (=RFC)... let's hope that we get it finalized soon! :-) Best Regards, -Juha W.- -----Original Message----- From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] Sent: 02 December, 2002 06:35 To: itojun@iijlab.net Cc: V6ops (E-mail) Subject: RE: on NAT-PT i once read in an article (probably by nokia) that mobile ipv6 has been mandated for 3gpp.is it true? anand thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 From owner-v6ops@ops.ietf.org Mon Dec 2 07:27:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11467 for ; Mon, 2 Dec 2002 07:27:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IphK-000DAj-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 04:29:14 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18IphH-000D9N-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 04:29:11 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA10572; Mon, 2 Dec 2002 04:28:07 -0800 (PST) Message-Id: <5.1.0.14.0.20021202064752.02513ce0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Dec 2002 07:27:05 -0500 To: Alain Durand From: Margaret Wasserman Subject: Re: on NAT-PT Cc: Brian E Carpenter , itojun@iijlab.net, v6ops@ops.ietf.org In-Reply-To: <7BD30663-05B9-11D7-A06E-00039376A6AA@sun.com> References: <3DE5DEE3.10B63AFB@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Alain, >NAT-PT needs to be revisited: >It needs to remove the DNS-ALG part in the v6 tov4 case, >it needs to limit the DOS thread and need to scale better, >at least as well/bad as NAT. Apparently, there is some disagreement about whether the DNS ALG part needs to be modified. Could you provide more details about why you think it needs to change? >A new RFC needs to define the tradeoff when to use it >compare to using dual stack. When would it make sense to use NAT-PT instead of dual-stack (with or without IPv4 NAT)? I would argue that there NO current or immediate, realistic cases where NA(P)T-PT is a better technical solution, for several reasons: (1) Dual stack should represent very little increase in code size or system requirements over an IPv6 stack for a host. Does anyone even have an implementation that can be built (not just configured, but compiled and loaded) to be IPv6-only at this point? (2) IPv4 NAT implementations are already widely deployed, mature and reliable. Also, the ALGs have all been developed and widely deployed, and the problems caused by IPv4 NAT for each application are well- understood, and applications have adapted, as needed. (3) The dual stack/IPv4 NAT approach allows two hosts behind the same NAT box to establish an IPv4 connection (if they can find each other), while NA(P)T-PT does not (they don't even have IPv4 addresses). The only argument I have heard for why one would use NAT-PT is in a large, brand new network, where it might be cheaper/easier to deploy an IPv6-only infrastructure, compared with deploying a dual stack infrastructure. The extra costs of a dual-stack/IPv4 NAT deployment, over an IPv6-only deployment include: (1) Providing IPv4 configuration to the routers. You already need to touch each router to configure IPv6, so this is just a matter of entering a few more pieces of information while you are there. (2) Deploying DHCPv4 servers. (This isn't required in a 3G network, as IPv4 address allocation is don't automatically for IPv4 PDP contexts, but pools of (possibly private) IPv4 addresses would need to be provided to the GGSNs. (3) Managing, monitoring & maintianing the IPv4 network (in addition to the IPv6 network that uses the same lines and hardware). I can't estimate what this costs, but since they share the same lines and hardware, adding IPv4 shouldn't increase the number of truck rolls. The primary example that people give of a major new network that would be IPv6-only is the 3G case... This is quite a theoretical case at this point, but let's use it as an example: In the 3G case, it seems likely that the NA(P)T-PT functionality would co-reside with the GGSN function. In this environment, you could _only_ support IPv6-only phones (there is no v4 infrastructure behind the NAT-PT/GGSN line). And, those phones could _only_ speak IPv4 to hosts on the other side of the NAT-PT/GGSN border, right? I'm not sure why anyone thinks that this would be acceptable, given the huge number of IPv4-only applications that exist today. If we are going to recommend this as a solution (which I don't think we should), I think that we need to be very clear about some things: (1) Two phones behind the same GGSN/NAT-PT could not make an IPv4 connection to each other, but two phones behind different GGSN/NAT-PTs could (with a third party rendezvous point or a STUN-like mechanism). So, be ready to answer the question: "Why did my favourite application (i.e a game) work fine when my husband was in Poughkeepsie, but it doesn't work now that he's home?". What's the answer? "Ma'am, just have your husband drive 4 miles across town and turn his cell phone off and back on again there. Then, as long as he doesn't turn it off again, your application should work?" Yeah, right. (2) IPv6 NAT-PT will have different application failure modes than IPv4 NAT, so be ready to answer the question: "Why does my laptop application work fine when I'm connected at home or work, but doesn't work when I am connected through my 3G cell phone?" Honest answer (which will never be given): "That's because we chose unproven and poorly understood technology to support IPv4 address sharing, rather than relying on the technology that has been widely deployed for years." I also think it is extremely doubtful that operators (in the next N years, anyway, where N > 5) will want to deploy an IPv6-only 3G network. I've worked with a number of vendors of 3G hardware, and none of them seem to be building devices that assume that the phones will all be IPv6-only (and capable of only establishing IPv6 PDP contexts). I am well acquainted with the design and requirements of one major vendor's GGSN, and their performance requirements indicate that they expect to service a large number of IPv4 connections (IPv4 PDP contexts), from IPv4-only and/or dual-stack phones, as well as a large number of IPv6 connections. So, I think that we should issue a strong recommendation against using NAT-PT in any environment and move it to historical? If, in the fullness of time, it turns out that we have a mostly-IPv6 Internet and a real-life need arises to support legacy IPv4-only equipment in an IPv6 world, we can take out NAT-PT, dust it off, and see if it will be helpful in that situation. Margaret From owner-v6ops@ops.ietf.org Mon Dec 2 09:23:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16134 for ; Mon, 2 Dec 2002 09:23:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IrVL-000GkY-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 06:24:59 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18IrVI-000Gjf-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 06:24:56 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8A52C4B23; Mon, 2 Dec 2002 23:24:49 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Sun, 01 Dec 2002 21:47:03 PST. <7BD30663-05B9-11D7-A06E-00039376A6AA@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Mon, 02 Dec 2002 23:24:49 +0900 Message-Id: <20021202142449.8A52C4B23@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk haven't you checked two of my messages started this thread? >NAT-PT needs to be revisited: >It needs to remove the DNS-ALG part in the v6 tov4 case, if you could do it without changing IPv6-only clients, i'm fine with that. >it needs to limit the DOS thread and need to scale better, >at least as well/bad as NAT. what kind of DoS? what kind of scalability differences do you see between v4-v4 NAT and v6-v4 NAT-PT? i don't see any (except that NAT-PT might potentially need to support massive number of customers, depending on configuration - you can balance the load between NAT-PT translation boxes so it's no issue). >A new RFC needs to define the tradeoff when to use it >compare to using dual stack. itojun From owner-v6ops@ops.ietf.org Mon Dec 2 10:27:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19388 for ; Mon, 2 Dec 2002 10:27:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IsVp-000IzG-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 07:29:33 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #2) id 18IsVh-000IyU-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 07:29:25 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB2FUSq27930 for ; Mon, 2 Dec 2002 17:30:28 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 17:29:17 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 17:29:16 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Mon, 2 Dec 2002 17:29:15 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC35E2@esebe005.ntc.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcKZ/vXy0hbf/Q65RUqQiWU61fNbEwAEdE5w From: To: , Cc: , , X-OriginalArrivalTime: 02 Dec 2002 15:29:16.0706 (UTC) FILETIME=[935CE820:01C29A17] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA19388 Hi, Margaret! Some comments below (marked with 'JW'): -----Original Message----- From: ext Margaret Wasserman [mailto:mrw@windriver.com] Sent: 02 December, 2002 14:27 >A new RFC needs to define the tradeoff when to use it >compare to using dual stack. When would it make sense to use NAT-PT instead of dual-stack (with or without IPv4 NAT)? I would argue that there NO current or immediate, realistic cases where NA(P)T-PT is a better technical solution, for several reasons: (1) Dual stack should represent very little increase in code size or system requirements over an IPv6 stack for a host. Does anyone even have an implementation that can be built (not just configured, but compiled and loaded) to be IPv6-only at this point? (2) IPv4 NAT implementations are already widely deployed, mature and reliable. Also, the ALGs have all been developed and widely deployed, and the problems caused by IPv4 NAT for each application are well- understood, and applications have adapted, as needed. (3) The dual stack/IPv4 NAT approach allows two hosts behind the same NAT box to establish an IPv4 connection (if they can find each other), while NA(P)T-PT does not (they don't even have IPv4 addresses). JW: A general comment: I am still not sure that everything can be done with dual stack (with or without IPv4 NAT), there can be cases in which you cannot avoid protocol translation... The only argument I have heard for why one would use NAT-PT is in a large, brand new network, where it might be cheaper/easier to deploy an IPv6-only infrastructure, compared with deploying a dual stack infrastructure. JW: Yes, I think that introduction of new IPv6-only networks (native IPv6 from the beginning, and possibly needing connections with legacy IPv4 nodes) is a good example. The extra costs of a dual-stack/IPv4 NAT deployment, over an IPv6-only deployment include: (1) Providing IPv4 configuration to the routers. You already need to touch each router to configure IPv6, so this is just a matter of entering a few more pieces of information while you are there. (2) Deploying DHCPv4 servers. (This isn't required in a 3G network, as IPv4 address allocation is don't automatically for IPv4 PDP contexts, but pools of (possibly private) IPv4 addresses would need to be provided to the GGSNs. (3) Managing, monitoring & maintianing the IPv4 network (in addition to the IPv6 network that uses the same lines and hardware). I can't estimate what this costs, but since they share the same lines and hardware, adding IPv4 shouldn't increase the number of truck rolls. The primary example that people give of a major new network that would be IPv6-only is the 3G case... This is quite a theoretical case at this point, but let's use it as an example: JW: Yes, IMS part of the 3GPP Release 5 network is IPv6-only (as discussed several times also on this mailing list). It is a good question, how probable the case that a Rel5 IMS UE needs to connect to an IPv4 node (outside the IMS domain) is, but for the sake of completeness that case needs to be documented in 3GPP scenarios & analysis. In the 3G case, it seems likely that the NA(P)T-PT functionality would co-reside with the GGSN function. JW: Hmm... I would not assume that NAT-PT and GGSN are co-located. NAT-PT could be located on the edge of the operator's network and the Internet. Or in the IMS case (IMS scenario 1), NAT-PT would be located on the edge of the IMS domain and the IPv4 network (public Internet). GGSN can anyway have several Access Points (both IPv4 and IPv6) to have connections to different networks (one IPv6 Access Point can support IPv6 IMS connections, second one can support connections to public IPv6 internet, and third one can support connections to IPv4 Internet, etc.). In this environment, you could _only_ support IPv6-only phones (there is no v4 infrastructure behind the NAT-PT/GGSN line). And, those phones could _only_ speak IPv4 to hosts on the other side of the NAT-PT/GGSN border, right? I'm not sure why anyone thinks that this would be acceptable, given the huge number of IPv4-only applications that exist today. JW: As I tried to explain above, I don't keep this kind of 'limited model' very probable. If we are going to recommend this as a solution (which I don't think we should), I think that we need to be very clear about some things: (1) Two phones behind the same GGSN/NAT-PT could not make an IPv4 connection to each other, but two phones behind different GGSN/NAT-PTs could (with a third party rendezvous point or a STUN-like mechanism). So, be ready to answer the question: "Why did my favourite application (i.e a game) work fine when my husband was in Poughkeepsie, but it doesn't work now that he's home?". What's the answer? "Ma'am, just have your husband drive 4 miles across town and turn his cell phone off and back on again there. Then, as long as he doesn't turn it off again, your application should work?" Yeah, right. JW: I would still keep making *IPv6* connection from phone to phone a better idea... That's the real peer-to-peer networking :-) (2) IPv6 NAT-PT will have different application failure modes than IPv4 NAT, so be ready to answer the question: "Why does my laptop application work fine when I'm connected at home or work, but doesn't work when I am connected through my 3G cell phone?" Honest answer (which will never be given): "That's because we chose unproven and poorly understood technology to support IPv4 address sharing, rather than relying on the technology that has been widely deployed for years." JW: As a general comment, IPv6 NAT-PT failure modes / problems compared to IPv4 NAT problems should be documented (if not done already by someone). I also think it is extremely doubtful that operators (in the next N years, anyway, where N > 5) will want to deploy an IPv6-only 3G network. JW: This sounds like a valid assumption for many operators. But we have to still remember that there is one part of the network that is IPv6-only and that is the Rel5 IMS. I've worked with a number of vendors of 3G hardware, and none of them seem to be building devices that assume that the phones will all be IPv6-only (and capable of only establishing IPv6 PDP contexts). I am well acquainted with the design and requirements of one major vendor's GGSN, and their performance requirements indicate that they expect to service a large number of IPv4 connections (IPv4 PDP contexts), from IPv4-only and/or dual-stack phones, as well as a large number of IPv6 connections. So, I think that we should issue a strong recommendation against using NAT-PT in any environment and move it to historical? JW: I still think that we need something like NAT-PT for some special cases, although the majority of the transition cases can be solved using dual stack & tunneling. I would suggest well documenting the NAT-PT problems and see what can be done / fixed. Thanks, -Juha- From owner-v6ops@ops.ietf.org Mon Dec 2 11:04:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22007 for ; Mon, 2 Dec 2002 11:04:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18It5y-000KYW-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 08:06:54 -0800 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18It5s-000KXf-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 08:06:48 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB2G6fQ1001462; Mon, 2 Dec 2002 17:06:41 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 2 Dec 2002 17:06:41 +0100 Message-ID: From: "Karim El-Malki (EAB)" To: "'Margaret Wasserman'" , Alain Durand Cc: Brian E Carpenter , itojun@iijlab.net, v6ops@ops.ietf.org Subject: RE: on NAT-PT Date: Mon, 2 Dec 2002 17:03:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Margaret > In the 3G case, it seems likely that the NA(P)T-PT > functionality would > co-reside with the GGSN function. I would disagree, there's nothing that forces you to have the GGSN and NAPT-PT co-located. I don't think this assumption is in any of the 3gpp-ietf docs. Having the two co-located seems like a special case to me. > > So, I think that we should issue a strong recommendation > against using NAT-PT > in any environment and move it to historical? I think the 3G scenario is helping IPv6 deployment by mandating IPv6 only for new multimedia applications. This helps in forcing people to go to v6, but it also means we need to support communication to ipv4 hosts. The 3g link-layer (pdp context) cannot support ipv4 and ipv6 together, so a phone having an ipv6 pdp context needs application proxies and translators to communicate with ipv4 hosts. Application proxies can handle the typical app.s (e.g. http) and the translator could be used for the remaining. That would reduce the use of translators, but still they would be needed. So I would disagree on such a strong recommendation. Rather I would prefer recommending application proxies for most used app.s and leave napt-pt (with adequate changes) for the remaining. Rgds /Karim From owner-v6ops@ops.ietf.org Mon Dec 2 11:30:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24382 for ; Mon, 2 Dec 2002 11:30:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ItV4-000Lh6-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 08:32:50 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18ItV1-000Lgg-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 08:32:48 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA10062; Mon, 2 Dec 2002 08:31:38 -0800 (PST) Message-Id: <5.1.0.14.0.20021202112728.025e9178@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Dec 2002 11:31:19 -0500 To: juha.wiljakka@nokia.com From: Margaret Wasserman Subject: RE: on NAT-PT Cc: , , , In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC35E2@esebe005.ntc.nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Maybe I'm confused... Juha wrote: >JW: Yes, IMS part of the 3GPP Release 5 network is IPv6-only (as discussed >several times also on this mailing list). It is a good question, how >probable the case that a Rel5 IMS UE needs to connect to an IPv4 node >(outside the IMS domain) is, but for the sake of completeness that case >needs to be documented in 3GPP scenarios & analysis. Will the IMS subsystem have separate phones from the rest of 3G? Or could a dual-stack phone access the IMS subsystem, and also create IPv4 PDP contexts to contact IPv4 nodes and services? Karim wrote: >The 3g link-layer (pdp context) cannot support ipv4 and ipv6 >together, so a phone having an ipv6 pdp context needs application proxies >and translators to communicate with ipv4 hosts. This does not match my understanding. I thought that a 3G phone could open several simultaneous PDP contexts, and that a dual stack phone could have simultaneous IPv4 and IPv6 PDP contexts. Am I mistaken? Margaret From owner-v6ops@ops.ietf.org Mon Dec 2 11:43:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25144 for ; Mon, 2 Dec 2002 11:43:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ithf-000MGw-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 08:45:51 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18Ithb-000MGf-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 08:45:48 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 3D9EA832F; Mon, 2 Dec 2002 17:45:41 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 22631781C; Mon, 2 Dec 2002 17:45:29 +0100 (CET) From: "Jeroen Massar" To: , <6bone@ISI.EDU>, Subject: RE: [6bone] Ghost Route Hunter Date: Mon, 2 Dec 2002 17:46:23 +0100 Organization: Unfix Message-ID: <000b01c29a22$5aa9acb0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200212021315.48011.ipng@uni-muenster.de> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25144 Christian Schild [mailto:ipng@uni-muenster.de] wrote: > Hi Jeroen, all, > > Am Sonntag, 1. Dezember 2002 17:34 schrieb Jeroen Massar: > > Also DFN (JOIN) which appears in about 90%+ of all the ghost routes > > should check up their equipment. Another possible important player > > we are aware of this fact for quite some time now and it did not pass > us unconcerned. Still, JOIN is one of the largest POPs in > 6bone, so the high value might just be a consequence of this fact. We discussed the > route withdrawal problem with most of our peering partners and we are > quite sure that we do not orginate them. That's also the case for VBNS, HURRICANE, UUNET and ABILENE who pass along many routes over their native connections. At this moment (17:20) UUNET, GBLX, DFN, Caladan and VERAT carry all ghost routes. That's the 'problem' of being a transit :) Their equipment could be perfect but apparently somebody downstream or upstream could peep it up. > Anyway, as we are not certain of this, please note that we decided to > exchange the equipment we use (no, it's currently _not_ a software > router :-). This will happen this week. > > So please take this message also as an announcement that > there will be > an outage of the JOIN POP (involving/including all our leaf > sites with prefix 3ffe:400::/24) on Wednesday, 4th December, hopefully > only in the morning (CET). Perfect! I like the fact that you respond and give a notice of the fact that your actively pursuing the problems with ofcourse the target to solve it. Also 2 ghost routes have vanished already: 3ffe:100::/24 now only has a short path to 3263 (TELEBIT-DK). Which was last seen at 2002-12-02 08:40. 3ffe:8010::/28 now only has a short path to 8664 (ICM-PL). Which was last seen at 2002-12-02 15:10. I due hope to hear comments from the concerned parties if they have any relevant information about the disappearance of these ghosts. Left are of which I heared nothing (yet, I hope): 3ffe:1400::/24 3ffe:1e00::/24 Greets, Jeroen From owner-v6ops@ops.ietf.org Mon Dec 2 11:57:08 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25831 for ; Mon, 2 Dec 2002 11:57:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ItuW-000MqX-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 08:59:08 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18ItuQ-000Mpu-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 08:59:02 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB2GwMk26424 for ; Mon, 2 Dec 2002 18:58:23 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 18:58:59 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 18:58:59 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Mon, 2 Dec 2002 18:58:58 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC35E3@esebe005.ntc.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcKaIGC6D+OlPLKDR1uvuDV/0ypkTwAACTCw From: To: Cc: , , , X-OriginalArrivalTime: 02 Dec 2002 16:58:59.0380 (UTC) FILETIME=[1BAFC740:01C29A24] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25831 Hi again, Margaret! Trying to clarify this issue a bit more: - 3G phone can have several simultaneous PDP contexts activated (those PDP contexts can be IPv4 or IPv6) - PDP context usage depends on used applications (and their QoS requirements) - in the case the user is using an IMS service, IPv6 PDP context is always used; in the IMS, both user data and the signalling traffic is IPv6; dual stack phone can naturally connect to IMS, but only using IPv6 PDP contexts, IPv4 PDP contexts can not be used when connecting to an IMS service. - other services than IMS services (e.g. web browsing) can be simultaneously used, using IPv4 or IPv6 PDP contexts Cheers, -Juha- -----Original Message----- From: ext Margaret Wasserman [mailto:mrw@windriver.com] Sent: 02 December, 2002 18:31 To: Wiljakka Juha (NMP/Tampere) Cc: Alain.Durand@sun.com; brian@hursley.ibm.com; itojun@iijlab.net; v6ops@ops.ietf.org Subject: RE: on NAT-PT Maybe I'm confused... Juha wrote: >JW: Yes, IMS part of the 3GPP Release 5 network is IPv6-only (as discussed >several times also on this mailing list). It is a good question, how >probable the case that a Rel5 IMS UE needs to connect to an IPv4 node >(outside the IMS domain) is, but for the sake of completeness that case >needs to be documented in 3GPP scenarios & analysis. Will the IMS subsystem have separate phones from the rest of 3G? Or could a dual-stack phone access the IMS subsystem, and also create IPv4 PDP contexts to contact IPv4 nodes and services? Karim wrote: >The 3g link-layer (pdp context) cannot support ipv4 and ipv6 >together, so a phone having an ipv6 pdp context needs application proxies >and translators to communicate with ipv4 hosts. This does not match my understanding. I thought that a 3G phone could open several simultaneous PDP contexts, and that a dual stack phone could have simultaneous IPv4 and IPv6 PDP contexts. Am I mistaken? Margaret From owner-v6ops@ops.ietf.org Mon Dec 2 12:02:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26077 for ; Mon, 2 Dec 2002 12:02:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Itzj-000N5G-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 09:04:31 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18ItzV-000N4s-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 09:04:18 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB2H4CKV002376; Mon, 2 Dec 2002 18:04:12 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 2 Dec 2002 18:04:12 +0100 Message-ID: From: "Karim El-Malki (EAB)" To: "'Margaret Wasserman'" , juha.wiljakka@nokia.com Cc: Alain.Durand@sun.com, brian@hursley.ibm.com, itojun@iijlab.net, v6ops@ops.ietf.org Subject: RE: on NAT-PT Date: Mon, 2 Dec 2002 18:00:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Karim wrote: > >The 3g link-layer (pdp context) cannot support ipv4 and ipv6 > >together, so a phone having an ipv6 pdp context needs > application proxies > >and translators to communicate with ipv4 hosts. > > This does not match my understanding. I thought that a 3G phone > could open several simultaneous PDP contexts, and that a dual > stack phone could have simultaneous IPv4 and IPv6 PDP contexts. > Am I mistaken? You would be mistaken when we consider IMS. If I have an IMS IPv6 pdp context, and want to communicate using IMS services with non-3g IPv4 hosts that are using IPv4 SIP based services, then I can't use another v4 pdp context. That's because IMS is only ipv6. So a translator + sip alg would be useful. In general, you can have multiple pdp contexts active as requested by app.s. However setting up another pdp context would mean using up more resources and some setup latency. It would be simpler if a phone which already has one active v6 pdp context could use it to communicate with v4 and v6 hosts. This could be done by using app. proxies for the most used app.s and translators for the rest. Rgds /Karim From owner-v6ops@ops.ietf.org Mon Dec 2 12:06:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26290 for ; Mon, 2 Dec 2002 12:06:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Iu3z-000NHW-00 for v6ops-data@psg.com; Mon, 02 Dec 2002 09:08:55 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #2) id 18Iu3w-000NG1-00 for v6ops@ops.ietf.org; Mon, 02 Dec 2002 09:08:52 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 2 Dec 2002 09:08:00 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Dec 2002 09:08:00 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Mon, 2 Dec 2002 09:08:01 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 2 Dec 2002 09:07:59 -0800 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.3710.0); Mon, 2 Dec 2002 09:07:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: on NAT-PT Date: Mon, 2 Dec 2002 09:07:58 -0800 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcKaAHq5qNpbbMZuR7GBRRQgSLUmPAAJKTBQ From: "Christian Huitema" To: "Margaret Wasserman" , "Alain Durand" Cc: "Brian E Carpenter" , , X-OriginalArrivalTime: 02 Dec 2002 17:07:59.0465 (UTC) FILETIME=[5D9A3590:01C29A25] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA26290 > >NAT-PT needs to be revisited: > >It needs to remove the DNS-ALG part in the v6 tov4 case, > >it needs to limit the DOS thread and need to scale better, > >at least as well/bad as NAT. > > Apparently, there is some disagreement about whether the DNS ALG part > needs > to be modified. Could you provide more details about why you think it > needs > to change? There is an extensive discussion of this issue in draft-huitema-ngtrans-unmaneval-01.txt. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Dec 3 08:08:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17762 for ; Tue, 3 Dec 2002 08:08:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JCmJ-00006W-00 for v6ops-data@psg.com; Tue, 03 Dec 2002 05:07:55 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18JCmF-00006K-00 for v6ops@ops.ietf.org; Tue, 03 Dec 2002 05:07:51 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id AFC3977DE; Tue, 3 Dec 2002 14:07:43 +0100 (CET) Received: from cyan (mediaserver.azr.nl [::ffff:156.83.254.8]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8477077B5; Tue, 3 Dec 2002 14:07:37 +0100 (CET) From: "Jeroen Massar" To: "'Hahn, Ch'" Cc: <6bone@ISI.EDU>, , , , , , , , Subject: RE: Ghost Route Hunter Date: Tue, 3 Dec 2002 14:06:41 +0100 Organization: Unfix Message-ID: <001101c29acc$d3bb7980$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <834CCB6AE296D5119645000347055E5E03534343@G9JNQ.mgb01.telekom.de> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hahn, Ch [mailto:HahnC@t-systems.com] wrote: > > Hi Jeron, s/Jeron/Jeroen/ :) > > -----Ursprungliche Nachricht----- > > Von: Jeroen Massar [mailto:jeroen@unfix.org] > Have this route in table. Quote from other reply: 8<------------ 3ffe:100::/24 now only has a short path to 3263 (TELEBIT-DK). Which was last seen at 2002-12-02 08:40. 3ffe:8010::/28 now only has a short path to 8664 (ICM-PL). Which was last seen at 2002-12-02 15:10. ------------->8 In the mean time there have been a couple of odd ones popping in and out, from the current report (2002-12-03 13:50) 8<----------- The following routes are currently ghosted and thus are not reachable from many places on the internet. - 2001:270::/35 - 1 ghosted paths - 3ffe:1400::/24 - 24 ghosted paths - 3ffe:1e00::/24 - 10 ghosted paths - 3ffe:400c::/32 - 1 ghosted paths - 3ffe:400d::/32 - 15 ghosted paths ----------->8 > > - 3ffe:1400::/24 > > netname: UNI-C > > descr: pTLA delegation for the 6bone > > remarks: *************************************** > > remarks: * * * * no longer operational * * * * > > remarks: *************************************** > > > > But still visible and ghosted and not officially retracted! > > > > Last changed line: > > changed: Anders.Bandholm@uni-c.dk 20010420 > > > > This would mean that the route would have been gone for over > > a year and > > a half! > > This route is currently announced by VERAT and Deutsche > > Telekom though. > > From my point of view it looks a little bit different. I see > this route in my table via two paths with a number of >25 > ASes in path and still incomplete. Last AS before > incompletness in both cases is 15982 (VERAT). We have a > peering with VERAT but don't receiving this route from them. > Instead we announing the route to them. > I've checked the FUBAR, STBEN-BE looking glass and saw the > route with our AS appended. Currently I have no idea how and > where in the path our AS# is appended, but I'm shure that we > are not originating this route. > > At first step I will filter this route and then lets see if > it will vanish or change its path. 3ffe:1400::/24 has 24 ghosted paths. We are thinking that there is an implemention being used somewhere that has a maximum number of ASn's per path which is now 'shortcutting' the ASpath which leaves VERAT at the front. The VERAT router is now included in the report and it doesn't have the route itself. Which clears them from blame ;) > > - 3ffe:1e00::/24 > > ipv6-site: SWISSCOM > > origin: AS3303 > > descr: Swisscom Innovations > > > > No netname available apparently. But it is currently announced by: > > source: APNIC > > aut-num: AS4697 > > as-name: NTTV6NET > > descr: NTT Software Laboratories > > > > I have already contacted these people seperatly, no response as yet. > > Nothing in their 6bone object seems reachable. > > The routing entry looks similar to the one above. Long AS > path and still incomplete. They haven't replied yet either. Going for the CC again. Would the owners of this pTLA please speak up ? > > - 3ffe:8010::/28 > > ipv6-site: ICM-PL > > origin: AS8664 > > descr: Interdisciplinary Centre for Mathematical and > > Computational Modelling > > Warsaw University, Poland > > > > Origin is currently ICM-PL and ICP-AS. > > 6bone-gw.6bone.pl is unreachable over IPv4 and IPv6 > > Have this route in table, seams still ok at this point. > 6bone-gw.6bone.pl is reachable via IPv4. See at the top. Apparently those where resurrected and the ghosts went away, fortunatly (for them ;) GReets, Jeroen From owner-v6ops@ops.ietf.org Tue Dec 3 08:33:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18869 for ; Tue, 3 Dec 2002 08:33:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JDBx-00019d-00 for v6ops-data@psg.com; Tue, 03 Dec 2002 05:34:25 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18JDBt-00019N-00 for v6ops@ops.ietf.org; Tue, 03 Dec 2002 05:34:22 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id C04BB7948; Tue, 3 Dec 2002 14:34:17 +0100 (CET) Received: from cyan (gateway.azr.nl [::ffff:156.83.254.8]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 05EDD77B1; Tue, 3 Dec 2002 14:34:11 +0100 (CET) From: "Jeroen Massar" To: <6bone@ISI.EDU>, , , , , Cc: Subject: SWISSCOM / AS3303 / 3ffe:1e00::/24 - Is there anyone alive? Date: Tue, 3 Dec 2002 14:33:16 +0100 Organization: Unfix Message-ID: <001201c29ad0$8a0a4880$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=1.3 required=5.0 tests=MAILTO_TO_SPAM_ADDR,NOSPAM_INC,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As I just got a nice bounce back: : host ns2.vptt.ch[193.5.238.14] said: 550 : User unknown 8<------------------- ipv6-site: SWISSCOM origin: AS3303 descr: Swisscom Innovations Ostermundigenstr. 93 3050 Bern Switzerland country: CH prefix: 3FFE:1E00::/24 application: ping gdvipv6.ctlabs.ch ------------------->8 gdvipv6.ctlabs.ch AAAA record not found, server failure gdvipv6.ctlabs.ch A record not found, server failure 8<------------------- application: ping aldebaran6.ctlabs.ch ------------------->8 8<------------------- application: ping deneb6.ctlabs.ch ------------------->8 deneb6.ctlabs.ch AAAA record not found, server failure deneb6.ctlabs.ch A record not found, server failure Thus these shouldn't work either: 8<------------------- tunnel: IPv6 in IPv4 gdvipv6.ctlabs.ch -> router2-0.att.ch ATT-LABS-EUROPE BGP4+ tunnel: IPv6 in IPv4 gdvipv6.ctlabs.ch -> vboipv6rtr.europe.digital.com DIGITAL-ETC BGP4+ ------------------->8 8<------------------- contact: HP1-6BONE contact: AF1-6BONE contact: AP148-RIPE ------------------->8 8<-------------- $ whois HP1-6BONE % RIPEdb(3.0.0b2) with ISI RPSL extensions % No entries found in 6BONE database. $ whois AF1-6BONE % RIPEdb(3.0.0b2) with ISI RPSL extensions person: Alberto Ferrer address: Pasaje Chacabuco 1147 address: Comodoro Rivadavia address: Chubut address: Argentina phone: +54 297 155940460 e-mail: yoco22@hotmail.com $ whois AP148-RIPE person: Andre Prim address: Swiss PTT address: Research & Development address: Technical Center address: CH-3000 Bern 29 address: Switzerland phone: +41 31 338 3437 fax-no: +41 31 338 5747 e-mail: prim_a@vptt.ch -------------->8 Only one on-site person, of which the mail doesn't bounce. But is this person alive and willing to do something about this? There is also a second object: 8<--------------- ipv6-site: SWISS-TELECOM origin: AS3303 descr: Corporate Technology Ostermundigenstr. 93 3029 Bern Switzerland country: CH prefix: 3FFE:1E00::/24 application: ping gdvipv6.ctv6.vptt.ch application: ping aldebaran6.ctv6.vptt.ch application: ping deneb6.vptt.ch tunnel: IPv6 in IPv4 gdvipv6.ctv6.vptt.ch -> router2-0.att.ch ATT-LABS-EUROPE BGP4+ contact: HP1-6BONE contact: AF1-6BONE contact: AP148-RIPE -------------->8 Same persons, different tunnels. helpdesk@ip-plus.net CC'd as they are they are for AS3303 'operational issues'. What is going to happen with this? Greets, Jeroen From owner-v6ops@ops.ietf.org Tue Dec 3 09:02:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20492 for ; Tue, 3 Dec 2002 09:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JDeg-0002P5-00 for v6ops-data@psg.com; Tue, 03 Dec 2002 06:04:06 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18JDeY-0002Ok-00 for v6ops@ops.ietf.org; Tue, 03 Dec 2002 06:03:59 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 368757948; Tue, 3 Dec 2002 15:03:49 +0100 (CET) Received: from cyan (gateway.azr.nl [::ffff:156.83.254.8]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4018477B5; Tue, 3 Dec 2002 15:03:42 +0100 (CET) From: "Jeroen Massar" To: <6bone@ISI.EDU>, Cc: , Subject: RE: SWISSCOM / AS3303 / 3ffe:1e00::/24 - Is there anyone alive? Date: Tue, 3 Dec 2002 15:02:42 +0100 Organization: Unfix Message-ID: <001601c29ad4$a9a91550$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <001201c29ad0$8a0a4880$534510ac@cyan> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-1.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MAILTO_TO_SPAM_ADDR,NOSPAM_INC, QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jeroen Massar wrote: > helpdesk@ip-plus.net CC'd as they are they are for AS3303 'operational > issues'. And what a great response you get: > Thank you for your e-mail. > Please indicate us what you were trying to do? > Are you a customer of us? > Did you try to reach a homepage? noc@ip-plus.net CC'd... maybe they have a clue :) So SWISSCOM NOC people do you know what IPv6 is and that you have a 6bone object? Greets, Jeroen 8<------------------------- As I just got a nice bounce back: : host ns2.vptt.ch[193.5.238.14] said: 550 : User unknown 8<------------------- ipv6-site: SWISSCOM origin: AS3303 descr: Swisscom Innovations Ostermundigenstr. 93 3050 Bern Switzerland country: CH prefix: 3FFE:1E00::/24 application: ping gdvipv6.ctlabs.ch ------------------->8 gdvipv6.ctlabs.ch AAAA record not found, server failure gdvipv6.ctlabs.ch A record not found, server failure 8<------------------- application: ping aldebaran6.ctlabs.ch ------------------->8 8<------------------- application: ping deneb6.ctlabs.ch ------------------->8 deneb6.ctlabs.ch AAAA record not found, server failure deneb6.ctlabs.ch A record not found, server failure Thus these shouldn't work either: 8<------------------- tunnel: IPv6 in IPv4 gdvipv6.ctlabs.ch -> router2-0.att.ch ATT-LABS-EUROPE BGP4+ tunnel: IPv6 in IPv4 gdvipv6.ctlabs.ch -> vboipv6rtr.europe.digital.com DIGITAL-ETC BGP4+ ------------------->8 8<------------------- contact: HP1-6BONE contact: AF1-6BONE contact: AP148-RIPE ------------------->8 8<-------------- $ whois HP1-6BONE % RIPEdb(3.0.0b2) with ISI RPSL extensions % No entries found in 6BONE database. $ whois AF1-6BONE % RIPEdb(3.0.0b2) with ISI RPSL extensions person: Alberto Ferrer address: Pasaje Chacabuco 1147 address: Comodoro Rivadavia address: Chubut address: Argentina phone: +54 297 155940460 e-mail: yoco22@hotmail.com $ whois AP148-RIPE person: Andre Prim address: Swiss PTT address: Research & Development address: Technical Center address: CH-3000 Bern 29 address: Switzerland phone: +41 31 338 3437 fax-no: +41 31 338 5747 e-mail: prim_a@vptt.ch -------------->8 Only one on-site person, of which the mail doesn't bounce. But is this person alive and willing to do something about this? There is also a second object: 8<--------------- ipv6-site: SWISS-TELECOM origin: AS3303 descr: Corporate Technology Ostermundigenstr. 93 3029 Bern Switzerland country: CH prefix: 3FFE:1E00::/24 application: ping gdvipv6.ctv6.vptt.ch application: ping aldebaran6.ctv6.vptt.ch application: ping deneb6.vptt.ch tunnel: IPv6 in IPv4 gdvipv6.ctv6.vptt.ch -> router2-0.att.ch ATT-LABS-EUROPE BGP4+ contact: HP1-6BONE contact: AF1-6BONE contact: AP148-RIPE -------------->8 Same persons, different tunnels. helpdesk@ip-plus.net CC'd as they are they are for AS3303 'operational issues'. What is going to happen with this? Greets, Jeroen From owner-v6ops@ops.ietf.org Tue Dec 3 09:40:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22495 for ; Tue, 3 Dec 2002 09:40:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JEEJ-00042k-00 for v6ops-data@psg.com; Tue, 03 Dec 2002 06:40:55 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18JEEC-00042I-00 for v6ops@ops.ietf.org; Tue, 03 Dec 2002 06:40:48 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 1964B7948; Tue, 3 Dec 2002 15:40:42 +0100 (CET) Received: from cyan (gateway.azr.nl [::ffff:156.83.254.8]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8DAF777B5; Tue, 3 Dec 2002 15:40:33 +0100 (CET) From: "Jeroen Massar" To: , , <6bone@mailman.isi.edu>, Cc: "'Helpdesk IP-Plus'" , Subject: RE: 6bone ghost for 3FFE:1E00::/24 and nothing working found Date: Tue, 3 Dec 2002 15:39:37 +0100 Organization: Unfix Message-ID: <001b01c29ad9$cf2c1a70$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <05D8EC731ACCFF45A2E5A3DD97EE489B764F9B@sxmbx06.corproot.net> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MAILTO_TO_SPAM_ADDR,NOSPAM_INC, QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22495 Martin.Gysi@swisscom.com [mailto:Martin.Gysi@swisscom.com] wrote: > Hi Jeroen, Hirotaka and all… > You’re quite right that none of these applications (ping…) work, neither is the route in use. But it is currently lingering around the internet: 3ffe:1e00::/24 (10 ghosted paths) Do you have any indications since when the prefix announcements stopped? > We used this address block quite a few years ago for first tests on IPv6, but the > infrastructure was shut down after that. I am currently working on re-establishing this network, > but it takes a while to get into everything required for this. We have bought some new servers > that this time should be here to stay, and I hope that we will be up and running by the end of > this year. Please contact me (martin.gysiATswisscom.com) or michael.schaedlerATswisscom.com for > anything regarding this, as André Prim (prim_aATvptt.ch) is now longer active in this domain. Update this in the 6bone whois database, that's the place to look for these informations. > By the way, I do wonder as well who yoco22AThotmail.com might be… Clean up the 6bone registry, one 6bone site should be enough per prefix. And ofcourse add maintainers to them. I also hope that the helpdesk@ip-plus.net learn that they are in the whois entry for AS3303. Just in case that they don't know how that works: 8<------------- $ whois -h whois.ripe.net AS3303 aut-num: AS3303 as-name: SWISSCOM descr: Swisscom Enterprise Solutions Ltd descr: IP-Plus Internet Backbone descr: descr: ================================================================== ==== descr: descr: Peering requests peering@ip-plus.net descr: Operational issues helpdesk@ip-plus.net descr: Spam and abuse issues abuse@ip-plus.net descr: Other info http://www.ip-plus.net descr: descr: ================================================================== ==== ------------->8 Apparently, especially due to really odd mails like: > First, we are a helpdesk for IP-Plus customers. > Second, if we get mails like the one of you we need to have more information about what is meant. > Third, IPv6 is not yet running - it's IPv4. > Fourth, if you need any further information, please contact IEEE. > > Thank you and good bye. They don't care about their network and don't know who does what in their company. And why does the AS3303 object say that address is for "Operational Issues" when they can't respond in a normal fashion to outside persons. What if they are causing huge BGP leaks (or ghost paths like they are doing now) Do they reply with "You are not a customer so go away" ? This leaves to wonder... and what IEEE has to do with it :) A rather odd attitude these people have. Greets, Jeroen -----Original Message----- From: Jeroen Massar [mailto:jeroen@unfix.org] Sent: Saturday, November 30, 2002 9:45 PM To: prim_a@vptt.ch; yoco22@hotmail.com Cc: 'David Kessens'; 'Bob Fink' Subject: 6bone ghost for 3FFE:1E00::/24 and nothing working found Hi, While hunting for ghost routes with our new tool called Ghost Route Hunter (GRH) we found out that your prefix is ghosted. The result of GRH can be found at: https://www.sixxs.net/tools/grh/ Currently your prefix is being announced by: aut-num: AS4697 as-name: NTTV6NET Even though your AS is AS3303 and that is a japanese AS. We also noticed quite a couple of oddities related to your 6bone object and wonder if it still exists. - contact HP1-6BONE doesn't exist. - contact HP1-6BONE has a hotmail address and is mainained by COMPENDIUM-AR. - contact AP148-RIPE is ripe. - pinghosts in the 6bone registry don't resolve: application: ping gdvipv6.ctv6.vptt.ch application: ping aldebaran6.ctv6.vptt.ch application: ping deneb6.vptt.ch $ host -t aaaa gdvipv6.ctv6.vptt.ch gdvipv6.ctv6.vptt.ch does not exist (Authoritative answer) $ host -t aaaa aldebaran6.ctv6.vptt.ch aldebaran6.ctv6.vptt.ch does not exist (Authoritative answer) $ host -t aaaa deneb6.vptt.ch deneb6.vptt.ch does not exist (Authoritative answer) - tunnel endpoints in the 6bone registry don't resolve: tunnel: IPv6 in IPv4 gdvipv6.ctv6.vptt.ch -> router2-0.att.ch ATT-LABS-EUROPE BGP4+ tunnel: IPv6 in IPv4 gdvipv6.ctlabs.ch -> router2-0.att.ch ATT-LABS-EUROPE BGP4+ tunnel: IPv6 in IPv4 gdvipv6.ctlabs.ch -> vboipv6rtr.europe.digital.com DIGITAL-ETC BGP4+ $ host -t a gdvipv6.ctv6.vptt.ch gdvipv6.ctv6.vptt.ch does not exist, try again $ host -t aaaa gdvipv6.ctv6.vptt.ch gdvipv6.ctv6.vptt.ch does not exist, try again $ host -t aaaa gdvipv6.vptt.ch gdvipv6.vptt.ch does not exist (Authoritative answer) And the remote sides don't even resolve either. Is there any information about this situation and are you going to fix it? Greets, Jeroen From owner-v6ops@ops.ietf.org Tue Dec 3 09:54:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23427 for ; Tue, 3 Dec 2002 09:54:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JETH-0004kn-00 for v6ops-data@psg.com; Tue, 03 Dec 2002 06:56:23 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18JETB-0004kV-00 for v6ops@ops.ietf.org; Tue, 03 Dec 2002 06:56:17 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 08C4D7948; Tue, 3 Dec 2002 15:56:09 +0100 (CET) Received: from cyan (ns.azr.nl [::ffff:156.83.254.8]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 984FD77B1; Tue, 3 Dec 2002 15:56:04 +0100 (CET) From: "Jeroen Massar" To: "'Nicolas DEFFAYET'" , Cc: <6bone@ISI.EDU>, , , Subject: RE: [6bone] RE: SWISSCOM / AS3303 / 3ffe:1e00::/24 - Is thereanyone alive? Date: Tue, 3 Dec 2002 15:55:09 +0100 Organization: Unfix Message-ID: <002201c29adb$fa3444c0$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1038926560.655.5.camel@wks1.fr.corp.ndsoftware.com> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_08_13 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Nicolas DEFFAYET [mailto:nicolas.deffayet@ndsoftware.net] wrote: > On Tue, 2002-12-03 at 15:02, Jeroen Massar wrote: > > Jeroen Massar wrote: > > > > > helpdesk@ip-plus.net CC'd as they are they are for AS3303 > 'operational > > > issues'. > > > > And what a great response you get: > > > > > Thank you for your e-mail. > > > Please indicate us what you were trying to do? > > > Are you a customer of us? > > > Did you try to reach a homepage? > > > > noc@ip-plus.net CC'd... maybe they have a clue :) > > > > So SWISSCOM NOC people do you know what IPv6 is and that you have a > > 6bone object? > > BGP routing table entry for 2001:918::/32 > Paths: (2 available, best #2, table Default-IP-Routing-Table) > Not advertised to any peer > 8379 6830 559 3303 > 2001:768:e:11::1 from 2001:768:e:11::1 (195.143.108.166) > (fe80::2d0:79ff:fee2:7800) > Origin IGP, metric 2300, localpref 100, valid, external > Community: 25358:300 25358:360 25358:410 25358:900 25358:1000 > 25358:3000 > Last update: Mon Dec 2 22:37:48 2002 > > 1752 6830 559 3303 > 3ffe:4013:0:1::1 from 3ffe:4013:0:1::1 (213.91.4.3) > (fe80::d55b:403) > Origin IGP, metric 2200, localpref 100, valid, internal, best > Community: 25358:300 25358:360 25358:410 25358:900 25358:1000 > 25358:3000 > Last update: Mon Dec 2 01:02:13 2002 > > AS3303 announce a sTLA (2001:918::/32). And they don't know about it... GREAT...... inet6num: 2001:0918::/32 netname: CH-UNISOURCE-20020927 descr: Provider Local Registry descr: Swisscom IP-PLus Internet Services Also announcing/having an sTLA doesn't allow one to neglect their 6bone prefix. Could somebody at Swisscom/IP-Plus pass a cluestick to their helpdesk and train them to the fact that IPv6 exists and what they can and should do about it etc? Greets, Jeroen From owner-v6ops@ops.ietf.org Tue Dec 3 17:10:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21731 for ; Tue, 3 Dec 2002 17:10:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JLFm-0006MA-00 for v6ops-data@psg.com; Tue, 03 Dec 2002 14:10:54 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JLFj-0006Lx-00 for v6ops@ops.ietf.org; Tue, 03 Dec 2002 14:10:52 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JLFi-0009De-00 for v6ops@ops.ietf.org; Tue, 03 Dec 2002 14:10:51 -0800 In-Reply-To: <001601c29ad4$a9a91550$534510ac@cyan> References: <001601c29ad4$a9a91550$534510ac@cyan> Content-Type: text/plain Message-Id: <1038926560.655.5.camel@wks1.fr.corp.ndsoftware.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [6bone] RE: SWISSCOM / AS3303 / 3ffe:1e00::/24 - Is there anyone alive? From: Nicolas DEFFAYET To: Jeroen Massar Cc: 6bone@ISI.EDU, v6ops@ops.ietf.org, helpdesk@ip-plus.net, noc@ip-plus.net Date: 03 Dec 2002 15:42:40 +0100 X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_08_13 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Tue, 2002-12-03 at 15:02, Jeroen Massar wrote: > Jeroen Massar wrote: > > > helpdesk@ip-plus.net CC'd as they are they are for AS3303 'operational > > issues'. > > And what a great response you get: > > > Thank you for your e-mail. > > Please indicate us what you were trying to do? > > Are you a customer of us? > > Did you try to reach a homepage? > > noc@ip-plus.net CC'd... maybe they have a clue :) > > So SWISSCOM NOC people do you know what IPv6 is and that you have a > 6bone object? BGP routing table entry for 2001:918::/32 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 8379 6830 559 3303 2001:768:e:11::1 from 2001:768:e:11::1 (195.143.108.166) (fe80::2d0:79ff:fee2:7800) Origin IGP, metric 2300, localpref 100, valid, external Community: 25358:300 25358:360 25358:410 25358:900 25358:1000 25358:3000 Last update: Mon Dec 2 22:37:48 2002 1752 6830 559 3303 3ffe:4013:0:1::1 from 3ffe:4013:0:1::1 (213.91.4.3) (fe80::d55b:403) Origin IGP, metric 2200, localpref 100, valid, internal, best Community: 25358:300 25358:360 25358:410 25358:900 25358:1000 25358:3000 Last update: Mon Dec 2 01:02:13 2002 AS3303 announce a sTLA (2001:918::/32). Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From owner-v6ops@ops.ietf.org Wed Dec 4 13:50:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27923 for ; Wed, 4 Dec 2002 13:50:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jecs-000GEc-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 10:52:02 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Jecm-000GED-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 10:51:56 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Jecl-0001jU-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 10:51:55 -0800 Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Message-Id: <20021204184941Z7789-195+4114@stovokor.epilogue.com> From: sar@epilogue.com To: v6ops@ops.ietf.org Subject: Atlanta V6Ops Meeting Minutes Date: Wed, 4 Dec 2002 13:49:38 -0500 X-Spam-Status: No, hits=1.9 required=5.0 tests=NO_REAL_NAME,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi all, Here are the meeting minutes for the Atlanta meeting. I'm planning to submit them on friday. If you have any issues with them please send mail. regards, sar ************************************** IPv6 Operations WG IETF55 Atlanta November 20 2002 Chairs: Jun-ichiro "Itojun" Hagino Margaret Wasserman and Notes: Shawn A. Routhier As with most meetings this one started off with some agenda bashing and a brief description of the previous and current status. For this WG this included a description of an interim meeting and the current work items. The interim meeting was held to launch the new WG and to discuss the charter and goals of the new WG. The initial work items accepted by the WG include: transition mechanisms, the survey of IPv4 addresses within RFCs and the 3GPP and unmanaged scenarios. New work items can be accepted by the WG but will need to go through the standard WG process. * We then proceeded to status reports and discussions on the four deployment scenarios that are currently under investigation. These include: unmanaged networks, ISPs, enterprises and cellular networks. * Christian Huitema - Unmanaged Networks Team Team members: R. Austein, S. Satapati, C. Huitema, R. van der Pol draft-ietf-ngtrans-unmanscope-02.txt draft-huitema-ngtrans-unmaneval-01.txt This group held a productive interim meeting and has above two drafts that have not been renamed into the V6OPS WG. The scenarios document needs some final clean up and minor edits but they belive the draft is mostly complete with two open issues dealing with the privacy and interoperability requirements. The privacy issue deals with the amount of privacy supplied by the transition mechanisms. Christian presented two opinions. Opinion 1 insists that there should not be any "privacy regression" - that is people using IPv6 should have no less privacy than people using IPv4 and a NAT. Opinion 2 is that the current level of privacy is just a random by-product of using a NAT and as such should not be turned into a requirement. This opinion also holds that other items, such as cookies, will break privacy. The floor was then opened to the WG for discussion on this topic. The sense of the room seemed to be that the options should be listed without being made requirements. Points from the discussion included 1) NATs with dynamic addresses could be added as a more private option. 2) The privacy requirements are not independent of the application. Different applications may choose different tradeoffs and attempting to choose a single option for the entire network might not work. 3) This is not simply a technical area. The social and legal realms may have implications for this area. As those realms are also evolving trying to codify them might not be useful. 4) The question of making the tradeoff was raised - who makes it, as well as when and how. 5) There is a difference between using a different address frequently (changing your address) and simply using an address that isn't derived directly from your MAC address. The final point of discussion was how this information should be presented or in what draft it should be included. The options are (1) try and put all of the privacy issues into a single document or (2) have each of the documents include a description of their issues. The WG seems to like (2) more with the caveat that eventually we may move to having a single document - either one of the current ones or a separate one - that handles the specific privacy issues and concerns. The interoperability issue deals with how much IPv4 <-> IPv6 interoperability is required during the IPv4 to IPv6 transition. We could aim for either only local interoperability or for full compatibility. There seems to be some consensus that local compatibility is required. The questions seem to be whether an IPv4 node should be able to reach services supplied by an IPv6 node or if an IPv6 node should be able to reach an IPv4 node. The WG seemed to feel that the number of IPv6 only devices would be low enough that we needn't worry about them that much. However there was resistance to this point with comments about IPv6 only devices and devices with dual stacks that are not configured to use the IPv4 side of the stack. It was also pointed out that an answer to these questions would depend on the cost of the options as well as which end is which and what each node is trying to do (be a host or server etc). Christian then discussed the solutions document which is currently a work in progress. It includes four cases. The first case (A) was that of a dual stack node behind a NAT with an IPv4 only ISP. The document suggests using Teredo in this case, but there was no clear consensus in the meeting that we need or should try to solve this problem. There was also some discussion about whether Teredo might be an overly complicated solution that would not be deployed in the real world. This discussion was sent to the mailing list. The second case (B) was that of a dual stack router and ISP. The discussion for this case covered NAT-PT and there was good consensus that we need a better NAT-PT specification. Three specific points were: the need for a reserved mapping prefix in IPv6, the need for a reserved mapping for IPv6 to IPv4 addresses and the dropping of automatic translation within the DNS. The reserved mapping from IPv6 to IPv4 addresses would make it easier for an entity to determine that it was communicating with an IPv6 entity and should attempt to use a native IPv6 address. Dropping the automatic translation would allow dual stack nodes to make their own decision about which address to use. The discussion brought up two points. The first was to suggest that IPv6 only hosts shouldn't talk to IPv4 only hosts, if a node wishes to be able to talk to an IPv4 only host it should be dual stacked. The second was that the solutions were becoming too complex. The third case (C) was that of a dual stack gateway and a single stack ISP which was using IPv4. In this case the document suggests using 6to4. The fourth case (D) was that of a dual stack gateway and a single stack ISP which was using IPv6. The recommendations from Christian were as follow. The scenarios document is mostly read and should be sent along for WG review, The solutions document still needs some work and is not ready for review, however either it or some of the problems it describes should be accepted by the WG for further work. * Cleveland Mickles - ISP Team draft-mickles-v6ops-isp-cases-02.txt This group has been working on the scenarios document and had planned to have it updated prior to IETF55, however they didn't met that deadline. Several sections have been added and some sections reworked however several sections require more work. These sections include: internet exchange point, broadband Ethernet and infrastructure. They plan to submit another revision of the document by the end of the year and then to start work on the solutions document. One set of comments they received dealt with having too much information in some sections. They attempted to rectify this, but the consensus of those that had read the draft was that there was still too much detail. They had also received some comments that the draft should address multi-homing. In the meeting there was one comment that multi-homing is important but there were several voices against its inclusion. There was a suggestion that they should include a small amount of text or a pointer to text describing possible show stoppers. The decision was to wait until the draft is produced and the WG can examine it then decide if it should be adopted by the WG. * Yanick Pouffary - Enterprise Team draft-pouffary-v6ops-ent-v6net-01.txt This is a fairly new group and so the drat is not yet complete. In this document the design group attempts to specify the scope of the document and the goals and non-goals. One of the primary goals was to identify and provide guidelines and tools for the transition. The following covers some of the points Yanick made in her presentation, for all the points please see the slides. The document includes a definition of "enterprise". The group felt that this description needs more context. The design group assumes that the reasons and methods for adoption of IPv6 will vary across users. They attempt to specify some of the variables that will influence how the transition will occur in some cases these will be external business reasons. The draft defines six scenarios. These are not intended to cover all possible options but are intended to include most of the general ones. The WG is requested to contribute any major scenarios they feel are missing. The design group feels that enterprises will need to do an inventory and determine what software will be affected by the transition. The enterprise will also need to determine what software can be extended and what will need to be updated. There were several comments about getting more deployment experience - some of this is already in the document as several members of the design team are deployers. One suggestion was for producing two sets of documents. One would be a distilled consensus document. The other set would describe what various groups have already done and what problems and pitfalls they have encountered. A further suggestion was that getting reports from non-vendors would be especially useful and that it might be useful to get similar reports for the other classes (ISP, Cellular etc). While the meeting didn't decide to create a separate set of documents the chair requested deployment reports from anybody who has such experience. There was a comment that the draft had two many acronyms, which the meeting agreed with. There was also some questions about the layout of the draft. Finally the design group plans to put the solutions into a separate document. * Jonne Soininen Cellular Networks Team draft-ietf-v6ops-3gpp-cases-00.txt draft-wiljakka-3gpp-ipv6-transition-02.txt Jonne pointed out that this group started first and so is somewhat ahead of the other groups. The scenarios document is already a WG document. This document seems to be stable and does not require major changes, though there are a few editorial tweaks to be handled. There was a request for a dual stack IMS scenario which was deemed out of scope for the design group. The last set of changes to the analysis document were mostly editorial and there are still several items left to do. These include clarifying the use of static vs dynamic tunneling, documenting the NAT-PT vs NAT64 issues, removing an error in the IMS 1 scenario and changing the name of the document (to analysis document). They also plan to use the Thakur document as input for the analysis document but need to check with the authors first. Jonne also described the scenarios they have developed for the analysis document so far these are. Please see the document for a description of these scenarios. The small number of people that have read the scenarios document feel that it is stable and acceptable for it to go to last call. There didn't seem to be a large amount of interest in the analysis document but it has been accepted as a working group item. The design group is to be turned into an authors group. One of the major areas of discussion was NAT-PT. The group agrees that there are substantial problems with NAT-PT however it is unclear as to how we can proceed given our current charter. (Note: Alain Durand has written a, possibly expired, draft on some of the issues.) Some of the points made in the discussion are: 1) NAT can not be a general solution - it may work for some applications but other applications will need a more specific ALG. 2) NAT-PT may eventually disappear while NATv4 may be around for a while. If so we may need to rework NAT-PT to make it as good as, but no better than NATv4. 3) Perhaps we should get some operational experience about the tools we have to determine they are truly broken before we try to write yet another. 4) The major scenario in which IPv6 only needs to inter-operate with IPv4 only may be the end game. When we want to allow for the use of legacy systems and most of the net is IPv6 only. 5) Some functions, such as DNS, will need to be dual stacked and we may need to understand how they interact with IPv6 before we can go to IPv6 only. 6) George Tsirtsis, the author of the RFC, pointed out that NAT-PT was not meant as a general solution. As such one of the first steps in updating the document should be to determine in which cases NAT-PT is useful. 7) One of the scenarios in the cellular document may require NAT-PT. One of the ADs, Thomas Narten, stated that if NAT-PT is broken then it should either be fixed or tossed. There were several suggestions as to what we should do including that NAT-PT should be revised or at least have an applicability statement inserted. There is no consensus that it can be fixed especially for all things that might want to use it. The meeting agreed that we should ask the ADs to add updating NAT-PT to our charter. * The following item describes the status and open issues of one of the current work items. * Erik Nordmark - draft-ietf-ngtrans-mech-v2-01.txt (update to RFC2893) Erik raised several issues and there was a small amount of discussion on some of them, however most of the discussion has been directed to the mailing list. Erik will send a draft to the mailing list with a basic plan of updating the draft according to the edits that the WG can agree on. The following list describes the issues that Erik raised. Should we drop mentions of unidirectional tunnels? (No discussion.) Is 1280 a reasonable MTU for encapsulators without dynamic tunnel MTU discovery? In the discussion it appears that a slightly larger size would be useful for mobile IP - this size would be 1280 plus space for another header. Is 4400 a reasonable cap on dynamic tunnel MTU discovery? In the discussion it was pointed out that it doesn't seem necessary to have a limit unless decpsulators have a large physical interface MTU, however most discussion should occur on the mailing list. Any other concerns about reassembly buffer size? (No discussion.) The IPv4 native address group includes IPv4 mapped addresses as currently defined. Is this an issue that needs to be dealt with? (No discussion.) Any comments on ingress filtering? * The following two items are proposals for new work items. * Myung-Ki Shin - draft-shin-v6ops-application-transition-00.txt This is an attempt to give developers some guidelines when writing or modifying applications. The discussion was quite short. One point was that some of the assumptions may be incorrect for example some applications can't be dual stacked. Another point was that an effort such as this should get a broader view. There is an effort underway to move this into the application area where it can get the appropriate review. This effort has been ongoing and unsuccessful so far but may be working better now. The chairs are to talk to the ADs to determine how to move forward on this effort. * Pekka Savola - draft-savola-v6ops-6to4-security-00.txt The basic issue is that the 6to4 specification is terse on security considerations and that security checks can be difficult to implement if multiple automatic tunneling mechanisms are used in the same box. One specific issue that Pekka brought up was that of 6to4 relay spoofing, in which an attacker could pretend to be a relay and send packets to a 6to4 router. He supplied two possible patches: (1) relays should always use 192.88.99.0/24 (from rfc3068) as their source address and (2) limited distribution of more specific 6to4 routes. The discussion questioned if (1) would be effective and indicated that some sort of cryptographic relationship would be necessary. Christian Huitema mentioned that this was being investigated as part of Teredo and that they are considering some sort of three way handshake. However this is a DDOS problem and it may not be unsolvable. There was some other discussion which included the following points: the use of asymmetric routing may be a flaw in the model, the lack of capability of ingress routing is part of the problem, better tracing in ICMP would help and finally that the problem is difficult but could be solved. As the WG was running out of time this discussion was ended and moved to the mailing list. ** We finished with some comments by Harald Alvestrand about the transition from the IPNG WG to the V6OPS WG. Harald has also sent a note describing this transition to the mailing list, people interested in this issue should also consult that note. Over the summer the ADs responsible for IPv4 became concerned about the NGtrans effort. They were concerned that there was a growing complexity in the transition options that would present deployment difficulties. This led to discussions about re-chartering the WG with several options being discussed including re-chartering the WG and concluding the current WG and creating a new WG. The end result of these discussions was to charter a new group and close the old group. The new group starts with a narrow charter that may be expanded as necessary. Harald pointed out that while this narrow charter is designed to focus this particular work effort, it is not meant to stop other work. People who are interested in items that are not included in the charter of the WG are encouraged to work on them with the standard options available. These options include bringing the item back to the WG or IESG after more work to try and get it adopted by the WG, publishing it as Informational or Experimental within the IETF framework or possibly taking the work somewhere else. There was a brief (as we were already past time) discussion of this issue that became a discussion of general IESG/IETF issues. Two of these issues were the requirements for publication of a document and for allocation of a resource. Both of these are handled on a cases by case basis but there are some general rules. In the case of publishing a document the requirements are higher for those on the standards track than those that will are Informational or Experimental. In the case of resource allocation, such as protocol numbers, the requirements are based on the scarcity of the resources. For scarce resources, such as protocol numbers, a stable standards track document is required, less scarce resources may be allocated in an Experimental document or via IANA. (Editor's note: there was also some discussion about resource allocation at the Thursday night plenary.) Two possible problems with the current process were also mentioned. The first is that it is possible for and AD to stall documents and the second is that it is difficult for a WG to indicate that they believe an AD has erred. In conclusion Harald reminded the group that he (or the IESG if appropriate) needs to hear about things in order to try and fix any problems and he encouraged people to talk to him (or them) if you believe there is some sort of process problem. From owner-v6ops@ops.ietf.org Wed Dec 4 15:43:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02914 for ; Wed, 4 Dec 2002 15:43:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JgNu-000LGr-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 12:44:42 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18JgNq-000LGe-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 12:44:38 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB4KhvG05839 for ; Wed, 4 Dec 2002 22:43:57 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Dec 2002 22:44:35 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 22:44:34 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: on NAT-PT Date: Wed, 4 Dec 2002 22:44:34 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC35F2@esebe005.ntc.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcKWmsrVup6reQIFTIKjCvgx8uRBJQFLsOwwAAEiUmA= From: To: Cc: X-OriginalArrivalTime: 04 Dec 2002 20:44:34.0807 (UTC) FILETIME=[F4418870:01C29BD5] X-Spam-Status: No, hits=1.6 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA02914 Itojun, thanks for your comments below; sorry for the very late reply! -----Original Message----- From: ext itojun@iijlab.net [mailto:itojun@iijlab.net] Sent: 28 November, 2002 06:47 there are some concerns raised in the working group meeting with respect to NAT-PT. it seems to me that the concerns does not have enough technical ground (or there are some confusions in understanding how NAT-PT works). i don't see the need for revising NAT-PT at all. some clarifications on the document might be nice, but no major re-work is needed, IMHO. draft-wiljakka-3gpp-ipv6-transition-01.txt, page 9: > NAPT-PT introduces a number of limitations that are expected to be > magnified within the 3GPP architecture. Some of these limitations > are listed here: > 1. NAPT-PT is a single point of failure for all ongoing > connections. > 2. Additional forwarding delays due to further processing, when > compared to normal IP forwarding. > 3. Problems with source address selection due to the inclusion of > a DNS ALG on the same node [NATPT-DNS]. > 4. NAPT-PT does not work (without application level gateways) for > applications that embed IP addresses in their payload. > 5. NAPT-PT breaks DNSSEC. > 6. NAPT-PT does not scale very well in large networks. (1), (2), and (4) are inherent problem with NAT. it is unavoidable. if you wish to avoid this, you'll need to make cellular node a dual stack node and make them use IPv4 directly (instead of using IPv6-to- IPv4 translation). JW: Right.. I am afraid that the dual stack won't work for all the scenarios (like IMS scenario 1). Furthermore, availability of public IPv4 addresses is not too good in many large (3GPP) networks; use of private v4 addresses together with v4 NATs won't make the situation better.. Do you think that listing these problems in our document is ok? Should we write some clarifying text that v4 NAT has same type of problems (i.e. not only NAT-PT)? (3) is incorrect, see below. (5) - when you rely upon DNS responses created on the fly, as well as a box that rewrites your data traffic, why this is a show-stopper? JW: Well, I wouldn't necessarily say that it is a showstopper, the problem is just mentioned here. (6) - see below. > To minimize the problems associated with NAPT-PT, the following > actions are recommended: > 1. Separate the DNS ALG from the NAPT-PT node. > 2. Ensure that NAPT-PT does not become a single point of > failure. > 3. Allow for load sharing between different translators. That > is, it should be possible for different connections to go > through different translators. Note that load sharing alone > does not prevent NAPT-PT from becoming a single point of > failure. > There are certain ways to fix the problems with NAPT-PT, one > suggestion is [NAT64]. (1) is not correct. NAT-PT RFC does not specify where to place DNS-ALG. DNS-ALG and NAT-PT translation part can reside on different boxes. when there's only one IPv4 address available to the site, there's no other choice than to collocate DNS-ALG and the translation part. (RFC2766 seems to talk about this situation only, which might be the source of the confusion) JW: OK... What would be your (text) suggestion; forgetting this recommendation? Alain D. commented in his mail that the DNS-ALG part in the "v6 to v4" case needs to removed from the NAT-PT document. (2) is not avoidable with NAT-PT, as it is a NAT (keeps state in translation part). SIIT could be another choice, but there are some concerns like draft-itojun-v6ops-v4mapped-harmful-01.txt in the use of IPv4 mapped address on wire. JW: Thanks for the pointer; I agree that avoiding it to become a single point of failure is not an easy task. (3) is not correct. you can place the following boxes and perform load balancing between NAT-PT translation part. see RFC3142 page 5 for more details. - multiple NAT-PT translation part, configured with different NAT-PT translation prefix, and - DNS-ALG that returns addresses crafted from multiple different NAT-PT translation prefix randomly JW: I will have a look at RFC3142. Thanks, -Juha W.- P.S. I agree with Brian Carpenter that we need a document discussing the issues with NAT-PT; after that we can see more clearly, how (/ whether) we shall revisit the NAT-PT RFC. From owner-v6ops@ops.ietf.org Wed Dec 4 17:04:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06399 for ; Wed, 4 Dec 2002 17:04:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jhe6-000PVM-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 14:05:30 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #2) id 18Jhe1-000PTL-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 14:05:25 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 4 Dec 2002 14:04:22 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Dec 2002 14:04:21 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 4 Dec 2002 14:04:21 -0800 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(5.0.2195.5600); Wed, 4 Dec 2002 14:04:18 -0800 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.3710.0); Wed, 4 Dec 2002 14:04:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: on NAT-PT Date: Wed, 4 Dec 2002 14:04:19 -0800 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcKWmsrVup6reQIFTIKjCvgx8uRBJQFLsOwwAAEiUmAABHPAgA== From: "Christian Huitema" To: , Cc: X-OriginalArrivalTime: 04 Dec 2002 22:04:14.0713 (UTC) FILETIME=[154D4E90:01C29BE1] X-Spam-Status: No, hits=0.4 required=5.0 tests=HOT_NASTY,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA06399 The following text is an extract from draft-huitema-ngtrans-unmaneval-01.txt, section 3.2.1: the problem with address translation: An obvious candidate for enabling communication between IPv4-only and IPv6-only hosts is "network address translation, protocol translation" [NAT-PT]. The NAT-PT mechanisms has two components, address translation and address discovery: address translation is the processing of IP packets by a NAT; address discovery is the mechanism by which an IPv4- only or IPv6-only host discovers the "translated address" at which packets for their correspondent should be addressed. The NAT-PT specification proposes to solve address discovery by using a DNS ALG, as specified in section 4 of [NAT-PT]. This section makes an important assumption: it assumes that the NAT-PT acts as a bridge between two networks, one IPv6-only and the other IPv6- only. As a result, the DNS-ALG will translate a DNS request for a AAAA record coming from the IPv6 host into a request for an A record, and vice versa. The problem is that address translation does not know if the traffic originates from an IPv4 only/IPv6 only node or from a dual stack node. When a dual stack node A wants to communicate with an IPv4 only host B, the dual stack host A gets either the IPv4 address of B (preferred) or an IPv6 address which is some kind of translation of the IPv4 address of B. This latter situation is not wanted, because it means unnecessary translation between IPv4 and IPv6. This is shown in the table below. ============================================================ | + A | | | | | + | IPv4 only | dual stack | IPv6 only | | B + | | | | ============================================================ | | | | | | IPv4 | IPv4 | IPv4 | t(IPv6)->IPv4 | | only | address | address | address | | | | | | ------------------------------------------------------------ | |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX| | dual | IPv4 address or | IPv4 or IPv6 | IPv6 address or | | stack | t(IPv4)->IPv6 | address | t(IPv6)->IPv4 | | |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX| ------------------------------------------------------------ | | | | | | IPv6 | t(IPv4)->IPv6 | IPv6 | IPv6 | | only | address | address | address | | | | | | ============================================================ The boxes with XXX-es are the cases where address translation could result in unwanted translation. In short, the problem is that inserting the DNS-ALG function in a gateway might be beneficial in the IPv4-only to IPv6-only scenario, but is detrimental in the scenarios that involve dual stack hosts. Since there is likely to be many more dual stack hosts than IPv6 only hosts, this means that NAT-PT as its stands is detrimental to IPv6 transition. -- Christian Huitema > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: Wednesday, December 04, 2002 12:45 PM > To: itojun@iijlab.net > Cc: v6ops@ops.ietf.org > Subject: Re: on NAT-PT > > Itojun, > > thanks for your comments below; sorry for the very late reply! > > -----Original Message----- > From: ext itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: 28 November, 2002 06:47 > > there are some concerns raised in the working group meeting > with respect to NAT-PT. it seems to me that the concerns does not > have enough technical ground (or there are some confusions in > understanding how NAT-PT works). i don't see the need for revising > NAT-PT at all. some clarifications on the document might be nice, > but no major re-work is needed, IMHO. > > draft-wiljakka-3gpp-ipv6-transition-01.txt, page 9: > > > NAPT-PT introduces a number of limitations that are expected to be > > magnified within the 3GPP architecture. Some of these limitations > > are listed here: > > 1. NAPT-PT is a single point of failure for all ongoing > > connections. > > 2. Additional forwarding delays due to further processing, when > > compared to normal IP forwarding. > > 3. Problems with source address selection due to the inclusion of > > a DNS ALG on the same node [NATPT-DNS]. > > 4. NAPT-PT does not work (without application level gateways) for > > applications that embed IP addresses in their payload. > > 5. NAPT-PT breaks DNSSEC. > > 6. NAPT-PT does not scale very well in large networks. > > (1), (2), and (4) are inherent problem with NAT. it is unavoidable. > if you wish to avoid this, you'll need to make cellular node a dual > stack node and make them use IPv4 directly (instead of using IPv6- > to- > IPv4 translation). > > JW: Right.. I am afraid that the dual stack won't work for all the > scenarios (like IMS scenario 1). Furthermore, availability of public IPv4 > addresses is not too good in many large (3GPP) networks; use of private > v4 addresses together with v4 NATs won't make the situation better.. Do > you think that listing these problems in our document is ok? Should we > write some clarifying text that v4 NAT has same type of problems (i.e. not > only NAT-PT)? > > (3) is incorrect, see below. > > (5) - when you rely upon DNS responses created on the fly, as well > as > a box that rewrites your data traffic, why this is a show-stopper? > > JW: Well, I wouldn't necessarily say that it is a showstopper, the problem > is just mentioned here. > > (6) - see below. > > > To minimize the problems associated with NAPT-PT, the following > > actions are recommended: > > 1. Separate the DNS ALG from the NAPT-PT node. > > 2. Ensure that NAPT-PT does not become a single point of > > failure. > > 3. Allow for load sharing between different translators. That > > is, it should be possible for different connections to go > > through different translators. Note that load sharing alone > > does not prevent NAPT-PT from becoming a single point of > > failure. > > There are certain ways to fix the problems with NAPT-PT, one > > suggestion is [NAT64]. > > (1) is not correct. NAT-PT RFC does not specify where to place DNS- > ALG. > DNS-ALG and NAT-PT translation part can reside on different boxes. > when there's only one IPv4 address available to the site, there's no > other choice than to collocate DNS-ALG and the translation part. > (RFC2766 seems to talk about this situation only, which might be > the source of the confusion) > > JW: OK... What would be your (text) suggestion; forgetting this > recommendation? Alain D. commented in his mail that the DNS-ALG part in > the "v6 to v4" case needs to removed from the NAT-PT document. > > (2) is not avoidable with NAT-PT, as it is a NAT (keeps state in > translation part). SIIT could be another choice, but there are > some concerns like draft-itojun-v6ops-v4mapped-harmful-01.txt in > the use of IPv4 mapped address on wire. > > JW: Thanks for the pointer; I agree that avoiding it to become a single > point of failure is not an easy task. > > (3) is not correct. you can place the following boxes and perform > load > balancing between NAT-PT translation part. see RFC3142 page 5 for > more details. > - multiple NAT-PT translation part, configured with different NAT-PT > translation prefix, and > - DNS-ALG that returns addresses crafted from multiple different > NAT-PT > translation prefix randomly > > JW: I will have a look at RFC3142. > > Thanks, > -Juha W.- > > P.S. I agree with Brian Carpenter that we need a document discussing the > issues with NAT-PT; after that we can see more clearly, how (/ whether) we > shall revisit the NAT-PT RFC. From owner-v6ops@ops.ietf.org Wed Dec 4 18:48:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10918 for ; Wed, 4 Dec 2002 18:48:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JjG5-0005BZ-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 15:48:49 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18JjG1-0005BL-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 15:48:45 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6A1ED4B22; Thu, 5 Dec 2002 08:48:41 +0900 (JST) To: "Christian Huitema" Cc: v6ops@ops.ietf.org In-reply-to: huitema's message of Wed, 04 Dec 2002 14:04:19 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Thu, 05 Dec 2002 08:48:41 +0900 Message-Id: <20021204234841.6A1ED4B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >The following text is an extract from >draft-huitema-ngtrans-unmaneval-01.txt, section 3.2.1: the problem with >address translation: (snip) >In short, the problem is that inserting the DNS-ALG function in a >gateway might be beneficial in the IPv4-only to IPv6-only scenario, but >is detrimental in the scenarios that involve dual stack hosts. Since >there is likely to be many more dual stack hosts than IPv6 only hosts, >this means that NAT-PT as its stands is detrimental to IPv6 transition. i don't think you have checked my initial posting. header is attached as an evidence. itojun --- Return-Path: Delivered-To: itojun@itojun.org Received: from psg.com (psg.com [147.28.0.62]) by coconut.itojun.org (Postfix) with ESMTP id 1AB2E4B22 for ; Thu, 28 Nov 2002 13:49:08 +0900 (JST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HGZY-000Ee4-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 20:46:44 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18HGZV-000Eds-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 20:46:41 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id BC9C24B22 for ; Thu, 28 Nov 2002 13:46:37 +0900 (JST) To: v6ops@ops.ietf.org Subject: on NAT-PT X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Thu, 28 Nov 2002 13:46:37 +0900 Message-Id: <20021128044637.BC9C24B22@coconut.itojun.org> X-Spam-Status: No, hits=1.0 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org there are some concerns raised in the working group meeting with respect to NAT-PT. it seems to me that the concerns does not have enough technical ground (or there are some confusions in understanding how NAT-PT works). i don't see the need for revising NAT-PT at all. some clarifications on the document might be nice, but no major re-work is needed, IMHO. itojun (snip) draft-huitema-ngtrans-unmaneval-01.txt, page 4: >This section makes an important assumption: it assumes that the NAT- >PT acts as a bridge between two networks, one IPv6-only and the >other IPv6-only. As a result, the DNS-ALG will translate a DNS "and the other IPv4-only", i suppose. >request for a AAAA record coming from the IPv6 host into a request >for an A record, and vice versa. The problem is that address >translation does not know if the traffic originates from an IPv4 >only/IPv6 only node or from a dual stack node. When a dual stack >node A wants to communicate with an IPv4 only host B, the dual stack >host A gets either the IPv4 address of B (preferred) or an IPv6 >address which is some kind of translation of the IPv4 address of B. >This latter situation is not wanted, because it means unnecessary >translation between IPv4 and IPv6. This is shown in the table below. the answer is simple - don't use DNS-ALG if you are a dual stack node. use DNS-ALG as your recursive resolver only when you are IPv6 only node (hence you use NAT-PT translation part if the ultimate destionation is IPv4-only). From owner-v6ops@ops.ietf.org Wed Dec 4 20:46:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14573 for ; Wed, 4 Dec 2002 20:46:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jl6x-000Bzh-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 17:47:31 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Jl6p-000Byz-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 17:47:24 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 85D684B22; Thu, 5 Dec 2002 10:47:21 +0900 (JST) To: juha.wiljakka@nokia.com Cc: v6ops@ops.ietf.org In-reply-to: juha.wiljakka's message of Wed, 04 Dec 2002 22:44:34 +0200. <245DBCAEEC4F074CB77B3F984FF9834FDC35F2@esebe005.ntc.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Thu, 05 Dec 2002 10:47:21 +0900 Message-Id: <20021205014721.85D684B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>> To minimize the problems associated with NAPT-PT, the following=20 >>> actions are recommended: =20 >>> 1. Separate the DNS ALG from the NAPT-PT node.=20 >> (1) is not correct. NAT-PT RFC does not specify where to place = >>DNS-ALG. >> DNS-ALG and NAT-PT translation part can reside on different boxes. >> when there's only one IPv4 address available to the site, there's no >> other choice than to collocate DNS-ALG and the translation part. >> (RFC2766 seems to talk about this situation only, which might be >> the source of the confusion) >JW: OK... What would be your (text) suggestion; forgetting this >recommendation? Alain D. commented in his mail that the DNS-ALG part in >the "v6 to v4" case needs to removed from the NAT-PT document. depends on what do you really mean by "separate". if you mean that DNS-ALG functionality has to reside onto separate box from NAT-PT translation functionality, it is already part of NAT-PT spec (so you can drop this bullet). it looks that you mean something else, like avoiding the use of DNS-ALG from NAT-PT (= alter NAT-PT spec). i don't see real technical ground for that. itojun From owner-v6ops@ops.ietf.org Wed Dec 4 21:08:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15068 for ; Wed, 4 Dec 2002 21:08:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JlSF-000DGa-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 18:09:31 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #2) id 18JlSB-000DFx-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 18:09:27 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 4 Dec 2002 18:08:15 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Dec 2002 18:08:15 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 4 Dec 2002 18:08:11 -0800 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(5.0.2195.5600); Wed, 4 Dec 2002 18:08:15 -0800 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.3710.0); Wed, 4 Dec 2002 18:07:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: on NAT-PT Date: Wed, 4 Dec 2002 18:08:14 -0800 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcKb77Fe0MyxsqR1R6CGuVtcohbteAAEpFcw From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 05 Dec 2002 02:07:57.0439 (UTC) FILETIME=[212038F0:01C29C03] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA15068 The problem is that the solution you propose is not applicable. You say: "don't use DNS-ALG if you are a dual stack node." The problem is that a host on an unmanaged cannot choose which DNS server to use: it receives a configuration through DHCP, and the configuration is the same for every host. The DHCP server does not know whether the host is dual stack or not, so it cannot give different value to different hosts. The solution is probably to not use NAT-PT at all in unmanaged networks: in practice, the host who desires to communicate with legacy IPv4 services will be dual stack. We need however to mitigate the problem posed by NAT-PT when it does address translation, and we should do that by following Rob's suggestion of reserving address ranges for the result of translation + making these addresses least preferred in the address selection rules. > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, December 04, 2002 3:49 PM > To: Christian Huitema > Cc: v6ops@ops.ietf.org > Subject: Re: on NAT-PT > > >The following text is an extract from > >draft-huitema-ngtrans-unmaneval-01.txt, section 3.2.1: the problem with > >address translation: > (snip) > >In short, the problem is that inserting the DNS-ALG function in a > >gateway might be beneficial in the IPv4-only to IPv6-only scenario, but > >is detrimental in the scenarios that involve dual stack hosts. Since > >there is likely to be many more dual stack hosts than IPv6 only hosts, > >this means that NAT-PT as its stands is detrimental to IPv6 transition. > > i don't think you have checked my initial posting. > header is attached as an evidence. > > itojun > > > --- > Return-Path: > Delivered-To: itojun@itojun.org > Received: from psg.com (psg.com [147.28.0.62]) > by coconut.itojun.org (Postfix) with ESMTP id 1AB2E4B22 > for ; Thu, 28 Nov 2002 13:49:08 +0900 (JST) > Received: from lserv by psg.com with local (Exim 3.36 #2) > id 18HGZY-000Ee4-00 > for v6ops-data@psg.com; Wed, 27 Nov 2002 20:46:44 -0800 > Received: from coconut.itojun.org ([219.101.47.130]) > by psg.com with esmtp (Exim 3.36 #2) > id 18HGZV-000Eds-00 > for v6ops@ops.ietf.org; Wed, 27 Nov 2002 20:46:41 -0800 > Received: from itojun.org (localhost [127.0.0.1]) > by coconut.itojun.org (Postfix) with ESMTP id BC9C24B22 > for ; Thu, 28 Nov 2002 13:46:37 +0900 (JST) > To: v6ops@ops.ietf.org > Subject: on NAT-PT > X-Template-Reply-To: itojun@itojun.org > X-Template-Return-Receipt-To: itojun@itojun.org > X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 > From: itojun@iijlab.net > Date: Thu, 28 Nov 2002 13:46:37 +0900 > Message-Id: <20021128044637.BC9C24B22@coconut.itojun.org> > X-Spam-Status: No, hits=1.0 required=5.0 > tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 > version=2.43 > X-Spam-Level: * > Sender: owner-v6ops@ops.ietf.org > Precedence: bulk > X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org > > there are some concerns raised in the working group meeting > with respect to NAT-PT. it seems to me that the concerns does not > have enough technical ground (or there are some confusions in > understanding how NAT-PT works). i don't see the need for revising > NAT-PT at all. some clarifications on the document might be nice, > but no major re-work is needed, IMHO. > > itojun > > > (snip) > draft-huitema-ngtrans-unmaneval-01.txt, page 4: > > >This section makes an important assumption: it assumes that the NAT- > >PT acts as a bridge between two networks, one IPv6-only and the > >other IPv6-only. As a result, the DNS-ALG will translate a DNS > > "and the other IPv4-only", i suppose. > > >request for a AAAA record coming from the IPv6 host into a request > >for an A record, and vice versa. The problem is that address > >translation does not know if the traffic originates from an IPv4 > >only/IPv6 only node or from a dual stack node. When a dual stack > >node A wants to communicate with an IPv4 only host B, the dual stack > >host A gets either the IPv4 address of B (preferred) or an IPv6 > >address which is some kind of translation of the IPv4 address of B. > >This latter situation is not wanted, because it means unnecessary > >translation between IPv4 and IPv6. This is shown in the table below. > > the answer is simple - don't use DNS-ALG if you are a dual stack > node. > use DNS-ALG as your recursive resolver only when you are IPv6 only > node (hence you use NAT-PT translation part if the ultimate > destionation is IPv4-only). From owner-v6ops@ops.ietf.org Wed Dec 4 21:08:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15082 for ; Wed, 4 Dec 2002 21:08:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JlSj-000DHP-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 18:10:01 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #2) id 18JlSf-000DGC-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 18:09:57 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 4 Dec 2002 18:09:25 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Dec 2002 18:09:22 -0800 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.3710.0); Wed, 4 Dec 2002 18:09:21 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 4 Dec 2002 18:09:24 -0800 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.3710.0); Wed, 4 Dec 2002 18:09:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: on NAT-PT Date: Wed, 4 Dec 2002 18:09:23 -0800 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcKcAtDcEkHQp45lSUSbcZCs5UgrTwAAHJYA From: "Christian Huitema" To: , Cc: X-OriginalArrivalTime: 05 Dec 2002 02:09:06.0635 (UTC) FILETIME=[4A5EB1B0:01C29C03] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA15082 > it looks that you mean something else, like avoiding the use of > DNS-ALG from NAT-PT (= alter NAT-PT spec). i don't see real > technical > ground for that. There is some ground: the possibility to use NAT-PT when the remote address is learned outside of the DNS channel. From owner-v6ops@ops.ietf.org Wed Dec 4 21:10:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15146 for ; Wed, 4 Dec 2002 21:10:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JlW9-000DYG-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 18:13:33 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18JlVy-000DWK-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 18:13:22 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 249E64B23; Thu, 5 Dec 2002 11:13:20 +0900 (JST) To: "Christian Huitema" Cc: v6ops@ops.ietf.org In-reply-to: huitema's message of Wed, 04 Dec 2002 18:09:23 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Thu, 05 Dec 2002 11:13:20 +0900 Message-Id: <20021205021320.249E64B23@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> it looks that you mean something else, like avoiding the use of >> DNS-ALG from NAT-PT (=3D alter NAT-PT spec). i don't see real technical >> ground for that. >There is some ground: the possibility to use NAT-PT when the remote >address is learned outside of the DNS channel. if your "channel" was not through NAT-PT and you have leant IPv4 address, you are basically dead. there's nothing we can do. if your "channel" is NAT-PT and you have leant IPv4 address, your NAT-PT does not support your particular "channel" - common NAT problem. itojun From owner-v6ops@ops.ietf.org Wed Dec 4 21:39:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16200 for ; Wed, 4 Dec 2002 21:39:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jlxj-000FNs-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 18:42:03 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #2) id 18Jlxh-000FMs-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 18:42:01 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 4 Dec 2002 18:41:30 -0800 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Dec 2002 18:41:26 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 4 Dec 2002 18:41:29 -0800 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(5.0.2195.5600); Wed, 4 Dec 2002 18:41:29 -0800 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.3710.0); Wed, 4 Dec 2002 18:41:09 -0800 Content-class: urn:content-classes:message Subject: RE: on NAT-PT MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Dec 2002 18:41:29 -0800 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: on NAT-PT Thread-Index: AcKcA+SBrbD5dyrhS8eMtPEa4M7KYQAA9qRw From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 05 Dec 2002 02:41:09.0992 (UTC) FILETIME=[C4C7AE80:01C29C07] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA16200 > >> it looks that you mean something else, like avoiding the use of > >> DNS-ALG from NAT-PT (=3D alter NAT-PT spec). i don't see real > technical > >> ground for that. > >There is some ground: the possibility to use NAT-PT when the remote > >address is learned outside of the DNS channel. > > if your "channel" was not through NAT-PT and you have leant IPv4 > address, you are basically dead. there's nothing we can do. > if your "channel" is NAT-PT and you have leant IPv4 address, your > NAT-PT does not support your particular "channel" - common NAT > problem. An IPv6 host doesn't have to be dead. If it has a piece of logic that combines a "nat-pt prefix" with the IPv4 destination address, then it can send the packet over IPv6 to that fabricated destination, and rely on the NAT-PT to do the translation job. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Dec 4 21:42:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16328 for ; Wed, 4 Dec 2002 21:42:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jm0B-000FXz-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 18:44:35 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Jm08-000FXj-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 18:44:32 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 940E24B22; Thu, 5 Dec 2002 11:44:30 +0900 (JST) To: "Christian Huitema" Cc: v6ops@ops.ietf.org In-reply-to: huitema's message of Wed, 04 Dec 2002 18:41:29 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Thu, 05 Dec 2002 11:44:30 +0900 Message-Id: <20021205024430.940E24B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >An IPv6 host doesn't have to be dead. If it has a piece of logic that >combines a "nat-pt prefix" with the IPv4 destination address, then it >can send the packet over IPv6 to that fabricated destination, and rely >on the NAT-PT to do the translation job. it seems to me that modifying an IPv6 host for transition purposes is not an option. basically it makes IPv6 hosts aware of NAT-PT (or whatever) translation in the middle, hence similar to RSIP model. itojun From owner-v6ops@ops.ietf.org Wed Dec 4 21:48:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16484 for ; Wed, 4 Dec 2002 21:48:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jm6E-000G2K-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 18:50:50 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #2) id 18Jm6B-000Fyi-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 18:50:47 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 4 Dec 2002 18:50:16 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Dec 2002 18:50:12 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 4 Dec 2002 18:50:16 -0800 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(5.0.2195.5600); Wed, 4 Dec 2002 18:50:15 -0800 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.3710.0); Wed, 4 Dec 2002 18:49:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message Subject: RE: on NAT-PT MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Dec 2002 18:50:15 -0800 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcKcCEELdqwUCtN9QNSqJd2kkj/oigAAH8/g From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 05 Dec 2002 02:49:55.0170 (UTC) FILETIME=[FDCF7C20:01C29C08] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA16484 > >An IPv6 host doesn't have to be dead. If it has a piece of logic that > >combines a "nat-pt prefix" with the IPv4 destination address, then it > >can send the packet over IPv6 to that fabricated destination, and rely > >on the NAT-PT to do the translation job. > > it seems to me that modifying an IPv6 host for transition purposes > is not an option. basically it makes IPv6 hosts aware of NAT-PT (or > whatever) translation in the middle, hence similar to RSIP model. I don't believe we should have a black-and-white attitude regarding this. I don't think that hosts developers can ignore that a transition is going on, at least during the next few years. Clearly, the best way for a host to support the transition is to be simply dual stack. Do you want to preclude hosts taking an in-between position, i.e. not dual-stack but still nat-pt aware? -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Dec 4 21:54:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16649 for ; Wed, 4 Dec 2002 21:54:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JmCf-000GLV-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 18:57:29 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18JmCc-000GLG-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 18:57:26 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB52sjj08650; Wed, 4 Dec 2002 21:54:46 -0500 (EST) Message-Id: <200212050254.gB52sjj08650@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Christian Huitema" cc: itojun@iijlab.net, juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: Re: on NAT-PT In-reply-to: (Your message of "Wed, 04 Dec 2002 18:09:23 PST.") Date: Wed, 04 Dec 2002 21:54:45 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > it looks that you mean something else, like avoiding the use of > > DNS-ALG from NAT-PT (= alter NAT-PT spec). i don't see real > > technical ground for that. > > There is some ground: the possibility to use NAT-PT when the remote > address is learned outside of the DNS channel. more generally, the possibility to selectively enable NAT-PT for specific services while leaving it disabled for others, regardless of how the application learns which address(es) to use. e.g. to support IPv6 access to a domain's v4-only SMTP servers I would like to be able to set up MX records for that domain that point to DNS names that resolve to v6 addresses of NAT-PT boxes that will forward the SMTP traffic to the v4-only SMTP servers. the primary MX records can point to v4 addresses, secondary MX records can point to NAT-PT boxes. that way the mail will be accepted even from v6-only clients. similar techniques can be used with SRV records, or with other protocols that do referrals. what I do not want is to have those NAT-PT boxes try to intercept all traffic to a particular domain, because this will break some apps. I'd much rather be able to specify handling on a per-port or per-service basis, even if that means returning 'connection refused' for some ports. From owner-v6ops@ops.ietf.org Wed Dec 4 21:55:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16673 for ; Wed, 4 Dec 2002 21:55:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JmD5-000GSX-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 18:57:55 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18JmD1-000GQk-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 18:57:51 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 791FE4B22; Thu, 5 Dec 2002 11:57:49 +0900 (JST) To: "Christian Huitema" Cc: v6ops@ops.ietf.org In-reply-to: huitema's message of Wed, 04 Dec 2002 18:50:15 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Thu, 05 Dec 2002 11:57:49 +0900 Message-Id: <20021205025749.791FE4B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>it seems to me that modifying an IPv6 host for transition purposes >>is not an option. basically it makes IPv6 hosts aware of NAT-PT (or >>whatever) translation in the middle, hence similar to RSIP model. >I don't believe we should have a black-and-white attitude regarding >this. I don't think that hosts developers can ignore that a transition >is going on, at least during the next few years. Clearly, the best way >for a host to support the transition is to be simply dual stack. Do you >want to preclude hosts taking an in-between position, i.e. not >dual-stack but still nat-pt aware?=20 that describes my position - "NAT-PT/whatever aware" node is not an option. it might look okay as shortterm workaround but will hurt us in the future. FYI, we have been there already - KAME DNS resolver code had an environment variable for setting address-translation prefix on the client side, we noticed that it is a bad thing, and it got removed. so this is from actual operational experience. itojun From owner-v6ops@ops.ietf.org Thu Dec 5 02:11:08 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29743 for ; Thu, 5 Dec 2002 02:11:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JqBO-0007Ok-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 23:12:26 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18JqBL-0007HO-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 23:12:23 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gB577sw24898; Thu, 5 Dec 2002 09:07:54 +0200 Date: Thu, 5 Dec 2002 09:07:53 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Christian Huitema , , , Subject: Re: on NAT-PT In-Reply-To: <200212050254.gB52sjj08650@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 4 Dec 2002, Keith Moore wrote: > > > it looks that you mean something else, like avoiding the use of > > > DNS-ALG from NAT-PT (= alter NAT-PT spec). i don't see real > > > technical ground for that. > > > > There is some ground: the possibility to use NAT-PT when the remote > > address is learned outside of the DNS channel. > > more generally, the possibility to selectively enable NAT-PT for specific > services while leaving it disabled for others, regardless of how the > application learns which address(es) to use. > > e.g. to support IPv6 access to a domain's v4-only SMTP servers I would > like to be able to set up MX records for that domain that point to DNS > names that resolve to v6 addresses of NAT-PT boxes that will forward > the SMTP traffic to the v4-only SMTP servers. the primary MX records > can point to v4 addresses, secondary MX records can point to NAT-PT > boxes. that way the mail will be accepted even from v6-only clients. > > similar techniques can be used with SRV records, or with other protocols > that do referrals. > > what I do not want is to have those NAT-PT boxes try to intercept all > traffic to a particular domain, because this will break some apps. > I'd much rather be able to specify handling on a per-port or per-service > basis, even if that means returning 'connection refused' for some ports. This sounds awfully lot like a selective TCP relay, and we use it for exactly that purpose. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 5 02:29:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02747 for ; Thu, 5 Dec 2002 02:29:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JqUH-0008j3-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 23:31:57 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18JqTl-0008fB-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 23:31:25 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB57RUj10236; Thu, 5 Dec 2002 02:27:30 -0500 (EST) Message-Id: <200212050727.gB57RUj10236@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , Christian Huitema , itojun@iijlab.net, juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: Re: on NAT-PT In-reply-to: (Your message of "Thu, 05 Dec 2002 09:07:53 +0200.") Date: Thu, 05 Dec 2002 02:27:30 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > what I do not want is to have those NAT-PT boxes try to intercept all > > traffic to a particular domain, because this will break some apps. > > I'd much rather be able to specify handling on a per-port or per-service > > basis, even if that means returning 'connection refused' for some ports. > > This sounds awfully lot like a selective TCP relay, and we use it for > exactly that purpose. very similar. there are advantages to doing a TCP relay, and other advantages to doing v6-v4 translation of IP packets. it's nice to be able to pick which one you want. From owner-v6ops@ops.ietf.org Thu Dec 5 02:55:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03462 for ; Thu, 5 Dec 2002 02:55:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JqtV-000AXq-00 for v6ops-data@psg.com; Wed, 04 Dec 2002 23:58:01 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18JqtR-000AXd-00 for v6ops@ops.ietf.org; Wed, 04 Dec 2002 23:57:57 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 13:12:35 +0530 Message-ID: From: "Thakur, Anand" To: Christian Huitema Cc: v6ops@ops.ietf.org, juha.wiljakka@nokia.com, itojun@iijlab.net Subject: RE: on NAT-PT Date: Thu, 5 Dec 2002 13:13:24 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.3 required=5.0 tests=EXCHANGE_SERVER,HOT_NASTY,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk hi christian, i don't think this a problem in na(p)t-pt, but more a problem in the way dns-alg works. for instance, if we could configure the dns-alg in such a way that it does the following: 1)maintain a table which maps the source ip address of the dns query and the type of query ("A" or "AAAA") 2)generate a dual-query ("A" + "AAAA") every time a dns query is detected. 3)when it intercepts a dns response it should ->translate the "A" response to "AAAA" response if the original quey was "AAAA" and the response is "A" only ->translate the "AAAA" response to "A" response if the original query was "A" and the response is "AAAA" only ->forward the "A" response only , if the original query was "A" and a dual response is received. ->forward the "AAAA" response only , if the original query was "AAAA" and a dual response is received. regards Anand Thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 > -----Original Message----- > From: Christian Huitema [SMTP:huitema@windows.microsoft.com] > Sent: Thursday, December 05, 2002 3:34 AM > To: juha.wiljakka@nokia.com; itojun@iijlab.net > Cc: v6ops@ops.ietf.org > Subject: RE: on NAT-PT > > The following text is an extract from > draft-huitema-ngtrans-unmaneval-01.txt, section 3.2.1: the problem with > address translation: > > An obvious candidate for enabling communication between IPv4-only and > > IPv6-only hosts is "network address translation, protocol > translation" > [NAT-PT]. The NAT-PT mechanisms has two components, address > translation > and address discovery: address translation is the processing of IP > packets by a NAT; address discovery is the mechanism by which an > IPv4- > only or IPv6-only host discovers the "translated address" at which > packets for their correspondent should be addressed. The NAT-PT > specification proposes to solve address discovery by using a DNS ALG, > as > specified in section 4 of [NAT-PT]. > > This section makes an important assumption: it assumes that the > NAT-PT > acts as a bridge between two networks, one IPv6-only and the other > IPv6- > only. As a result, the DNS-ALG will translate a DNS request for a > AAAA > record coming from the IPv6 host into a request for an A record, and > vice > versa. The problem is that address translation does not know if the > traffic originates from an IPv4 only/IPv6 only node or from a dual > stack > node. When a dual stack node A wants to communicate with an IPv4 only > > host B, the dual stack host A gets either the IPv4 address of B > (preferred) or an IPv6 address which is some kind of translation of > the > IPv4 address of B. This latter situation is not wanted, because it > means > unnecessary translation between IPv4 and IPv6. This is shown in the > table > below. > > ============================================================ > | + A | | | | > | + | IPv4 only | dual stack | IPv6 only | > | B + | | | | > ============================================================ > | | | | | > | IPv4 | IPv4 | IPv4 | t(IPv6)->IPv4 | > | only | address | address | address | > | | | | | > ------------------------------------------------------------ > | |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX| > | dual | IPv4 address or | IPv4 or IPv6 | IPv6 address or | > | stack | t(IPv4)->IPv6 | address | t(IPv6)->IPv4 | > | |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX| > ------------------------------------------------------------ > | | | | | > | IPv6 | t(IPv4)->IPv6 | IPv6 | IPv6 | > | only | address | address | address | > | | | | | > ============================================================ > > > The boxes with XXX-es are the cases where address translation could > result in unwanted translation. > > In short, the problem is that inserting the DNS-ALG function in a > gateway might be beneficial in the IPv4-only to IPv6-only scenario, but > is detrimental in the scenarios that involve dual stack hosts. Since > there is likely to be many more dual stack hosts than IPv6 only hosts, > this means that NAT-PT as its stands is detrimental to IPv6 transition. > > -- Christian Huitema > > > -----Original Message----- > > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > > Sent: Wednesday, December 04, 2002 12:45 PM > > To: itojun@iijlab.net > > Cc: v6ops@ops.ietf.org > > Subject: Re: on NAT-PT > > > > Itojun, > > > > thanks for your comments below; sorry for the very late reply! > > > > -----Original Message----- > > From: ext itojun@iijlab.net [mailto:itojun@iijlab.net] > > Sent: 28 November, 2002 06:47 > > > > there are some concerns raised in the working group meeting > > with respect to NAT-PT. it seems to me that the concerns does > not > > have enough technical ground (or there are some confusions in > > understanding how NAT-PT works). i don't see the need for > revising > > NAT-PT at all. some clarifications on the document might be > nice, > > but no major re-work is needed, IMHO. > > > > draft-wiljakka-3gpp-ipv6-transition-01.txt, page 9: > > > > > NAPT-PT introduces a number of limitations that are expected to > be > > > magnified within the 3GPP architecture. Some of these limitations > > > are listed here: > > > 1. NAPT-PT is a single point of failure for all ongoing > > > connections. > > > 2. Additional forwarding delays due to further processing, > when > > > compared to normal IP forwarding. > > > 3. Problems with source address selection due to the inclusion > of > > > a DNS ALG on the same node [NATPT-DNS]. > > > 4. NAPT-PT does not work (without application level gateways) > for > > > applications that embed IP addresses in their payload. > > > 5. NAPT-PT breaks DNSSEC. > > > 6. NAPT-PT does not scale very well in large networks. > > > > (1), (2), and (4) are inherent problem with NAT. it is > unavoidable. > > if you wish to avoid this, you'll need to make cellular node a > dual > > stack node and make them use IPv4 directly (instead of using > IPv6- > > to- > > IPv4 translation). > > > > JW: Right.. I am afraid that the dual stack won't work for all the > > scenarios (like IMS scenario 1). Furthermore, availability of public > IPv4 > > addresses is not too good in many large (3GPP) networks; use of > private > > v4 addresses together with v4 NATs won't make the situation better.. > Do > > you think that listing these problems in our document is ok? Should we > > write some clarifying text that v4 NAT has same type of problems (i.e. > not > > only NAT-PT)? > > > > (3) is incorrect, see below. > > > > (5) - when you rely upon DNS responses created on the fly, as > well > > as > > a box that rewrites your data traffic, why this is a > show-stopper? > > > > JW: Well, I wouldn't necessarily say that it is a showstopper, the > problem > > is just mentioned here. > > > > (6) - see below. > > > > > To minimize the problems associated with NAPT-PT, the following > > > actions are recommended: > > > 1. Separate the DNS ALG from the NAPT-PT node. > > > 2. Ensure that NAPT-PT does not become a single point of > > > failure. > > > 3. Allow for load sharing between different translators. > That > > > is, it should be possible for different connections to go > > > through different translators. Note that load sharing > alone > > > does not prevent NAPT-PT from becoming a single point of > > > failure. > > > There are certain ways to fix the problems with NAPT-PT, one > > > suggestion is [NAT64]. > > > > (1) is not correct. NAT-PT RFC does not specify where to place > DNS- > > ALG. > > DNS-ALG and NAT-PT translation part can reside on different > boxes. > > when there's only one IPv4 address available to the site, > there's no > > other choice than to collocate DNS-ALG and the translation part. > > (RFC2766 seems to talk about this situation only, which might be > > the source of the confusion) > > > > JW: OK... What would be your (text) suggestion; forgetting this > > recommendation? Alain D. commented in his mail that the DNS-ALG part > in > > the "v6 to v4" case needs to removed from the NAT-PT document. > > > > (2) is not avoidable with NAT-PT, as it is a NAT (keeps state in > > translation part). SIIT could be another choice, but there are > > some concerns like draft-itojun-v6ops-v4mapped-harmful-01.txt in > > the use of IPv4 mapped address on wire. > > > > JW: Thanks for the pointer; I agree that avoiding it to become a > single > > point of failure is not an easy task. > > > > (3) is not correct. you can place the following boxes and > perform > > load > > balancing between NAT-PT translation part. see RFC3142 page 5 > for > > more details. > > - multiple NAT-PT translation part, configured with different > NAT-PT > > translation prefix, and > > - DNS-ALG that returns addresses crafted from multiple different > > NAT-PT > > translation prefix randomly > > > > JW: I will have a look at RFC3142. > > > > Thanks, > > -Juha W.- > > > > P.S. I agree with Brian Carpenter that we need a document discussing > the > > issues with NAT-PT; after that we can see more clearly, how (/ > whether) we > > shall revisit the NAT-PT RFC. > > From owner-v6ops@ops.ietf.org Thu Dec 5 08:05:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09927 for ; Thu, 5 Dec 2002 08:05:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jviu-000KmS-00 for v6ops-data@psg.com; Thu, 05 Dec 2002 05:07:24 -0800 Received: from node147c0.a2000.nl ([24.132.71.192] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #2) id 18Jvis-000KmE-00 for v6ops@ops.ietf.org; Thu, 05 Dec 2002 05:07:22 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id gB5D79B07910; Thu, 5 Dec 2002 14:07:09 +0100 (CET) Date: Thu, 5 Dec 2002 14:07:09 +0100 From: Ronald van der Pol To: "Thakur, Anand" Cc: Christian Huitema , v6ops@ops.ietf.org, juha.wiljakka@nokia.com, itojun@iijlab.net Subject: Re: on NAT-PT Message-ID: <20021205130709.GD6682@rvdp.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-Spam-Status: No, hits=-4.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Dec 05, 2002 at 13:13:24 +0530, Thakur, Anand wrote: > > hi christian, > i don't think this a problem in na(p)t-pt, but more a problem in the way > dns-alg works. for instance, if we could configure the dns-alg in such a way > that it does the following: Suppose a dual-stack client asks for an AAAA. > 1)maintain a table which maps the source ip address of the dns query and the > type of query ("A" or "AAAA") Map that dual-stack client has asked for AAAA. > 2)generate a dual-query ("A" + "AAAA") every time a dns query is detected. Send A+AAAA queries. Suppose you receive A response only. > 3)when it intercepts a dns response it should > ->translate the "A" response to "AAAA" response if the original quey was > "AAAA" and the response is "A" only So, the A response is mapped to AAAA and send to the dual-stack client. That's not what you want. You want the dual-stack client to communicate over v4 transport with the destination. So, should not send a mapped AAAA to the dual-stack client. The dual-stack client should retry and ask for A. rvdp From owner-v6ops@ops.ietf.org Thu Dec 5 09:39:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13667 for ; Thu, 5 Dec 2002 09:39:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JxBS-000Ofy-00 for v6ops-data@psg.com; Thu, 05 Dec 2002 06:40:58 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18JxBO-000Ofm-00 for v6ops@ops.ietf.org; Thu, 05 Dec 2002 06:40:54 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB5EdXj15523; Thu, 5 Dec 2002 09:39:33 -0500 (EST) Message-Id: <200212051439.gB5EdXj15523@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Thakur, Anand" cc: Christian Huitema , v6ops@ops.ietf.org, juha.wiljakka@nokia.com, itojun@iijlab.net Subject: Re: on NAT-PT In-reply-to: (Your message of "Thu, 05 Dec 2002 13:13:24 +0530.") Date: Thu, 05 Dec 2002 09:39:33 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > i don't think this a problem in na(p)t-pt, but more a problem in the way > dns-alg works. for instance, if we could configure the dns-alg in such a way > that it does the following: > 1)maintain a table which maps the source ip address of the dns query and the > type of query ("A" or "AAAA") > 2)generate a dual-query ("A" + "AAAA") every time a dns query is detected. > 3)when it intercepts a dns response it should > ->translate the "A" response to "AAAA" response if the original quey was > "AAAA" and the response is "A" only > ->translate the "AAAA" response to "A" response if the original query was > "A" and the response is "AAAA" only > ->forward the "A" response only , if the original query was "A" and a dual > response is received. > ->forward the "AAAA" response only , if the original query was "AAAA" and a > dual response is received. > it's simply not reasonable to make assumptions about the capability of the host that will be using the result of a DNS query, from the IP address (or kind of IP address) of the host that submits a DNS query. there are too many ways that this can go wrong. in general the host that uses the result of a query is not necessarily the same as the host that makes the query. Keith From owner-v6ops@ops.ietf.org Thu Dec 5 13:35:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22857 for ; Thu, 5 Dec 2002 13:35:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K0rO-0009N5-00 for v6ops-data@psg.com; Thu, 05 Dec 2002 10:36:30 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #2) id 18K0rK-0009Mt-00 for v6ops@ops.ietf.org; Thu, 05 Dec 2002 10:36:27 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB5IbZW16754 for ; Thu, 5 Dec 2002 20:37:35 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Dec 2002 20:36:24 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 20:36:23 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Thu, 5 Dec 2002 20:36:22 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC35FF@esebe005.ntc.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcKWmsrVup6reQIFTIKjCvgx8uRBJQFLsOwwAAEiUmAABHPAgAArDgwg From: To: Cc: , X-OriginalArrivalTime: 05 Dec 2002 18:36:23.0183 (UTC) FILETIME=[361A99F0:01C29C8D] X-Spam-Status: No, hits=1.7 required=5.0 tests=HOT_NASTY,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA22857 Christian, thanks for the pointer! One thing we could do is to use that text as a reference in our analysis document. Looking at the discussion after your mail, there seems not be a clear consensus on (the severity of) the NAT-PT issues. IMHO, a separate draft describing / analyzing those would certainly be beneficial... Cheers, -Juha- -----Original Message----- From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: 05 December, 2002 00:04 To: Wiljakka Juha (NMP/Tampere); itojun@iijlab.net Cc: v6ops@ops.ietf.org Subject: RE: on NAT-PT The following text is an extract from draft-huitema-ngtrans-unmaneval-01.txt, section 3.2.1: the problem with address translation: An obvious candidate for enabling communication between IPv4-only and IPv6-only hosts is "network address translation, protocol translation" [NAT-PT]. The NAT-PT mechanisms has two components, address translation and address discovery: address translation is the processing of IP packets by a NAT; address discovery is the mechanism by which an IPv4- only or IPv6-only host discovers the "translated address" at which packets for their correspondent should be addressed. The NAT-PT specification proposes to solve address discovery by using a DNS ALG, as specified in section 4 of [NAT-PT]. This section makes an important assumption: it assumes that the NAT-PT acts as a bridge between two networks, one IPv6-only and the other IPv6- only. As a result, the DNS-ALG will translate a DNS request for a AAAA record coming from the IPv6 host into a request for an A record, and vice versa. The problem is that address translation does not know if the traffic originates from an IPv4 only/IPv6 only node or from a dual stack node. When a dual stack node A wants to communicate with an IPv4 only host B, the dual stack host A gets either the IPv4 address of B (preferred) or an IPv6 address which is some kind of translation of the IPv4 address of B. This latter situation is not wanted, because it means unnecessary translation between IPv4 and IPv6. This is shown in the table below. ============================================================ | + A | | | | | + | IPv4 only | dual stack | IPv6 only | | B + | | | | ============================================================ | | | | | | IPv4 | IPv4 | IPv4 | t(IPv6)->IPv4 | | only | address | address | address | | | | | | ------------------------------------------------------------ | |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX| | dual | IPv4 address or | IPv4 or IPv6 | IPv6 address or | | stack | t(IPv4)->IPv6 | address | t(IPv6)->IPv4 | | |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX| ------------------------------------------------------------ | | | | | | IPv6 | t(IPv4)->IPv6 | IPv6 | IPv6 | | only | address | address | address | | | | | | ============================================================ The boxes with XXX-es are the cases where address translation could result in unwanted translation. In short, the problem is that inserting the DNS-ALG function in a gateway might be beneficial in the IPv4-only to IPv6-only scenario, but is detrimental in the scenarios that involve dual stack hosts. Since there is likely to be many more dual stack hosts than IPv6 only hosts, this means that NAT-PT as its stands is detrimental to IPv6 transition. -- Christian Huitema > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: Wednesday, December 04, 2002 12:45 PM > To: itojun@iijlab.net > Cc: v6ops@ops.ietf.org > Subject: Re: on NAT-PT > > Itojun, > > thanks for your comments below; sorry for the very late reply! > > -----Original Message----- > From: ext itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: 28 November, 2002 06:47 > > there are some concerns raised in the working group meeting > with respect to NAT-PT. it seems to me that the concerns does not > have enough technical ground (or there are some confusions in > understanding how NAT-PT works). i don't see the need for revising > NAT-PT at all. some clarifications on the document might be nice, > but no major re-work is needed, IMHO. > > draft-wiljakka-3gpp-ipv6-transition-01.txt, page 9: > > > NAPT-PT introduces a number of limitations that are expected to be > > magnified within the 3GPP architecture. Some of these limitations > > are listed here: > > 1. NAPT-PT is a single point of failure for all ongoing > > connections. > > 2. Additional forwarding delays due to further processing, when > > compared to normal IP forwarding. > > 3. Problems with source address selection due to the inclusion of > > a DNS ALG on the same node [NATPT-DNS]. > > 4. NAPT-PT does not work (without application level gateways) for > > applications that embed IP addresses in their payload. > > 5. NAPT-PT breaks DNSSEC. > > 6. NAPT-PT does not scale very well in large networks. > > (1), (2), and (4) are inherent problem with NAT. it is unavoidable. > if you wish to avoid this, you'll need to make cellular node a dual > stack node and make them use IPv4 directly (instead of using IPv6- > to- > IPv4 translation). > > JW: Right.. I am afraid that the dual stack won't work for all the > scenarios (like IMS scenario 1). Furthermore, availability of public IPv4 > addresses is not too good in many large (3GPP) networks; use of private > v4 addresses together with v4 NATs won't make the situation better.. Do > you think that listing these problems in our document is ok? Should we > write some clarifying text that v4 NAT has same type of problems (i.e. not > only NAT-PT)? > > (3) is incorrect, see below. > > (5) - when you rely upon DNS responses created on the fly, as well > as > a box that rewrites your data traffic, why this is a show-stopper? > > JW: Well, I wouldn't necessarily say that it is a showstopper, the problem > is just mentioned here. > > (6) - see below. > > > To minimize the problems associated with NAPT-PT, the following > > actions are recommended: > > 1. Separate the DNS ALG from the NAPT-PT node. > > 2. Ensure that NAPT-PT does not become a single point of > > failure. > > 3. Allow for load sharing between different translators. That > > is, it should be possible for different connections to go > > through different translators. Note that load sharing alone > > does not prevent NAPT-PT from becoming a single point of > > failure. > > There are certain ways to fix the problems with NAPT-PT, one > > suggestion is [NAT64]. > > (1) is not correct. NAT-PT RFC does not specify where to place DNS- > ALG. > DNS-ALG and NAT-PT translation part can reside on different boxes. > when there's only one IPv4 address available to the site, there's no > other choice than to collocate DNS-ALG and the translation part. > (RFC2766 seems to talk about this situation only, which might be > the source of the confusion) > > JW: OK... What would be your (text) suggestion; forgetting this > recommendation? Alain D. commented in his mail that the DNS-ALG part in > the "v6 to v4" case needs to removed from the NAT-PT document. > > (2) is not avoidable with NAT-PT, as it is a NAT (keeps state in > translation part). SIIT could be another choice, but there are > some concerns like draft-itojun-v6ops-v4mapped-harmful-01.txt in > the use of IPv4 mapped address on wire. > > JW: Thanks for the pointer; I agree that avoiding it to become a single > point of failure is not an easy task. > > (3) is not correct. you can place the following boxes and perform > load > balancing between NAT-PT translation part. see RFC3142 page 5 for > more details. > - multiple NAT-PT translation part, configured with different NAT-PT > translation prefix, and > - DNS-ALG that returns addresses crafted from multiple different > NAT-PT > translation prefix randomly > > JW: I will have a look at RFC3142. > > Thanks, > -Juha W.- > > P.S. I agree with Brian Carpenter that we need a document discussing the > issues with NAT-PT; after that we can see more clearly, how (/ whether) we > shall revisit the NAT-PT RFC. From owner-v6ops@ops.ietf.org Thu Dec 5 23:02:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12898 for ; Thu, 5 Dec 2002 23:02:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K9gt-0008BD-00 for v6ops-data@psg.com; Thu, 05 Dec 2002 20:02:15 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18K9gN-00089s-00 for v6ops@ops.ietf.org; Thu, 05 Dec 2002 20:01:44 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 09:31:37 +0530 Message-ID: From: "Thakur, Anand" To: Keith Moore Cc: Christian Huitema , v6ops@ops.ietf.org, juha.wiljakka@nokia.com, itojun@iijlab.net Subject: RE: on NAT-PT Date: Fri, 6 Dec 2002 09:32:31 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk can you give me an example where the user of a dns response is different from the originator of the query? regards Anand Thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Thursday, December 05, 2002 8:10 PM > To: Thakur, Anand > Cc: Christian Huitema; v6ops@ops.ietf.org; juha.wiljakka@nokia.com; > itojun@iijlab.net > Subject: Re: on NAT-PT > > > i don't think this a problem in na(p)t-pt, but more a problem in the way > > dns-alg works. for instance, if we could configure the dns-alg in such a > way > > that it does the following: > > 1)maintain a table which maps the source ip address of the dns query and > the > > type of query ("A" or "AAAA") > > 2)generate a dual-query ("A" + "AAAA") every time a dns query is > detected. > > 3)when it intercepts a dns response it should > > ->translate the "A" response to "AAAA" response if the original quey was > > "AAAA" and the response is "A" only > > ->translate the "AAAA" response to "A" response if the original query > was > > "A" and the response is "AAAA" only > > ->forward the "A" response only , if the original query was "A" and a > dual > > response is received. > > ->forward the "AAAA" response only , if the original query was "AAAA" > and a > > dual response is received. > > > > it's simply not reasonable to make assumptions about the capability of > the host that will be using the result of a DNS query, from the IP address > (or kind of IP address) of the host that submits a DNS query. there are > too many ways that this can go wrong. in general the host that uses > the result of a query is not necessarily the same as the host that makes > the query. > > Keith From owner-v6ops@ops.ietf.org Thu Dec 5 23:18:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13272 for ; Thu, 5 Dec 2002 23:18:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K9wW-000942-00 for v6ops-data@psg.com; Thu, 05 Dec 2002 20:18:24 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18K9w0-00092q-00 for v6ops@ops.ietf.org; Thu, 05 Dec 2002 20:17:53 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 09:47:46 +0530 Message-ID: From: "Thakur, Anand" To: Ronald van der Pol Cc: Christian Huitema , v6ops@ops.ietf.org, juha.wiljakka@nokia.com, itojun@iijlab.net Subject: RE: on NAT-PT Date: Fri, 6 Dec 2002 09:48:41 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.2 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk i agree. what if we do the following: whatever the incoming response, the dns_alg will forward 2 responses to the client: 1)if the response is v4 only, then the dns_alg along with the v4 response will forward a mapped v6 response. 2)vice-versa if the response is v6 only 3)if 2 responses are received then forward them both to the client a simple functionality in the client may be able to discard the not-required result. though this will require a bit of effort on the part of the dns_alg, but is nothing as compared to the effort that excessive translation will cause. regards Anand Thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 > -----Original Message----- > From: Ronald van der Pol [SMTP:Ronald.vanderPol@rvdp.org] > Sent: Thursday, December 05, 2002 6:37 PM > To: Thakur, Anand > Cc: Christian Huitema; v6ops@ops.ietf.org; juha.wiljakka@nokia.com; > itojun@iijlab.net > Subject: Re: on NAT-PT > > On Thu, Dec 05, 2002 at 13:13:24 +0530, Thakur, Anand wrote: > > > > > hi christian, > > i don't think this a problem in na(p)t-pt, but more a problem in the way > > dns-alg works. for instance, if we could configure the dns-alg in such a > way > > that it does the following: > > Suppose a dual-stack client asks for an AAAA. > > > 1)maintain a table which maps the source ip address of the dns query and > the > > type of query ("A" or "AAAA") > > Map that dual-stack client has asked for AAAA. > > > 2)generate a dual-query ("A" + "AAAA") every time a dns query is > detected. > > Send A+AAAA queries. Suppose you receive A response only. > > > 3)when it intercepts a dns response it should > > ->translate the "A" response to "AAAA" response if the original quey was > > "AAAA" and the response is "A" only > > So, the A response is mapped to AAAA and send to the dual-stack client. > That's not what you want. You want the dual-stack client to communicate > over v4 transport with the destination. So, should not send a mapped > AAAA to the dual-stack client. The dual-stack client should retry and > ask for A. > > rvdp From owner-v6ops@ops.ietf.org Thu Dec 5 23:31:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13562 for ; Thu, 5 Dec 2002 23:31:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KA9X-0009mP-00 for v6ops-data@psg.com; Thu, 05 Dec 2002 20:31:51 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18KA91-0009k6-00 for v6ops@ops.ietf.org; Thu, 05 Dec 2002 20:31:19 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB64Ttj29552; Thu, 5 Dec 2002 23:29:55 -0500 (EST) Message-Id: <200212060429.gB64Ttj29552@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Thakur, Anand" cc: Keith Moore , Christian Huitema , v6ops@ops.ietf.org, juha.wiljakka@nokia.com, itojun@iijlab.net Subject: Re: on NAT-PT In-reply-to: (Your message of "Fri, 06 Dec 2002 09:32:31 +0530.") Date: Thu, 05 Dec 2002 23:29:55 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > can you give me an example where the user of a dns response is different > from the originator of the query? a) anytime the query is cached by an intermediary b) in any application that uses IP addresses for referrals from one node to another, but which gets the initial IP addresses from a DNS lookup From owner-v6ops@ops.ietf.org Fri Dec 6 01:48:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16897 for ; Fri, 6 Dec 2002 01:48:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KCIr-000GtU-00 for v6ops-data@psg.com; Thu, 05 Dec 2002 22:49:37 -0800 Received: from halt-in.cisco.com ([171.70.144.185] helo=mailman.cisco.com) by psg.com with esmtp (Exim 3.36 #2) id 18KCIM-000Gqi-00 for v6ops@ops.ietf.org; Thu, 05 Dec 2002 22:49:06 -0800 Received: from [10.21.96.109] by mailman.cisco.com (171.70.144.185) with ESMTP; 05 Dec 2002 16:08:32 +0000 Message-Id: <4.3.2.7.2.20021205224509.01f75db0@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Dec 2002 22:48:36 -0800 To: "Thakur, Anand" From: Senthil Sivakumar Subject: RE: on NAT-PT Cc: Ronald van der Pol , Christian Huitema , v6ops@ops.ietf.org, juha.wiljakka@nokia.com, itojun@iijlab.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 09:48 AM 12/6/2002 +0530, Thakur, Anand wrote: >i agree. > what if we do the following: >whatever the incoming response, the dns_alg will forward 2 responses to the >client: >1)if the response is v4 only, then the dns_alg along with the v4 response >will forward a mapped v6 response. How does the dns alg know that there won't be a v6 response for the same query. >2)vice-versa if the response is v6 only >3)if 2 responses are received then forward them both to the client >a simple functionality in the client may be able to discard the not-required >result. though this will require a bit of effort on the part of the dns_alg, >but is nothing as compared to the effort that excessive translation will >cause. Most of the clients only care about the first response and discard others. Now you are suggesting that the client to be changed which does not sound very appealing. Senthil >regards >Anand Thakur >HCL Perot Systems >A-14 Sector-57,Noida >tel ext. - 3257 >mobile:9811748512 > > > -----Original Message----- > > From: Ronald van der Pol [SMTP:Ronald.vanderPol@rvdp.org] > > Sent: Thursday, December 05, 2002 6:37 PM > > To: Thakur, Anand > > Cc: Christian Huitema; v6ops@ops.ietf.org; juha.wiljakka@nokia.com; > > itojun@iijlab.net > > Subject: Re: on NAT-PT > > > > On Thu, Dec 05, 2002 at 13:13:24 +0530, Thakur, Anand wrote: > > > > > > > > hi christian, > > > i don't think this a problem in na(p)t-pt, but more a problem in the way > > > dns-alg works. for instance, if we could configure the dns-alg in such a > > way > > > that it does the following: > > > > Suppose a dual-stack client asks for an AAAA. > > > > > 1)maintain a table which maps the source ip address of the dns query and > > the > > > type of query ("A" or "AAAA") > > > > Map that dual-stack client has asked for AAAA. > > > > > 2)generate a dual-query ("A" + "AAAA") every time a dns query is > > detected. > > > > Send A+AAAA queries. Suppose you receive A response only. > > > > > 3)when it intercepts a dns response it should > > > ->translate the "A" response to "AAAA" response if the original quey was > > > "AAAA" and the response is "A" only > > > > So, the A response is mapped to AAAA and send to the dual-stack client. > > That's not what you want. You want the dual-stack client to communicate > > over v4 transport with the destination. So, should not send a mapped > > AAAA to the dual-stack client. The dual-stack client should retry and > > ask for A. > > > > rvdp From owner-v6ops@ops.ietf.org Fri Dec 6 11:35:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12980 for ; Fri, 6 Dec 2002 11:35:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KLS2-000FGs-00 for v6ops-data@psg.com; Fri, 06 Dec 2002 08:35:42 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18KLRW-000FGE-00 for v6ops@ops.ietf.org; Fri, 06 Dec 2002 08:35:10 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gB6GZ8Q07973 for ; Fri, 6 Dec 2002 18:35:08 +0200 Date: Fri, 6 Dec 2002 18:35:08 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: New 6to4 security draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, I've submitted the new 6to4 security draft to internet-drafts; in the meantime, it's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-6to4-security-01.txt I made the more or less major changes I mentioned earlier, and in addition: - change some SHOULDs to MUSTs - kill some text in security considerations - kill most of those redundant examples in the appendix Note: I'll soon get off the net for about a week, so have bashing this one. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sat Dec 7 00:39:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09981 for ; Sat, 7 Dec 2002 00:39:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KXh8-0004Tw-00 for v6ops-data@psg.com; Fri, 06 Dec 2002 21:40:06 -0800 Received: from avarice.inner.net ([199.33.248.2] helo=inner.net) by psg.com with esmtp (Exim 3.36 #2) id 18KXh4-0004Sq-00 for v6ops@ops.ietf.org; Fri, 06 Dec 2002 21:40:02 -0800 Received: (from smtpd@localhost) by inner.net (8.12.5/8.12.5) id gB6JhpI0017285 for ; Fri, 6 Dec 2002 19:43:51 GMT Message-Id: <200212061943.gB6JhpI0017285@inner.net> Received: from ministry-of-love.inner.net(63.215.138.186), claiming to be "inner.net" via SMTP by inner.net, id smtpdkMYKlj; Fri Dec 6 14:43:48 2002 To: v6ops@ops.ietf.org Subject: IPv4-mapped problems slides Date: Sat, 07 Dec 2002 00:39:53 -0500 From: Craig Metz X-Spam-Status: No, hits=0.9 required=5.0 tests=MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Due to time constraints, I was unable to give my presentation at IETF 55 (Atlanta) on security/correctness problems and proposed solutions with IPv4- mapped addresses. I have posted the slides that I prepared for this presentation for those who might be interested at: http://www.inner.net/~cmetz/slides.dvi http://www.inner.net/~cmetz/slides.txt Because these were formatted for display off my laptop's screen, the TeX DVI is in a wacky paper format (16in x 12in) that happens to be the right size for a full-screen slide. Folks with UNIX-like systems and TeX can probably display this file using: xdvi -paper 16x12 slides.dvi The rest of the world should go straight to the .txt file, it's not pretty, but it's a whole lot less headache. I welcome rational and civilized discussion of this material. -Craig From owner-v6ops@ops.ietf.org Mon Dec 9 08:04:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07483 for ; Mon, 9 Dec 2002 08:04:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LNZw-000KHT-00 for v6ops-data@psg.com; Mon, 09 Dec 2002 05:04:08 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18LNZt-000KHH-00 for v6ops@ops.ietf.org; Mon, 09 Dec 2002 05:04:05 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06853; Mon, 9 Dec 2002 08:01:09 -0500 (EST) Message-Id: <200212091301.IAA06853@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Date: Mon, 09 Dec 2002 08:01:09 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security Considerations for 6to4 Author(s) : P. Savola Filename : draft-savola-v6ops-6to4-security-01.txt Pages : 27 Date : 2002-12-6 The IPv6 interim mechanism 6to4 [6TO4] uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes Relay Routers and Routers, which accept and decapsulate 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-savola-v6ops-6to4-security-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-v6ops-6to4-security-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-6to4-security-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2002-12-6140025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-v6ops-6to4-security-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-v6ops-6to4-security-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-6140025.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 9 13:45:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24272 for ; Mon, 9 Dec 2002 13:45:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LSty-000Kim-00 for v6ops-data@psg.com; Mon, 09 Dec 2002 10:45:10 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18LStv-000KiY-00 for v6ops@ops.ietf.org; Mon, 09 Dec 2002 10:45:07 -0800 Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10295 for ; Mon, 9 Dec 2002 11:45:06 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H6V004518363B@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 09 Dec 2002 11:45:06 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H6V00E9J83525@mail.sun.net> for v6ops@ops.ietf.org; Mon, 09 Dec 2002 11:45:05 -0700 (MST) Date: Mon, 09 Dec 2002 10:45:05 -0800 From: Alain Durand Subject: Re: on NAT-PT To: itojun@iijlab.net Cc: Christian Huitema , v6ops@ops.ietf.org Message-id: <3DF4E4B1.50705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: <20021205025749.791FE4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT itojun@iijlab.net wrote: > that describes my position - "NAT-PT/whatever aware" node is not > an option. it might look okay as shortterm workaround but will hurt > us in the future. > > FYI, we have been there already - KAME DNS resolver code had an > environment variable for setting address-translation prefix on the > client side, we noticed that it is a bad thing, and it got removed. > so this is from actual operational experience. > >itojun > Is there any paper documenting this 'operational practice' and why you consider it a 'bad thing' ? I would like to understand better why you claim that it is 'universally' a bad thing and not just 'a bad thing' within your local environment. - Alain. From owner-v6ops@ops.ietf.org Mon Dec 9 18:07:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07294 for ; Mon, 9 Dec 2002 18:07:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LX18-000JuH-00 for v6ops-data@psg.com; Mon, 09 Dec 2002 15:08:50 -0800 Received: from h181.p048.iij4u.or.jp ([210.130.48.181] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 18LX11-000Ju0-00 for v6ops@ops.ietf.org; Mon, 09 Dec 2002 15:08:45 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 1BC037AF; Tue, 10 Dec 2002 08:08:13 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 09 Dec 2002 10:45:05 PST. <3DF4E4B1.50705@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: Jun-ichiro itojun Hagino Date: Tue, 10 Dec 2002 08:08:13 +0900 Message-Id: <20021209230813.1BC037AF@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Is there any paper documenting this 'operational practice' >and why you consider it a 'bad thing' ? >I would like to understand better why you claim that it is 'universally' >a bad thing and not just 'a bad thing' within your local environment. unfortunately there's no documentation. this is universally bad because (1) it requires every node to configure the translation prefix manually (kills spirit of autoconfigured hosts), or to cook up DHCPv6 option for it (horrid idea), (2) NAT or NAT-PT has to be invisible to the client, instead of explicitly visible (otherwise, why bother rewriting protocol contents?), and (3) the idea where client is aware of things that happen in the middle is exactly the same as RSIP. our changelog shows that the feature (to specify translation prefix via environment variable, which in turn controls getaddrinfo(3)) was dropped in January 2000. itojun Sun Jan 23 13:24:00 JST 2000 itojun@iijlab.net * kame/libinet6/getaddrinfo.c: remove #ifdef FAITH (and use of environment varaible GAI). this has been broken for a long time (means noone is using it), and this shouldn't be here. if you would like to set FAITH'ed prefix, use totd or /etc/hosts. From owner-v6ops@ops.ietf.org Mon Dec 9 18:23:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07825 for ; Mon, 9 Dec 2002 18:23:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXI8-000LoO-00 for v6ops-data@psg.com; Mon, 09 Dec 2002 15:26:24 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18LXI5-000Lo7-00 for v6ops@ops.ietf.org; Mon, 09 Dec 2002 15:26:21 -0800 Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25395 for ; Mon, 9 Dec 2002 16:26:20 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H6V003EQL3V0M@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 09 Dec 2002 16:26:20 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H6V00E55L3U22@mail.sun.net> for v6ops@ops.ietf.org; Mon, 09 Dec 2002 16:26:19 -0700 (MST) Date: Mon, 09 Dec 2002 15:26:18 -0800 From: Alain Durand Subject: Re: on NAT-PT To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org Message-id: <3DF5269A.606@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: <20021209230813.1BC037AF@starfruit.itojun.org> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Jun-ichiro itojun Hagino wrote: >>Is there any paper documenting this 'operational practice' >>and why you consider it a 'bad thing' ? >>I would like to understand better why you claim that it is 'universally' >>a bad thing and not just 'a bad thing' within your local environment. >> >> > > unfortunately there's no documentation. > this is universally bad because > (1) it requires every node to configure the translation prefix manually > (kills spirit of autoconfigured hosts), or to cook up DHCPv6 option for > it (horrid idea), > It could be a well know prefix. You won't have to configure a special prefix for that. > (2) NAT or NAT-PT has to be invisible to the client, instead of > explicitly visible (otherwise, why bother rewriting protocol contents?), > and > I do no think so, au contraire. This is a last resort to enable IPv6-only apps on Ipv6-only node to communicate with their Ipv4 only peers. Requiring such nodes (or apps?) to have special knowledge that something is needed to "bridge" to the other world does not seems unreasonable to me. This is what we mean by "IPv6 nodes will have to pay the burden of the transition". > (3) the idea where client is aware of things that happen in the middle > is exactly the same as RSIP. > You'll be aware that things will happen. You will not have to negotiate it, and that makes a big difference. > our changelog shows that the feature (to specify translation prefix > via environment variable, which in turn controls getaddrinfo(3)) was > dropped in January 2000. > You can always put it back in ;-) Remember, this is for IPv6-only nodes, the kind that is not yet largely deployed. - Alain. From owner-v6ops@ops.ietf.org Mon Dec 9 23:32:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16873 for ; Mon, 9 Dec 2002 23:32:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lc4o-000HqB-00 for v6ops-data@psg.com; Mon, 09 Dec 2002 20:32:58 -0800 Received: from [203.190.136.36] (helo=hpsexgw.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18Lc4k-000Ho6-00 for v6ops@ops.ietf.org; Mon, 09 Dec 2002 20:32:56 -0800 Received: by HPSEXGW with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 09:45:57 +0530 Message-ID: From: "Thakur, Anand" To: "V6ops (E-mail)" Subject: application proxy Date: Tue, 10 Dec 2002 10:03:13 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, could someone please give me an example of 'application proxies' (for ipv6/ipv4 transition) that people have been talking about in their drafts. is BIA or BIS an example of this? if yes,are there any more examples? regards Anand Thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 From owner-v6ops@ops.ietf.org Tue Dec 10 03:12:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01349 for ; Tue, 10 Dec 2002 03:12:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LfUh-000NvJ-00 for v6ops-data@psg.com; Tue, 10 Dec 2002 00:11:55 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18LfUf-000Nv6-00 for v6ops@ops.ietf.org; Tue, 10 Dec 2002 00:11:53 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBA8B9G06411 for ; Tue, 10 Dec 2002 10:11:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Dec 2002 10:11:34 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Dec 2002 10:11:33 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Analysis on IPv6 Transition in 3GPP Networks Date: Tue, 10 Dec 2002 10:11:33 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC360C@esebe005.ntc.nokia.com> Thread-Topic: IPv4-mapped problems slides Thread-Index: AcKdtAtbdTcyPll7TRuBsoHMKqQiGgCbr/pg From: To: X-OriginalArrivalTime: 10 Dec 2002 08:11:33.0870 (UTC) FILETIME=[C0CC28E0:01C2A023] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01349 Hi all! This draft was published yesterday - any comments are appreciated a lot! Analysis on IPv6 Transition in 3GPP Networks http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-00.txt Cheers, -Juha W.- From owner-v6ops@ops.ietf.org Tue Dec 10 05:41:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03408 for ; Tue, 10 Dec 2002 05:41:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LhqE-0000yP-00 for v6ops-data@psg.com; Tue, 10 Dec 2002 02:42:18 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18LhqB-0000y4-00 for v6ops@ops.ietf.org; Tue, 10 Dec 2002 02:42:15 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 16:05:22 +0530 Message-ID: From: "Thakur, Anand" To: Senthil Sivakumar Cc: Ronald van der Pol , Christian Huitema , v6ops@ops.ietf.org, juha.wiljakka@nokia.com, itojun@iijlab.net Subject: RE: on NAT-PT Date: Tue, 10 Dec 2002 16:06:35 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk senthil sivakumar wrote. > >i agree. > > what if we do the following: > >whatever the incoming response, the dns_alg will forward 2 responses to the > >client: > >1)if the response is v4 only, then the dns_alg along with the v4 response > >will forward a mapped v6 response. >How does the dns alg know that there won't be a v6 response for the same query. I guess there should be a time out for this. i.e after waiting for a pre-determined amount of time (which will of course be implementation dependent)the DNS-ALG should assume that a V6 response is not going to come and forward the mapped v6 response along with the v4 response. > >2)vice-versa if the response is v6 only > >3)if 2 responses are received then forward them both to the client > >a simple functionality in the client may be able to discard the not-required > >result. though this will require a bit of effort on the part of the dns_alg, > >but is nothing as compared to the effort that excessive translation will > >cause. >Most of the clients only care about the first response and discard others. >Now you >are suggesting that the client to be changed which does not sound very >appealing. The only problem here may be changing the vast number of IPV4 clients. since deployment of v6-only and/or dual-stack clients is still in the pipeline, modification may not be that big a task especially considering the benefits that may be reaped out of this.in fact, modifying ipv4 clients may not be required by making sure that the dns-alg forwards the v4 reply first, so that if the client, if v4, accepts this response and discards any further responses (as it will normally do). regards Anand Thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 From owner-v6ops@ops.ietf.org Tue Dec 10 05:51:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03540 for ; Tue, 10 Dec 2002 05:51:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Li0b-0001IX-00 for v6ops-data@psg.com; Tue, 10 Dec 2002 02:53:01 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18Li0Z-0001II-00 for v6ops@ops.ietf.org; Tue, 10 Dec 2002 02:52:59 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 16:22:41 +0530 Message-ID: From: "Thakur, Anand" To: "V6ops (E-mail)" Subject: dns-alg misbehavior Date: Tue, 10 Dec 2002 16:23:54 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk hi all, consider the following situation: an ipv6 client generates a "AAAA" query and due to some mishap(say due to misbehavior of dns-alg) gets back a "A" reply. what will the client do? will it silently drop the packet and assume 'destination does not exist or not reachable' or does it wait a specific amount of time for a valid "AAAA" response to arrive. what happens if the situation is reversed for a v4 client? regards Anand Thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 From owner-v6ops@ops.ietf.org Tue Dec 10 08:57:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06365 for ; Tue, 10 Dec 2002 08:57:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LkqG-0005E5-00 for v6ops-data@psg.com; Tue, 10 Dec 2002 05:54:32 -0800 Received: from [218.145.161.39] (helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 18LkqC-0005Dt-00 for v6ops@ops.ietf.org; Tue, 10 Dec 2002 05:54:28 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 569A07AF; Tue, 10 Dec 2002 22:54:20 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 09 Dec 2002 15:26:18 PST. <3DF5269A.606@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: Jun-ichiro itojun Hagino Date: Tue, 10 Dec 2002 22:54:20 +0900 Message-Id: <20021210135420.569A07AF@starfruit.itojun.org> X-Spam-Status: No, hits=2.3 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> unfortunately there's no documentation. >> this is universally bad because >> (1) it requires every node to configure the translation prefix manually >> (kills spirit of autoconfigured hosts), or to cook up DHCPv6 option for >> it (horrid idea), >It could be a well know prefix. You won't have to configure a special >prefix for that. that's much more sick. >> our changelog shows that the feature (to specify translation prefix >> via environment variable, which in turn controls getaddrinfo(3)) was >> dropped in January 2000. >You can always put it back in ;-) i don't think so. >Remember, this is for IPv6-only nodes, >the kind that is not yet largely deployed. it also applies to IPv6/v4 dual stack nodes with IPv4 not configured. itojun From owner-v6ops@ops.ietf.org Tue Dec 10 12:18:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14404 for ; Tue, 10 Dec 2002 12:18:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lo31-000Adx-00 for v6ops-data@psg.com; Tue, 10 Dec 2002 09:19:55 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18Lo2y-000AdV-00 for v6ops@ops.ietf.org; Tue, 10 Dec 2002 09:19:52 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28975 for ; Tue, 10 Dec 2002 10:19:51 -0700 (MST) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H6W0027VYT2GR@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 10 Dec 2002 10:19:51 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H6W00KHKYT15O@mail.sun.net> for v6ops@ops.ietf.org; Tue, 10 Dec 2002 10:19:50 -0700 (MST) Date: Tue, 10 Dec 2002 09:20:30 -0800 From: Alain Durand Subject: Re: on NAT-PT In-reply-to: <20021210135420.569A07AF@starfruit.itojun.org> To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.548) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Tuesday, December 10, 2002, at 05:54 AM, Jun-ichiro itojun Hagino wrote: >>> unfortunately there's no documentation. >>> this is universally bad because >>> (1) it requires every node to configure the translation prefix >>> manually >>> (kills spirit of autoconfigured hosts), or to cook up DHCPv6 option >>> for >>> it (horrid idea), >> It could be a well know prefix. You won't have to configure a special >> prefix for that. > > that's much more sick. > Could you please elaborate why? - Alain. From owner-v6ops@ops.ietf.org Wed Dec 11 08:17:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03932 for ; Wed, 11 Dec 2002 08:17:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M6iC-0008uC-00 for v6ops-data@psg.com; Wed, 11 Dec 2002 05:15:40 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18M6i9-0008tw-00 for v6ops@ops.ietf.org; Wed, 11 Dec 2002 05:15:37 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03683; Wed, 11 Dec 2002 08:12:40 -0500 (EST) Message-Id: <200212111312.IAA03683@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-00.txt Date: Wed, 11 Dec 2002 08:12:40 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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-00.txt Pages : 17 Date : 2002-12-9 This document analyzes making the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to nodes in other networks, 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-analysis-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-3gpp-analysis-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: <2002-12-9150229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-9150229.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Dec 11 09:34:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06814 for ; Wed, 11 Dec 2002 09:34:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M7yG-000Bjb-00 for v6ops-data@psg.com; Wed, 11 Dec 2002 06:36:20 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 18M7yD-000BhX-00 for v6ops@ops.ietf.org; Wed, 11 Dec 2002 06:36:17 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gBBEZPBx062434 for ; Wed, 11 Dec 2002 15:35:32 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gBBEZBg5076432 for ; Wed, 11 Dec 2002 15:35:15 +0100 Received: from lig32-238-75-46.emea.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20036 from ; Wed, 11 Dec 2002 15:35:07 +0100 Message-Id: <3DF714DB.19B74094@hursley.ibm.com> Date: Wed, 11 Dec 2002 11:35:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt References: <200212091301.IAA06853@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=DATE_IN_PAST_03_06,NOSPAM_INC,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, Just a few comments. Generally I wonder if there is a way to reorganize the text to make the relay spoofing problem the most visible (first?) part. It is the unsolved problem, after all. On section 5.2.2 and the other discussions of this problem: I think you could consider making a recommendation that 6to4 decapsulators SHOULD keep an LRU cache of recent relayed headers for trace purposes. If you cache a few hundred {src,dst,src_v4} triplets you could use this to trace spoofs. As you observe in more than one place, this only helps if ISPs run v4 ingress filtering - but so many of the Internet's vulnerabilities need ingress filtering that we can't penalize 6to4 for that. You also say somewhere that this would only allow you to trace zombies in a DDOS attack - but it is necessary to trace zombies in any case, even if you can't find the attacker that way. Another use of a cache is that you might be able to build a relay blacklist mechanism of some kind, or a rate limiting mechanism - this is really outside the scope of an IETF draft but the cache would be an enabling mechanism. We haven't talked about possible crypto based solutions. At least in theory, one could use something like AH to authenticate relayed packets, assuming that each relay knows one of a small number of private keys (imagine each major ISP having a 6to4 private key for its relays) and that each decapsulator knows all the corresponding public keys. > 6.3. All Relays Must Be Anycast It's pretty obvious from the description that this doesn't work, and you should probably say so more clearly. Also, this section and 7.3.1 really should be combined. > 7.3.2. Limited Distribution of More Specific Routes Again, your description makes this fairly obviously hopeless. I do note however that relays, being routers, can look "sideways" at the IPv4 routing table. If they had some magic way of deriving the "last relay" address from this, there would be a solution without effectively creating a spare copy of the IPv4 table. Brian From owner-v6ops@ops.ietf.org Wed Dec 11 12:46:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14290 for ; Wed, 11 Dec 2002 12:46:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MAyk-000K7F-00 for v6ops-data@psg.com; Wed, 11 Dec 2002 09:49:02 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18MAyh-000K73-00 for v6ops@ops.ietf.org; Wed, 11 Dec 2002 09:48:59 -0800 Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24446 for ; Wed, 11 Dec 2002 10:48:59 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H6Y0001IUTMUO@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 11 Dec 2002 10:48:58 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H6Y00BB7UTLE4@mail.sun.net> for v6ops@ops.ietf.org; Wed, 11 Dec 2002 10:48:58 -0700 (MST) Date: Wed, 11 Dec 2002 09:48:57 -0800 From: Alain Durand Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt To: v6ops@ops.ietf.org Message-id: <3DF77A89.7030806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: <200212091301.IAA06853@ietf.org> <3DF714DB.19B74094@hursley.ibm.com> X-Spam-Status: No, hits=-1.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka, There are some aspects you somehow overlooked in your draft. 1. This attack by spoofing relay can be distributed to a huge number of reflectors (just have to find their address in the DNS). This changes quiet a lot of things, and makes tracing the attack and stopping it very difficult. For example, it is not clear how statistical analysis done on packet sampling will work. 2. If outgoing 6to4 relays get widely deployed and the attack uses a very large number of reflectors with just one zombie, it is not clear that the relays will act as a contention point... 3. ...but if they do, the attack is transformed from a DDOS attack on the fake IPv6 src to a DDOS attack on the relays! - Alain. From owner-v6ops@ops.ietf.org Thu Dec 12 05:30:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18913 for ; Thu, 12 Dec 2002 05:30:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MQbH-000GUT-00 for v6ops-data@psg.com; Thu, 12 Dec 2002 02:29:51 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18MQbE-000GUA-00 for v6ops@ops.ietf.org; Thu, 12 Dec 2002 02:29:48 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Dec 2002 15:59:23 +0530 Message-ID: From: "Thakur, Anand" To: "Juha. Wiljakka (E-mail)" Cc: "V6ops (E-mail)" Subject: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Date: Thu, 12 Dec 2002 16:00:39 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi juha, First of all congratulations on a well compiled draft. The draft is very close to completeness and covers all mobile IPv6 transaction scenarios. We (Mr. Ajay Jain and myself) have gone through your draft and have the following (general) comments: 1) Apart from the fact that na(p)t-pt issues are magnified in a 3gpp network, the cases dealt with here would exist anywhere and everywhere when deployment of v6 gathers momentum. 2) > In most 3GPP scenarios it is preferred to use manually configured tunnels or EGP/IGP based tunneling mechanisms. I am not sure if manually configured tunnels will provide a good solution in the years to come . Especially when ipv6 ONLY sites start to mushroom all over the place, it will be extremely difficult (and probably not worthwhile) to manage such a great number of manually configured tunnels. In fact the earlier part of this section does state that manually configured tunnels may not provide a long term solution. Then, why is it later on mentioned that such tunnels are preffered? Personall, i don't think we should go for short term solutions. 3) (3.3) >Therefore, overall, the transition scenario involving an IPv4 UE communicating >with an IPv4 peer through an IPv6 network is not considered very >likely in 3GPP networks. I totally agree to this . 4) > (3.4) IPv6 UE connecting to an IPv4 node This will probably be the most prevalent scenario in the initial stages and yet we don't have a concrete solution to deal with this. na(p)t-pt is far far from perfect. I strongly recommend (as in 3.4) the usage of application proxies, especially considering the fact that a user will mostly be concerned with services like http,ftp,telnet and mail related protocols, the proxies for which can be easily implemented at the Gi interface. As far as na(p)t-pt is concerned, this section basically is trying to say that na(P)t-pt has a lot of drawbacks. so basically progress will be done only when a solution to these problems (especially concerning nat-pt dns-alg ) are found. 5) >the NAT-PT issues should be clearly >documented in an RFC in the v6ops Working Group I agree and it is a matter that requires immediate attention i.e if we want v6 to be deployed soon. 6) > An alternative solution could be a general network address > translation mechanisms such as NAT46 [NAT64]. I think a little more work should be done on NAT46 to sort out any drawbacks that it might have because as I see it , nat46 may be the only solution to issues concerning na(p)t-pt v4->v6. 7) This draft clearly (may be that is not the main purpose) points out that all tunneling and/or translating mechanisms in existence today are far from perfect. The most difficult part is when neither of the hosts is dual stack. so, it would be only logical to first find a transition mechanism (whether it's tunneling or translation) that: 1) scales well 2) practicable whether there are small islands of v6 in a v4 ocean or vice-versa and, 3) preferably can be implemented in all or atleast most of the scenarios mentioned in this draft. best regards Anand Thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 From owner-v6ops@ops.ietf.org Thu Dec 12 07:03:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20212 for ; Thu, 12 Dec 2002 07:03:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MS5U-000JPp-00 for v6ops-data@psg.com; Thu, 12 Dec 2002 04:05:08 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18MS5R-000JPZ-00 for v6ops@ops.ietf.org; Thu, 12 Dec 2002 04:05:05 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBCC4LG24527 for ; Thu, 12 Dec 2002 14:04:21 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Dec 2002 14:05:02 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Dec 2002 14:05:02 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Date: Thu, 12 Dec 2002 14:05:01 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3626@esebe005.ntc.nokia.com> Thread-Topic: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Thread-Index: AcKhyW7yDkR/R/MtQyu+fYhQI0KMogABqxLw From: To: Cc: X-OriginalArrivalTime: 12 Dec 2002 12:05:02.0829 (UTC) FILETIME=[B39D29D0:01C2A1D6] X-Spam-Status: No, hits=1.0 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20212 Hi, Anand! -----Original Message----- From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] Sent: 12 December, 2002 12:31 First of all congratulations on a well compiled draft. The draft is very close to completeness and covers all mobile IPv6 transaction scenarios. We (Mr. Ajay Jain and myself) have gone through your draft and have the following (general) comments: JW: Thanks! Good comments are always useful! :-) 1) Apart from the fact that na(p)t-pt issues are magnified in a 3gpp network, the cases dealt with here would exist anywhere and everywhere when deployment of v6 gathers momentum. JW: Yep, I also think that those issues are universal, not depending on the access network type etc. One thing is that 3GPP networks will have a very big number of nodes (terminals). 2) > In most 3GPP scenarios it is preferred to use manually configured tunnels or EGP/IGP based tunneling mechanisms. I am not sure if manually configured tunnels will provide a good solution in the years to come . Especially when ipv6 ONLY sites start to mushroom all over the place, it will be extremely difficult (and probably not worthwhile) to manage such a great number of manually configured tunnels. In fact the earlier part of this section does state that manually configured tunnels may not provide a long term solution. Then, why is it later on mentioned that such tunnels are preffered? Personall, i don't think we should go for short term solutions. JW: I agree that we should use solutions that are future proof. One thing is that the selection of the type of tunneling mechanism is up to the operator/ISP deployment scenario and we can only give generic recommendations in our draft. A basic question is how many tunnels we need to set up - if the number is not so big (e.g. one tunnel to IPv6 Internet, etc.), it is no problem setting up manually configured tunnels in the network. It is good to remember that use of automatic tunneling (e.g. 6to4) in very big networks is not trouble-free either. Anyway, text in this section may need some edits. A counter question: what kind of tunneling mechanims would you recommend? 4) > (3.4) IPv6 UE connecting to an IPv4 node his will probably be the most prevalent scenario in the initial stages and yet we don't have a concrete solution to deal with this. na(p)t-pt is far far from perfect. I strongly recommend (as in 3.4) the usage of application proxies, especially considering the fact that a user will mostly be concerned with services like http,ftp,telnet and mail related protocols, the proxies for which can be easily implemented at the Gi interface. As far as na(p)t-pt is concerned, this section basically is trying to say that na(P)t-pt has a lot of drawbacks. so basically progress will be done only when a solution to these problems (especially concerning nat-pt dns-alg ) are found. JW: Use of application proxies (when possible) is not a bad idea at all. But in the cases like IMS scenario 1 we need also IP level protocol translation. As commented in our draft, NAT-PT problems should be well understood & documented. After that we should see what can be done to those problems. 6) > An alternative solution could be a general network address > translation mechanisms such as NAT46 [NAT64]. I think a little more work should be done on NAT46 to sort out any drawbacks that it might have because as I see it , nat46 may be the only solution to issues concerning na(p)t-pt v4->v6. JW: Alain, I think this comment is for you.. :-) 7) This draft clearly (may be that is not the main purpose) points out that all tunneling and/or translating mechanisms in existence today are far from perfect. The most difficult part is when neither of the hosts is dual stack. so, it would be only logical to first find a transition mechanism (whether it's tunneling or translation) that: 1) scales well 2) practicable whether there are small islands of v6 in a v4 ocean or vice-versa and, 3) preferably can be implemented in all or atleast most of the scenarios mentioned in this draft. JW: Yep, one main goal in this exercise is to see what existing tr. mechanisms are usable for 3GPP scenarios and document any gaps. Pointing out possible problems in the existing mechanisms also includes in this work. However, we are not going to specify any new mechanisms. We don't need just one or two mechanisms that would fit in all cases, but it would be nice to have a compact set of solutions (let's call it transition toolbox) that the operators could use making IPv6 to go full speed ahead. Thanks again for your comments! -Juha W.- From owner-v6ops@ops.ietf.org Thu Dec 12 12:15:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02742 for ; Thu, 12 Dec 2002 12:15:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MWuG-0004WK-00 for v6ops-data@psg.com; Thu, 12 Dec 2002 09:13:52 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #2) id 18MWuD-0004UF-00 for v6ops@ops.ietf.org; Thu, 12 Dec 2002 09:13:49 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 12 Dec 2002 09:13:17 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Dec 2002 09:13:17 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 12 Dec 2002 09:13:17 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 12 Dec 2002 09:13:17 -0800 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.3710.0); Thu, 12 Dec 2002 09:13:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Date: Thu, 12 Dec 2002 09:14:15 -0800 Message-ID: Thread-Topic: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Thread-Index: AcKhP9a0WUnpVUa0QJWSkYIML38WnAAvdq0Q From: "Christian Huitema" To: X-OriginalArrivalTime: 12 Dec 2002 17:13:17.0092 (UTC) FILETIME=[C30DBE40:01C2A201] X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA02742 First, let's say that I found the revised draft much more complete than the previous one. The analysis of the attacks is much more thorough. It starts providing an actual "is this really worse" study; I wish we could make that systematic, with the following comparison: 1) Is the situation worse than a current IPv4 Internet, in which spoofing source addresses is relatively easy? For example, in the current Internet, an IPv4 source can attack an IPv4 destination; attacks in which an IPv6 source can attack an IPv4 destination or vice versa are basically in the category as "same as IPv4." 2) Is the situation worse than an hypothetical IPv4 Internet, in which ingress filtering would be implemented and spoofing source addresses would be hard? As noted in the draft, the only attack that is actually worse in that hypothesis is " relay spoofing". 3) Is the situation worse than an ideal IPv6 Internet, which would not inherit anything from the current IPv4 Internet, and would implement strict ingress filtering for all IPv6 addresses. The answer is probably yes in many cases, since spoofing IPv4 addresses allows sending spoofed packets through a relay. The question is then, where do we place the bar. If we consider option 1, then we mostly have to do good housekeeping, mostly implementing the filtering requirements outlined in the draft. If we consider option 2, we have to find a solution to the "relay spoofing" attack. The previous drafts suggested using the anycast address as a source address; the new draft is much more moderate, and outlines the many issues with that solution; frankly, I don't believe we should combat source address spoofing by requiring relays to spoof a source address. Since the attack is only efficient when the destination is targeted with a large amount of traffic, a combination of sampling and ITRACE would probably work. In the hypothesis that Alain mentions, where a single zombie deflects traffic through multiple reflectors, sending a sampling of "6to4-ITRACE" messages to the IPv6 source would give out the zombie address very quickly. In practice, I believe we should not be too concerned with option 3. We have to acknowledge that opening relays implies that IPv6 will have by and large the same "qualities" as IPv4. At least during the transition phase, most IPv6 hosts will be dual-homed, which means they will benefit from IPv4 qualities anyhow. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Dec 12 14:13:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07929 for ; Thu, 12 Dec 2002 14:13:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MYmh-0009Wr-00 for v6ops-data@psg.com; Thu, 12 Dec 2002 11:14:11 -0800 Received: from smistad.uninett.no ([158.38.62.77]) by psg.com with esmtp (Exim 3.36 #2) id 18MYmX-0009V0-00 for v6ops@ops.ietf.org; Thu, 12 Dec 2002 11:14:01 -0800 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id 90263292C2; Thu, 12 Dec 2002 20:13:59 +0100 (CET) Date: Thu, 12 Dec 2002 20:13:59 +0100 (CET) Message-Id: <20021212.201359.26218223.he@uninett.no> To: huitema@windows.microsoft.com Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt From: Havard Eidnes In-Reply-To: References: X-Mailer: Mew version 1.95b124 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA07929 > 1) Is the situation worse than a current IPv4 Internet, in which > spoofing source addresses is relatively easy? Pasts sins should not be an excuse to repeat them in the future. I think we can all agree that the current failure of deployment of (IPv4) source address spoofing prevention measures at the edge is one of the important components in the operational mess we are in at the present where it is for all practical purposes impossible to track down and weed out DDoS attack agents, and we should not be promoting protocols which embeds the current situation in concrete, and label is at "good enough". > At least during the transition phase, most IPv6 hosts will be > dual-homed, which means they will benefit from IPv4 qualities > anyhow. I think you mean "dual-stack"? I think the same comment as above applies here as well. Regards, - Håvard From owner-v6ops@ops.ietf.org Thu Dec 12 14:32:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09104 for ; Thu, 12 Dec 2002 14:32:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MZ7I-000AUH-00 for v6ops-data@psg.com; Thu, 12 Dec 2002 11:35:28 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #2) id 18MZ7F-000ASq-00 for v6ops@ops.ietf.org; Thu, 12 Dec 2002 11:35:25 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 12 Dec 2002 11:34:58 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Dec 2002 11:34:53 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 12 Dec 2002 11:34:53 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 12 Dec 2002 11:34:53 -0800 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.3710.0); Thu, 12 Dec 2002 11:34:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Date: Thu, 12 Dec 2002 11:36:05 -0800 Message-ID: Thread-Topic: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Thread-Index: AcKiEt0vgZ3gYZ0NSd672pFvasxfbAAAa0vg From: "Christian Huitema" To: "Havard Eidnes" Cc: X-OriginalArrivalTime: 12 Dec 2002 19:34:48.0679 (UTC) FILETIME=[886F1770:01C2A215] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09104 > Pasts sins should not be an excuse to repeat them in the future. The past is actually the present. Moving from present to future should also be considered important. > I think we can all agree that the current failure of deployment of > (IPv4) source address spoofing prevention measures at the edge is one > of the important components in the operational mess we are in at the > present where it is for all practical purposes impossible to track > down and weed out DDoS attack agents, and we should not be promoting > protocols which embeds the current situation in concrete, and label is > at "good enough". It is not at all obvious that ingress filtering would prevent the worse DDOS attacks, which are virus based. In any case, I am just proposing that we grade the attacks in three buckets: those that are no worse than the current mess, those that are worse than a clean IPv4 network, and those that are worse than a clean IPv6-only network. > > At least during the transition phase, most IPv6 hosts will be > > dual-homed, which means they will benefit from IPv4 qualities > > anyhow. > > I think you mean "dual-stack"? I think the same comment as above > applies here as well. There is a question of time. As long as most services have to be provided in both IPv4 & IPv6, then the fact of life is that they can be subject to DDOS over either IPv4 or IPv6. The next question is, can we get a clean picture by the time it makes sense to have IPv6 only networking. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Dec 12 22:58:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27552 for ; Thu, 12 Dec 2002 22:58:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MgzR-0004Pi-00 for v6ops-data@psg.com; Thu, 12 Dec 2002 19:59:53 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18MgzP-0004OM-00 for v6ops@ops.ietf.org; Thu, 12 Dec 2002 19:59:51 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 09:29:27 +0530 Message-ID: From: "Thakur, Anand" To: juha.wiljakka@nokia.com Cc: "V6ops (E-mail)" , "Ajay Jain (E-mail)" Subject: RE: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Date: Fri, 13 Dec 2002 09:30:53 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Juha, >One thing is that the selection of the type of tunneling mechanism is up to the operator/ISP >deployment scenario and we can only give generic recommendations in our draft. Yes,i agree that we are not authorized to mandate a particular tunneling/translation mechanism to the operator. But still don't you think that if different operators have faith in different transition mechanisms then compatibility may be a major issue? >A counter question: what kind of tunneling mechanims would you recommend? I still insist that we need to come up with a tunneling mechanism that is perfect. Whether that means rectification/modification of an existing method or introduction of a new method. Since transition mechanisms have not yet been deployed at a large scale, i don't think it is too late to introduce (if required i.e.)a new tunneling mechanism. Anyway, i feel that if can do away with NA(P)T-PT problems, atleast 80% of the job will be done. Anand Thakur HCL Perot Systems A-14 Sector-57,Noida tel ext. - 3257 mobile:9811748512 From owner-v6ops@ops.ietf.org Fri Dec 13 03:56:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18448 for ; Fri, 13 Dec 2002 03:56:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MleM-000H52-00 for v6ops-data@psg.com; Fri, 13 Dec 2002 00:58:26 -0800 Received: from parsmtp1.rd.francetelecom.com ([194.167.105.13]) by psg.com with esmtp (Exim 3.36 #2) id 18MleJ-000H4j-00 for v6ops@ops.ietf.org; Fri, 13 Dec 2002 00:58:23 -0800 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Dec 2002 09:58:21 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Date: Fri, 13 Dec 2002 09:58:20 +0100 Message-ID: Thread-Topic: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Thread-Index: AcKhy1R6A2uNY6zJTN6XXmgD4q7+owAuGPQA From: "BELOEIL Luc FTRD/DMI/CAE" To: "Juha. Wiljakka (E-mail)" Cc: "V6ops (E-mail)" X-OriginalArrivalTime: 13 Dec 2002 08:58:21.0593 (UTC) FILETIME=[C991F090:01C2A285] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18448 Hi Juha, Thanks to have update the draft ! I still have the same comments on 4.2 paragraph. 1- a UE that uses IMS services must contact IMS devices over IPv6 (because IMS is IPv6-only). I agree. 2- Nevertheless a UE that uses IMS services could also be dual-stack (even if it does not use its IPv4 stack to contact IMS devices) 3- As pointed out in section 2.2 and 3.1, DSTM could also be used so as to send IPv4 datagrams over IPv6 in IPv6 PDP Contexts. 4- when that dual-stack UE is connecting to an IPv4-only node in a IPv4-only network through IMS, I argue that NAT-PT can be avoided by using DSTM. I understand that DSTM might not be easy to set-up inside 3GPP networks but that is an alternative to NAT-PT. Perhaps that 3GPP does not want that such transition mechanisms involve UE but only network ? Regards, Luc From owner-v6ops@ops.ietf.org Fri Dec 13 05:20:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19539 for ; Fri, 13 Dec 2002 05:20:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Mmx1-000Ja6-00 for v6ops-data@psg.com; Fri, 13 Dec 2002 02:21:47 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #2) id 18Mmwy-000JZu-00 for v6ops@ops.ietf.org; Fri, 13 Dec 2002 02:21:45 -0800 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBDAN5p22614 for ; Fri, 13 Dec 2002 12:23:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Dec 2002 12:21:41 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Dec 2002 12:21:00 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Date: Fri, 13 Dec 2002 12:20:59 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC362D@esebe005.ntc.nokia.com> Thread-Topic: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Thread-Index: AcKhy1R6A2uNY6zJTN6XXmgD4q7+owAuGPQAAALmb+A= From: To: Cc: X-OriginalArrivalTime: 13 Dec 2002 10:21:00.0514 (UTC) FILETIME=[55513C20:01C2A291] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA19539 Hi, Luc! Thanks for your comments! However, the UE really must be IPv6-only to the IMS direction. IMS case 1 can not be solved using DSTM - that solution would be "dual stacked" to the IMS direction. Of course, otherwise the mobile can be dual stack. IPv4 stack can be used for e.g. Internet access / web surfing (using a separate IPv4 PDP context), i.e. for non-IMS-related traffic. Best Regards, -Juha- -----Original Message----- From: ext BELOEIL Luc FTRD/DMI/CAE [mailto:luc.beloeil@rd.francetelecom.com] Sent: 13 December, 2002 10:58 To: Wiljakka Juha (NMP/Tampere) Cc: V6ops (E-mail) Subject: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Hi Juha, Thanks to have update the draft ! I still have the same comments on 4.2 paragraph. 1- a UE that uses IMS services must contact IMS devices over IPv6 (because IMS is IPv6-only). I agree. 2- Nevertheless a UE that uses IMS services could also be dual-stack (even if it does not use its IPv4 stack to contact IMS devices) 3- As pointed out in section 2.2 and 3.1, DSTM could also be used so as to send IPv4 datagrams over IPv6 in IPv6 PDP Contexts. 4- when that dual-stack UE is connecting to an IPv4-only node in a IPv4-only network through IMS, I argue that NAT-PT can be avoided by using DSTM. I understand that DSTM might not be easy to set-up inside 3GPP networks but that is an alternative to NAT-PT. Perhaps that 3GPP does not want that such transition mechanisms involve UE but only network ? Regards, Luc From owner-v6ops@ops.ietf.org Sun Dec 15 09:19:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03585 for ; Sun, 15 Dec 2002 09:19:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18NZaQ-0003n2-00 for v6ops-data@psg.com; Sun, 15 Dec 2002 06:17:42 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18NZaO-0003mq-00 for v6ops@ops.ietf.org; Sun, 15 Dec 2002 06:17:40 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBFEGs029953 for ; Sun, 15 Dec 2002 16:16:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 15 Dec 2002 16:17:36 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 15 Dec 2002 16:17:35 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Date: Sun, 15 Dec 2002 16:17:34 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3634@esebe005.ntc.nokia.com> Thread-Topic: comments : draft-ietf-v6ops-3gpp-analysis-00.txt Thread-Index: AcKiXBbKxFlGE7BkQiiP6bwcB0b04wB5kZPw From: To: Cc: , X-OriginalArrivalTime: 15 Dec 2002 14:17:35.0702 (UTC) FILETIME=[B7228760:01C2A444] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03585 Hi, Anand! -----Original Message----- From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] Sent: 13 December, 2002 06:01 >One thing is that the selection of the type of tunneling mechanism is up to the operator/ISP >deployment scenario and we can only give generic recommendations in our draft. Yes,i agree that we are not authorized to mandate a particular tunneling/translation mechanism to the operator. But still don't you think that if different operators have faith in different transition mechanisms then compatibility may be a major issue? JW: I can see your point.. I also think that there are all too many alternatives available at the moment - at least I would be confused as an operator if I had to select from all the currently available alternatives. This is why I see this scenario / analysis work important. I think that a compact transition toolbox (including a couple of basic mechanisms) is needed to solve the transition scenarios - compatibility / interoperability must not be forgotten. >A counter question: what kind of tunneling mechanims would you recommend? I still insist that we need to come up with a tunneling mechanism that is perfect. Whether that means rectification/modification of an existing method or introduction of a new method. Since transition mechanisms have not yet been deployed at a large scale, i don't think it is too late to introduce (if required i.e.)a new tunneling mechanism. Anyway, i feel that if can do away with NA(P)T-PT problems, atleast 80% of the job will be done. JW: Yep, we are in an early phase and can not clearly see yet which mechanisms are going to win. A good thing to be remembered is that the v6ops charter does not currently include specifying new transition mechanisms, at least not before the design team studies are completed. Cheers, -Juha- From owner-v6ops@ops.ietf.org Tue Dec 17 05:59:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11325 for ; Tue, 17 Dec 2002 05:59:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OFS9-0007H2-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 02:59:57 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18OFS6-0007Gq-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 02:59:54 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Dec 2002 16:29:50 +0530 Message-ID: From: "Thakur, Anand" To: "Juha. Wiljakka (E-mail)" Cc: "V6ops (E-mail)" Subject: 3gpp scenario 2 Date: Tue, 17 Dec 2002 16:31:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk hi huha, i was just wondering about the scenario in which 2 IPV6 UEs communicate over an IPV4 network. In this scenario won't initial DNS resolution be a very difficult job (if not impossible)? If you have not understood my question read this example: Let Host A be on IPV6 netork X and Host B on IPV6 network Y. Now, if A makes a DNS query ("A") for B, none of the name resolvers in network X will have an entry for B . How will this query finally reach network Y, assuming all intermediate routers are IPV4 only? Will A have to explicitly tunnel this request to network Y? I am also assuming that DNS servers in the IPV4 internet don't support "AAAA". regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 From owner-v6ops@ops.ietf.org Tue Dec 17 06:22:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11555 for ; Tue, 17 Dec 2002 06:22:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OFpK-0008Hl-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 03:23:54 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18OFpG-0008HZ-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 03:23:51 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBHBN4005355 for ; Tue, 17 Dec 2002 13:23:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Dec 2002 13:23:48 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 13:23:45 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 13:23:45 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp scenario 2 Date: Tue, 17 Dec 2002 13:23:44 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3644@esebe005.ntc.nokia.com> Thread-Topic: 3gpp scenario 2 Thread-Index: AcKlu+nvKg790N+CRhSQydUAPO5mDAAATFqg From: To: Cc: X-OriginalArrivalTime: 17 Dec 2002 11:23:45.0092 (UTC) FILETIME=[C2D54040:01C2A5BE] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA11555 Anand, I assume that this is a very common problem / environment in initial IPv6 deployment, i.e. two separate IPv6 islands connected by IPv4 network using "IPv6 in IPv4" tunneling and solutions have already been thought by several (DNS) experts. What if we already have some static "IPv6 in IPv4" tunnels configured from the operator's network to, say, IPv6 internet / 6bone and there is IPv6 connection to node B? I am very happy to receive more comments on this issue. Thanks, -Juha- -----Original Message----- From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] Sent: 17 December, 2002 13:01 To: Wiljakka Juha (NMP/Tampere) Cc: V6ops (E-mail) Subject: 3gpp scenario 2 hi huha, i was just wondering about the scenario in which 2 IPV6 UEs communicate over an IPV4 network. In this scenario won't initial DNS resolution be a very difficult job (if not impossible)? If you have not understood my question read this example: Let Host A be on IPV6 netork X and Host B on IPV6 network Y. Now, if A makes a DNS query ("A") for B, none of the name resolvers in network X will have an entry for B . How will this query finally reach network Y, assuming all intermediate routers are IPV4 only? Will A have to explicitly tunnel this request to network Y? I am also assuming that DNS servers in the IPV4 internet don't support "AAAA". regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 From owner-v6ops@ops.ietf.org Tue Dec 17 06:40:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11827 for ; Tue, 17 Dec 2002 06:40:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OG7d-00098F-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 03:42:49 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18OG7Z-00097w-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 03:42:46 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Dec 2002 17:12:43 +0530 Message-ID: From: "Thakur, Anand" To: juha.wiljakka@nokia.com Cc: v6ops@ops.ietf.org, "Ajay Jain (E-mail)" Subject: RE: 3gpp scenario 2 Date: Tue, 17 Dec 2002 17:13:54 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Juha, As of now this seems to be the only solution, but i wonder if this solution is going to scale well when number of IPV6 islands shoots up. Especially in the 3gpp case we could be dealing with hundreds of thousands of (may be even millions) of V6 nodes. In addition we will have to mandate that every V6 island has to be connected to the 6bone. Plus, what about the scenario where Host A is in a V4 network Z and generates a "A" query for Host B? regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 > -----Original Message----- > From: juha.wiljakka@nokia.com [SMTP:juha.wiljakka@nokia.com] > Sent: Tuesday, December 17, 2002 4:54 PM > To: Anand.Thakur@hpsglobal.com > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp scenario 2 > > Anand, > > I assume that this is a very common problem / environment in initial IPv6 > deployment, i.e. two separate IPv6 islands connected by IPv4 network using > "IPv6 in IPv4" tunneling and solutions have already been thought by > several (DNS) experts. > > What if we already have some static "IPv6 in IPv4" tunnels configured from > the operator's network to, say, IPv6 internet / 6bone and there is IPv6 > connection to node B? > > I am very happy to receive more comments on this issue. > > Thanks, > -Juha- > > -----Original Message----- > From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] > Sent: 17 December, 2002 13:01 > To: Wiljakka Juha (NMP/Tampere) > Cc: V6ops (E-mail) > Subject: 3gpp scenario 2 > > > hi huha, > i was just wondering about the scenario in which 2 IPV6 UEs communicate > over > an IPV4 network. In this scenario won't initial DNS resolution be a very > difficult job (if not impossible)? > If you have not understood my question read this example: > Let Host A be on IPV6 netork X and Host B on IPV6 network Y. Now, if A > makes > a DNS query ("A") for B, none of the name resolvers in network X will have > an entry for B . How will this query finally reach network Y, assuming all > intermediate routers are IPV4 only? Will A have to explicitly tunnel this > request to network Y? I am also assuming that DNS servers in the IPV4 > internet don't support "AAAA". > > regards > Anand Thakur > HCL Perot Systems (A SEI CMM Level 5 Company) > Plot No 3, Sector 125, NOIDA (UP)-201301, India > * Tel +91 120 4432755-79, X3348 (EPABX) > mobile:9811748512 From owner-v6ops@ops.ietf.org Tue Dec 17 06:49:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11906 for ; Tue, 17 Dec 2002 06:49:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OGGE-0009e1-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 03:51:42 -0800 Received: from parsmtp2.rd.francetelecom.com ([194.167.105.14]) by psg.com with esmtp (Exim 3.36 #2) id 18OGGA-0009dn-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 03:51:38 -0800 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 12:51:35 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A5C2.A6399D66" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: =?utf-8?Q?RE=C2=A0=3A_3gpp_scenario_2?= Date: Tue, 17 Dec 2002 12:51:35 +0100 Message-ID: Thread-Topic: 3gpp scenario 2 Thread-Index: AcKlu+nvKg790N+CRhSQydUAPO5mDAAATFqgAAFAsVw= From: "BELOEIL Luc FTRD/DMI/CAE" To: , Cc: X-OriginalArrivalTime: 17 Dec 2002 11:51:35.0856 (UTC) FILETIME=[A6AF9B00:01C2A5C2] X-Spam-Status: No, hits=2.5 required=5.0 tests=BASE64_ENC_TEXT,CARRIAGE_RETURNS,SPAM_PHRASE_00_01, SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2A5C2.A6399D66 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVoYSBhbmQgQW5hbmQsDQogDQpDYW4geW91IGNsYXJpZnk6ICJXaGF0IGlmIHdlIGFscmVh ZHkgaGF2ZSBzb21lIHN0YXRpYyAiSVB2NiBpbiBJUHY0IiB0dW5uZWxzIGNvbmZpZ3VyZWQgZnJv bSB0aGUgb3BlcmF0b3IncyBuZXR3b3JrIHRvLCBzYXksIElQdjYgaW50ZXJuZXQgLyA2Ym9uZSBh bmQgdGhlcmUgaXMgSVB2NiBjb25uZWN0aW9uIHRvIG5vZGUgQj8iDQoNCk15IHNtYWxsIGV4cGVy aWVuY2Ugc2hvd3MgdGhhdCBjb25maWd1cmluZyBzdGF0aWMgdHVubmVscyBiZWNvbWVzIHF1aWNr bHkgYm9yaW5nLiBJIHdvdWxkIHByZWZlciBhIDZ0bzQtYmFzZWQgc29sdXRpb24uIEJ1dCBpdCBz ZWVtcyB0aGF0IHNlY3VyaXR5IGlzc3VlcyBhcmUgcmVtYWluaW5nLi4uIEkgaGF2ZSB0byBjaGVj ayB0aGF0Lg0KDQpMdWMNCg0KDQoJLS0tLS0tLS0gTWVzc2FnZSBkJ29yaWdpbmUtLS0tLS0tLSAN CglEZToganVoYS53aWxqYWtrYUBub2tpYS5jb20gW21haWx0bzpqdWhhLndpbGpha2thQG5va2lh LmNvbV0gDQoJRGF0ZTogbWFyLiAxNy8xMi8yMDAyIDEyOjIzIA0KCcOAOiBBbmFuZC5UaGFrdXJA aHBzZ2xvYmFsLmNvbSANCglDYzogdjZvcHNAb3BzLmlldGYub3JnIA0KCU9iamV0OiBSRTogM2dw cCBzY2VuYXJpbyAyDQoJDQoJDQoNCglBbmFuZCwNCgkNCglJIGFzc3VtZSB0aGF0IHRoaXMgaXMg YSB2ZXJ5IGNvbW1vbiBwcm9ibGVtIC8gZW52aXJvbm1lbnQgaW4gaW5pdGlhbCBJUHY2IGRlcGxv eW1lbnQsIGkuZS4gdHdvIHNlcGFyYXRlIElQdjYgaXNsYW5kcyBjb25uZWN0ZWQgYnkgSVB2NCBu ZXR3b3JrIHVzaW5nICJJUHY2IGluIElQdjQiIHR1bm5lbGluZyBhbmQgc29sdXRpb25zIGhhdmUg YWxyZWFkeSBiZWVuIHRob3VnaHQgYnkgc2V2ZXJhbCAoRE5TKSBleHBlcnRzLg0KCQ0KCVdoYXQg aWYgd2UgYWxyZWFkeSBoYXZlIHNvbWUgc3RhdGljICJJUHY2IGluIElQdjQiIHR1bm5lbHMgY29u ZmlndXJlZCBmcm9tIHRoZSBvcGVyYXRvcidzIG5ldHdvcmsgdG8sIHNheSwgSVB2NiBpbnRlcm5l dCAvIDZib25lIGFuZCB0aGVyZSBpcyBJUHY2IGNvbm5lY3Rpb24gdG8gbm9kZSBCPw0KCQ0KCUkg YW0gdmVyeSBoYXBweSB0byByZWNlaXZlIG1vcmUgY29tbWVudHMgb24gdGhpcyBpc3N1ZS4NCgkN CglUaGFua3MsDQoJICAgICAgICAtSnVoYS0NCgkNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KCUZyb206IGV4dCBUaGFrdXIsIEFuYW5kIFttYWlsdG86QW5hbmQuVGhha3VyQGhwc2dsb2Jh bC5jb21dDQoJU2VudDogMTcgRGVjZW1iZXIsIDIwMDIgMTM6MDENCglUbzogV2lsamFra2EgSnVo YSAoTk1QL1RhbXBlcmUpDQoJQ2M6IFY2b3BzIChFLW1haWwpDQoJU3ViamVjdDogM2dwcCBzY2Vu YXJpbyAyDQoJDQoJDQoJaGkgaHVoYSwNCglpIHdhcyBqdXN0IHdvbmRlcmluZyBhYm91dCB0aGUg c2NlbmFyaW8gaW4gd2hpY2ggMiBJUFY2IFVFcyBjb21tdW5pY2F0ZSBvdmVyDQoJYW4gSVBWNCBu ZXR3b3JrLiBJbiB0aGlzIHNjZW5hcmlvIHdvbid0IGluaXRpYWwgRE5TIHJlc29sdXRpb24gYmUg YSB2ZXJ5DQoJZGlmZmljdWx0IGpvYiAoaWYgbm90IGltcG9zc2libGUpPw0KCUlmIHlvdSBoYXZl IG5vdCB1bmRlcnN0b29kIG15IHF1ZXN0aW9uIHJlYWQgdGhpcyBleGFtcGxlOg0KCUxldCBIb3N0 IEEgYmUgb24gSVBWNiBuZXRvcmsgWCBhbmQgSG9zdCBCIG9uIElQVjYgbmV0d29yayBZLiBOb3cs IGlmIEEgbWFrZXMNCglhIEROUyBxdWVyeSAoIkEiKSBmb3IgQiwgbm9uZSBvZiB0aGUgbmFtZSBy ZXNvbHZlcnMgaW4gbmV0d29yayBYIHdpbGwgaGF2ZQ0KCWFuIGVudHJ5IGZvciBCIC4gSG93IHdp bGwgdGhpcyBxdWVyeSBmaW5hbGx5IHJlYWNoIG5ldHdvcmsgWSwgYXNzdW1pbmcgYWxsDQoJaW50 ZXJtZWRpYXRlIHJvdXRlcnMgYXJlIElQVjQgb25seT8gV2lsbCBBIGhhdmUgdG8gZXhwbGljaXRs eSB0dW5uZWwgdGhpcw0KCXJlcXVlc3QgdG8gbmV0d29yayBZPyBJIGFtIGFsc28gYXNzdW1pbmcg dGhhdCBETlMgc2VydmVycyBpbiB0aGUgSVBWNA0KCWludGVybmV0IGRvbid0IHN1cHBvcnQgIkFB QUEiLg0KCQ0KCXJlZ2FyZHMNCglBbmFuZCBUaGFrdXINCglIQ0wgUGVyb3QgU3lzdGVtcyAoQSBT RUkgQ01NIExldmVsIDUgQ29tcGFueSkNCglQbG90IE5vIDMsIFNlY3RvciAxMjUsIE5PSURBIChV UCktMjAxMzAxLCBJbmRpYQ0KCSogVGVsICArOTEgMTIwIDQ0MzI3NTUtNzksIFgzMzQ4IChFUEFC WCkNCgltb2JpbGU6OTgxMTc0ODUxMg0KCQ0KCQ0KCQ0KDQo= ------_=_NextPart_001_01C2A5C2.A6399D66 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5SRTogM2dwcCBzY2VuYXJp byAyPC9USVRMRT4KPC9IRUFEPgo8Qk9EWSBkaXI9bHRyPgo8RElWPkhpIEp1aGEgYW5kIEFuYW5k LDwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkNhbiB5b3UgY2xhcmlmeTogIjxGT05UIHNp emU9Mj5XaGF0IGlmIHdlIGFscmVhZHkgaGF2ZSBzb21lIHN0YXRpYyAiSVB2NiBpbiAKSVB2NCIg dHVubmVscyBjb25maWd1cmVkIGZyb20gdGhlIG9wZXJhdG9yJ3MgbmV0d29yayB0bywgc2F5LCBJ UHY2IGludGVybmV0IC8gCjZib25lIGFuZCB0aGVyZSBpcyBJUHY2IGNvbm5lY3Rpb24gdG8gbm9k ZSBCPyI8L0ZPTlQ+PC9ESVY+CjxQPk15IHNtYWxsIGV4cGVyaWVuY2Ugc2hvd3MgdGhhdCBjb25m aWd1cmluZyBzdGF0aWMgdHVubmVscyBiZWNvbWVzIHF1aWNrbHkgCmJvcmluZy4gSSB3b3VsZCBw cmVmZXIgYSA2dG80LWJhc2VkIHNvbHV0aW9uLiBCdXQgaXQgc2VlbXMgdGhhdCBzZWN1cml0eSBp c3N1ZXMgCmFyZSByZW1haW5pbmcuLi4gSSBoYXZlIHRvIGNoZWNrIHRoYXQuPC9QPgo8UD5MdWM8 L1A+CjxESVY+PEJSPjwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklH SFQ6IDBweCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS0tLS0gTWVzc2FnZSBkJ29yaWdpbmUt LS0tLS0tLSA8QlI+PEI+RGU6PC9CPiAKICBqdWhhLndpbGpha2thQG5va2lhLmNvbSBbbWFpbHRv Omp1aGEud2lsamFra2FAbm9raWEuY29tXSA8QlI+PEI+RGF0ZTo8L0I+IG1hci4gCiAgMTcvMTIv MjAwMiAxMjoyMyA8QlI+PEI+w4A6PC9CPiBBbmFuZC5UaGFrdXJAaHBzZ2xvYmFsLmNvbSA8QlI+ PEI+Q2M6PC9CPiAKICB2Nm9wc0BvcHMuaWV0Zi5vcmcgPEJSPjxCPk9iamV0OjwvQj4gUkU6IDNn cHAgc2NlbmFyaW8gMjxCUj48QlI+PC9GT05UPjwvRElWPgogIDxQPjxGT05UIHNpemU9Mj5BbmFu ZCw8QlI+PEJSPkkgYXNzdW1lIHRoYXQgdGhpcyBpcyBhIHZlcnkgY29tbW9uIHByb2JsZW0gLyAK ICBlbnZpcm9ubWVudCBpbiBpbml0aWFsIElQdjYgZGVwbG95bWVudCwgaS5lLiB0d28gc2VwYXJh dGUgSVB2NiBpc2xhbmRzIAogIGNvbm5lY3RlZCBieSBJUHY0IG5ldHdvcmsgdXNpbmcgIklQdjYg aW4gSVB2NCIgdHVubmVsaW5nIGFuZCBzb2x1dGlvbnMgaGF2ZSAKICBhbHJlYWR5IGJlZW4gdGhv dWdodCBieSBzZXZlcmFsIChETlMpIGV4cGVydHMuPEJSPjxCUj5XaGF0IGlmIHdlIGFscmVhZHkg aGF2ZSAKICBzb21lIHN0YXRpYyAiSVB2NiBpbiBJUHY0IiB0dW5uZWxzIGNvbmZpZ3VyZWQgZnJv bSB0aGUgb3BlcmF0b3IncyBuZXR3b3JrIHRvLCAKICBzYXksIElQdjYgaW50ZXJuZXQgLyA2Ym9u ZSBhbmQgdGhlcmUgaXMgSVB2NiBjb25uZWN0aW9uIHRvIG5vZGUgQj88QlI+PEJSPkkgYW0gCiAg dmVyeSBoYXBweSB0byByZWNlaXZlIG1vcmUgY29tbWVudHMgb24gdGhpcyAKICBpc3N1ZS48QlI+ PEJSPlRoYW5rcyw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IAogIC1KdWhhLTxCUj48QlI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+RnJvbTogZXh0 IFRoYWt1ciwgQW5hbmQgWzxBIAogIGhyZWY9Im1haWx0bzpBbmFuZC5UaGFrdXJAaHBzZ2xvYmFs LmNvbSI+bWFpbHRvOkFuYW5kLlRoYWt1ckBocHNnbG9iYWwuY29tPC9BPl08QlI+U2VudDogCiAg MTcgRGVjZW1iZXIsIDIwMDIgMTM6MDE8QlI+VG86IFdpbGpha2thIEp1aGEgKE5NUC9UYW1wZXJl KTxCUj5DYzogVjZvcHMgCiAgKEUtbWFpbCk8QlI+U3ViamVjdDogM2dwcCBzY2VuYXJpbyAyPEJS PjxCUj48QlI+aGkgaHVoYSw8QlI+aSB3YXMganVzdCAKICB3b25kZXJpbmcgYWJvdXQgdGhlIHNj ZW5hcmlvIGluIHdoaWNoIDIgSVBWNiBVRXMgY29tbXVuaWNhdGUgb3ZlcjxCUj5hbiBJUFY0IAog IG5ldHdvcmsuIEluIHRoaXMgc2NlbmFyaW8gd29uJ3QgaW5pdGlhbCBETlMgcmVzb2x1dGlvbiBi ZSBhIHZlcnk8QlI+ZGlmZmljdWx0IAogIGpvYiAoaWYgbm90IGltcG9zc2libGUpPzxCUj5JZiB5 b3UgaGF2ZSBub3QgdW5kZXJzdG9vZCBteSBxdWVzdGlvbiByZWFkIHRoaXMgCiAgZXhhbXBsZTo8 QlI+TGV0IEhvc3QgQSBiZSBvbiBJUFY2IG5ldG9yayBYIGFuZCBIb3N0IEIgb24gSVBWNiBuZXR3 b3JrIFkuIE5vdywgCiAgaWYgQSBtYWtlczxCUj5hIEROUyBxdWVyeSAoIkEiKSBmb3IgQiwgbm9u ZSBvZiB0aGUgbmFtZSByZXNvbHZlcnMgaW4gbmV0d29yayBYIAogIHdpbGwgaGF2ZTxCUj5hbiBl bnRyeSBmb3IgQiAuIEhvdyB3aWxsIHRoaXMgcXVlcnkgZmluYWxseSByZWFjaCBuZXR3b3JrIFks IAogIGFzc3VtaW5nIGFsbDxCUj5pbnRlcm1lZGlhdGUgcm91dGVycyBhcmUgSVBWNCBvbmx5PyBX aWxsIEEgaGF2ZSB0byBleHBsaWNpdGx5IAogIHR1bm5lbCB0aGlzPEJSPnJlcXVlc3QgdG8gbmV0 d29yayBZPyBJIGFtIGFsc28gYXNzdW1pbmcgdGhhdCBETlMgc2VydmVycyBpbiAKICB0aGUgSVBW NDxCUj5pbnRlcm5ldCBkb24ndCBzdXBwb3J0ICJBQUFBIi48QlI+PEJSPnJlZ2FyZHM8QlI+QW5h bmQgCiAgVGhha3VyPEJSPkhDTCBQZXJvdCBTeXN0ZW1zIChBIFNFSSBDTU0gTGV2ZWwgNSBDb21w YW55KTxCUj5QbG90IE5vIDMsIFNlY3RvciAKICAxMjUsIE5PSURBIChVUCktMjAxMzAxLCBJbmRp YTxCUj4qIFRlbCZuYnNwOyArOTEgMTIwIDQ0MzI3NTUtNzksIFgzMzQ4IAogIChFUEFCWCk8QlI+ bW9iaWxlOjk4MTE3NDg1MTI8QlI+PEJSPjxCUj48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT4KCjwv Qk9EWT4KPC9IVE1MPg== ------_=_NextPart_001_01C2A5C2.A6399D66-- From owner-v6ops@ops.ietf.org Tue Dec 17 07:00:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12124 for ; Tue, 17 Dec 2002 07:00:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OGR2-000ADL-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 04:02:52 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18OGQz-000AD7-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 04:02:49 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Dec 2002 17:32:47 +0530 Message-ID: From: "Thakur, Anand" To: BELOEIL Luc FTRD/DMI/CAE , juha.wiljakka@nokia.com Cc: v6ops@ops.ietf.org, "Ajay Jain (E-mail)" Subject: RE: 3gpp scenario 2 Date: Tue, 17 Dec 2002 17:33:58 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA12124 Hi Luc, I totally agree that configured tunneling is very boring and time consuming but in this case you will have to set up only one configured tunnel to the 6bone/v6 internet. From there on it will be the responsibility of the 6bone to send you back a legitimate reply ;-) But the question remains, how do you know that HOST B is V6 and not V4? Being in a V6 island you should be able to maintain connectivity with the V4 world also. If you generate a dual query (one to the 6bone and one to the V4 internet) and get a blank from the V4 net, then what? Do you wait for the 6bone reply? But most clients would accept the answer that they get first. regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 > -----Original Message----- > From: BELOEIL Luc FTRD/DMI/CAE [SMTP:luc.beloeil@rd.francetelecom.com] > Sent: Tuesday, December 17, 2002 5:22 PM > To: juha.wiljakka@nokia.com; Anand.Thakur@hpsglobal.com > Cc: v6ops@ops.ietf.org > Subject: RE : 3gpp scenario 2 > > Hi Juha and Anand, > > Can you clarify: "What if we already have some static "IPv6 in IPv4" > tunnels configured from the operator's network to, say, IPv6 internet / > 6bone and there is IPv6 connection to node B?" > > My small experience shows that configuring static tunnels becomes quickly > boring. I would prefer a 6to4-based solution. But it seems that security > issues are remaining... I have to check that. > > Luc > > > -------- Message d'origine-------- > De: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Date: mar. 17/12/2002 12:23 > À: Anand.Thakur@hpsglobal.com > Cc: v6ops@ops.ietf.org > Objet: RE: 3gpp scenario 2 > > > > Anand, > > I assume that this is a very common problem / environment in initial > IPv6 deployment, i.e. two separate IPv6 islands connected by IPv4 network > using "IPv6 in IPv4" tunneling and solutions have already been thought by > several (DNS) experts. > > What if we already have some static "IPv6 in IPv4" tunnels > configured from the operator's network to, say, IPv6 internet / 6bone and > there is IPv6 connection to node B? > > I am very happy to receive more comments on this issue. > > Thanks, > -Juha- > > -----Original Message----- > From: ext Thakur, Anand [ ] > Sent: 17 December, 2002 13:01 > To: Wiljakka Juha (NMP/Tampere) > Cc: V6ops (E-mail) > Subject: 3gpp scenario 2 > > > hi huha, > i was just wondering about the scenario in which 2 IPV6 UEs > communicate over > an IPV4 network. In this scenario won't initial DNS resolution be a > very > difficult job (if not impossible)? > If you have not understood my question read this example: > Let Host A be on IPV6 netork X and Host B on IPV6 network Y. Now, if > A makes > a DNS query ("A") for B, none of the name resolvers in network X > will have > an entry for B . How will this query finally reach network Y, > assuming all > intermediate routers are IPV4 only? Will A have to explicitly tunnel > this > request to network Y? I am also assuming that DNS servers in the > IPV4 > internet don't support "AAAA". > > regards > Anand Thakur > HCL Perot Systems (A SEI CMM Level 5 Company) > Plot No 3, Sector 125, NOIDA (UP)-201301, India > * Tel +91 120 4432755-79, X3348 (EPABX) > mobile:9811748512 > > > > From owner-v6ops@ops.ietf.org Tue Dec 17 07:15:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12321 for ; Tue, 17 Dec 2002 07:15:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OGfp-000AuE-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 04:18:09 -0800 Received: from tms001bb.han.telia.se ([131.115.230.132]) by psg.com with esmtp (Exim 3.36 #2) id 18OGfm-000At5-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 04:18:06 -0800 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Dec 2002 13:17:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: 3gpp scenario 2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 17 Dec 2002 13:17:57 +0100 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE807E144@TMS031MB.tcad.telia.se> Thread-Topic: 3gpp scenario 2 Thread-Index: AcKlu+nvKg790N+CRhSQydUAPO5mDAAATFqgAAG7AoA= From: To: , Cc: X-OriginalArrivalTime: 17 Dec 2002 12:17:57.0614 (UTC) FILETIME=[557CB8E0:01C2A5C6] X-Spam-Status: No, hits=1.0 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA12321 this is not an issue as long as you have a continuous name space. and just because someone is deploying ipv6-only networks, doesn't mean the name space is automatically fragmented. jasminko > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: den 17 december 2002 12:24 > To: Anand.Thakur@hpsglobal.com > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp scenario 2 > > > Anand, > > I assume that this is a very common problem / environment in > initial IPv6 deployment, i.e. two separate IPv6 islands > connected by IPv4 network using "IPv6 in IPv4" tunneling and > solutions have already been thought by several (DNS) experts. > > What if we already have some static "IPv6 in IPv4" tunnels > configured from the operator's network to, say, IPv6 internet > / 6bone and there is IPv6 connection to node B? > > I am very happy to receive more comments on this issue. > > Thanks, > -Juha- > > -----Original Message----- > From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] > Sent: 17 December, 2002 13:01 > To: Wiljakka Juha (NMP/Tampere) > Cc: V6ops (E-mail) > Subject: 3gpp scenario 2 > > > hi huha, > i was just wondering about the scenario in which 2 IPV6 UEs > communicate over > an IPV4 network. In this scenario won't initial DNS > resolution be a very > difficult job (if not impossible)? > If you have not understood my question read this example: > Let Host A be on IPV6 netork X and Host B on IPV6 network Y. > Now, if A makes > a DNS query ("A") for B, none of the name resolvers in > network X will have > an entry for B . How will this query finally reach network Y, > assuming all > intermediate routers are IPV4 only? Will A have to explicitly > tunnel this > request to network Y? I am also assuming that DNS servers in the IPV4 > internet don't support "AAAA". > > regards > Anand Thakur > HCL Perot Systems (A SEI CMM Level 5 Company) > Plot No 3, Sector 125, NOIDA (UP)-201301, India > * Tel +91 120 4432755-79, X3348 (EPABX) > mobile:9811748512 > > > From owner-v6ops@ops.ietf.org Tue Dec 17 07:25:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12517 for ; Tue, 17 Dec 2002 07:25:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OGpZ-000BMb-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 04:28:13 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 18OGpW-000BM4-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 04:28:10 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gBHCRRXm029626; Tue, 17 Dec 2002 13:27:33 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gBHCRKOa157768; Tue, 17 Dec 2002 13:27:21 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42066 from ; Tue, 17 Dec 2002 13:27:16 +0100 Message-Id: <3DFF1806.B3A6608@hursley.ibm.com> Date: Tue, 17 Dec 2002 13:26:46 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Thakur, Anand" Cc: "V6ops (E-mail)" Subject: Re: 3gpp scenario 2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.2 required=5.0 tests=NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Thakur, Anand" wrote: ... > I am also assuming that DNS servers in the IPV4 > internet don't support "AAAA". What makes you think so? Here is the output from nslookup inside a network that I promise you is IPv4 only. AAAA records travel just fine over an IPv4 network. > set querytype=ANY > ns3.surfnet.nl Server: .ibm.com Address: 9. Non-authoritative answer: ns3.surfnet.nl IPv6 address = 2001:610:1:800b:a00:20ff:fe9a:16eb ns3.surfnet.nl internet address = 195.169.124.71 Authoritative answers can be found from: (root) nameserver = J.ROOT-SERVERS.NET (root) nameserver = K.ROOT-SERVERS.NET (root) nameserver = L.ROOT-SERVERS.NET (root) nameserver = M.ROOT-SERVERS.NET (root) nameserver = A.ROOT-SERVERS.NET Brian From owner-v6ops@ops.ietf.org Tue Dec 17 07:35:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12687 for ; Tue, 17 Dec 2002 07:35:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OGzP-000BsP-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 04:38:23 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18OGzM-000Bqy-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 04:38:20 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBHCbY004291 for ; Tue, 17 Dec 2002 14:37:34 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Dec 2002 14:38:17 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 14:38:14 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 14:38:13 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: FW: 3gpp scenario 2 Date: Tue, 17 Dec 2002 14:38:07 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3646@esebe005.ntc.nokia.com> Thread-Topic: 3gpp scenario 2 Thread-Index: AcKlu+nvKg790N+CRhSQydUAPO5mDAAATFqgAAFAsVwAAXwI4A== From: To: , Cc: X-OriginalArrivalTime: 17 Dec 2002 12:38:13.0535 (UTC) FILETIME=[2A3B8AF0:01C2A5C9] X-Spam-Status: No, hits=3.7 required=5.0 tests=BASE64_ENC_TEXT,CARRIAGE_RETURNS,NO_REAL_NAME, OUTLOOK_FW_MSG,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id HAA12687 Hi, Luc! Our proposed solution concluding that "In most 3GPP scenarios it is preferred to use manually configured tunnels or EGP/IGP based tunneling mechanisms." is written in "3GPP analysis" chapter 3.2. In my comment below I just refer to using "IPv6 in IPv4" tunnels from the operator's network to other IPv6 islands - configured tunneling makes sense, if there is a limited number of other IPV6 islands you need to connect to. Note that we also state "However, manually configured tunnels can be an administrative burden when the number of islands and therefore tunnels rises. Therefore it is also possible to use dynamic tunneling mechanisms such as "6to4" [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms [BGP][IGP]." in our analysis doc. BR, -Juha- -----Original Message----- From: ext BELOEIL Luc FTRD/DMI/CAE [mailto:luc.beloeil@rd.francetelecom.com] Sent: 17 December, 2002 13:52 Can you clarify: "What if we already have some static "IPv6 in IPv4" tunnels configured from the operator's network to, say, IPv6 internet / 6bone and there is IPv6 connection to node B?" My small experience shows that configuring static tunnels becomes quickly boring. I would prefer a 6to4-based solution. But it seems that security issues are remaining... I have to check that. Luc -------- Message d'origine-------- De: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] Date: mar. 17/12/2002 12:23 À: Anand.Thakur@hpsglobal.com Cc: v6ops@ops.ietf.org Objet: RE: 3gpp scenario 2 Anand, I assume that this is a very common problem / environment in initial IPv6 deployment, i.e. two separate IPv6 islands connected by IPv4 network using "IPv6 in IPv4" tunneling and solutions have already been thought by several (DNS) experts. What if we already have some static "IPv6 in IPv4" tunnels configured from the operator's network to, say, IPv6 internet / 6bone and there is IPv6 connection to node B? I am very happy to receive more comments on this issue. Thanks, -Juha- -----Original Message----- From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] Sent: 17 December, 2002 13:01 To: Wiljakka Juha (NMP/Tampere) Cc: V6ops (E-mail) Subject: 3gpp scenario 2 hi huha, i was just wondering about the scenario in which 2 IPV6 UEs communicate over an IPV4 network. In this scenario won't initial DNS resolution be a very difficult job (if not impossible)? If you have not understood my question read this example: Let Host A be on IPV6 netork X and Host B on IPV6 network Y. Now, if A makes a DNS query ("A") for B, none of the name resolvers in network X will have an entry for B . How will this query finally reach network Y, assuming all intermediate routers are IPV4 only? Will A have to explicitly tunnel this request to network Y? I am also assuming that DNS servers in the IPV4 internet don't support "AAAA". regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 From owner-v6ops@ops.ietf.org Tue Dec 17 14:08:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20569 for ; Tue, 17 Dec 2002 14:08:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ON6U-0006ih-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 11:10:06 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18ON6O-0006iA-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 11:10:00 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBHJ9kK10165; Tue, 17 Dec 2002 21:09:47 +0200 Date: Tue, 17 Dec 2002 21:09:46 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: luc.beloeil@rd.francetelecom.com, , Subject: Re: FW: 3gpp scenario 2 In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3646@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,SUPERLONG_LINE, USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Tue, 17 Dec 2002 juha.wiljakka@nokia.com wrote: > Our proposed solution concluding that "In most 3GPP scenarios it is > preferred to use manually configured tunnels or EGP/IGP based tunneling > mechanisms." is written in "3GPP analysis" chapter 3.2. > > In my comment below I just refer to using "IPv6 in IPv4" tunnels from > the operator's network to other IPv6 islands - configured tunneling > makes sense, if there is a limited number of other IPV6 islands you need > to connect to. Note that we also state > > "However, manually > configured tunnels can be an administrative burden when the number > of islands and therefore tunnels rises. Therefore it is also > possible to use dynamic tunneling mechanisms such as "6to4" > [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms > [BGP][IGP]." > > in our analysis doc. I think one should keep in mind that it's not necessary to reach every IPv6 island directly (a usual justification for e.g. IGP/EGP tunneling). I think we can pretty much discard [BGP][IGP] from scenario 2 too -- they're applicable for smaller-than-Internet scopes, which scenario 2 does not seem to be at all. > -----Original Message----- > From: ext BELOEIL Luc FTRD/DMI/CAE [mailto:luc.beloeil@rd.francetelecom.com] > Sent: 17 December, 2002 13:52 > > Can you clarify: "What if we already have some static "IPv6 in IPv4" tunnels configured from the operator's network to, say, IPv6 internet / 6bone and there is IPv6 connection to node B?" > My small experience shows that configuring static tunnels becomes quickly boring. I would prefer a 6to4-based solution. But it seems that security issues are remaining... I have to check that. > Luc > > > -------- Message d'origine-------- > De: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Date: mar. 17/12/2002 12:23 > À: Anand.Thakur@hpsglobal.com > Cc: v6ops@ops.ietf.org > Objet: RE: 3gpp scenario 2 > > > Anand, > > I assume that this is a very common problem / environment in initial IPv6 deployment, i.e. two separate IPv6 islands connected by IPv4 network using "IPv6 in IPv4" tunneling and solutions have already been thought by several (DNS) experts. > > What if we already have some static "IPv6 in IPv4" tunnels configured from the operator's network to, say, IPv6 internet / 6bone and there is IPv6 connection to node B? > > I am very happy to receive more comments on this issue. > > Thanks, > -Juha- > > -----Original Message----- > From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] > Sent: 17 December, 2002 13:01 > To: Wiljakka Juha (NMP/Tampere) > Cc: V6ops (E-mail) > Subject: 3gpp scenario 2 > > > hi huha, > i was just wondering about the scenario in which 2 IPV6 UEs communicate over > an IPV4 network. In this scenario won't initial DNS resolution be a very > difficult job (if not impossible)? > If you have not understood my question read this example: > Let Host A be on IPV6 netork X and Host B on IPV6 network Y. Now, if A makes > a DNS query ("A") for B, none of the name resolvers in network X will have > an entry for B . How will this query finally reach network Y, assuming all > intermediate routers are IPV4 only? Will A have to explicitly tunnel this > request to network Y? I am also assuming that DNS servers in the IPV4 > internet don't support "AAAA". > > regards > Anand Thakur > HCL Perot Systems (A SEI CMM Level 5 Company) > Plot No 3, Sector 125, NOIDA (UP)-201301, India > * Tel +91 120 4432755-79, X3348 (EPABX) > mobile:9811748512 > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Dec 17 16:28:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24353 for ; Tue, 17 Dec 2002 16:28:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OPIJ-000Hf7-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 13:30:27 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18OPIB-000HeO-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 13:30:20 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBHLUFw11338; Tue, 17 Dec 2002 23:30:16 +0200 Date: Tue, 17 Dec 2002 23:30:15 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt In-Reply-To: <3DF714DB.19B74094@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Thanks for comments. On Wed, 11 Dec 2002, Brian E Carpenter wrote: > Generally I wonder if there is a way to reorganize the text to make the > relay spoofing problem the most visible (first?) part. It is the unsolved > problem, after all. I'm not sure if it is really the only unsolved problem: that depends on whether one is satisfied with the "solutions" for other problems. But I agree: it should be made clearer what are the (more?) real problems and what are not. I also agree with Christian's three-tier evaluation criteria -- that's one way to consider them. I'm not sure how usable it really is (ie. the criteria to meet those three levels vary quite a bit), but at least it's something. So I think I'll add more beef to the summary section (e.g. in a form of a table) or the issues and their perceived issues. > On section 5.2.2 and the other discussions of this problem: > > I think you could consider making a recommendation that > 6to4 decapsulators SHOULD keep an LRU cache of recent relayed > headers for trace purposes. If you cache a few hundred > {src,dst,src_v4} triplets you could use this to trace spoofs. Problem here is what you're going to _do_ with these traces. Most systems where 6to4 is implementated are already able to do this, after a fashion -- with firewall logging rules. But unless there's some way to easily use that information, it is not all that usable when run e.g. in 6to4 sites. > As you observe in more than one place, this only helps if ISPs run > v4 ingress filtering - but so many of the Internet's vulnerabilities > need ingress filtering that we can't penalize 6to4 for that. v4 ingress filtering is a problem -- yes. 6to4 is slightly different in the respect that it expects 6to4 routers to form weakish trust relationships with any IP address in the Internet. This would be less the case if such relationships would only be required with e.g. some of your own ISP's addresses. > You also say somewhere that this would only allow you to trace > zombies in a DDOS attack - but it is necessary to trace zombies > in any case, even if you can't find the attacker that way. More or less agree. > Another use of a cache is that you might be able to build > a relay blacklist mechanism of some kind, or a rate limiting > mechanism - this is really outside the scope of an IETF draft > but the cache would be an enabling mechanism. Currently, a cache would work -- to an extent. But I fear if we assume no IPv4 ingress filtering, we get to the situation where the attackers could just spoof the 6to4 relays they know of.. > We haven't talked about possible crypto based solutions. At least in > theory, one could use something like AH to authenticate relayed packets, > assuming that each relay knows one of a small number of private keys > (imagine each major ISP having a 6to4 private key for its relays) > and that each decapsulator knows all the corresponding public keys. Agree; if we'd want "real", stronger security in 6to4, there are not many other possibilities other than a crypto-based approach. Crypto would be usable in the limited distribution of more specifics concept, I believe -- if you need the public keys of all the relays, I believe we might end up in an unsolvable key management nightmare.. > > 6.3. All Relays Must Be Anycast > > It's pretty obvious from the description that this doesn't > work, and you should probably say so more clearly. Also, > this section and 7.3.1 really should be combined. As this seems to be becoming a concensus, I'll look at this. > > 7.3.2. Limited Distribution of More Specific Routes > > Again, your description makes this fairly obviously hopeless. I don't want to give too much hope even though there may be some light at the end of the tunnel :-) -- but I believe this model _could_ work. And conceptually it would be pretty close to the current Internet routing security model -- so it would be a relatively good solution. I'm interested on working this more, fleshing it out, but I'd first like some thoughts whether folks feel this could be doable. > I do note however that relays, being routers, can look "sideways" > at the IPv4 routing table. If they had some magic way of deriving > the "last relay" address from this, there would be a solution > without effectively creating a spare copy of the IPv4 table. I'm not sure what you mean by the "last relay" (or magic deriving) ..? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Dec 17 16:41:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24726 for ; Tue, 17 Dec 2002 16:41:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OPVE-000IpY-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 13:43:48 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18OPVC-000IpH-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 13:43:46 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBHLhe611423; Tue, 17 Dec 2002 23:43:41 +0200 Date: Tue, 17 Dec 2002 23:43:40 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt In-Reply-To: <3DF77A89.7030806@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 11 Dec 2002, Alain Durand wrote: > There are some aspects you somehow overlooked in your draft. > > 1. This attack by spoofing relay can be distributed to > a huge number of reflectors (just have to find their address > in the DNS). This changes quiet a lot of things, and > makes tracing the attack and stopping it very difficult. > For example, it is not clear how statistical analysis > done on packet sampling will work. I meant to write about these a bit, but seemingly forgot. (I don't see this as a huge issue, as it seems to me that to succeed, this would require at least hundreds of relay routers.) If 6to4 router/node acts as a reflector, distributing the attacks to a number of reflectors naturally makes the statistical analysis in them a bit more difficult. However, if 6to4 relay routers are still a bit more sparsely distributed, most of the reflected traffic gets aggregated to smaller number of relays, and then statistical analysis there might be doable. > 2. If outgoing 6to4 relays get widely deployed and the attack > uses a very large number of reflectors with just one zombie, > it is not clear that the relays will act as a contention point... This is a less dangerous attack (relays << routers). > 3. ...but if they do, the attack is transformed from a DDOS attack > on the fake IPv6 src to a DDOS attack on the relays! I believe there are two issues that should perhaps be separated: attacks against 6to4 infrastructure and general Internet (one could say that if an attack can just harm the 6to4 mechanism itself, it's a bit more harmless). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Dec 17 17:16:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25441 for ; Tue, 17 Dec 2002 17:16:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OQ3Z-000LrV-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 14:19:17 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18OQ3W-000LrG-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 14:19:14 -0800 Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19588 for ; Tue, 17 Dec 2002 15:19:14 -0700 (MST) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H7A0044GBC1AS@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 17 Dec 2002 15:19:14 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H7A00C54BC0P3@mail.sun.net> for v6ops@ops.ietf.org; Tue, 17 Dec 2002 15:19:13 -0700 (MST) Date: Tue, 17 Dec 2002 14:19:12 -0800 From: Alain Durand Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt To: Pekka Savola , v6ops@ops.ietf.org Message-id: <3DFFA2E0.2000102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka Savola wrote: >On Wed, 11 Dec 2002, Alain Durand wrote: > > >>There are some aspects you somehow overlooked in your draft. >> >>1. This attack by spoofing relay can be distributed to >> a huge number of reflectors (just have to find their address >> in the DNS). This changes quiet a lot of things, and >> makes tracing the attack and stopping it very difficult. >> For example, it is not clear how statistical analysis >> done on packet sampling will work. >> >> > >I meant to write about these a bit, but seemingly forgot. (I don't see >this as a huge issue, as it seems to me that to succeed, this would >require at least hundreds of relay routers.) > Maybe I was not very clear, I meant a single zombie pretending to be a relay and sending a single packet to a very large number of 6to4 hosts with IPv6 src set to the victim machine. - Alain. From owner-v6ops@ops.ietf.org Tue Dec 17 23:13:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01733 for ; Tue, 17 Dec 2002 23:13:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OVaN-0002aw-00 for v6ops-data@psg.com; Tue, 17 Dec 2002 20:13:31 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18OVaL-0002YT-00 for v6ops@ops.ietf.org; Tue, 17 Dec 2002 20:13:29 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Dec 2002 09:43:21 +0530 Message-ID: From: "Thakur, Anand" To: "Juha. Wiljakka (E-mail)" Cc: "Ajay Jain (E-mail)" Subject: conclusion on 3GPP scenario 2 ? Date: Wed, 18 Dec 2002 09:44:37 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.4 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Juha, Were you able to come to any conclusion after yesterday's discussion on scenario 2? Especially in the context of the following 2 comments: 1)by Pekka >I think we can pretty much discard [BGP][IGP] from scenario 2 too -- >they're applicable for smaller-than-Internet scopes, which scenario 2 does >not seem to be at all. This remark may imply that configured tunneling is the only way out! Especially because "6 to 4" security issues are yet to be sorted out. So, if we are not using configured tunneling(due to the associated administrative burden),6 to 4(associated security problems) and [BGP][IGP](because of the comment above), then what are we supposed to use? 2)by Jasminko >this is not an issue as long as you have a continuous name space. >and just because someone is deploying ipv6-only networks, doesn't mean the name space is automatically fragmented. This remark would suggest that we need not worry about 'isolated' V6 islands. "AAAA" queries for V6 hosts will be processed due to the presence of continuous name space. regards, Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 From owner-v6ops@ops.ietf.org Wed Dec 18 05:41:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01613 for ; Wed, 18 Dec 2002 05:41:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ObeO-0005AQ-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 02:42:04 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18ObeL-0005AE-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 02:42:02 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Dec 2002 16:11:55 +0530 Message-ID: From: "Thakur, Anand" To: "Juha. Wiljakka (E-mail)" Cc: "V6ops (E-mail)" Subject: RE: conclusion on 3GPP scenario 2 ? Date: Wed, 18 Dec 2002 16:13:12 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Juha, Taking up the same example of Host A (in network X which is V6 only) and B (in network Y which is V6 only). When Network Y is set up can't the network administrator (or anybody for that matter) make sure that Host B (and other hosts also) have their IPV6 addresses entered in a DNS server which resides in the public IPV4 internet. This way Host A will be able to resolve Host B's address without the query actually going to network Y. The dual stack edge router of network X can always translate the IP headers of the DNS packets as required. regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 From owner-v6ops@ops.ietf.org Wed Dec 18 06:41:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02559 for ; Wed, 18 Dec 2002 06:41:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OcaO-0007p7-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 03:42:00 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18OcaI-0007ov-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 03:41:54 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBIBf8027230 for ; Wed, 18 Dec 2002 13:41:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Dec 2002 13:35:08 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Dec 2002 13:35:08 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FW: 3gpp scenario 2 Date: Wed, 18 Dec 2002 13:35:07 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3651@esebe005.ntc.nokia.com> Thread-Topic: FW: 3gpp scenario 2 Thread-Index: AcKl/96RoDLu8lMKRVudLim+8dqp+gAiKdVg From: To: Cc: , , , , X-OriginalArrivalTime: 18 Dec 2002 11:35:08.0743 (UTC) FILETIME=[84BBDD70:01C2A689] X-Spam-Status: No, hits=0.9 required=5.0 tests=NO_REAL_NAME,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA02559 Pekka, can you give more (specific) comments on the applicability of IGP/EGP based tunneling mechanisms in scenario 2? Scalability seems to be your main concern? Thanks, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 17 December, 2002 21:10 On Tue, 17 Dec 2002 juha.wiljakka@nokia.com wrote: > Our proposed solution concluding that "In most 3GPP scenarios it is > preferred to use manually configured tunnels or EGP/IGP based tunneling > mechanisms." is written in "3GPP analysis" chapter 3.2. > > In my comment below I just refer to using "IPv6 in IPv4" tunnels from > the operator's network to other IPv6 islands - configured tunneling > makes sense, if there is a limited number of other IPV6 islands you need > to connect to. Note that we also state > > "However, manually > configured tunnels can be an administrative burden when the number > of islands and therefore tunnels rises. Therefore it is also > possible to use dynamic tunneling mechanisms such as "6to4" > [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms > [BGP][IGP]." > > in our analysis doc. I think one should keep in mind that it's not necessary to reach every IPv6 island directly (a usual justification for e.g. IGP/EGP tunneling). I think we can pretty much discard [BGP][IGP] from scenario 2 too -- they're applicable for smaller-than-Internet scopes, which scenario 2 does not seem to be at all. From owner-v6ops@ops.ietf.org Wed Dec 18 09:37:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09628 for ; Wed, 18 Dec 2002 09:37:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OfLd-000FiP-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 06:38:57 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18OfLa-000FiD-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 06:38:55 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBIEbVj21238; Wed, 18 Dec 2002 09:37:31 -0500 (EST) Message-Id: <200212181437.gBIEbVj21238@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Thakur, Anand" cc: "Juha. Wiljakka (E-mail)" , "V6ops (E-mail)" Subject: Re: conclusion on 3GPP scenario 2 ? In-reply-to: (Your message of "Wed, 18 Dec 2002 16:13:12 +0530.") Date: Wed, 18 Dec 2002 09:37:31 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Taking up the same example of Host A (in network X which is V6 only) and B > (in network Y which is V6 only). When Network Y is set up can't the network > administrator (or anybody for that matter) make sure that Host B (and other > hosts also) have their IPV6 addresses entered in a DNS server which resides > in the public IPV4 internet. This way Host A will be able to resolve Host > B's address without the query actually going to network Y. The dual stack > edge router of network X can always translate the IP headers of the DNS > packets as required. uh, hopefully not unless it's configured to only translate IP headers of protocols for which it will do no harm - translating IP headers in general will break applications that should work over IPv6. From owner-v6ops@ops.ietf.org Wed Dec 18 16:50:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19624 for ; Wed, 18 Dec 2002 16:50:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Om4v-000ADN-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 13:50:09 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Om4q-000ACr-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 13:50:04 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBILnrE22349; Wed, 18 Dec 2002 23:49:53 +0200 Date: Wed, 18 Dec 2002 23:49:53 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: luc.beloeil@rd.francetelecom.com, , , , Subject: RE: FW: 3gpp scenario 2 In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3651@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Dec 2002 juha.wiljakka@nokia.com wrote: > can you give more (specific) comments on the applicability of IGP/EGP > based tunneling mechanisms in scenario 2? Scalability seems to be your > main concern? Let's consider the possible cases here (perhaps it should be clarified which is the case in the particular scenario): 1) inside the GPRS network: if the 3GPP operator has a large backbone, it may not have native IPv6 everywhere. Tunneling may have to be used there. Personally I think this is a non-issue, because as 3GPP is so heavily IPv6, I don't see why anyone would bother deploying it without all the network infrastructure (or most of it so it doesn't really matter) being IPv6-enabled. But if this is important, here something like [BGP][IGP] could be usable. Not required, really, or maybe not even optimal, but they could be used. 2) outside the GPRS network, between the operator's network and the Internet IPv6 (islands): there is no doubt some tunneling over IPv4 will be needed _somewhere_. But where? a) if the 3GPP operator is connected natively to an v6-enabled ISP, the 3GPP operator himself does not necessarily have to do anything: he can more or less assume someone else (e.g. his ISP) is doing the bridging between these IPv6 islands. b) if the 3GPP operator is connected to some IPv4 and IPv6 networks, it may want to perform tunneling to some IPv6 islands over IPv4 itself. This is just a matter of routing and policy. However, considering these two specific tools: [IGP] is used in IGP only and IGP is not run across administrative borders; so it's clearly useless. [BGP] could theoretically be used, but its main area of applicability is to enable automatic tunneling over IPv4-enabled core using IPv4/6 edge routers (the typical case being an ISP's MPLS core network). If this was applied to the general Internet, it would basically mean that participating islands would have to be have BGP sessions between them using some tunneling techinique like 6to4, IPv4 eBGP multihop, etc. So it seems to me neither of these is applicable in the context 2). Perhaps this clarifies my point? > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 17 December, 2002 21:10 > > On Tue, 17 Dec 2002 juha.wiljakka@nokia.com wrote: > > Our proposed solution concluding that "In most 3GPP scenarios it is > > preferred to use manually configured tunnels or EGP/IGP based tunneling > > mechanisms." is written in "3GPP analysis" chapter 3.2. > > > > In my comment below I just refer to using "IPv6 in IPv4" tunnels from > > the operator's network to other IPv6 islands - configured tunneling > > makes sense, if there is a limited number of other IPV6 islands you need > > to connect to. Note that we also state > > > > "However, manually > > configured tunnels can be an administrative burden when the number > > of islands and therefore tunnels rises. Therefore it is also > > possible to use dynamic tunneling mechanisms such as "6to4" > > [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms > > [BGP][IGP]." > > > > in our analysis doc. > > I think one should keep in mind that it's not necessary to reach every > IPv6 island directly (a usual justification for e.g. IGP/EGP tunneling). > > I think we can pretty much discard [BGP][IGP] from scenario 2 too -- > they're applicable for smaller-than-Internet scopes, which scenario 2 does > not seem to be at all. > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Dec 18 16:57:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19915 for ; Wed, 18 Dec 2002 16:57:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OmD9-000Age-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 13:58:39 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18OmD3-000Aez-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 13:58:33 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBILwRu22466; Wed, 18 Dec 2002 23:58:27 +0200 Date: Wed, 18 Dec 2002 23:58:26 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt In-Reply-To: <3DFFA2E0.2000102@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 17 Dec 2002, Alain Durand wrote: > >On Wed, 11 Dec 2002, Alain Durand wrote: > > > > > >>There are some aspects you somehow overlooked in your draft. > >> > >>1. This attack by spoofing relay can be distributed to > >> a huge number of reflectors (just have to find their address > >> in the DNS). This changes quiet a lot of things, and > >> makes tracing the attack and stopping it very difficult. > >> For example, it is not clear how statistical analysis > >> done on packet sampling will work. > >> > >> > > > >I meant to write about these a bit, but seemingly forgot. (I don't see > >this as a huge issue, as it seems to me that to succeed, this would > >require at least hundreds of relay routers.) > > > > Maybe I was not very clear, I meant a single zombie > pretending to be a relay and sending a single packet > to a very large number of 6to4 hosts with IPv6 src > set to the victim machine. Right, I misunderstood a part of your cases. However, I believe this becomes a real pain in the case that there are enough relays (in the degree of hundreds or thousands) so rate-limiting or statistical analysis on _relays_ is not really possible; obviously 6to4 nodes/routers can't do much there -- but that's little different to someone today sending a TCP SYN to Joe Random with forged source address. The difference is mainly in that the attack is doable even if you're ipv4 ingress filtered as trace about real IPv4 address used in the attack is lost at 6to4 routers. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Dec 18 17:30:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20664 for ; Wed, 18 Dec 2002 17:30:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Omk4-000CZM-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 14:32:40 -0800 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18Omk1-000CYs-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 14:32:37 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBIMWSAv008187; Wed, 18 Dec 2002 23:32:28 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 18 Dec 2002 23:32:28 +0100 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28810@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola '" , "'juha.wiljakka@nokia.com '" Cc: "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" , "Karim El-Malki (EAB)" Subject: RE: FW: 3gpp scenario 2 Date: Wed, 18 Dec 2002 23:28:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka >Let's consider the possible cases here (perhaps it should be clarified >which is the case in the particular scenario): > >1) inside the GPRS network: if the 3GPP operator has a large backbone, >it >may not have native IPv6 everywhere. Tunneling may have to be used >there. This is exactly the case. The tunnelling mechanisms paragraph mentions explicitly the case where it applies: In a 3GPP network, one IPv6 island could contain the GGSN while another island contains the operator's IPv6 application servers.... > >Personally I think this is a non-issue, because as 3GPP is so heavily >IPv6, I don't see why anyone would bother deploying it without all the >network infrastructure (or most of it so it doesn't really matter) being >IPv6-enabled. I don't agree. Most operators already have IPv4 backbone networks and many would want to migrate them gradually while introducing IPv6 islands. So it does not make sense to base our recommendations on native IPv6 operator backbones only. The IGP/EGP mechanism is for the case in which the operator is not ready to upgrade the backbone. > >But if this is important, here something like [BGP][IGP] could be >usable. OK, so I think we agree that this scenario makes sense. Rgds /Karim From owner-v6ops@ops.ietf.org Wed Dec 18 17:40:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20770 for ; Wed, 18 Dec 2002 17:40:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OmtM-000D4b-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 14:42:16 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18OmtJ-000D4O-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 14:42:13 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09197 for ; Wed, 18 Dec 2002 15:42:12 -0700 (MST) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H7C00KCQ72BQN@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 18 Dec 2002 15:42:12 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H7C0031X72A06@mail.sun.net> for v6ops@ops.ietf.org; Wed, 18 Dec 2002 15:42:11 -0700 (MST) Date: Wed, 18 Dec 2002 14:42:10 -0800 From: Alain Durand Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <3E00F9C2.4070409@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka Savola wrote: >Maybe I was not very clear, I meant a single zombie >pretending to be a relay and sending a single packet >to a very large number of 6to4 hosts with IPv6 src >set to the victim machine. > > > >Right, I misunderstood a part of your cases. > >However, I believe this becomes a real pain in the case that there are >enough relays (in the degree of hundreds or thousands) so rate-limiting or >statistical analysis on _relays_ is not really possible; obviously 6to4 >nodes/routers can't do much there -- but that's little different to >someone today sending a TCP SYN to Joe Random with forged source address. > >The difference is mainly in that the attack is doable even if you're ipv4 >ingress filtered as trace about real IPv4 address used in the attack is >lost at 6to4 routers. > This is exactly the point I've been trying to make. In this scenario, the 6to4 technology enables one to set up an attack that was supposed to be prevented by ingress filtering. And again, there is no way to prevent it from hapening. - Alain. From owner-v6ops@ops.ietf.org Wed Dec 18 17:44:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20880 for ; Wed, 18 Dec 2002 17:44:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OmyQ-000DNm-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 14:47:30 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18OmyJ-000DNA-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 14:47:23 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBIMlEV22835; Thu, 19 Dec 2002 00:47:14 +0200 Date: Thu, 19 Dec 2002 00:47:13 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (EAB)" cc: "'juha.wiljakka@nokia.com '" , "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" Subject: RE: FW: 3gpp scenario 2 In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28810@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Dec 2002, Karim El-Malki (EAB) wrote: > This is exactly the case. The tunnelling mechanisms paragraph > mentions explicitly the case where it applies: > > In a 3GPP > network, one IPv6 island could contain the GGSN while another > island contains the operator's IPv6 application servers.... I disagree: it _could_ be a case. It also reads: Encapsulating node can be e.g. the GGSN or the edge router between the border of the operator's IPv6 network and the public Internet. this makes it very apparent to me that main focus was tunneling in the internet -approach. > >But if this is important, here something like [BGP][IGP] could be > >usable. > > OK, so I think we agree that this scenario makes sense. As currently written, I totally disagree. IGP/BGP tunneling and mechanisms like these are _additional complexity_. Such mechanisms should not be advocated -- in the face of configured tunneling which is far superior for a small-to-moderate number of islands -- without a lot of care. IMO there's something really wrong in the 3GPP operator's network if it needs to have e.g. more than 10-15 isolated IPv6 islands there (~ reaching one limit where in some cases configured tunneling could become more difficult to maintain). btw. the ridiculously long paragraph should be split in about 5. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Dec 18 17:54:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21013 for ; Wed, 18 Dec 2002 17:54:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18On7E-000DtS-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 14:56:36 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #2) id 18On7B-000DpO-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 14:56:33 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 18 Dec 2002 14:56:02 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Dec 2002 14:56:02 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 18 Dec 2002 14:56:02 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 18 Dec 2002 14:56:01 -0800 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.3710.0); Wed, 18 Dec 2002 14:56:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Date: Wed, 18 Dec 2002 14:55:57 -0800 Message-ID: Thread-Topic: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Thread-Index: AcKm4xLFoqfo9VU+QAyimQNfIXnIDwABGSig From: "Christian Huitema" To: "Pekka Savola" , "Alain Durand" Cc: X-OriginalArrivalTime: 18 Dec 2002 22:56:01.0615 (UTC) FILETIME=[A2F16DF0:01C2A6E8] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA21013 > However, I believe this becomes a real pain in the case that there are > enough relays (in the degree of hundreds or thousands) so rate-limiting or > statistical analysis on _relays_ is not really possible; obviously 6to4 > nodes/routers can't do much there -- but that's little different to > someone today sending a TCP SYN to Joe Random with forged source address. > > The difference is mainly in that the attack is doable even if you're ipv4 > ingress filtered as trace about real IPv4 address used in the attack is > lost at 6to4 routers. Which is why we need some sort of mitigation. One way to make the attack risky for the attacker is to send back a tracing message, as follow: Upon reception of a 6to4 packet from IPv4 source S4, IPv4 destination D4, IPv6 source S6 and IPv6 destination D6, the 6to4 router performs ingress checks. If S6 is a "native" (non 6to4) IPv6 address, the router checks that D6 is a local destination, i.e. a 6to4 address whose header embeds the destination D4; if that it not the case, it drops the packet. (This is as specified today.) If D4 and D6 have the right value, the 6to4 router picks a random boolean value, true x% of the time; if the value is true, the router formats and send an IPv6 packet, such as: IPv6 source: the router's 6to4 address; IPv6 destination: S6 Payload type and format: TBD Content: includes notation of S4 In a situation of attack, these packets can be retrieved by S6 (the attacked party) to identify S4 (the IPv4 attacker.) It does not matter that the attack is spread to a large number of relays: x% of the attacker's packet will provide a sufficient signature, they will all contain the address S4. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Dec 18 18:01:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21167 for ; Wed, 18 Dec 2002 18:01:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OnDP-000EGE-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 15:02:59 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18OnDL-000EFz-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 15:02:55 -0800 Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21788 for ; Wed, 18 Dec 2002 16:02:54 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H7C00KL380UQN@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 18 Dec 2002 16:02:54 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H7C00G3680TSF@mail.sun.net> for v6ops@ops.ietf.org; Wed, 18 Dec 2002 16:02:54 -0700 (MST) Date: Wed, 18 Dec 2002 15:02:53 -0800 From: Alain Durand Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt To: Christian Huitema Cc: Pekka Savola , v6ops@ops.ietf.org Message-id: <3E00FE9D.5050206@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT This could be a very good deterent. - Alain. Christian Huitema wrote: >Which is why we need some sort of mitigation. One way to make the attack >risky for the attacker is to send back a tracing message, as follow: > >Upon reception of a 6to4 packet from IPv4 source S4, IPv4 destination >D4, IPv6 source S6 and IPv6 destination D6, the 6to4 router performs >ingress checks. If S6 is a "native" (non 6to4) IPv6 address, the router >checks that D6 is a local destination, i.e. a 6to4 address whose header >embeds the destination D4; if that it not the case, it drops the packet. >(This is as specified today.) If D4 and D6 have the right value, the >6to4 router picks a random boolean value, true x% of the time; if the >value is true, the router formats and send an IPv6 packet, such as: > IPv6 source: the router's 6to4 address; > IPv6 destination: S6 > Payload type and format: TBD > Content: includes notation of S4 >In a situation of attack, these packets can be retrieved by S6 (the >attacked party) to identify S4 (the IPv4 attacker.) It does not matter >that the attack is spread to a large number of relays: x% of the >attacker's packet will provide a sufficient signature, they will all >contain the address S4. > >-- Christian Huitema > > From owner-v6ops@ops.ietf.org Wed Dec 18 18:27:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21777 for ; Wed, 18 Dec 2002 18:27:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OndJ-000Fij-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 15:29:45 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18OndG-000Ffm-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 15:29:42 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA11288; Wed, 18 Dec 2002 15:29:09 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBINT7D32269; Wed, 18 Dec 2002 15:29:07 -0800 X-mProtect: <200212182329> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd189GBX; Wed, 18 Dec 2002 15:29:05 PST Message-ID: <3E0106A9.9050003@iprg.nokia.com> Date: Wed, 18 Dec 2002 15:37:13 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alain Durand , Christian Huitema CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt References: <3E00FE9D.5050206@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain/Christian, Maybe I missed something, but could it not be the case that the attacker is randomly varying his source address? In which case, the log collected at S6 may contain uncorrelated (and untraceable) S4's? Fred ftemplin@iprg.nokia.com Alain Durand wrote: > This could be a very good deterent. > > - Alain. > > > Christian Huitema wrote: > >> Which is why we need some sort of mitigation. One way to make the attack >> risky for the attacker is to send back a tracing message, as follow: >> >> Upon reception of a 6to4 packet from IPv4 source S4, IPv4 destination >> D4, IPv6 source S6 and IPv6 destination D6, the 6to4 router performs >> ingress checks. If S6 is a "native" (non 6to4) IPv6 address, the router >> checks that D6 is a local destination, i.e. a 6to4 address whose header >> embeds the destination D4; if that it not the case, it drops the packet. >> (This is as specified today.) If D4 and D6 have the right value, the >> 6to4 router picks a random boolean value, true x% of the time; if the >> value is true, the router formats and send an IPv6 packet, such as: >> IPv6 source: the router's 6to4 address; >> IPv6 destination: S6 >> Payload type and format: TBD >> Content: includes notation of S4 >> In a situation of attack, these packets can be retrieved by S6 (the >> attacked party) to identify S4 (the IPv4 attacker.) It does not matter >> that the attack is spread to a large number of relays: x% of the >> attacker's packet will provide a sufficient signature, they will all >> contain the address S4. >> >> -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Dec 18 18:52:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22370 for ; Wed, 18 Dec 2002 18:52:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Oo0Q-000H7i-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 15:53:38 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18Oo0N-000H6R-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 15:53:35 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19752 for ; Wed, 18 Dec 2002 16:53:34 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H7C00CT3AD9MZ@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 18 Dec 2002 16:53:34 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H7C003Y6AD906@mail.sun.net> for v6ops@ops.ietf.org; Wed, 18 Dec 2002 16:53:33 -0700 (MST) Date: Wed, 18 Dec 2002 15:53:33 -0800 From: Alain Durand Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt To: "Fred L. Templin" Cc: Christian Huitema , Pekka Savola , v6ops@ops.ietf.org Message-id: <3E010A7D.40102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: <3E00FE9D.5050206@sun.com> <3E0106A9.9050003@iprg.nokia.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Fred L. Templin wrote: > Alain/Christian, > > Maybe I missed something, but could it not be the case that the > attacker is randomly varying his source address? In which case, > the log collected at S6 may contain uncorrelated (and > untraceable) S4's? No, this would be catched by IPv4 ingress filtering. - Alain. From owner-v6ops@ops.ietf.org Wed Dec 18 18:58:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22523 for ; Wed, 18 Dec 2002 18:58:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Oo79-000HXj-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 16:00:35 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18Oo76-000HSi-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 16:00:32 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA12247; Wed, 18 Dec 2002 16:00:02 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBJ001e26699; Wed, 18 Dec 2002 16:00:01 -0800 X-mProtect: <200212190000> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSq9yAh; Wed, 18 Dec 2002 15:59:59 PST Message-ID: <3E010DE7.5060805@iprg.nokia.com> Date: Wed, 18 Dec 2002 16:08:07 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alain Durand CC: Christian Huitema , Pekka Savola , v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt References: <3E00FE9D.5050206@sun.com> <3E0106A9.9050003@iprg.nokia.com> <3E010A7D.40102@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain Durand wrote: > > > Fred L. Templin wrote: > >> Alain/Christian, >> >> Maybe I missed something, but could it not be the case that the >> attacker is randomly varying his source address? In which case, >> the log collected at S6 may contain uncorrelated (and >> untraceable) S4's? > > > No, this would be catched by IPv4 ingress filtering. Maybe I'm behind the times here, but when I last looked at DDoS attacks randomly varying the IPv4 source address was an element that made the attacks particularly difficult to trace. At that time, it was not necessarily true that all sites in the global IPv4 Internet properly configured IPv4 ingress filtering. Are you saying this is no longer the case? Thanks, Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Dec 18 19:06:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22636 for ; Wed, 18 Dec 2002 19:06:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OoEw-000I1B-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 16:08:38 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18OoEt-000I0a-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 16:08:35 -0800 Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26694 for ; Wed, 18 Dec 2002 17:08:34 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H7C00CSWB2AN4@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 18 Dec 2002 17:08:34 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H7C00GEKB29SO@mail.sun.net> for v6ops@ops.ietf.org; Wed, 18 Dec 2002 17:08:33 -0700 (MST) Date: Wed, 18 Dec 2002 16:08:33 -0800 From: Alain Durand Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt To: "Fred L. Templin" Cc: Christian Huitema , Pekka Savola , v6ops@ops.ietf.org Message-id: <3E010E01.7010906@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: <3E00FE9D.5050206@sun.com> <3E0106A9.9050003@iprg.nokia.com> <3E010A7D.40102@sun.com> <3E010DE7.5060805@iprg.nokia.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Fred L. Templin wrote: > > Maybe I'm behind the times here, but when I last looked at DDoS > attacks randomly varying the IPv4 source address was an element > that made the attacks particularly difficult to trace. At that > time, it was not necessarily true that all sites in the global > IPv4 Internet properly configured IPv4 ingress filtering. Are > you saying this is no longer the case? Some ISPs do ingress filtering, some don't. The issue here is to make sure 6to4 will not be used as a way to bypass ingress filtering when/if in place. - Alain. From owner-v6ops@ops.ietf.org Wed Dec 18 19:27:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22785 for ; Wed, 18 Dec 2002 19:27:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OoYo-000JAT-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 16:29:10 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18OoYl-000J9k-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 16:29:07 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA14074; Wed, 18 Dec 2002 16:28:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBJ0SZ625028; Wed, 18 Dec 2002 16:28:35 -0800 X-mProtect: <200212190028> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEAqY3y; Wed, 18 Dec 2002 16:28:34 PST Message-ID: <3E011499.509@iprg.nokia.com> Date: Wed, 18 Dec 2002 16:36:41 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Alain Durand , Pekka Savola , v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > With a defense like the one I propose, it becomes about as hard to spoof > a v6 address using 6to4 as it is to spoof a v4 address (or a v6 address) > in the first place, which implies that 6to4 would have a neutral effect > on Internet security. This is the part I was missing. To paraphrase, without your proposed mechanism a v6 source address using 6to4 can be spoofed more easily than a v4 source address since the 6to4 router strips off the v4 source. With your proposed mechanism, a v6 source address using 6to4 can be spoofed IFF the v4 source can be spoofed, i.e., v6 using 6to4 and v4 are equally (in)secure. I don't have a strong opinion on whether/not this is good enough. But, I do I see a difference in the two models: in the v4 case, the v4 destination receives the log of v4 source addresses. In the v6 case (and using your mechanism) the *true* v6 source receives the log of v4 source addresses. Thanks, Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Dec 18 23:22:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28487 for ; Wed, 18 Dec 2002 23:22:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OsDp-000857-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 20:23:45 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18OsDl-00084u-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 20:23:42 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 09:53:35 +0530 Message-ID: From: "Thakur, Anand" To: Pekka Savola , juha.wiljakka@nokia.com Cc: luc.beloeil@rd.francetelecom.com, Anand.Thakur@hpsglobal.com, v6ops@ops.ietf.org, alain.durand@sun.com, Karim.El-Malki@era.ericsson.se Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 09:54:55 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.8 required=5.0 tests=EMAIL_ATTRIBUTION,EXCHANGE_SERVER,OUTLOOK_FW_MSG, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk on Thursday, December 19, 2002 3:20 AM Pekka Savola wrote: >2) outside the GPRS network, between the operator's network and the >Internet IPv6 (islands): there is no doubt some tunneling over IPv4 will >be needed _somewhere_. But where? >a) if the 3GPP operator is connected natively to an v6-enabled ISP, the >3GPP operator himself does not necessarily have to do anything: he can >more or less assume someone else (e.g. his ISP) is doing the bridging >between these IPv6 islands. > b) if the 3GPP operator is connected to some IPv4 and IPv6 networks, it >may want to perform tunneling to some IPv6 islands over IPv4 itself. This >is just a matter of routing and policy. I think this is a very valid point and more or less summarizes a solution to scenario2. Correct me if i am wrong, but 2a) seems to indicate the following: +--------------+ +--------------+ native IPV6 connectivity | X's ISP | V6 conn. | Y's ISP | native IPV6 connectivity _____________| |______________| |__________________ / +-------------+ +--------------+ \ / \ +---------------------/-----+ +---------------------------+ +---------------------\-----+ | IPV6 network X |___V4________ | IPV4 internet |______V4_____________| V6 island Y | | (3gpp operator) | | | | | +--------------------------+ +--------------------------+ +---------------------------+ These diagrams are time consuming, but they say a picture is worth a thousand words !! So, basically a parallel IPV6 internet is existing with the IPV4 internet? regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 > -----Original Message----- > From: Pekka Savola [SMTP:pekkas@netcore.fi] > Sent: Thursday, December 19, 2002 3:20 AM > To: juha.wiljakka@nokia.com > Cc: luc.beloeil@rd.francetelecom.com; Anand.Thakur@hpsglobal.com; > v6ops@ops.ietf.org; alain.durand@sun.com; Karim.El-Malki@era.ericsson.se > Subject: RE: FW: 3gpp scenario 2 > > On Wed, 18 Dec 2002 juha.wiljakka@nokia.com wrote: > > can you give more (specific) comments on the applicability of IGP/EGP > > based tunneling mechanisms in scenario 2? Scalability seems to be your > > main concern? > > Let's consider the possible cases here (perhaps it should be clarified > which is the case in the particular scenario): > > 1) inside the GPRS network: if the 3GPP operator has a large backbone, it > may not have native IPv6 everywhere. Tunneling may have to be used there. > > Personally I think this is a non-issue, because as 3GPP is so heavily > IPv6, I don't see why anyone would bother deploying it without all the > network infrastructure (or most of it so it doesn't really matter) being > IPv6-enabled. > > But if this is important, here something like [BGP][IGP] could be usable. > > Not required, really, or maybe not even optimal, but they could be used. > > 2) outside the GPRS network, between the operator's network and the > Internet IPv6 (islands): there is no doubt some tunneling over IPv4 will > be needed _somewhere_. But where? > > a) if the 3GPP operator is connected natively to an v6-enabled ISP, the > 3GPP operator himself does not necessarily have to do anything: he can > more or less assume someone else (e.g. his ISP) is doing the bridging > between these IPv6 islands. > > b) if the 3GPP operator is connected to some IPv4 and IPv6 networks, it > may want to perform tunneling to some IPv6 islands over IPv4 itself. This > > is just a matter of routing and policy. > > However, considering these two specific tools: > > [IGP] is used in IGP only and IGP is not run across administrative > borders; so it's clearly useless. > > [BGP] could theoretically be used, but its main area of applicability is > to enable automatic tunneling over IPv4-enabled core using IPv4/6 edge > routers (the typical case being an ISP's MPLS core network). If this was > applied to the general Internet, it would basically mean that > participating islands would have to be have BGP sessions between them > using some tunneling techinique like 6to4, IPv4 eBGP multihop, etc. > > So it seems to me neither of these is applicable in the context 2). > > Perhaps this clarifies my point? > > > -----Original Message----- > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: 17 December, 2002 21:10 > > > > On Tue, 17 Dec 2002 juha.wiljakka@nokia.com wrote: > > > Our proposed solution concluding that "In most 3GPP scenarios it is > > > preferred to use manually configured tunnels or EGP/IGP based > tunneling > > > mechanisms." is written in "3GPP analysis" chapter 3.2. > > > > > > In my comment below I just refer to using "IPv6 in IPv4" tunnels from > > > the operator's network to other IPv6 islands - configured tunneling > > > makes sense, if there is a limited number of other IPV6 islands you > need > > > to connect to. Note that we also state > > > > > > "However, manually > > > configured tunnels can be an administrative burden when the number > > > > of islands and therefore tunnels rises. Therefore it is also > > > possible to use dynamic tunneling mechanisms such as "6to4" > > > [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms > > > [BGP][IGP]." > > > > > > in our analysis doc. > > > > I think one should keep in mind that it's not necessary to reach every > > IPv6 island directly (a usual justification for e.g. IGP/EGP tunneling). > > > > I think we can pretty much discard [BGP][IGP] from scenario 2 too -- > > they're applicable for smaller-than-Internet scopes, which scenario 2 > does > > not seem to be at all. > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Dec 18 23:39:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28742 for ; Wed, 18 Dec 2002 23:39:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OsUo-0009F9-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 20:41:18 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18OsUg-0009ES-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 20:41:11 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 10:11:05 +0530 Message-ID: From: "Thakur, Anand" To: Pekka Savola , "Karim El-Malki (EAB)" Cc: "'juha.wiljakka@nokia.com '" , "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" Subject: Another issue !! Date: Thu, 19 Dec 2002 10:12:26 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, I have another issue in mind. Let's say a dual stack UE establishes a V6 pdp context with it's GGSN. But the destination node is V4 and the intermediate network (internet) is also V4. Assuming that the GPRS operator's network supports both IPV6 and V4, is there any way the GGSN and UE can mutually agree to replace the active V6 pdp context by a V4 one and thus avoid any unnecessary translation? regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 > -----Original Message----- > From: Pekka Savola [SMTP:pekkas@netcore.fi] > Sent: Thursday, December 19, 2002 4:17 AM > To: Karim El-Malki (EAB) > Cc: 'juha.wiljakka@nokia.com '; 'luc.beloeil@rd.francetelecom.com '; > 'Anand.Thakur@hpsglobal.com '; 'v6ops@ops.ietf.org '; > 'alain.durand@sun.com ' > Subject: RE: FW: 3gpp scenario 2 > > On Wed, 18 Dec 2002, Karim El-Malki (EAB) wrote: > > This is exactly the case. The tunnelling mechanisms paragraph > > mentions explicitly the case where it applies: > > > > In a 3GPP > > network, one IPv6 island could contain the GGSN while another > > island contains the operator's IPv6 application servers.... > > I disagree: it _could_ be a case. > > It also reads: > > Encapsulating node can be e.g. the GGSN or the edge router between > the border of the operator's IPv6 network and the public Internet. > > this makes it very apparent to me that main focus was tunneling in the > internet -approach. > > > > >But if this is important, here something like [BGP][IGP] could be > > >usable. > > > > OK, so I think we agree that this scenario makes sense. > > As currently written, I totally disagree. > > IGP/BGP tunneling and mechanisms like these are _additional complexity_. > > Such mechanisms should not be advocated -- in the face of configured > tunneling which is far superior for a small-to-moderate number of islands > -- without a lot of care. > > IMO there's something really wrong in the 3GPP operator's network if it > needs to have e.g. more than 10-15 isolated IPv6 islands there (~ reaching > one limit where in some cases configured tunneling could become more > difficult to maintain). > > btw. the ridiculously long paragraph should be split in about 5. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From owner-v6ops@ops.ietf.org Thu Dec 19 00:07:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29158 for ; Thu, 19 Dec 2002 00:07:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Osvz-000B7x-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 21:09:23 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Osvv-000B7k-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 21:09:19 -0800 Received: from starfruit.itojun.org (lamb.itojun.org [202.232.15.91]) by coconut.itojun.org (Postfix) with ESMTP id 8118C4B2E; Thu, 19 Dec 2002 14:09:16 +0900 (JST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 251987B3; Thu, 19 Dec 2002 14:07:47 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Tue, 10 Dec 2002 09:20:30 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: Jun-ichiro itojun Hagino Date: Thu, 19 Dec 2002 14:07:47 +0900 Message-Id: <20021219050747.251987B3@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>> unfortunately there's no documentation. >>>> this is universally bad because >>>> (1) it requires every node to configure the translation prefix >>>> manually >>>> (kills spirit of autoconfigured hosts), or to cook up DHCPv6 option >>>> for >>>> it (horrid idea), >>> It could be a well know prefix. You won't have to configure a special >>> prefix for that. >> that's much more sick. >Could you please elaborate why? the failure mode with your proposal is a disaster. what happens if your site do not provide IPv6-to-IPv4 translation with the hardcoded prefix? your IPv6-only machine will try to connect to non-existent prefix, and the packet will travel to somewhere unknown. and with your plan, it seems that you are planning to reuse the same prefix in multiple locations (at least in different sites, and could be multiple locations within a site). it will lead to unstable translation service as routing to the hardcoded prefix can flap and the packet to hardcoded prefix can reach a different translation box, the other translation box does not have the state info for the traffic, and the connection will be killed. existing NAT-PT product (like from Yokogawa) is much more robust than what you are proposing. DNS-ALG box and NAT-PT translation box are separate. each of the NAT-PT translation box T1, T2, ... Tn are configured with certain (seaprate) IPv6 prefixes for each, P1, P2, .. Pn. DNS-ALG box monitors which NAT-PT translation boxes are alive. DNS-ALG will return fabricated AAAA response (for actual A response from the outside DNS authoritative server) using prefix Pi, when Ti is alive (it does not return AAAA with Pj if Tj is dead). itojun From owner-v6ops@ops.ietf.org Thu Dec 19 00:13:08 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29268 for ; Thu, 19 Dec 2002 00:13:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ot1n-000BTZ-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 21:15:23 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18Ot1k-000BTN-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 21:15:20 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBJ5EX013274 for ; Thu, 19 Dec 2002 07:14:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Dec 2002 07:15:17 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Dec 2002 07:15:17 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Another issue !! Date: Thu, 19 Dec 2002 07:15:16 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3654@esebe005.ntc.nokia.com> Thread-Topic: Another issue !! Thread-Index: AcKnGNsT2xMgaVInRvqmKlMZbGw8FAAA9I6g From: To: , , Cc: , , X-OriginalArrivalTime: 19 Dec 2002 05:15:17.0299 (UTC) FILETIME=[9E634030:01C2A71D] X-Spam-Status: No, hits=1.0 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA29268 Anand, in my opinion this is not an issue. I suppose that in the case you describe below, IPv4 PDP context would have been used anyway. Of course, we do not unnecessarily want to use translation. And PDP contexts can be activated / de-activated based on the (application) need. Another issue is that is there enough public IPv4 addresses? If a private IPv4 address is allocated to the terminal, IPv4 NAT would be needed... BR, -Juha- -----Original Message----- From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] Sent: 19 December, 2002 06:42 I have another issue in mind. Let's say a dual stack UE establishes a V6 pdp context with it's GGSN. But the destination node is V4 and the intermediate network (internet) is also V4. Assuming that the GPRS operator's network supports both IPV6 and V4, is there any way the GGSN and UE can mutually agree to replace the active V6 pdp context by a V4 one and thus avoid any unnecessary translation? regards Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 > -----Original Message----- > From: Pekka Savola [SMTP:pekkas@netcore.fi] > Sent: Thursday, December 19, 2002 4:17 AM > To: Karim El-Malki (EAB) > Cc: 'juha.wiljakka@nokia.com '; 'luc.beloeil@rd.francetelecom.com '; > 'Anand.Thakur@hpsglobal.com '; 'v6ops@ops.ietf.org '; > 'alain.durand@sun.com ' > Subject: RE: FW: 3gpp scenario 2 > > On Wed, 18 Dec 2002, Karim El-Malki (EAB) wrote: > > This is exactly the case. The tunnelling mechanisms paragraph > > mentions explicitly the case where it applies: > > > > In a 3GPP > > network, one IPv6 island could contain the GGSN while another > > island contains the operator's IPv6 application servers.... > > I disagree: it _could_ be a case. > > It also reads: > > Encapsulating node can be e.g. the GGSN or the edge router between > the border of the operator's IPv6 network and the public Internet. > > this makes it very apparent to me that main focus was tunneling in the > internet -approach. > > > > >But if this is important, here something like [BGP][IGP] could be > > >usable. > > > > OK, so I think we agree that this scenario makes sense. > > As currently written, I totally disagree. > > IGP/BGP tunneling and mechanisms like these are _additional complexity_. > > Such mechanisms should not be advocated -- in the face of configured > tunneling which is far superior for a small-to-moderate number of islands > -- without a lot of care. > > IMO there's something really wrong in the 3GPP operator's network if it > needs to have e.g. more than 10-15 isolated IPv6 islands there (~ reaching > one limit where in some cases configured tunneling could become more > difficult to maintain). > > btw. the ridiculously long paragraph should be split in about 5. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From owner-v6ops@ops.ietf.org Thu Dec 19 01:26:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00224 for ; Thu, 19 Dec 2002 01:26:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OuAR-000G3q-00 for v6ops-data@psg.com; Wed, 18 Dec 2002 22:28:23 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18OuAO-000G3e-00 for v6ops@ops.ietf.org; Wed, 18 Dec 2002 22:28:20 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBJ6S3b26105; Thu, 19 Dec 2002 08:28:03 +0200 Date: Thu, 19 Dec 2002 08:28:03 +0200 (EET) From: Pekka Savola To: "Fred L. Templin" cc: Christian Huitema , Alain Durand , Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt In-Reply-To: <3E011499.509@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Dec 2002, Fred L. Templin wrote: > I don't have a strong opinion on whether/not this is good enough. > But, I do I see a difference in the two models: in the v4 case, the > v4 destination receives the log of v4 source addresses. In the v6 > case (and using your mechanism) the *true* v6 source receives the > log of v4 source addresses. Hmm.. your use of the word "true" seem ambiguous? The proposed solution (which seems like a nice idea to me) is that the _attacked node_ (ipv6 source address in the spoofed packets) receives these reports -- seems the same as the case in v4 (with the exception that reports are received from the internet, not from received packets themselves). But this is by no means simple as that; you have to consider things like the attacker sending false reports to the target directly to "water down" the report results. As such this is very much like iTrace, and if implemented, I guess this should be just an extension (or simplification) of it, for this specific purpose. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 19 03:04:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11229 for ; Thu, 19 Dec 2002 03:04:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ovgd-000Mp3-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 00:05:43 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18OvgZ-000MoO-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 00:05:39 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBJ84q006254 for ; Thu, 19 Dec 2002 10:04:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Dec 2002 10:05:36 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Dec 2002 10:05:35 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 10:05:34 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3656@esebe005.ntc.nokia.com> Thread-Topic: FW: 3gpp scenario 2 Thread-Index: AcKm32jFFZwhRDPvSsi3UViVv5/2cgAUpvZg From: To: Cc: , , , , X-OriginalArrivalTime: 19 Dec 2002 08:05:35.0547 (UTC) FILETIME=[68F028B0:01C2A735] X-Spam-Status: No, hits=1.2 required=5.0 tests=NO_REAL_NAME,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11229 Pekka, thanks for your constructive comments! Comments (marked JW) below: -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 18 December, 2002 23:50 Let's consider the possible cases here (perhaps it should be clarified which is the case in the particular scenario): 1) inside the GPRS network: if the 3GPP operator has a large backbone, it may not have native IPv6 everywhere. Tunneling may have to be used there. Personally I think this is a non-issue, because as 3GPP is so heavily IPv6, I don't see why anyone would bother deploying it without all the network infrastructure (or most of it so it doesn't really matter) being IPv6-enabled. But if this is important, here something like [BGP][IGP] could be usable. Not required, really, or maybe not even optimal, but they could be used. JW: I agree with Karim's later comments that many GPRS operators already have IPv4 backbone networks (gradually migrating them while introducing IPv6 islands). And native v6 backbones are quite rare in the first phases of the transition. We can write clearer 'applicability statement' for the use of [BGP] / [IGP]. Another thing we should do is to more clearly separate 'inside the operator's network' and 'outside the operator's network' cases in the next revision! 2) outside the GPRS network, between the operator's network and the Internet IPv6 (islands): there is no doubt some tunneling over IPv4 will be needed _somewhere_. But where? JW: Yep, tunneling is needed in the network and 'where to tunnel' can be considered case by case; only general recommendations can be given in our draft. a) if the 3GPP operator is connected natively to an v6-enabled ISP, the 3GPP operator himself does not necessarily have to do anything: he can more or less assume someone else (e.g. his ISP) is doing the bridging between these IPv6 islands. JW: Well, yes...this looks like an easy case and starts to be close to the scope of the ISP design team.. :-) b) if the 3GPP operator is connected to some IPv4 and IPv6 networks, it may want to perform tunneling to some IPv6 islands over IPv4 itself. This is just a matter of routing and policy. However, considering these two specific tools: [IGP] is used in IGP only and IGP is not run across administrative borders; so it's clearly useless. [BGP] could theoretically be used, but its main area of applicability is to enable automatic tunneling over IPv4-enabled core using IPv4/6 edge routers (the typical case being an ISP's MPLS core network). If this was applied to the general Internet, it would basically mean that participating islands would have to be have BGP sessions between them using some tunneling techinique like 6to4, IPv4 eBGP multihop, etc. So it seems to me neither of these is applicable in the context 2). JW: Thanks for your opinion, I can quite clearly see that your basic recommendation for this case 2b) is to use a couple of configured tunnels? Perhaps this clarifies my point? JW: Yep, it does! BR, -Juha- > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 17 December, 2002 21:10 > > On Tue, 17 Dec 2002 juha.wiljakka@nokia.com wrote: > > Our proposed solution concluding that "In most 3GPP scenarios it is > > preferred to use manually configured tunnels or EGP/IGP based tunneling > > mechanisms." is written in "3GPP analysis" chapter 3.2. > > > > In my comment below I just refer to using "IPv6 in IPv4" tunnels from > > the operator's network to other IPv6 islands - configured tunneling > > makes sense, if there is a limited number of other IPV6 islands you need > > to connect to. Note that we also state > > > > "However, manually > > configured tunnels can be an administrative burden when the number > > of islands and therefore tunnels rises. Therefore it is also > > possible to use dynamic tunneling mechanisms such as "6to4" > > [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms > > [BGP][IGP]." > > > > in our analysis doc. > > I think one should keep in mind that it's not necessary to reach every > IPv6 island directly (a usual justification for e.g. IGP/EGP tunneling). > > I think we can pretty much discard [BGP][IGP] from scenario 2 too -- > they're applicable for smaller-than-Internet scopes, which scenario 2 does > not seem to be at all. > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 19 03:13:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11338 for ; Thu, 19 Dec 2002 03:13:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ovqc-000N9e-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 00:16:02 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18OvqY-000N9R-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 00:15:59 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBJ8FC016580 for ; Thu, 19 Dec 2002 10:15:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Dec 2002 10:15:56 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Dec 2002 10:15:56 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Dec 2002 10:15:55 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 10:15:54 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3657@esebe005.ntc.nokia.com> Thread-Topic: FW: 3gpp scenario 2 Thread-Index: AcKm52oFHE3Fo9rwSBuU4GnOTB8onQATgDKg From: To: , Cc: , , , X-OriginalArrivalTime: 19 Dec 2002 08:15:55.0737 (UTC) FILETIME=[DA99A490:01C2A736] X-Spam-Status: No, hits=0.4 required=5.0 tests=EMAIL_ATTRIBUTION,NO_REAL_NAME,OUTLOOK_FW_MSG, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11338 Some more comments below: -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 19 December, 2002 00:47 On Wed, 18 Dec 2002, Karim El-Malki (EAB) wrote: It also reads: Encapsulating node can be e.g. the GGSN or the edge router between the border of the operator's IPv6 network and the public Internet. this makes it very apparent to me that main focus was tunneling in the internet -approach. JW: This is a thing I commented in my previous mail: we must more clearly separate those outside / inside operator's network cases in the next revision. IMO there's something really wrong in the 3GPP operator's network if it needs to have e.g. more than 10-15 isolated IPv6 islands there (~ reaching one limit where in some cases configured tunneling could become more difficult to maintain). JW: I also think that configured tunneling is fine when the number of tunnels can be kept limited. Around 10 configured tunnels may be sufficient for many 3GPP nws. btw. the ridiculously long paragraph should be split in about 5. JW: Let's do that in January! I admit that the editor could click 'enter' more frequently... BR, -Juha- From owner-v6ops@ops.ietf.org Thu Dec 19 03:26:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11446 for ; Thu, 19 Dec 2002 03:26:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ow2l-000NXe-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 00:28:35 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Ow2h-000NXN-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 00:28:31 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBJ8SEs27176; Thu, 19 Dec 2002 10:28:14 +0200 Date: Thu, 19 Dec 2002 10:28:13 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: luc.beloeil@rd.francetelecom.com, , , , Subject: RE: FW: 3gpp scenario 2 In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3656@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Dec 2002 juha.wiljakka@nokia.com wrote: > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 18 December, 2002 23:50 > > Let's consider the possible cases here (perhaps it should be clarified > which is the case in the particular scenario): > > 1) inside the GPRS network: if the 3GPP operator has a large backbone, it > may not have native IPv6 everywhere. Tunneling may have to be used there. > > Personally I think this is a non-issue, because as 3GPP is so heavily > IPv6, I don't see why anyone would bother deploying it without all the > network infrastructure (or most of it so it doesn't really matter) being > IPv6-enabled. > > But if this is important, here something like [BGP][IGP] could be usable. > Not required, really, or maybe not even optimal, but they could be used. > > JW: I agree with Karim's later comments that many GPRS operators already > have IPv4 backbone networks (gradually migrating them while introducing > IPv6 islands). And native v6 backbones are quite rare in the first phases > of the transition. We can write clearer 'applicability statement' for the use > of [BGP] / [IGP]. Sure, but my thought is that dual-stack v4/v6 backbones already exist, and are definitely on the rise. It's not like 3GPP networks are deploying today or tomorrow. Often setting up the infrastructure required to install something like BGP/IGP tunneling is greater than the pain of configured tunneling or dual-stack backbone. In any case, I'm not sure how specific this discussion is to 3GPP. Depending on how you view the operator, seems pretty close to ISP (or enterprise) network. > Another thing we should do is to more clearly separate > 'inside the operator's network' and 'outside the operator's network' cases in > the next revision! Definitely agree :-) > a) if the 3GPP operator is connected natively to an v6-enabled ISP, the > 3GPP operator himself does not necessarily have to do anything: he can > more or less assume someone else (e.g. his ISP) is doing the bridging > between these IPv6 islands. > > JW: Well, yes...this looks like an easy case and starts to be close to > the scope of the ISP design team.. :-) Definitely... If the 3GPP operator does tunneling over IPv4 Internet, IMO it should be considered 3GPP operator/ISP, and then ISP parts would apply. Nothing really 3GPP-specific as I see it. > JW: Thanks for your opinion, I can quite clearly see that your basic > recommendation for this case 2b) is to use a couple of configured > tunnels? Yes -- but it depends quite a bit on how many ISP functions the 3GPP operator wants to perform (indeed, I believe most of them are ISP's of some sort themselves) -- and then the issue about external connectivity seems a bit moot. My point is that I don't see anything 3GPP -specific in the Internet case. Either it gets connectivity to other IPv6 sites through its ISP's or transits, or connects to some of them directly ("acting as ISP doing peering"). The latter is unscalable. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 19 04:09:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12060 for ; Thu, 19 Dec 2002 04:09:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Owgt-000OpZ-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 01:10:03 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18Owgq-000Ooc-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 01:10:00 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 14:39:51 +0530 Message-ID: From: "Thakur, Anand" To: "Karim El-Malki (EAB)" , "'Pekka Savola '" , "'juha.wiljakka@nokia.com '" Cc: "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 14:41:12 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.2 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I don't agree. Most operators already have IPv4 backbone networks and >many would want to migrate them gradually while introducing IPv6 >islands. So it does not make sense to base our recommendations on >native IPv6 operator backbones only. The IGP/EGP mechanism is for >the case in which the operator is not ready to upgrade the >backbone. by IPV6 islands are we reffering to entire PLMNs being IPV6? if yes, then will an IPV4 UE be able to perform GPRS attach to an IPV6 PLMN (island)? Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 > -----Original Message----- > From: Karim El-Malki (EAB) [SMTP:Karim.El-Malki@era.ericsson.se] > Sent: Thursday, December 19, 2002 3:59 AM > To: 'Pekka Savola '; 'juha.wiljakka@nokia.com ' > Cc: 'luc.beloeil@rd.francetelecom.com '; 'Anand.Thakur@hpsglobal.com '; > 'v6ops@ops.ietf.org '; 'alain.durand@sun.com '; Karim El-Malki (EAB) > Subject: RE: FW: 3gpp scenario 2 > > Hi Pekka > > >Let's consider the possible cases here (perhaps it should be clarified > >which is the case in the particular scenario): > > > >1) inside the GPRS network: if the 3GPP operator has a large backbone, > >it > >may not have native IPv6 everywhere. Tunneling may have to be used > >there. > > This is exactly the case. The tunnelling mechanisms paragraph > mentions explicitly the case where it applies: > > In a 3GPP > network, one IPv6 island could contain the GGSN while another > island contains the operator's IPv6 application servers.... > > > > >Personally I think this is a non-issue, because as 3GPP is so heavily > >IPv6, I don't see why anyone would bother deploying it without all the > >network infrastructure (or most of it so it doesn't really matter) being > >IPv6-enabled. > > I don't agree. Most operators already have IPv4 backbone networks and > many would want to migrate them gradually while introducing IPv6 > islands. So it does not make sense to base our recommendations on > native IPv6 operator backbones only. The IGP/EGP mechanism is for > the case in which the operator is not ready to upgrade the > backbone. > > > > >But if this is important, here something like [BGP][IGP] could be > >usable. > > OK, so I think we agree that this scenario makes sense. > > Rgds > /Karim From owner-v6ops@ops.ietf.org Thu Dec 19 05:01:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12738 for ; Thu, 19 Dec 2002 05:01:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OxX1-0000gC-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 02:03:55 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18OxWz-0000ff-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 02:03:53 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBJA30001410 for ; Thu, 19 Dec 2002 12:03:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Dec 2002 12:03:44 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Dec 2002 12:03:43 +0200 Received: from maebe001.NOE.Nokia.com ([10.209.0.44]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Dec 2002 12:03:32 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 11:02:29 +0100 Message-ID: <05C8D36DA4EF684D8BD4E309B1CD5AF14C4C73@maebe001.europe.nokia.com> Thread-Topic: FW: 3gpp scenario 2 Thread-Index: AcKm4ER0OhhK3JaYQzy1025HdQcFbQAYoaHQ From: To: , Cc: , , , , X-OriginalArrivalTime: 19 Dec 2002 10:03:32.0099 (UTC) FILETIME=[E2E44D30:01C2A745] X-Spam-Status: No, hits=1.7 required=5.0 tests=NO_REAL_NAME,OUTLOOK_FW_MSG,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA12738 Hi Pekka, some comments below (marked <>): -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 18 December, 2002 22:50 To: Wiljakka Juha (NMP/Tampere) Cc: luc.beloeil@rd.francetelecom.com; Anand.Thakur@hpsglobal.com; v6ops@ops.ietf.org; alain.durand@sun.com; Karim.El-Malki@era.ericsson.se Subject: RE: FW: 3gpp scenario 2 [BGP] could theoretically be used, but its main area of applicability is to enable automatic tunneling over IPv4-enabled core using IPv4/6 edge routers (the typical case being an ISP's MPLS core network). If this was applied to the general Internet, it would basically mean that participating islands would have to be have BGP sessions between them using some tunneling techinique like 6to4, IPv4 eBGP multihop, etc. So it seems to me neither of these is applicable in the context 2). --- <> [BGP] defines 2 different deployment options: the first one assumes MP-BGP implementation over IPv4 (identification of MP-BGP edge routers by their IPv4 addresses, using trivial 6in4 tunneling), while the second one assumes MP-BGP implementation over IPv6, thus needing to rely on some existing tunneling technique (as you mentioned before). Why can't we just consider the first approach, avoiding the need for any additional tunneling mechanisms? Br, _iLS _____________________________________________ Ivan Laloux Sbida Research Engineer IMN / RST / NSR Málaga System Competence Team Nokia Networks Mail:ext-Ivan.Laloux@nokia.com Tel: +34 95 202 85 19 (ext. 41) Fax: +34 95 202 00 44 _____________________________________________ From owner-v6ops@ops.ietf.org Thu Dec 19 05:22:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13165 for ; Thu, 19 Dec 2002 05:22:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OxqQ-0001P5-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 02:23:58 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18OxqM-0001Op-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 02:23:54 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBJANZr28108; Thu, 19 Dec 2002 12:23:35 +0200 Date: Thu, 19 Dec 2002 12:23:35 +0200 (EET) From: Pekka Savola To: Ext-Ivan.Laloux@nokia.com cc: juha.wiljakka@nokia.com, , , , , Subject: RE: FW: 3gpp scenario 2 In-Reply-To: <05C8D36DA4EF684D8BD4E309B1CD5AF14C4C73@maebe001.europe.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Dec 2002 Ext-Ivan.Laloux@nokia.com wrote: > Hi Pekka, some comments below (marked <>): > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 18 December, 2002 22:50 > To: Wiljakka Juha (NMP/Tampere) > Cc: luc.beloeil@rd.francetelecom.com; Anand.Thakur@hpsglobal.com; > v6ops@ops.ietf.org; alain.durand@sun.com; Karim.El-Malki@era.ericsson.se > Subject: RE: FW: 3gpp scenario 2 > > [BGP] could theoretically be used, but its main area of applicability is > to enable automatic tunneling over IPv4-enabled core using IPv4/6 edge > routers (the typical case being an ISP's MPLS core network). If this was > applied to the general Internet, it would basically mean that > participating islands would have to be have BGP sessions between them > using some tunneling techinique like 6to4, IPv4 eBGP multihop, etc. > > So it seems to me neither of these is applicable in the context 2). > > --- > > <> [BGP] defines 2 different deployment options: the first one > assumes MP-BGP implementation over IPv4 (identification of MP-BGP edge > routers by their IPv4 addresses, using trivial 6in4 tunneling), while > the second one assumes MP-BGP implementation over IPv6, thus needing to > rely on some existing tunneling technique (as you mentioned before). Why > can't we just consider the first approach, avoiding the need for any > additional tunneling mechanisms? For automatic tunneling inside the 3GPP operator, yes. For Internet, no. It'd require that you would have IPv4 BGP peerings to IPv6 islands in the internet -- which is obviously a non-starter (scalability, requirement for multihop IPv4 BGP sessions with folks you don't know about, etc.). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 19 08:44:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15925 for ; Thu, 19 Dec 2002 08:44:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P0zi-0009Ge-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 05:45:46 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18P0ze-0009Fp-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 05:45:43 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBJDit013996 for ; Thu, 19 Dec 2002 15:44:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Dec 2002 12:13:16 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Dec 2002 12:13:16 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Dec 2002 12:13:16 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 12:13:14 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC365C@esebe005.ntc.nokia.com> Thread-Topic: FW: 3gpp scenario 2 Thread-Index: AcKnOJPLgT6bY4+CRI25sLvSZ5PY6QADAaiQ From: To: Cc: , , , , X-OriginalArrivalTime: 19 Dec 2002 10:13:16.0408 (UTC) FILETIME=[3F2AC780:01C2A747] X-Spam-Status: No, hits=0.9 required=5.0 tests=NO_REAL_NAME,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA15925 Hi, Pekka! -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 19 December, 2002 10:28 On Thu, 19 Dec 2002 juha.wiljakka@nokia.com wrote: > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 18 December, 2002 23:50 > > JW: I agree with Karim's later comments that many GPRS operators already > have IPv4 backbone networks (gradually migrating them while introducing > IPv6 islands). And native v6 backbones are quite rare in the first phases > of the transition. We can write clearer 'applicability statement' for the use > of [BGP] / [IGP]. Sure, but my thought is that dual-stack v4/v6 backbones already exist, and are definitely on the rise. It's not like 3GPP networks are deploying today or tomorrow. Often setting up the infrastructure required to install something like BGP/IGP tunneling is greater than the pain of configured tunneling or dual-stack backbone. JW: Yep, the development direction goes IPv4-only backbones -> dual stack backbones (and finally in the future -> IPv6 backbones), given recommendations depend on the status of IPv6 deployment in particular operator's network. In any case, I'm not sure how specific this discussion is to 3GPP. Depending on how you view the operator, seems pretty close to ISP (or enterprise) network. JW: Maybe not so 3GPP specific at all, transition issues (like where to use which tunneling mechanism) are general. > a) if the 3GPP operator is connected natively to an v6-enabled ISP, the > 3GPP operator himself does not necessarily have to do anything: he can > more or less assume someone else (e.g. his ISP) is doing the bridging > between these IPv6 islands. > > JW: Well, yes...this looks like an easy case and starts to be close to > the scope of the ISP design team.. :-) Definitely... If the 3GPP operator does tunneling over IPv4 Internet, IMO it should be considered 3GPP operator/ISP, and then ISP parts would apply. Nothing really 3GPP-specific as I see it. JW: OK, this is more or less a question of definition, I can discuss that with the other authors. Anyway, I do not want to concentrate only on 'operator's network internal' cases in our document. Like our abstract says, In these scenarios, the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed > JW: Thanks for your opinion, I can quite clearly see that your basic > recommendation for this case 2b) is to use a couple of configured > tunnels? Yes -- but it depends quite a bit on how many ISP functions the 3GPP operator wants to perform (indeed, I believe most of them are ISP's of some sort themselves) -- and then the issue about external connectivity seems a bit moot. My point is that I don't see anything 3GPP -specific in the Internet case. Either it gets connectivity to other IPv6 sites through its ISP's or transits, or connects to some of them directly ("acting as ISP doing peering"). The latter is unscalable. From owner-v6ops@ops.ietf.org Thu Dec 19 11:26:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19258 for ; Thu, 19 Dec 2002 11:26:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P3WO-000GaE-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 08:27:40 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18P3WI-000GZz-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 08:27:34 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBJGRPKV014115; Thu, 19 Dec 2002 17:27:25 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Dec 2002 17:27:25 +0100 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA2881C@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" Cc: "'juha.wiljakka@nokia.com '" , "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 17:23:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > IGP/BGP tunneling and mechanisms like these are _additional > complexity_. > > Such mechanisms should not be advocated -- in the face of configured > tunneling which is far superior for a small-to-moderate > number of islands > -- without a lot of care. I don't think it is possible to make such a clear-cut statement. The additional complexity gives you some advantages. If a path goes down the router knows about it for example. You can't have this in general with static routes. My point is that it depends on the exact deployment and operator requirements so we can only make recommendations. I think it is correct to recommend static or EGP/IGP mechanisms if the operator wants to connect its v6 islands over v4. /Karim From owner-v6ops@ops.ietf.org Thu Dec 19 11:32:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19349 for ; Thu, 19 Dec 2002 11:32:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P3cX-000GsN-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 08:34:01 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18P3cR-000GsB-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 08:33:55 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBJGXjK30856; Thu, 19 Dec 2002 18:33:45 +0200 Date: Thu, 19 Dec 2002 18:33:44 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (EAB)" cc: "'juha.wiljakka@nokia.com '" , "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" Subject: RE: FW: 3gpp scenario 2 In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA2881C@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Dec 2002, Karim El-Malki (EAB) wrote: > > IGP/BGP tunneling and mechanisms like these are _additional > > complexity_. > > > > Such mechanisms should not be advocated -- in the face of configured > > tunneling which is far superior for a small-to-moderate > > number of islands > > -- without a lot of care. > > I don't think it is possible to make such a clear-cut statement. > The additional complexity gives you some advantages. If a path > goes down the router knows about it for example. You can't have > this in general with static routes. Configured tunneling does not have to mean static routes. Static routes are usually used because they're simple, and right tool for most jobs. Many run routing protocols on top of configured tunnels, thus there is no problem you describe. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 19 11:39:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19483 for ; Thu, 19 Dec 2002 11:38:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P3j0-000H9h-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 08:40:42 -0800 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18P3is-000H98-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 08:40:34 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBJGeDAx018197; Thu, 19 Dec 2002 17:40:16 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Dec 2002 17:40:13 +0100 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA2881D@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" , juha.wiljakka@nokia.com Cc: luc.beloeil@rd.francetelecom.com, Anand.Thakur@hpsglobal.com, v6ops@ops.ietf.org, alain.durand@sun.com Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 17:36:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Sure, but my thought is that dual-stack v4/v6 backbones > already exist, and > are definitely on the rise. It's not like 3GPP networks are > deploying > today or tomorrow. I think the issue was that 3GPP core networks have already been deployed and are running IPv4. > Often setting up the infrastructure required to > install something like BGP/IGP tunneling is greater than the pain of > configured tunneling or dual-stack backbone. When an operator introduces v6 islands over an existing v4 backbone it doesn't have to modify the existing network. Both configured tunnelling and EGP/IGP would be the same from this point of view. In certain cases upgrading the whole backbone at once is worse. /Karim From owner-v6ops@ops.ietf.org Thu Dec 19 11:43:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19581 for ; Thu, 19 Dec 2002 11:43:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P3o2-000HQk-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 08:45:54 -0800 Received: from [131.107.3.121] (helo=mail5.microsoft.com) by psg.com with esmtp (Exim 3.36 #2) id 18P3nq-000HOp-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 08:45:42 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 19 Dec 2002 08:45:11 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Dec 2002 08:45:11 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 19 Dec 2002 08:45:11 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 19 Dec 2002 08:45:10 -0800 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.3710.0); Thu, 19 Dec 2002 08:45:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Date: Thu, 19 Dec 2002 08:45:10 -0800 Message-ID: Thread-Topic: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Thread-Index: AcKnJ9LZizi5dTUZTCuZi3GKRiWRvwAVYVYw From: "Christian Huitema" To: "Pekka Savola" , "Fred L. Templin" Cc: "Alain Durand" , X-OriginalArrivalTime: 19 Dec 2002 16:45:11.0597 (UTC) FILETIME=[FF4FDDD0:01C2A77D] X-Spam-Status: No, hits=3.4 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA19581 > The proposed solution (which seems like a nice idea to me) is that the > _attacked node_ (ipv6 source address in the spoofed packets) receives > these reports -- seems the same as the case in v4 (with the exception that > reports are received from the internet, not from received packets > themselves). > > But this is by no means simple as that; you have to consider things like > the attacker sending false reports to the target directly to "water down" > the report results. Remember, the only property of the solution is to make anonymous DOS attacks as hard in IPv4+6to4 as it would be in just IPv4. The attacker needs to be able to spoof its own source address to send false reports, otherwise the reports can be used to trace him. > As such this is very much like iTrace, and if implemented, I guess this > should be just an extension (or simplification) of it, for this specific > purpose. Yes. Note that there is a class of attack that is not completely discussed in your draft, i.e. what happen if a relay does not implement the checks. For example, suppose a relay that simply listens on the anycast address, takes packets, and forward them without further checks. Building such relays is tempting, as you can cut costs: no need to check the IPv6 source address, etc. Obviously, that could have some interesting consequences. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Dec 19 11:53:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19851 for ; Thu, 19 Dec 2002 11:53:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P3xB-000HxS-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 08:55:21 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18P3x7-000HxA-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 08:55:17 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBJGt1b31015; Thu, 19 Dec 2002 18:55:01 +0200 Date: Thu, 19 Dec 2002 18:55:00 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (EAB)" cc: juha.wiljakka@nokia.com, , , , Subject: RE: FW: 3gpp scenario 2 In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA2881D@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Dec 2002, Karim El-Malki (EAB) wrote: > > Sure, but my thought is that dual-stack v4/v6 backbones > > already exist, and > > are definitely on the rise. It's not like 3GPP networks are > > deploying > > today or tomorrow. > > I think the issue was that 3GPP core networks have already been deployed > and are running IPv4. .. but v6 part of it isn't deployed today or tomorrow. Prudent folks would be preparing for enabling of IPv6 today -- so that when finally viable 3GPP solutions are available, their network is already upgraded, router software tested etc. > > Often setting up the infrastructure required to > > install something like BGP/IGP tunneling is greater than the pain of > > configured tunneling or dual-stack backbone. > > When an operator introduces v6 islands over an existing v4 backbone > it doesn't have to modify the existing network. Both configured > tunnelling and EGP/IGP would be the same from this point of view. .. at the expense of possibly having to upgrade latest and greatest software in the islands to support these mechanisms. > In certain cases upgrading the whole backbone at once is worse. Who says the backbone must be upgraded at once? Usually things like these are done over a longer period, e.g. 6-12 months. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 19 12:07:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20113 for ; Thu, 19 Dec 2002 12:07:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P49y-000Ie1-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 09:08:34 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18P49q-000Idm-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 09:08:26 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18P49p-0001UE-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 11:08:25 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Thread-Index: AcKm7Vxon4uh/3pARDSRjfL/BZqfbQAAr8ag Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt Date: Wed, 18 Dec 2002 15:54:58 -0800 From: "Christian Huitema" To: "Fred L. Templin" , "Alain Durand" Cc: "Pekka Savola" , X-Spam-Status: No, hits=2.9 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20113 > Maybe I missed something, but could it not be the case that the > attacker is randomly varying his source address? In which case, > the log collected at S6 may contain uncorrelated (and > untraceable) S4's? The specific problem we are addressing is that of an attacker that cannot change her source address, e.g. because the ISP imposes ingress filtering. Such an attacker cannot mount an attack against an IPv4 site without identifying herself; yet it could use servers behind 6to4 routers as a prop in an anonymous reflection attack against an IPv6 target. With a defense like the one I propose, it becomes about as hard to spoof a v6 address using 6to4 as it is to spoof a v4 address (or a v6 address) in the first place, which implies that 6to4 would have a neutral effect on Internet security. -- Christian Huitema > Alain Durand wrote: > > This could be a very good deterent. > > > > - Alain. > > > > > > Christian Huitema wrote: > > > >> Which is why we need some sort of mitigation. One way to make the > attack > >> risky for the attacker is to send back a tracing message, as follow: > >> > >> Upon reception of a 6to4 packet from IPv4 source S4, IPv4 destination > >> D4, IPv6 source S6 and IPv6 destination D6, the 6to4 router performs > >> ingress checks. If S6 is a "native" (non 6to4) IPv6 address, the router > >> checks that D6 is a local destination, i.e. a 6to4 address whose header > >> embeds the destination D4; if that it not the case, it drops the > packet. > >> (This is as specified today.) If D4 and D6 have the right value, the > >> 6to4 router picks a random boolean value, true x% of the time; if the > >> value is true, the router formats and send an IPv6 packet, such as: > >> IPv6 source: the router's 6to4 address; > >> IPv6 destination: S6 > >> Payload type and format: TBD > >> Content: includes notation of S4 > >> In a situation of attack, these packets can be retrieved by S6 (the > >> attacked party) to identify S4 (the IPv4 attacker.) It does not matter > >> that the attack is spread to a large number of relays: x% of the > >> attacker's packet will provide a sufficient signature, they will all > >> contain the address S4. > >> > >> -- Christian Huitema > > From owner-v6ops@ops.ietf.org Thu Dec 19 12:13:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20245 for ; Thu, 19 Dec 2002 12:13:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P4H9-000J5U-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 09:15:59 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18P4H6-000J4X-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 09:15:56 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBJHFk431199; Thu, 19 Dec 2002 19:15:46 +0200 Date: Thu, 19 Dec 2002 19:15:46 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: "Fred L. Templin" , Alain Durand , Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Dec 2002, Christian Huitema wrote: > Remember, the only property of the solution is to make anonymous DOS > attacks as hard in IPv4+6to4 as it would be in just IPv4. The attacker > needs to be able to spoof its own source address to send false reports, > otherwise the reports can be used to trace him. True. (However, if the attacker has v6 access which isn't ingress filtered, he could send some reports anyway -- but then it would be cheaper for him to just launch a direct DoS, not use 6to4 at all.) > > As such this is very much like iTrace, and if implemented, I guess > this > > should be just an extension (or simplification) of it, for this > specific > > purpose. > > Yes. > > Note that there is a class of attack that is not completely discussed in > your draft, i.e. what happen if a relay does not implement the checks. > For example, suppose a relay that simply listens on the anycast address, > takes packets, and forward them without further checks. Building such > relays is tempting, as you can cut costs: no need to check the IPv6 > source address, etc. Obviously, that could have some interesting > consequences. The non-compliant (or reckless) implementation part was deliberately excluded (except for a few special cases) from the threat analysis, as there are way too many things that could go wrong. Relays (that operate in v6 native -> 6to4 direction) will have to have 6to4 router code in anyway, though, so I don't think there's a significant difference in cost and complexity... but even so, of course, it could be done. I'll consider whether there are some critical checks that relays must do (usually ones that are difficult to implement, for one reason or another). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 19 12:17:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20299 for ; Thu, 19 Dec 2002 12:17:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P4KV-000JEO-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 09:19:27 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18P4KS-000JEA-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 09:19:24 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBJHJGKW023716; Thu, 19 Dec 2002 18:19:17 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Dec 2002 18:19:16 +0100 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA2881E@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" Cc: juha.wiljakka@nokia.com, luc.beloeil@rd.francetelecom.com, Anand.Thakur@hpsglobal.com, v6ops@ops.ietf.org, alain.durand@sun.com Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 18:15:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Thu, 19 Dec 2002, Karim El-Malki (EAB) wrote: > > > Sure, but my thought is that dual-stack v4/v6 backbones > > > already exist, and > > > are definitely on the rise. It's not like 3GPP networks are > > > deploying > > > today or tomorrow. > > > > I think the issue was that 3GPP core networks have already > been deployed > > and are running IPv4. > > .. but v6 part of it isn't deployed today or tomorrow. Prudent folks > would be preparing for enabling of IPv6 today -- so that when finally > viable 3GPP solutions are available, their network is > already upgraded, > router software tested etc. True you want to prepare as early as possible. However you may want to do your initial deployment without risking to disrupt your live v4 network. You can do that without upgrading your backbone. Of course the final aim is to upgrade the backbone, but I don't think we should recommend that they must go dual-stack from day one if they don't want to. > > > > Often setting up the infrastructure required to > > > install something like BGP/IGP tunneling is greater > than the pain of > > > configured tunneling or dual-stack backbone. > > > > When an operator introduces v6 islands over an existing v4 backbone > > it doesn't have to modify the existing network. Both configured > > tunnelling and EGP/IGP would be the same from this point of view. > > .. at the expense of possibly having to upgrade latest and greatest > software in the islands to support these mechanisms. The v6 islands haven't been deployed yet so that's ok. > > > In certain cases upgrading the whole backbone at once is worse. > > Who says the backbone must be upgraded at once? Usually > things like these > are done over a longer period, e.g. 6-12 months. What I'm saying is that there may be operators that don't want to risk disrupting a live network in the early stages of ipv6 deployment. They would do that when they have more experience with running the v6 network. For those in this situation they can tunnel between the v6 islands in the early stages. So it is a scenario we need to consider IMO. /Karim From owner-v6ops@ops.ietf.org Thu Dec 19 12:17:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20313 for ; Thu, 19 Dec 2002 12:17:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P4LC-000JIJ-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 09:20:10 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18P4L9-000JGs-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 09:20:08 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBJHJxKW023830; Thu, 19 Dec 2002 18:19:59 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Dec 2002 18:19:58 +0100 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA2881F@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" Cc: "'juha.wiljakka@nokia.com '" , "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 18:16:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Thu, 19 Dec 2002, Karim El-Malki (EAB) wrote: > > > IGP/BGP tunneling and mechanisms like these are _additional > > > complexity_. > > > > > > Such mechanisms should not be advocated -- in the face > of configured > > > tunneling which is far superior for a small-to-moderate > > > number of islands > > > -- without a lot of care. > > > > I don't think it is possible to make such a clear-cut statement. > > The additional complexity gives you some advantages. If a path > > goes down the router knows about it for example. You can't have > > this in general with static routes. > > Configured tunneling does not have to mean static routes. > Static routes > are usually used because they're simple, and right tool for > most jobs. > > Many run routing protocols on top of configured tunnels, > thus there is no > problem you describe. Don't think this is something we should recommend. It would likely mean running a routing protocol to advertise the IPv4 tunnel endpoint address and a v6 routing protocol within the tunnel to advertise the v6 routes. If we can run something like MP-BGP over v4 isn't that better? That's why I was assuming that configured tunnels would be used with static routes. /Karim From owner-v6ops@ops.ietf.org Thu Dec 19 12:34:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20816 for ; Thu, 19 Dec 2002 12:34:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P4aZ-000KHx-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 09:36:03 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18P4aU-000KHh-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 09:35:58 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18P4aT-0001Xs-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 11:35:57 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Thakur, Anand" To: Pekka Savola , juha.wiljakka@nokia.com Cc: luc.beloeil@rd.francetelecom.com, Anand.Thakur@hpsglobal.com, v6ops@ops.ietf.org, alain.durand@sun.com, Karim.El-Malki@era.ericsson.se Subject: RE: FW: 3gpp scenario 2 Date: Thu, 19 Dec 2002 14:07:05 +0530 X-Spam-Status: No, hits=-0.3 required=5.0 tests=OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >My point is that I don't see anything 3GPP -specific in the Internet case. >Either it gets connectivity to other IPv6 sites through its ISP's or >transits, or connects to some of them directly ("acting as ISP doing >peering"). The latter is unscalable. I agree. In fact in one of my earlier mails i had mentioned the same thing(that the scenarios are not 3gpp specific). But the point here is that some extra issues and points do arise in the 3gpp case. like the presence of an extraordinary number of mobile nodes accessing the internet and blowing up of NAT-PT - DNS_ALG issues. Anand Thakur HCL Perot Systems (A SEI CMM Level 5 Company) Plot No 3, Sector 125, NOIDA (UP)-201301, India * Tel +91 120 4432755-79, X3348 (EPABX) mobile:9811748512 > -----Original Message----- > From: Pekka Savola [SMTP:pekkas@netcore.fi] > Sent: Thursday, December 19, 2002 1:58 PM > To: juha.wiljakka@nokia.com > Cc: luc.beloeil@rd.francetelecom.com; Anand.Thakur@hpsglobal.com; > v6ops@ops.ietf.org; alain.durand@sun.com; Karim.El-Malki@era.ericsson.se > Subject: RE: FW: 3gpp scenario 2 > > On Thu, 19 Dec 2002 juha.wiljakka@nokia.com wrote: > > -----Original Message----- > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: 18 December, 2002 23:50 > > > > Let's consider the possible cases here (perhaps it should be clarified > > which is the case in the particular scenario): > > > > 1) inside the GPRS network: if the 3GPP operator has a large backbone, > it > > may not have native IPv6 everywhere. Tunneling may have to be used > there. > > > > Personally I think this is a non-issue, because as 3GPP is so heavily > > IPv6, I don't see why anyone would bother deploying it without all the > > network infrastructure (or most of it so it doesn't really matter) being > > > IPv6-enabled. > > > > But if this is important, here something like [BGP][IGP] could be > usable. > > Not required, really, or maybe not even optimal, but they could be used. > > > > JW: I agree with Karim's later comments that many GPRS operators > already > > have IPv4 backbone networks (gradually migrating them while introducing > > IPv6 islands). And native v6 backbones are quite rare in the first > phases > > of the transition. We can write clearer 'applicability statement' for > the use > > of [BGP] / [IGP]. > > Sure, but my thought is that dual-stack v4/v6 backbones already exist, and > are definitely on the rise. It's not like 3GPP networks are deploying > today or tomorrow. Often setting up the infrastructure required to > install something like BGP/IGP tunneling is greater than the pain of > configured tunneling or dual-stack backbone. > > In any case, I'm not sure how specific this discussion is to 3GPP. > Depending on how you view the operator, seems pretty close to ISP (or > enterprise) network. > > > Another thing we should do is to more clearly separate > > 'inside the operator's network' and 'outside the operator's network' > cases in > > the next revision! > > Definitely agree :-) > > > a) if the 3GPP operator is connected natively to an v6-enabled ISP, the > > 3GPP operator himself does not necessarily have to do anything: he can > > more or less assume someone else (e.g. his ISP) is doing the bridging > > between these IPv6 islands. > > > > JW: Well, yes...this looks like an easy case and starts to be close to > > the scope of the ISP design team.. :-) > > Definitely... > > If the 3GPP operator does tunneling over IPv4 Internet, IMO it should be > considered 3GPP operator/ISP, and then ISP parts would apply. Nothing > really 3GPP-specific as I see it. > > > JW: Thanks for your opinion, I can quite clearly see that your basic > > recommendation for this case 2b) is to use a couple of configured > > tunnels? > > Yes -- but it depends quite a bit on how many ISP functions the 3GPP > operator wants to perform (indeed, I believe most of them are ISP's of > some sort themselves) -- and then the issue about external connectivity > seems a bit moot. > > My point is that I don't see anything 3GPP -specific in the Internet case. > > Either it gets connectivity to other IPv6 sites through its ISP's or > transits, or connects to some of them directly ("acting as ISP doing > peering"). The latter is unscalable. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Dec 19 16:36:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27725 for ; Thu, 19 Dec 2002 16:36:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P8MH-0009Pi-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 13:37:33 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18P8MF-0009PU-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 13:37:31 -0800 Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17215 for ; Thu, 19 Dec 2002 14:37:30 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H7D00A8UYQHQA@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 19 Dec 2002 14:37:29 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H7D002DZYQGDV@mail.sun.net> for v6ops@ops.ietf.org; Thu, 19 Dec 2002 14:37:29 -0700 (MST) Date: Thu, 19 Dec 2002 13:37:28 -0800 From: Alain Durand Subject: Re: on NAT-PT To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org Message-id: <3E023C18.5060606@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: <20021219050747.251987B3@starfruit.itojun.org> X-Spam-Status: No, hits=-1.8 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_05_08,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Jun-ichiro itojun Hagino wrote: >>Could you please elaborate why? >> >> > > the failure mode with your proposal is a disaster. what happens if > your site do not provide IPv6-to-IPv4 translation with the hardcoded > prefix? your IPv6-only machine will try to connect to non-existent > prefix, and the packet will travel to somewhere unknown. > This prefix would have to be non globally routable and should be filtered out at site boundary to avoid this issue. This is not something catastrophic. Actually, this is very similar to what you, Dave Thaler and I are proposing for DNS stub resolver configuration. > and with your plan, it seems that you are planning to reuse the same > prefix in multiple locations (at least in different sites, and could be > multiple locations within a site). it will lead to unstable > translation service as routing to the hardcoded prefix can flap and > the packet to hardcoded prefix can reach a different translation box, > the other translation box does not have the state info for the > traffic, and the connection will be killed. > Yes, but the next one will succeed. I think of this as a good property, as in case of failure, not everything is lost, just current connections. > existing NAT-PT product (like from Yokogawa) is much more robust than > what you are proposing. > Nice commercial advertizing. > DNS-ALG box and NAT-PT translation box are separate. each of the > NAT-PT translation box T1, T2, ... Tn are configured with certain > (seaprate) IPv6 prefixes for each, P1, P2, .. Pn. DNS-ALG box > monitors which NAT-PT translation boxes are alive. DNS-ALG will return > fabricated AAAA response (for actual A response from the outside DNS > authoritative server) using prefix Pi, when Ti is alive (it does not > return AAAA with Pj if Tj is dead). > So what happens if a host has started a communication using Pi/Ti and Ti goes down? The communication dies and each subsequent communications to the same destination fail until the DNS cache on the host is flushed. This is a much worse failure mode than the one discussed above. Also very bad, this breaks DNSsec. - Alain. From owner-v6ops@ops.ietf.org Thu Dec 19 19:27:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01944 for ; Thu, 19 Dec 2002 19:27:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PB2N-000LaX-00 for v6ops-data@psg.com; Thu, 19 Dec 2002 16:29:11 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18PB2J-000LaL-00 for v6ops@ops.ietf.org; Thu, 19 Dec 2002 16:29:08 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 08F414B22; Fri, 20 Dec 2002 09:29:05 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Thu, 19 Dec 2002 13:37:28 PST. <3E023C18.5060606@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Fri, 20 Dec 2002 09:29:04 +0900 Message-Id: <20021220002905.08F414B22@coconut.itojun.org> X-Spam-Status: No, hits=1.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> the failure mode with your proposal is a disaster. what happens if >> your site do not provide IPv6-to-IPv4 translation with the hardcoded >> prefix? your IPv6-only machine will try to connect to non-existent >> prefix, and the packet will travel to somewhere unknown. >This prefix would have to be non globally routable >and should be filtered out at site boundary to avoid this issue. >This is not something catastrophic. >Actually, this is very similar to what you, Dave Thaler and I are proposing >for DNS stub resolver configuration. with DNS stub resolver configuration, only DNS resolver will be affected. what you are proposing here will affect every application that use DNS resolver (since the DNS resolver attaches magic prefix to all the responsees from DNS). there's big difference. >> and with your plan, it seems that you are planning to reuse the same >> prefix in multiple locations (at least in different sites, and could be >> multiple locations within a site). it will lead to unstable >> translation service as routing to the hardcoded prefix can flap and >> the packet to hardcoded prefix can reach a different translation box, >> the other translation box does not have the state info for the >> traffic, and the connection will be killed. >Yes, but the next one will succeed. I think of this as a good property, >as in case of failure, not everything is lost, just current connections. what is the "next one" in your text above? i was not talking about a connection attempt, but an existing TCP connection suddenly shut down by routing changes. >> existing NAT-PT product (like from Yokogawa) is much more robust than >> what you are proposing. >Nice commercial advertizing. what's wrong with you? what is wrong in stating the state of the implementation exist in the real world? just to be clear, i have no commercial relationship whatsoever with yokogawa. if i see you mention any name of product in the future discussion, everyone will know how your way of discussion is unfair. >> DNS-ALG box and NAT-PT translation box are separate. each of the >> NAT-PT translation box T1, T2, ... Tn are configured with certain >> (seaprate) IPv6 prefixes for each, P1, P2, .. Pn. DNS-ALG box >> monitors which NAT-PT translation boxes are alive. DNS-ALG will return >> fabricated AAAA response (for actual A response from the outside DNS >> authoritative server) using prefix Pi, when Ti is alive (it does not >> return AAAA with Pj if Tj is dead). >So what happens if a host has started a communication using Pi/Ti >and Ti goes down? The communication dies and each subsequent >communications to the same destination fail until the DNS >cache on the host is flushed. This is a much worse failure mode >than the one discussed above. yes, if Ti goes down, connections that went through Ti will go down. however, many of the host resolver implementation do not cache DNS responses (luckily for translators, unluckily for DNS), so the next connection attempt will use something other than Ti. if you attack NAT-PT on this point, your proposal must have no state at all in your translation boxes. from seeing NAT64 proposal i don't think it true. if you are not talking about NAT64, go back to your cube and write a draft, then discuss. >Also very bad, this breaks DNSsec. (i think i have repeated this too many times) when you rely on intermediate device which rewrites your packet, what kind of protection do DNSsec really provide? and when you fabricate address by attaching some hardcoded prefix onto the value returned from DNSsec? with the lack of deployment of DNSsec, and the likelihood of deployment is so low, i don't think your popular claim "it breaks DNSsec" is realistic. itojun From owner-v6ops@ops.ietf.org Fri Dec 20 08:29:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26867 for ; Fri, 20 Dec 2002 08:29:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PNED-000FMr-00 for v6ops-data@psg.com; Fri, 20 Dec 2002 05:30:13 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18PNE9-000FMb-00 for v6ops@ops.ietf.org; Fri, 20 Dec 2002 05:30:09 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBKDTL025945 for ; Fri, 20 Dec 2002 15:29:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 20 Dec 2002 15:29:38 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Dec 2002 15:29:36 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Summary on comments on "3GPP analysis" doc so far (since December 10th) Date: Fri, 20 Dec 2002 15:29:35 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3663@esebe005.ntc.nokia.com> Thread-Topic: Summary on comments on "3GPP analysis" doc so far (since December 10th) Thread-Index: AcKoK9Z2g8wU1EeKR1ypqTBOXr6JDA== From: To: Cc: , , , , , , , X-OriginalArrivalTime: 20 Dec 2002 13:29:36.0838 (UTC) FILETIME=[D7437E60:01C2A82B] X-Spam-Status: No, hits=1.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01,SUBJECT_MONTH, SUBJECT_MONTH_2,SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA26867 Hi all! I have tried to collect a summary on the discussion on "3GPP analysis" document so far. ---------------------- 1) Thakur The na(p)t-pt issues (magnified in a 3gpp network) exist anywhere and everywhere when deployment of v6 gathers momentum, solution to nat-pt (dns alg) problems must be found. 2) Thakur Not sure if manually configured tunnels provide a good solution in the years to come. Worries how to manage a great number of manually configured tunnels => The selection of the tunneling mechanism is up to the operator/ISP deployment scenario and we can only give generic recommendations in our draft. A basic question is how many tunnels we need to set up - if the number is not so big, it is no problem setting up manually configured tunnels in the network. It is good to remember that use of automatic tunneling (e.g. 6to4) in very big networks is not trouble-free either. => Some edits in the text may be needed 3) Thakur Recommends (as in 3.4) the usage of application proxies, when possible. => Use of application proxies (when possible) is not a bad idea at all. But in the cases like IMS scenario 1 we need also IP level protocol translation. 4) Thakur Worries that all tunneling / translation mechanisms in existence today are far from perfect. We need to find a transition mechanism that scales well, is usable whether there are small islands of v6 in a v4 ocean or vice-versa, and preferably can be implemented in all or at least most of the scenarios mentioned in this draft. => One main goal in this exercise is to see what existing tr. mechanisms are usable for 3GPP scenarios and document any gaps. Pointing out possible problems in the existing mechanisms also includes in this work. However, we are *not* going to specify any new mechanisms. We don't need just one or two mechanisms that would fit in all cases, but it would be nice to have a compact set of solutions (let's call it transition toolbox) that the operators can deploy IPv6. 5) Thakur DNS functionality related questions (especially name space fragmentation in GPRS scenario 2) => comment from Jasminko Mulahusic: This is not an issue as long as you have a continuous name space. If someone is deploying ipv6-only networks, it doesn't automatically mean the name space is fragmented. => Brian Carpenter: AAAA records travel just fine over an IPv4 network 6) Thakur Usage of IPv4 PDP context instead of IPv6 PDP context (by the dual stack UE) in the case the network and the peer node is IPv4. => Not an issue, v4 / v6 PDP contexts can be flexibly used in 3GPP networks based on application needs, availability of public IPv4 addresses is a problem. 7) Beloeil Using dual stack solution to solve IMS scenario 1 => This is not feasible solution according to current 3GPP specifications stating that *IMS is IPv6-only*. - IMS is an extensive concept; when saying that IMS is "exclusively IPv6", it is a valid statement for all elements that are connected to the IMS / considered to be a part of the IMS. Both signalling and user data traffic belong to the IMS. E.g. the connections between two IMS UEs belong to the IMS. Connections can only be IPv6, not IPv4 and not IPv4 & IPv6 simultaneously. - Tunneling traffic (IPv4 in IPv6) through the IMS and IPv4 connection from the IMS UE to the IPv4 correspondent node is not a feasible solution for this problem. 8) Beloeil Static tunnels become quickly boring. Would prefer a 6to4-based solution (however, the security issues are remaining). => Static tunneling makes sense when the number of tunnels can be kept limited. 9) Savola Comments on separating internal / external cases => Based on the discussion it was agreed to more clearly separate "inside the operator's network" and "outside the operator's network" cases in the next revision! This is valid (at least) for GPRS scenario 2. 10) Savola Operator backbone IPv6 deployment status (how much IPv6 is already deployed today?) => Many GPRS operators already have IPv4 backbone networks (gradually migrating them while introducing IPv6 islands). And native v6 backbones are quite rare in the first phases of the transition. => Discussion on the actual deployment status continues and maybe some clarifying text is needed in the scenarios or analysis document 11) Savola Applicability of [BGP] / [IGP] tunneling (scalability issues; applicable for smaller-than-Internet scopes - not applicable when making connections over the Internet). Basic recommendation for the GPRS scenario 2 is to use a couple of configured tunnels. => can be applicable for 'inside the operator's network' case / for the cases when operator's backbone is based on IPv4. => some more text / a bit clearer applicability statement is needed => Karim El-Malki: Applicability of those mechanisms depends on the exact deployment and operator requirements so we can only make recommendations. I think it is correct to recommend static or EGP/IGP mechanisms if the operator wants to connect its v6 islands over v4. 12) Savola What parts of the transition is done by the ISPs and what is done by 3GPP operators. How many ISP functions does the 3GPP operator wants to perform (indeed, believes that most of them are ISP's of some sort themselves) => add some clarifying text on the environment 13) Savola Max 10-15 isolated IPv6 islands (to be connected using configured tunnels) in the 3GPP operator's network should be sufficient (~ reaching one limit where in some cases configured tunneling could become more difficult to maintain). 14) Laloux [BGP] defines 2 different deployment options: the first one assumes MP-BGP implementation over IPv4, while the second one assumes MP-BGP implementation over IPv6, thus needing to rely on some existing tunneling technique (as you mentioned before). We could just consider the first approach, avoiding the need for any additional tunneling mechanisms. 15) Thakur The transition scenarios are not 3gpp specific, but extra issues and points arise in the 3gpp case: the presence of an extraordinary number of mobile nodes accessing the Internet and blowing up of NAT-PT / DNS ALG issues. 16) Savola The long paragraph in chapter 3.2 should be split in about 5. --------------- I will return to this discussion in January and compose revision -01 of the 3GPP Analysis doc around January 20th. Merry x'mas & a happy new IPv6 year 2003! Best Regards, -Juha W.- From owner-v6ops@ops.ietf.org Fri Dec 20 08:52:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27245 for ; Fri, 20 Dec 2002 08:52:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PNbz-000G4A-00 for v6ops-data@psg.com; Fri, 20 Dec 2002 05:54:47 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18PNbw-000G3x-00 for v6ops@ops.ietf.org; Fri, 20 Dec 2002 05:54:44 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBKDsPQ07517; Fri, 20 Dec 2002 15:54:25 +0200 Date: Fri, 20 Dec 2002 15:54:25 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (EAB)" cc: "'juha.wiljakka@nokia.com '" , "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" Subject: RE: FW: 3gpp scenario 2 In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA2881F@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Dec 2002, Karim El-Malki (EAB) wrote: > > Many run routing protocols on top of configured tunnels, > > thus there is no > > problem you describe. > > Don't think this is something we should recommend. > It would likely mean running a routing protocol to advertise the IPv4 > tunnel endpoint address and a v6 routing protocol within the tunnel to > advertise the v6 routes. I don't see anything particularly bad about this; after all, it's a temporary thing only (but if your underlying infrastructure is completely backed up at the IPv4 layer, most wouldn't need to run v6 routing protocols, of course). People are doing much, much nastier things with routing protocols (consider e.g. MPLS/BGP VPN's carrying IGP routes). > If we can run something like MP-BGP over v4 > isn't that better? If that requires additional infrastructure, like upgrading your routers to support the extension, configure full BGP mesh of peerings between all the islands, or the like -- perhaps not. But I'm not completely opposed to the idea: if, for some reason I couldn't fathom, the operator was running MPLS core network, MP-BGP over v4 just _might_ be a good solution if the number of the islands is high. But I don't believe we should be designing to cope with every possible cornercase (whether this is one is another question) -- then we'd get nothing done, and would end up requiring all kinds of transition mechanisms -- I *don't* want, based on 3GPP analysis, that we end up requiring standardization of [BGP] or [IGP] because there's some perceived need for deployment. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Dec 20 10:04:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28819 for ; Fri, 20 Dec 2002 10:04:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18POj3-000IPc-00 for v6ops-data@psg.com; Fri, 20 Dec 2002 07:06:09 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18POj0-000IPQ-00 for v6ops@ops.ietf.org; Fri, 20 Dec 2002 07:06:06 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBKF5sKY028949; Fri, 20 Dec 2002 16:05:54 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Dec 2002 16:05:54 +0100 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28824@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" Cc: "'juha.wiljakka@nokia.com '" , "'luc.beloeil@rd.francetelecom.com '" , "'Anand.Thakur@hpsglobal.com '" , "'v6ops@ops.ietf.org '" , "'alain.durand@sun.com '" Subject: RE: FW: 3gpp scenario 2 Date: Fri, 20 Dec 2002 16:01:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > If we can run something like MP-BGP over v4 > > isn't that better? > > If that requires additional infrastructure, like upgrading > your routers to > support the extension, configure full BGP mesh of peerings > between all the > islands, or the like -- perhaps not. It depends on the network of course. If you already have a fully-meshed BGP network then you could introduce new ipv6 islands with dual-stack edge routers and have them talk MP-BGP. You'd introduce the same infrastructure as if you were running configured tunnels. > > But I'm not completely opposed to the idea: if, for some > reason I couldn't > fathom, the operator was running MPLS core network, MP-BGP > over v4 just > _might_ be a good solution if the number of the islands is high. I only used MP-BGP over v4 as an example of v6 route advertisement. I was in no way meaning to focus on the MPLS solution. Any tunnelling mechanism can be used. > > But I don't believe we should be designing to cope with > every possible > cornercase (whether this is one is another question) -- then > we'd get > nothing done, and would end up requiring all kinds of transition > mechanisms -- I *don't* want, based on 3GPP analysis, that we end up > requiring standardization of [BGP] or [IGP] because there's some > perceived need for deployment. If we're recommending too many mechanisms I would agree, but we're only recommending two mechanisms: static configured and EGP/IGP. I think that's a good balance for now and it gives implementers and network designers some direction but also some flexibility. From my experience in mobile network design I think a set of tools for different scenarios is what is needed rather than a single option. /Karim From owner-v6ops@ops.ietf.org Fri Dec 20 14:12:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06841 for ; Fri, 20 Dec 2002 14:12:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PSbP-0002Ir-00 for v6ops-data@psg.com; Fri, 20 Dec 2002 11:14:31 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18PSbL-0002IW-00 for v6ops@ops.ietf.org; Fri, 20 Dec 2002 11:14:27 -0800 Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26659 for ; Fri, 20 Dec 2002 12:14:26 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H7F00H27MS291@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 20 Dec 2002 12:14:26 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H7F00C86MS12E@mail.sun.net> for v6ops@ops.ietf.org; Fri, 20 Dec 2002 12:14:26 -0700 (MST) Date: Fri, 20 Dec 2002 11:14:25 -0800 From: Alain Durand Subject: Re: on NAT-PT To: itojun@iijlab.net Cc: v6ops@ops.ietf.org Message-id: <3E036C11.2010606@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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.0.1) Gecko/20020920 Netscape/7.0 References: <20021220002905.08F414B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_03_05,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT itojun@iijlab.net wrote: >>> the failure mode with your proposal is a disaster. what happens if >>> your site do not provide IPv6-to-IPv4 translation with the hardcoded >>> prefix? your IPv6-only machine will try to connect to non-existent >>> prefix, and the packet will travel to somewhere unknown. >>> >>> >>This prefix would have to be non globally routable >>and should be filtered out at site boundary to avoid this issue. >>This is not something catastrophic. >>Actually, this is very similar to what you, Dave Thaler and I are proposing >>for DNS stub resolver configuration. >> >> > > with DNS stub resolver configuration, only DNS resolver will be > affected. > And all application that rely on DNS... regardless of the destination. > what you are proposing here will affect every application > that use DNS resolver (since the DNS resolver attaches magic prefix > to all the responsees from DNS). there's big difference. > It only affecst v6-only applications on v6-only nodes that want to sent packet to v4-only nodes. Regular communication with IPv6 hosts is not affected. >>> and with your plan, it seems that you are planning to reuse the same >>> prefix in multiple locations (at least in different sites, and could be >>> multiple locations within a site). it will lead to unstable >>> translation service as routing to the hardcoded prefix can flap and >>> the packet to hardcoded prefix can reach a different translation box, >>> the other translation box does not have the state info for the >>> traffic, and the connection will be killed. >>> >>> >>Yes, but the next one will succeed. I think of this as a good property, >>as in case of failure, not everything is lost, just current connections. >> >> > > what is the "next one" in your text above? i was not talking about > a connection attempt, but an existing TCP connection suddenly shut down > by routing changes. > I think we are concerned about different things. You express concerns about maintening an existing connection in the event of a NAT box failure, I'm concerned about mainteting 'usability of the Internet' in the event of this failure. Many connections in the Internet are short lived or can be easily restarted. Example: in typical Web browsing usage, connections are very short. To load a particular page, usually there are several connections happening under the hood. If one fails, that's no big deal, maibe a picture or an icon will not display and the user will do 'refresh'. If we can make sure that when the user does 'refresh', this new connection actually works, I think we would have achieved a reasonable level of reliability. >>> DNS-ALG box and NAT-PT translation box are separate. each of the >>> NAT-PT translation box T1, T2, ... Tn are configured with certain >>> (seaprate) IPv6 prefixes for each, P1, P2, .. Pn. DNS-ALG box >>> monitors which NAT-PT translation boxes are alive. DNS-ALG will return >>> fabricated AAAA response (for actual A response from the outside DNS >>> authoritative server) using prefix Pi, when Ti is alive (it does not >>> return AAAA with Pj if Tj is dead). >>> >>> >>So what happens if a host has started a communication using Pi/Ti >>and Ti goes down? The communication dies and each subsequent >>communications to the same destination fail until the DNS >>cache on the host is flushed. This is a much worse failure mode >>than the one discussed above. >> >> > > yes, if Ti goes down, connections that went through Ti will go down. > however, many of the host resolver implementation do not cache DNS > responses (luckily for translators, unluckily for DNS), so the next > connection attempt will use something other than Ti. > This is not true for every implementation. In particular, ours does cache. I do not think it is a good think to build a protocol based on the assumption that DNS stub resolvers are stupid and do not cache. > if you attack NAT-PT on this point, your proposal must have no state > at all in your translation boxes. > I disagree. Re-read my paragraph about web browsing. Stateless is always better, but if we need to introduce state, we have to make sure that we mimimalized the impact in case of problem. NAT-PT DNS-alg as you describe introduces state in the stub resolver on a per-name resolution basis. Even if the stun resolver does not cache, the application that ask for the resolution may very well do. Using a well know prefix (a la NAT64, but not necessarily ::ffff:0:0) put state in the NAT box on a per-connection basis. If the box fails, current connections are trashed, but new ones can be routed to a new box. >>Also very bad, this breaks DNSsec. >> >> > > (i think i have repeated this too many times) > I repeat it because it is true. > when you rely on intermediate device which rewrites your packet, > what kind of protection do DNSsec really provide? > Using NAT-PT DNS ALG, the node does not know it is using NAT, so it cannot differentiate DNSsec does not work because I'm behind NAT-PT from DNSsec tells me something fishy happened. Remember, DNSsec will still work fine for 'regular' IPv6 name to address translation for regular IPv6 addresses. > and when you > fabricate address by attaching some hardcoded prefix onto the value > returned from DNSsec? > DNSsec signature can still be checked in the stub resolver before the wkn prefix is attached. > with the lack of deployment of DNSsec, and the likelihood of > deployment is so low, i don't think your popular claim "it breaks > DNSsec" is realistic. > > How can you make such a public statement! How can you say publically we are deploying IPv6 and do not care about DNSsec! This makes no sense to me... - Alain. From owner-v6ops@ops.ietf.org Mon Dec 23 09:38:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04280 for ; Mon, 23 Dec 2002 09:38:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QTk3-0006sq-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 06:39:39 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18QTjz-0006sW-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 06:39:36 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04129; Mon, 23 Dec 2002 09:36:31 -0500 (EST) Message-Id: <200212231436.JAA04129@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt Date: Mon, 23 Dec 2002 09:36:30 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : Transition Scenarios for 3GPP Networks Author(s) : J. Soininen Filename : draft-ietf-v6ops-3gpp-cases-01.txt Pages : 10 Date : 2002-12-23 This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope of this document. The purpose of the document is to list the scenarios for further discussion and study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-cases-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-cases-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2002-12-23094600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-cases-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-cases-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-23094600.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 23 10:25:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06587 for ; Mon, 23 Dec 2002 10:25:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QUUm-000991-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 07:27:56 -0800 Received: from [211.45.79.102] (helo=jupiter.jmi.co.kr) by psg.com with smtp (Exim 3.36 #2) id 18QUUj-00098d-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 07:27:53 -0800 Received: (qmail 15620 invoked by uid 525); 24 Dec 2002 00:28:53 +0900 Received: (qmail 15596 invoked from network); 24 Dec 2002 00:28:51 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 24 Dec 2002 00:28:51 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id AAA29900 for ; Tue, 24 Dec 2002 00:31:59 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QTp6-0003qx-00 for ietf-announce-list@ran.ietf.org; Mon, 23 Dec 2002 09:44:52 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QTlY-0003i9-00 for all-ietf@ran.ietf.org; Mon, 23 Dec 2002 09:41:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04129; Mon, 23 Dec 2002 09:36:31 -0500 (EST) Message-Id: <200212231436.JAA04129@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@dreamwiz.com Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt Date: Mon, 23 Dec 2002 09:36:30 -0500 X-Spam-Status: No, hits=4.0 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: **** 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 : Transition Scenarios for 3GPP Networks Author(s) : J. Soininen Filename : draft-ietf-v6ops-3gpp-cases-01.txt Pages : 10 Date : 2002-12-23 This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope of this document. The purpose of the document is to list the scenarios for further discussion and study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-cases-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-cases-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2002-12-23094600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-cases-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-cases-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-23094600.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 23 11:18:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08106 for ; Mon, 23 Dec 2002 11:18:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QVKG-000BRq-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 08:21:08 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18QVK9-000BRV-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 08:21:01 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBNGKvG10782 for ; Mon, 23 Dec 2002 18:20:58 +0200 Date: Mon, 23 Dec 2002 18:20:57 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt In-Reply-To: <200212231436.JAA04129@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 23 Dec 2002 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Transition Scenarios for 3GPP Networks > Author(s) : J. Soininen > Filename : draft-ietf-v6ops-3gpp-cases-01.txt > Pages : 10 > Date : 2002-12-23 As the changes were very minor, I'm assuming this is to go to W.G. last call soonish. I'd check it against ID-nits, e.g. the references need to be split up or categorized. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Dec 23 19:12:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17970 for ; Mon, 23 Dec 2002 19:12:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Qci0-000EQG-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 16:14:08 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18Qchx-000ELQ-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 16:14:05 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA06540; Mon, 23 Dec 2002 16:12:54 -0800 (PST) Message-Id: <5.1.0.14.2.20021223190612.049d1c40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Dec 2002 19:12:33 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Request to Publish ISATAP Cc: itojun@iijlab.net, Bob Fink , Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.5 required=5.0 tests=MAILTO_TO_SPAM_ADDR,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, On December 13th, the OPS and Internet area directors received a request to sponsor ISATAP as a standards track RFC, obsoleting the automatic tunneling mechanism specified in RFC 2893 (see attached). ISATAP would be submitted to the RFC editor for publication as an individual submission. Since that time, ISATAP has been updated. The newest version can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-08.txt Consistent with IESG policy, our area director has asked the chairs of the v6ops WG whether the publication of this document would constitute an end-run around the v6ops WG. The v6ops chairs do believe that the publication of this document would represent an end-run for two reasons: (1) It is proposed that ISATAP would obsolete a portion of RFC 2893. The v6ops WG is currently updating RFC 2893, and it will be our decision whether or not to remove the automatic tunneling mechanism. ISATAP does not, and should not, obsolete that mechanism. (2) The v6ops WG is currently undergoing a process to enumerate and analyze the expected scenarios for IPv4 -> IPv4/IPv6 transition, with the goal of producing a single, coordinated set of transition mechanisms, each of which will include appropriate applicability information. The publication of a transition mechanism via another track, before its applicability is analyzed, would undermine this effort. The v6ops chairs will be expressing this opinion to the IESG in one week. We wanted the WG to be aware of this situation, and we would welcome your feedback regarding our position. Thanks, Margaret and Itojun v6ops Chairs --- From: Fred Templin To: randy@psg.com, bwijnen@lucent.com, narten@us.ibm.com, erik.nordmark@sun.com Cc: harald@alvestrand.no, tgleeson@cisco.com, mohitt@microsoft.com, dthaler@microsoft.com, osprey67@yahoo.com Subject: Plea to ADs to sponsor isatap-07 for standards track Date: Fri, 13 Dec 2002 21:32:48 -0800 (PST) To the Operations & Management, and Internet Area Directors, Today (12/13/02), 'draft-ietf-ngtrans-isatap-07.txt' was submitted to the Internet Draft registrar. The document is available for immediate perusal at: http://www.geocities.com/osprey67/isatap-07.txt In the spirit of Harald Alvestrand's 11/19/02 message to v6ops entitled "On NGTRANS, transition mechanisms and consortia", I am issuing a plea to the ADs to sponsor this document for standards track based on the obvious merit that it obsoletes the automatic tunneling mechanisms specified in RFC 2893. I look forward to receiving your feedback and guidance in this matter, Sincerely, Fred L. Templin osprey67@yahoo.com From owner-v6ops@ops.ietf.org Mon Dec 23 20:41:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18876 for ; Mon, 23 Dec 2002 20:41:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Qe5o-000MeM-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 17:42:48 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #2) id 18Qe5l-000MdU-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 17:42:45 -0800 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 23 Dec 2002 17:42:13 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 23 Dec 2002 17:42:12 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Dec 2002 17:42:12 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 23 Dec 2002 17:42:12 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 23 Dec 2002 17:42:12 -0800 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.3710.0); Mon, 23 Dec 2002 17:42:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: Request to Publish ISATAP Date: Mon, 23 Dec 2002 17:42:11 -0800 Message-ID: Thread-Topic: RE: Request to Publish ISATAP Thread-Index: AcKq7a53O7gAtV1aSCCJmMZkNgXbMQ== From: "Christian Huitema" To: "Margaret Wasserman" , Cc: , "Bob Fink" , "Randy Bush" X-OriginalArrivalTime: 24 Dec 2002 01:42:02.0030 (UTC) FILETIME=[A7E0E4E0:01C2AAED] X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_FONT_COLOR_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2AAED.AD8425F7" ------_=_NextPart_001_01C2AAED.AD8425F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Margaret, Itojun,=20 =20 I am a bit puzzled by some elements of your response. =20 > The v6ops chairs do believe that the publication of this > document would represent an end-run for two reasons: >=20 > (1) It is proposed that ISATAP would obsolete a portion > of RFC 2893. The v6ops WG is currently updating > RFC 2893, and it will be our decision whether or > not to remove the automatic tunneling mechanism. > ISATAP does not, and should not, obsolete that > mechanism. =20 I re-read the ISATAP draft, and I am at a loss with this comment. The draft cites 2893 as it goes on using the 2893 nomenclature, but I don't see where it actually proposes to obsolete either 2893, or mechanisms defined in 2893. In any case, the proposition was for an experimental publication; experiments come and go, and certainly do not obsolete standard track recommendations. =20 > (2) The v6ops WG is currently undergoing a process > to enumerate and analyze the expected scenarios > for IPv4 -> IPv4/IPv6 transition, with the > goal of producing a single, coordinated set > of transition mechanisms, each of which will > include appropriate applicability information. > The publication of a transition mechanism via > another track, before its applicability is > analyzed, would undermine this effort. =20 I think that there ought to be a different bar for experimental and standard tracks presentation. The standard track document is something we recommend, a solution that we believe is well engineered. An experimental RFC does not convey an endorsement; it is more a license to, well, experiment. Judging an experimental RFC by how it fits with the overall grand plan of the working group defeats the whole concept of experimental RFC, which may well precisely be to experiment outside of this consensus. =20 This does not mean that we should just say yes. It should just mean that the bar should be different. Not, "does it fit with our plans?" But rather, "If this experiment was conducted, would it hurt the Internet?" For example, it would be quite reasonable, even necessary, to refuse publication of a protocol if its security holes would endanger its users, or even worse other Internet users. It would also be necessary and reasonable to refuse publication of a protocol that would cause or aggravate network congestion. =20 If the working group wants to refuse the publication of ISATAP, it should do so on technical grounds, because the mechanism would be somehow dangerous, not because it does not fit in the plan. The "does not fit" comment would rather belong to some kind of application statement. And, there is indeed always the possibility to have a standard track RFC obsolete a previous experiment.=20 =20 > The v6ops chairs will be expressing this opinion to the IESG > in one week. We wanted the WG to be aware of this situation, > and we would welcome your feedback regarding our position. =20 I would very much like this position to be reconsidered. =20 -- Christian Huitema =20 ------_=_NextPart_001_01C2AAED.AD8425F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Margaret, Itojun,

 

I am a bit puzzled by some elements of your = response.

 

> The v6ops chairs do believe that the publication of = this

> document would represent an end-run for two = reasons:

>

>     (1) It is proposed that ISATAP would = obsolete a portion

>           of = RFC 2893.  The v6ops WG is currently updating

>           RFC = 2893, and it will be our decision whether or

>           not = to remove the automatic tunneling mechanism.

>           = ISATAP does not, and should not, obsolete that

>           = mechanism.

 

I re-read the ISATAP draft, and I = am at a loss with this comment. The draft cites 2893 as it goes on using the = 2893 nomenclature, but I don't see where it actually proposes to obsolete either 2893, or mechanisms defined in 2893. In any case, the proposition was for an experimental publication; experiments come and go, and certainly do not obsolete standard track recommendations.

 

>     (2) The v6ops WG is currently undergoing = a process

>           to = enumerate and analyze the expected scenarios

>           for = IPv4 -> IPv4/IPv6 transition, with the

>           goal = of producing a single, coordinated set

>           of = transition mechanisms, each of which will

>           = include appropriate applicability information.

>           The = publication of a transition mechanism via

>           = another track, before its applicability is

>           = analyzed, would undermine this effort.

 

I think that there ought to be a = different bar for experimental and standard tracks presentation. The standard = track document is something we recommend, a solution that we believe is well engineered. An experimental RFC does not convey an endorsement; it is = more a license to, well, experiment. Judging an experimental RFC by how it fits = with the overall grand plan of the working group defeats the whole concept of experimental RFC, which may well precisely be to experiment outside of = this consensus.

 

This does not mean that we should = just say yes. It should just mean that the bar should be different. Not, = "does it fit with our plans?" But rather, "If this experiment was = conducted, would it hurt the Internet?" For example, it would be quite = reasonable, even necessary, to refuse publication of a protocol if its security = holes would endanger its users, or even worse other Internet users. It would also be necessary and reasonable to refuse publication of a protocol that would = cause or aggravate network congestion.

 

If the working group wants to = refuse the publication of ISATAP, it should do so on technical grounds, because the mechanism would be somehow dangerous, not because it does not fit in the = plan. The “does not fit” comment would rather belong to some kind = of application statement. And, there is indeed always the possibility to = have a standard track RFC obsolete a previous experiment.

 

> The v6ops chairs will be expressing this opinion to the = IESG

> in one week.  We wanted the WG to be aware of this = situation,

> and we would welcome your feedback regarding our = position.

 

I would very much like this position to be = reconsidered.

 

-- Christian Huitema

 

=00 ------_=_NextPart_001_01C2AAED.AD8425F7-- --------------InterScan_NT_MIME_Boundary-- From owner-v6ops@ops.ietf.org Mon Dec 23 20:46:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19095 for ; Mon, 23 Dec 2002 20:46:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QeBz-000NZr-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 17:49:11 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18QeBw-000NZa-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 17:49:08 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 50AD44B27; Tue, 24 Dec 2002 10:49:06 +0900 (JST) To: "Christian Huitema" Cc: "Margaret Wasserman" , v6ops@ops.ietf.org, "Bob Fink" , "Randy Bush" In-reply-to: huitema's message of Mon, 23 Dec 2002 17:42:11 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Request to Publish ISATAP From: itojun@iijlab.net Date: Tue, 24 Dec 2002 10:49:06 +0900 Message-Id: <20021224014906.50AD44B27@coconut.itojun.org> X-Spam-Status: No, hits=2.0 required=5.0 tests=IN_REP_TO,MAILTO_TO_SPAM_ADDR,NO_REAL_NAME, SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I re-read the ISATAP draft, and I am at a loss with this comment. The >draft cites 2893 as it goes on using the 2893 nomenclature, but I don't >see where it actually proposes to obsolete either 2893, or mechanisms >defined in 2893. In any case, the proposition was for an experimental >publication; experiments come and go, and certainly do not obsolete >standard track recommendations. to correct your understandings - please see the last part of the previous email Margaret have sent. (the part where an email from Fred is quoted verbatim) - Fred asked to publish it as a standard-track document - he suggested that ISATAP obsoletes automatic tunnelling in RFC2893 (::10.2.2.2). the chairs does not agree with it and there's no consensus in the wg seen from the chairs itojun From: Fred Templin To: randy@psg.com, bwijnen@lucent.com, narten@us.ibm.com, erik.nordmark@sun.com Cc: harald@alvestrand.no, tgleeson@cisco.com, mohitt@microsoft.com, dthaler@microsoft.com, osprey67@yahoo.com Subject: Plea to ADs to sponsor isatap-07 for standards track <---- Date: Fri, 13 Dec 2002 21:32:48 -0800 (PST) (snip) In the spirit of Harald Alvestrand's 11/19/02 message to v6ops entitled "On NGTRANS, transition mechanisms and consortia", I am issuing a plea to the ADs to sponsor this document for standards track based on the obvious merit that it obsoletes the automatic <---- tunneling mechanisms specified in RFC 2893. <---- From owner-v6ops@ops.ietf.org Mon Dec 23 20:47:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19109 for ; Mon, 23 Dec 2002 20:47:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QeCo-000Nfl-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 17:50:02 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18QeCl-000NaP-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 17:49:59 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA00501; Mon, 23 Dec 2002 17:48:42 -0800 (PST) Message-Id: <5.1.0.14.2.20021223204448.0494cde0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Dec 2002 20:48:21 -0500 To: "Christian Huitema" From: Margaret Wasserman Subject: RE: Request to Publish ISATAP Cc: , , "Bob Fink" , "Randy Bush" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Christian, >I re-read the ISATAP draft, and I am at a loss with this comment. The >draft cites 2893 as it goes on using the 2893 nomenclature, but I don't >see where it actually proposes to obsolete either 2893, or mechanisms >defined in 2893. In any case, the proposition was for an experimental >publication; experiments come and go, and certainly do not obsolete >standard track recommendations. If you read the proposal for publication, which I included at the bottom of the message, it says: "In the spirit of Harald Alvestrand's 11/19/02 message to v6ops entitled "On NGTRANS, transition mechanisms and consortia", I am issuing a plea to the ADs to sponsor this document for standards track based on the obvious merit that it obsoletes the automatic tunneling mechanisms specified in RFC 2893." Please note that it request "standards track" publication and claims that the document obsoletes the "automatic tunneling mechanisms specified in RFC 2893". Does this change your opinion of our position? Margaret From owner-v6ops@ops.ietf.org Mon Dec 23 21:10:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19513 for ; Mon, 23 Dec 2002 21:10:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QeZA-00009g-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 18:13:08 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #2) id 18QeZ7-00003p-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 18:13:05 -0800 Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 23 Dec 2002 18:12:34 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 23 Dec 2002 18:12:34 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Dec 2002 18:12:34 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Mon, 23 Dec 2002 18:12:33 -0800 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(5.0.2195.5600); Mon, 23 Dec 2002 18:12:33 -0800 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.3710.0); Mon, 23 Dec 2002 18:12:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request to Publish ISATAP Date: Mon, 23 Dec 2002 18:12:32 -0800 Message-ID: Thread-Topic: Request to Publish ISATAP Thread-Index: AcKq7rDzvvsdzmitQTi5nJALhJQncgAAcU1g From: "Christian Huitema" To: Cc: "Margaret Wasserman" , , "Bob Fink" , "Randy Bush" X-OriginalArrivalTime: 24 Dec 2002 02:12:19.0472 (UTC) FILETIME=[E3288900:01C2AAF1] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA19513 > >I re-read the ISATAP draft, and I am at a loss with this comment. The > >draft cites 2893 as it goes on using the 2893 nomenclature, but I don't > >see where it actually proposes to obsolete either 2893, or mechanisms > >defined in 2893. In any case, the proposition was for an experimental > >publication; experiments come and go, and certainly do not obsolete > >standard track recommendations. > > to correct your understandings - > please see the last part of the previous email Margaret have sent. > (the part where an email from Fred is quoted verbatim) > > - Fred asked to publish it as a standard-track document > - he suggested that ISATAP obsoletes automatic tunnelling in RFC2893 > (::10.2.2.2). the chairs does not agree with it and there's no > consensus in the wg seen from the chairs I must say that I oversaw Fred's request for standard track. I was confused by the reference to Harald's communication, which was explicitly about experimental RFC. Shame on me! I agree that the only side-channel should be for publication as experimental, not standard track; I also agree that experimental documents should not attempt to obsolete or modify the content of standards. I think that the WG should OK experimental publication of ISATAP, because it will freeze the draft, which would actually help experimenting. As I wrote in the previous message, we can always publish a standard track document later. -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Dec 23 21:23:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19640 for ; Mon, 23 Dec 2002 21:23:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QelZ-0001a3-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 18:25:57 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18QelW-0001Y0-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 18:25:54 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D39C64B27; Tue, 24 Dec 2002 11:25:52 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Fri, 20 Dec 2002 11:14:25 PST. <3E036C11.2010606@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Tue, 24 Dec 2002 11:25:52 +0900 Message-Id: <20021224022552.D39C64B27@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk so you don't apologize for attacking me on "product advertisement"? how nice. >> what you are proposing here will affect every application >> that use DNS resolver (since the DNS resolver attaches magic prefix >> to all the responsees from DNS). there's big difference. >It only affecst v6-only applications on v6-only nodes that >want to sent packet to v4-only nodes. Regular communication >with IPv6 hosts is not affected. even though it is for limited scope, what you are proposing is harmful. >>>Yes, but the next one will succeed. I think of this as a good property, >>>as in case of failure, not everything is lost, just current connections. >> what is the "next one" in your text above? i was not talking about >> a connection attempt, but an existing TCP connection suddenly shut down >> by routing changes. >I think we are concerned about different things. >You express concerns about maintening an existing connection >in the event of a NAT box failure, >I'm concerned about mainteting 'usability of the Internet' >in the event of this failure. Many connections in the Internet >are short lived or can be easily restarted. >Example: in typical Web browsing usage, connections are very short. >To load a particular page, usually there are several connections >happening under the hood. If one fails, that's no big deal, >maibe a picture or an icon will not display and the user >will do 'refresh'. If we can make sure that when >the user does 'refresh', this new connection actually >works, I think we would have achieved a reasonable >level of reliability. i'm not convinced at all with your argument on TCP lifetime (that TCP lifetime is short and it is okay to terminate one as people will re-connect). translators cannot make assumptions on TCP lifetime. even if you are proposing it for HTTP-only translators, i object - starting HTTP/1.1 they reuse TCP connection for multiple HTTP requests and you can't assume that the TCP lifetime is short. >> yes, if Ti goes down, connections that went through Ti will go down. >> however, many of the host resolver implementation do not cache DNS >> responses (luckily for translators, unluckily for DNS), so the next >> connection attempt will use something other than Ti. >This is not true for every implementation. In particular, ours does cache. >I do not think it is a good think to build a protocol based on the >assumption that DNS stub resolvers are stupid and do not cache. DNS-ALG can respond with shorter DNS TTL for fabricated responses to minimize the impact to resolvers that perform caches, in case of failure in one of the translator boxes. >> if you attack NAT-PT on this point, your proposal must have no state >> at all in your translation boxes. >> >I disagree. Re-read my paragraph about web browsing. >Stateless is always better, but if we need to introduce state, >we have to make sure that we mimimalized the impact in >case of problem. > >NAT-PT DNS-alg as you describe introduces state >in the stub resolver on a per-name resolution basis. >Even if the stun resolver does not cache, the application >that ask for the resolution may very well do. > >Using a well know prefix (a la NAT64, but not necessarily ::ffff:0:0) >put state in the NAT box on a per-connection basis. >If the box fails, current connections are trashed, but new >ones can be routed to a new box. i disagree with the above. see below. what you are proposing is RSIP. on TCP lifetime discussion, see above (about 40 lines before). >>>Also very bad, this breaks DNSsec. >> (i think i have repeated this too many times) >I repeat it because it is true. >> when you rely on intermediate device which rewrites your packet, >> what kind of protection do DNSsec really provide? >Using NAT-PT DNS ALG, the node does not know it is using >NAT, so it cannot differentiate DNSsec does not work because >I'm behind NAT-PT from DNSsec tells me something fishy >happened. Remember, DNSsec will still work fine for 'regular' >IPv6 name to address translation for regular IPv6 addresses. >> and when you the nodes MUST NOT know that there is a middlebox. never. if the end nodes has to be aware of middleboxes, it's not IP. it's called RSIP. this is why i have been objecting your idea to alter resolver in the end nodes. >> fabricate address by attaching some hardcoded prefix onto the value >> returned from DNSsec? >DNSsec signature can still be checked in the stub resolver >before the wkn prefix is attached. you have been ignoring my comment (i made this comment months ago) to use "AD is secure" for the response from DNS-ALG. >> with the lack of deployment of DNSsec, and the likelihood of >> deployment is so low, i don't think your popular claim "it breaks >> DNSsec" is realistic. >How can you make such a public statement! How can you say publically >we are deploying IPv6 and do not care about DNSsec! >This makes no sense to me... this is a operational group. you need to face the operational reality, instead of acting as an armchair detective. itojun From owner-v6ops@ops.ietf.org Mon Dec 23 21:48:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20231 for ; Mon, 23 Dec 2002 21:48:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Qf91-0004CA-00 for v6ops-data@psg.com; Mon, 23 Dec 2002 18:50:11 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Qf8y-0004Bv-00 for v6ops@ops.ietf.org; Mon, 23 Dec 2002 18:50:08 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 53D024B27; Tue, 24 Dec 2002 11:50:06 +0900 (JST) To: "Christian Huitema" Cc: "Margaret Wasserman" , v6ops@ops.ietf.org, "Bob Fink" , "Randy Bush" In-reply-to: huitema's message of Mon, 23 Dec 2002 17:42:11 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Request to Publish ISATAP From: itojun@iijlab.net Date: Tue, 24 Dec 2002 11:50:06 +0900 Message-Id: <20021224025006.53D024B27@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >If the working group wants to refuse the publication of ISATAP, it >should do so on technical grounds, because the mechanism would be >somehow dangerous, not because it does not fit in the plan. The "does >not fit" comment would rather belong to some kind of application >statement. And, there is indeed always the possibility to have a >standard track RFC obsolete a previous experiment. (chair hat off) sorry for doing it in this late stage (from Fred's view), i see a couple of major technical problem with ISATAP-08 document. in 5.1, the document proposes a different handling of link-layer address option in ND from the normal ND. also in 5.2, the document proposes special handling of router discovery. ND and router discovery have to be link-layer independent, and if we wish to make any changes to ND/autoconf, we must update RFC2461/2462, in link-layer independent manner. in 5.1, paragraph 2, what does "enhanced address resolution" mean? is it documented in ISATAP document? if so, where? it is proposed that router discovery mechanism (near 5.2, find "PRL" for Potential Router List) would use DNS for discovering ISATAP router. it creates circular dependency between link layer (ISATAP) and DNS. the use of DNS must be dropped from the router discovery mechanism. ISATAP router is a choke point wrt scalability of the mechanism (for instance, link speed of ISATAP router would be the bottleneck for all of the nodes in an ISATAP-based site). we might be able to achieve some level of load-balancing using coordinated advertisement of ISATAP router via PRL announcement, however, it is not enough. i can't really parse section 7 paragraph 2. what does it mean? > Appendix B proposes a specification for managing the IEEE OUI > assigned to IANA for EUI-64 interface identifier construction. This > specification is made freely available to IANA for any purpose they > may find useful. (and to re-itereate) ISATAP does not supersede automatic tunnelling in RFC2893. automatic tunnelling does not limit itself to the use within a site (::/96 route won't be there from RFC2772, but anyways, RFC2893 does not limit the domain of usage like ISATAP). there's no equivalent to ISATAP router in auto tunnel. ISATAP and automatic tunnelling are different mechanism, therefore the Plea to AD was technically incorrect. (mech-v2-01 obsoletes automatic tunnelling for different reason - lack of implementation/scaling/usage) itojun From owner-v6ops@ops.ietf.org Tue Dec 24 08:50:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07442 for ; Tue, 24 Dec 2002 08:50:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QpSt-000KPl-00 for v6ops-data@psg.com; Tue, 24 Dec 2002 05:51:23 -0800 Received: from web13005.mail.yahoo.com ([216.136.174.15]) by psg.com with smtp (Exim 3.36 #2) id 18QpSq-000KPU-00 for v6ops@ops.ietf.org; Tue, 24 Dec 2002 05:51:20 -0800 Message-ID: <20021224135119.34800.qmail@web13005.mail.yahoo.com> Received: from [63.197.18.101] by web13005.mail.yahoo.com via HTTP; Tue, 24 Dec 2002 05:51:19 PST Date: Tue, 24 Dec 2002 05:51:19 -0800 (PST) From: Fred Templin Subject: Re: Request to Publish ISATAP To: itojun@iijlab.net, Christian Huitema Cc: Margaret Wasserman , v6ops@ops.ietf.org, Bob Fink , Randy Bush , osprey67@yahoo.com In-Reply-To: <20021224025006.53D024B27@coconut.itojun.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Itojun, Let me first say, it should be clear to all that I am struggling with process details. But, how can *anyone* be expected to get things exactly right when the NGTRANS closing has come upon us so quickly and the closing procedures have been so nebulous? The new charter seems restrictive to the point of requiring authors to leap high buildings just to get their documents recognized - even though some (like ISATAP) have been out in the public discussion for over *two years* now. The chairs have asked for transition scenario documents, and one has been written, presented and revised for ISATAP. I am certain that ISATAP can provide useful benefit to some of the other operational areas as well, and additional scenario documents could be written. But again, how high does an author need to jump to get on your radar screen?? If this document can't go standards track right now, let's at least get it through as experimental so we can prove to the community in due course that further progression is warranted. Now to your questions: --- itojun@iijlab.net wrote: > (chair hat off) > > sorry for doing it in this late stage (from Fred's view), > i see a couple of major technical problem with ISATAP-08 document. > > in 5.1, the document proposes a different handling of link-layer > address option in ND from the normal ND. This is explicitly *allowed* by RFC 2461, section 7.2.2, last paragraph on P. 59. I won't cut-and-paste the tex for the sake of brevity, but the normative text that allows what ISATAP is doing is plain for all to see. > also in 5.2, the document > proposes special handling of router discovery. ND and router discovery > have to be link-layer independent, and if we wish to make any changes > to ND/autoconf, we must update RFC2461/2462, in link-layer independent > manner. Remember; this is an IPv6 over NBMA document. But, in RFC 2461, section 1, we have the following text: However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., NBMA links) alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). Clearly, no updates to RFC2461 are necessary since ISATAP is exactly such "the appropriate document..." as described above. > in 5.1, paragraph 2, what does "enhanced address resolution" mean? > is it documented in ISATAP document? if so, where? This refers to the text exactly one sentence earlier, which says: ISATAP hosts SHOULD enhance the static address resolution computation with a unicast Neighbor Solicitation(NS)/Neighbor Advertisement(NA) So, "simple address resolution" = static computation with no neighbor discovery exchange, and "enhanced address resolution" = static computation plus a unicast NS/NA exchange. How clear do we need to be? > it is proposed that router discovery mechanism (near 5.2, find "PRL" > for Potential Router List) would use DNS for discovering ISATAP router. > it creates circular dependency between link layer (ISATAP) and DNS. > the use of DNS must be dropped from the router discovery mechanism. Yes, DNS is one alternative for discovering the ISATAP router - but not the only one. Even so, the sequence a dual-stack node can use the following bootstrapping procedure: - discover IPv4 address; DNS server - configure the IPv4 stack - wait for a while for native IPv6 RAs to arrive - if no native v6 service: - discover a domain name for the ISATAP service - resolve the name into a list of IPv4 addresses by name service lookup (could be DNS, could be static file, ec.) Can you explain to me a scenario in which this would *not* work? > ISATAP router is a choke point wrt scalability of the mechanism > (for instance, link speed of ISATAP router would be the bottleneck for > all of the nodes in an ISATAP-based site). > we might be able to achieve some level of load-balancing using > coordinated advertisement of ISATAP router via PRL announcement, > however, it is not enough. Talk about unsubsantiated opinions! This statement would have been like the founding architects saying: "packet switching networks can incur congestion in some cases, so let's not even bother building them". Clearly, there is a need for better understanding of ISATAP's scaling properties - but, that's what experiments are for! BTW, my belief is that the ISATAP scaling question is a non-issue. Even if a site administrator felt the need to strategically deploy equipment for fault tolerance, load balancing, etc. the specification provides abundat flexibility to support this. It is left to implementors to create robust products to satisfy the anticipated needs of customers; the ISATAP specification has no business meddling in implementation details. > i can't really parse section 7 paragraph 2. what does it mean? > > Appendix B proposes a specification for managing the IEEE OUI > > assigned to IANA for EUI-64 interface identifier construction. This > > specification is made freely available to IANA for any purpose they > > may find useful. Let me recommend that you give it 1-2 more re-reads, then skip ahead to Appendix B. The meaning is there, and the words (while not optimal) seem adequate to me. If you are still confused, let me assure you this text has absolutely no operational bearing on the rest of the specification. > (and to re-itereate) > ISATAP does not supersede automatic tunnelling in RFC2893. automatic > tunnelling does not limit itself to the use within a site (::/96 route > won't be there from RFC2772, but anyways, RFC2893 does not limit the > domain of usage like ISATAP). there's no equivalent to ISATAP router > in auto tunnel. ISATAP and automatic tunnelling are different > mechanism, therefore the Plea to AD was technically incorrect. > (mech-v2-01 obsoletes automatic tunnelling for different reason - lack > of implementation/scaling/usage) See my above comments on process; I'm sure you can sense my frustration in having been stuck on the outside looking in after all this time of collaborative contribution to the community. Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Tue Dec 24 08:57:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07575 for ; Tue, 24 Dec 2002 08:57:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QpZa-000Ki6-00 for v6ops-data@psg.com; Tue, 24 Dec 2002 05:58:18 -0800 Received: from web13008.mail.yahoo.com ([216.136.174.18]) by psg.com with smtp (Exim 3.36 #2) id 18QpZW-000KhQ-00 for v6ops@ops.ietf.org; Tue, 24 Dec 2002 05:58:14 -0800 Message-ID: <20021224135813.11984.qmail@web13008.mail.yahoo.com> Received: from [63.197.18.101] by web13008.mail.yahoo.com via HTTP; Tue, 24 Dec 2002 05:58:13 PST Date: Tue, 24 Dec 2002 05:58:13 -0800 (PST) From: Fred Templin Subject: Re: Request to Publish ISATAP To: itojun@iijlab.net, Christian Huitema Cc: Margaret Wasserman , v6ops@ops.ietf.org, Bob Fink , Randy Bush , osprey67@yahoo.com In-Reply-To: <20021224025006.53D024B27@coconut.itojun.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Itojun, Let me first say, it should be clear to all that I am struggling with process details. But, how can *anyone* be expected to get things exactly right when the NGTRANS closing has come upon us so quickly and the closing procedures have been so nebulous? The new charter seems restrictive to the point of requiring authors to leap high buildings just to get their documents recognized - even though some (like ISATAP) have been out in the public discussion for over *two years* now. The chairs have asked for transition scenario documents, and one has been written, presented and revised for ISATAP. I am certain that ISATAP can provide useful benefit to some of the other operational areas as well, and additional scenario documents could be written. But again, how high does an author need to jump to get on your radar screen?? If this document can't go standards track right now, let's at least get it through as experimental so we can prove to the community in due course that further progression is warranted. Now to your questions: --- itojun@iijlab.net wrote: > (chair hat off) > > sorry for doing it in this late stage (from Fred's view), > i see a couple of major technical problem with ISATAP-08 document. > > in 5.1, the document proposes a different handling of link-layer > address option in ND from the normal ND. This is explicitly *allowed* by RFC 2461, section 7.2.2, last paragraph on P. 59. I won't cut-and-paste the tex for the sake of brevity, but the normative text that allows what ISATAP is doing is plain for all to see. > also in 5.2, the document > proposes special handling of router discovery. ND and router discovery > have to be link-layer independent, and if we wish to make any changes > to ND/autoconf, we must update RFC2461/2462, in link-layer independent > manner. Remember; this is an IPv6 over NBMA document. But, in RFC 2461, section 1, we have the following text: However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., NBMA links) alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). Clearly, no updates to RFC2461 are necessary since ISATAP is exactly such "the appropriate document..." as described above. > in 5.1, paragraph 2, what does "enhanced address resolution" mean? > is it documented in ISATAP document? if so, where? This refers to the text exactly one sentence earlier, which says: ISATAP hosts SHOULD enhance the static address resolution computation with a unicast Neighbor Solicitation(NS)/Neighbor Advertisement(NA) So, "simple address resolution" = static computation with no neighbor discovery exchange, and "enhanced address resolution" = static computation plus a unicast NS/NA exchange. How clear do we need to be? > it is proposed that router discovery mechanism (near 5.2, find "PRL" > for Potential Router List) would use DNS for discovering ISATAP router. > it creates circular dependency between link layer (ISATAP) and DNS. > the use of DNS must be dropped from the router discovery mechanism. Yes, DNS is one alternative for discovering the ISATAP router - but not the only one. Even so, the sequence a dual-stack node can use the following bootstrapping procedure: - discover IPv4 address; DNS server - configure the IPv4 stack - wait for a while for native IPv6 RAs to arrive - if no native v6 service: - discover a domain name for the ISATAP service - resolve the name into a list of IPv4 addresses by name service lookup (could be DNS, could be static file, ec.) Can you explain to me a scenario in which this would *not* work? > ISATAP router is a choke point wrt scalability of the mechanism > (for instance, link speed of ISATAP router would be the bottleneck for > all of the nodes in an ISATAP-based site). > we might be able to achieve some level of load-balancing using > coordinated advertisement of ISATAP router via PRL announcement, > however, it is not enough. Talk about unsubsantiated opinions! This statement would have been like the founding architects saying: "packet switching networks can incur congestion in some cases, so let's not even bother building them". Clearly, there is a need for better understanding of ISATAP's scaling properties - but, that's what experiments are for! BTW, my belief is that the ISATAP scaling question is a non-issue. Even if a site administrator felt the need to strategically deploy equipment for fault tolerance, load balancing, etc. the specification provides abundat flexibility to support this. It is left to implementors to create robust products to satisfy the anticipated needs of customers; the ISATAP specification has no business meddling in implementation details. > i can't really parse section 7 paragraph 2. what does it mean? > > Appendix B proposes a specification for managing the IEEE OUI > > assigned to IANA for EUI-64 interface identifier construction. This > > specification is made freely available to IANA for any purpose they > > may find useful. Let me recommend that you give it 1-2 more re-reads, then skip ahead to Appendix B. The meaning is there, and the words (while not optimal) seem adequate to me. If you are still confused, let me assure you this text has absolutely no operational bearing on the rest of the specification. > (and to re-itereate) > ISATAP does not supersede automatic tunnelling in RFC2893. automatic > tunnelling does not limit itself to the use within a site (::/96 route > won't be there from RFC2772, but anyways, RFC2893 does not limit the > domain of usage like ISATAP). there's no equivalent to ISATAP router > in auto tunnel. ISATAP and automatic tunnelling are different > mechanism, therefore the Plea to AD was technically incorrect. > (mech-v2-01 obsoletes automatic tunnelling for different reason - lack > of implementation/scaling/usage) See my above comments on process; I'm sure you can sense my frustration in having been stuck on the outside looking in after all this time of collaborative contribution to the community. Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Tue Dec 24 10:44:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08861 for ; Tue, 24 Dec 2002 10:44:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QrCw-000Phh-00 for v6ops-data@psg.com; Tue, 24 Dec 2002 07:43:02 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #2) id 18QrCu-000Ph9-00 for v6ops@ops.ietf.org; Tue, 24 Dec 2002 07:43:00 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4EE20B1F; Tue, 24 Dec 2002 10:42:59 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 24 Dec 2002 10:42:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request to Publish ISATAP Date: Tue, 24 Dec 2002 10:42:58 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034BFD09@tayexc13.americas.cpqcorp.net> Thread-Topic: Request to Publish ISATAP Thread-Index: AcKq4g1cM1bVLiFOR2250Yr+EyloJQAgJt3w From: "Bound, Jim" To: "Margaret Wasserman" , Cc: , "Bob Fink" , "Randy Bush" X-OriginalArrivalTime: 24 Dec 2002 15:42:59.0158 (UTC) FILETIME=[22AB9F60:01C2AB63] X-Spam-Status: No, hits=0.7 required=5.0 tests=MAILTO_TO_SPAM_ADDR,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA08861 Margaret, I concur with Christian Huitema's comments and agree. This work should be moved to Experimental RFC so the code can be solidified and tested. As Christian stated the bar should be far less than standards track. I do not support your mail stating Fred wanted to go to standards track but only experimental. I also did not see anything in draft -08 that alters Neighbor Discovery or our base Transitioin Mechanism for auto-tunnels (which I support being removed). ISATAP is being deployed in the v6 test beds currently and lets get all to do the latest experimental RFC and see what develops. Regards, /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, December 23, 2002 7:13 PM > To: v6ops@ops.ietf.org > Cc: itojun@iijlab.net; Bob Fink; Randy Bush > Subject: Request to Publish ISATAP > > > > Hi All, > > On December 13th, the OPS and Internet area directors > received a request to sponsor ISATAP as a standards track > RFC, obsoleting the automatic tunneling mechanism specified > in RFC 2893 (see attached). ISATAP would be submitted to the > RFC editor for publication as an individual submission. > > Since that time, ISATAP has been updated. The newest version > can be found at: > > http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-08.txt > > Consistent with IESG policy, our area director has asked the > chairs of the v6ops WG whether the publication of this > document would constitute an end-run around the v6ops WG. > > The v6ops chairs do believe that the publication of this > document would represent an end-run for two reasons: > > (1) It is proposed that ISATAP would obsolete a portion > of RFC 2893. The v6ops WG is currently updating > RFC 2893, and it will be our decision whether or > not to remove the automatic tunneling mechanism. > ISATAP does not, and should not, obsolete that > mechanism. > > (2) The v6ops WG is currently undergoing a process > to enumerate and analyze the expected scenarios > for IPv4 -> IPv4/IPv6 transition, with the > goal of producing a single, coordinated set > of transition mechanisms, each of which will > include appropriate applicability information. > The publication of a transition mechanism via > another track, before its applicability is > analyzed, would undermine this effort. > > The v6ops chairs will be expressing this opinion to the IESG > in one week. We wanted the WG to be aware of this situation, > and we would welcome your feedback regarding our position. > > Thanks, > Margaret and Itojun > v6ops Chairs > > --- > > From: Fred Templin > To: randy@psg.com, bwijnen@lucent.com, narten@us.ibm.com, > erik.nordmark@sun.com > Cc: harald@alvestrand.no, tgleeson@cisco.com, mohitt@microsoft.com, > dthaler@microsoft.com, osprey67@yahoo.com > Subject: Plea to ADs to sponsor isatap-07 for standards track > Date: Fri, 13 Dec 2002 21:32:48 -0800 (PST) > > > To the Operations & Management, and Internet Area Directors, > > > Today (12/13/02), 'draft-ietf-ngtrans-isatap-07.txt' was > submitted to the Internet Draft registrar. The document is > available for immediate perusal at: > > http://www.geocities.com/osprey67/isatap-07.txt In the spirit of Harald Alvestrand's 11/19/02 message to v6ops entitled "On NGTRANS, transition mechanisms and consortia", I am issuing a plea to the ADs to sponsor this document for standards track based on the obvious merit that it obsoletes the automatic tunneling mechanisms specified in RFC 2893. I look forward to receiving your feedback and guidance in this matter, Sincerely, Fred L. Templin osprey67@yahoo.com From owner-v6ops@ops.ietf.org Tue Dec 24 10:45:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08887 for ; Tue, 24 Dec 2002 10:45:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QrHs-000Pz6-00 for v6ops-data@psg.com; Tue, 24 Dec 2002 07:48:08 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18QrHp-000PxJ-00 for v6ops@ops.ietf.org; Tue, 24 Dec 2002 07:48:05 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA16704; Tue, 24 Dec 2002 07:46:50 -0800 (PST) Message-Id: <5.1.0.14.2.20021224101921.049e65c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Dec 2002 10:46:26 -0500 To: Fred Templin From: Margaret Wasserman Subject: Re: Request to Publish ISATAP Cc: itojun@iijlab.net, Christian Huitema , v6ops@ops.ietf.org, Bob Fink , Randy Bush , osprey67@yahoo.com In-Reply-To: <20021224135119.34800.qmail@web13005.mail.yahoo.com> References: <20021224025006.53D024B27@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Fred, >Let me first say, it should be clear to all that I am struggling >with process details. But, how can *anyone* be expected to get >things exactly right when the NGTRANS closing has come upon us >so quickly and the closing procedures have been so nebulous? I can certainly understand your frustration, and I think we're all struggling with some of the process details here. Very few of us have been through the shutdown of a WG before, so we are learning the process as we do it. >The new charter seems restrictive to the point of requiring >authors to leap high buildings just to get their documents >recognized - even though some (like ISATAP) have been out in >the public discussion for over *two years* now. I hope it is clear that the restrictiveness of the current v6ops charter is intentional. We are not chartered to publish any new standards track transition mechanisms until we understand the most likely deployment scenarios, and have completed the analysis to determine what transition mechanisms are actually needed. The analysis is well underway for the 3GPP and Unmanaged areas, and the Enterprise and ISP areas are making progress on scenarios. >The chairs have asked for transition scenario documents, and >one has been written, presented and revised for ISATAP. I am >certain that ISATAP can provide useful benefit to some of the >other operational areas as well, and additional scenario documents >could be written. If I recall correctly, these documents were requested by the ngtrans chairs. I think that the ISATAP document, in particular, will provide useful input to the Enterprise design team. If you think that ISATAP is applicable to the scenarios raised in the 3GPP, Unmanaged or ISP documents, you may want to discuss that on the v6ops list or with the authors of those documents. >But again, how high does an author need to jump >to get on your radar screen?? ISATAP is already on the radar screen. We're just not ready to publish any new mechanisms until their applicability is demonstrated by the scenario/analysis work. >If this document can't go standards >track right now, let's at least get it through as experimental >so we can prove to the community in due course that further >progression is warranted. It is outside the scope of the v6ops WG to publish ISATAP as an experimental RFC. However, if you would like to do an individual submission for publication as an experimental RFC, you should first publish your final document, preferably with fixes to address Itojun's issues, as an Internet-Draft. Before you publish it, you should also make sure that it meets the RFC editorial policies, found at: http://www.rfc-editor.org/policy.html Then, send mail to the RFC editor (rfc-editor@rfc-editor.org) requesting that the RFC editor publish your individual submission as an experimental RFC. As part of their usual review process, the RFC editor will ask the IESG if your document represents an end-run around any IETF WGs and/or has any technical issues that should block its publication. At that point, our AD, Randy Bush, will probably come to the v6ops WG chairs and ask us if we have any procedural or technical objections to publishing the document as experimental. At that point, Itojun and I will discuss this amongst ourselves and with the WG, and we will return an answer to the IESG. Let me know if you have any questions about this process. In the meantime, the question on the table is whether ISATAP should be published as a standards track document that obsoletes part of RFC 2893, which we believe it should not. Margaret From owner-v6ops@ops.ietf.org Tue Dec 24 10:52:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08942 for ; Tue, 24 Dec 2002 10:52:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QrN1-0000I4-00 for v6ops-data@psg.com; Tue, 24 Dec 2002 07:53:27 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18QrMx-0000Fj-00 for v6ops@ops.ietf.org; Tue, 24 Dec 2002 07:53:23 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA17673; Tue, 24 Dec 2002 07:52:05 -0800 (PST) Message-Id: <5.1.0.14.2.20021224104709.049cd8f8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Dec 2002 10:51:41 -0500 To: "Bound, Jim" From: Margaret Wasserman Subject: RE: Request to Publish ISATAP Cc: , , "Bob Fink" , "Randy Bush" In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B034BFD09@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,MAILTO_TO_SPAM_ADDR,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, >[...] I >do not support your mail stating Fred wanted to go to standards track >but only experimental. I'm not sure what you mean... In the only request for publication that I have seen, Fred explicitly requested standards track publications, and indicated that the document should obsolete part of RFC 2893. See his message attached below. >ISATAP is being deployed in the v6 test beds currently and lets get all >to do the latest experimental RFC and see what develops. Unfortunately, the v6ops WG is not chartered to publish ISATAP as an experimental RFC. However, I have sent Fred instructions on how to ask the RFC editor to publish his individual submission as an experimental RFC. Margaret >From: Fred Templin >To: randy@psg.com, bwijnen@lucent.com, narten@us.ibm.com, > erik.nordmark@sun.com >Cc: harald@alvestrand.no, tgleeson@cisco.com, mohitt@microsoft.com, > dthaler@microsoft.com, osprey67@yahoo.com >Subject: Plea to ADs to sponsor isatap-07 for standards track >Date: Fri, 13 Dec 2002 21:32:48 -0800 (PST) > >To the Operations & Management, and Internet Area Directors, > >Today (12/13/02), 'draft-ietf-ngtrans-isatap-07.txt' was >submitted to the Internet Draft registrar. The document is >available for immediate perusal at: > > > http://www.geocities.com/osprey67/isatap-07.txt > > >In the spirit of Harald Alvestrand's 11/19/02 message to v6ops entitled >"On NGTRANS, transition mechanisms and consortia", I am issuing a plea >to the ADs to sponsor this document for standards track based on the >obvious merit that it obsoletes the automatic tunneling mechanisms >specified in RFC 2893. > > >I look forward to receiving your feedback and guidance >in this matter, > > >Sincerely, > > >Fred L. Templin >osprey67@yahoo.com From owner-v6ops@ops.ietf.org Tue Dec 24 12:43:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10637 for ; Tue, 24 Dec 2002 12:43:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Qt77-0005kq-00 for v6ops-data@psg.com; Tue, 24 Dec 2002 09:45:09 -0800 Received: from web13002.mail.yahoo.com ([216.136.174.12]) by psg.com with smtp (Exim 3.36 #2) id 18Qt74-0005jO-00 for v6ops@ops.ietf.org; Tue, 24 Dec 2002 09:45:06 -0800 Message-ID: <20021224174506.30322.qmail@web13002.mail.yahoo.com> Received: from [63.67.101.5] by web13002.mail.yahoo.com via HTTP; Tue, 24 Dec 2002 09:45:06 PST Date: Tue, 24 Dec 2002 09:45:06 -0800 (PST) From: Fred Templin Subject: Re: Request to Publish ISATAP To: Margaret Wasserman Cc: itojun@iijlab.net, Christian Huitema , v6ops@ops.ietf.org, Bob Fink , Randy Bush , osprey67@yahoo.com In-Reply-To: <5.1.0.14.2.20021224101921.049e65c0@mail.windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.8 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Margaret, --- Margaret Wasserman wrote: > Let me know if you have any questions about this process. Thanks for the clear explaination. Your note gave a detailed roadmap for publication as experimental RFC which I'm certain can be followed with no further process issues. > In the meantime, the question on the table is whether ISATAP > should be published as a standards track document that > obsoletes part of RFC 2893, which we believe it should not. I respect the v6ops WG chairs' decision on this, and withdraw the question of standards-track publication. Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Tue Dec 24 12:45:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10655 for ; Tue, 24 Dec 2002 12:45:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QtAY-0005zP-00 for v6ops-data@psg.com; Tue, 24 Dec 2002 09:48:42 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18QtAV-0005y8-00 for v6ops@ops.ietf.org; Tue, 24 Dec 2002 09:48:39 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.24]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA10230; Tue, 24 Dec 2002 09:47:24 -0800 (PST) Message-Id: <5.1.0.14.2.20021224124650.049d0008@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Dec 2002 12:46:58 -0500 To: Fred Templin From: Margaret Wasserman Subject: Re: Request to Publish ISATAP Cc: itojun@iijlab.net, Christian Huitema , v6ops@ops.ietf.org, Bob Fink , Randy Bush , osprey67@yahoo.com In-Reply-To: <20021224174506.30322.qmail@web13002.mail.yahoo.com> References: <5.1.0.14.2.20021224101921.049e65c0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.6 required=5.0 tests=IN_REP_TO,MAILTO_TO_SPAM_ADDR,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks, Fred. Margaret At 09:45 AM 12/24/2002 -0800, Fred Templin wrote: >Margaret, > >--- Margaret Wasserman wrote: > > Let me know if you have any questions about this process. > >Thanks for the clear explaination. Your note gave a detailed >roadmap for publication as experimental RFC which I'm certain >can be followed with no further process issues. > > > In the meantime, the question on the table is whether ISATAP > > should be published as a standards track document that > > obsoletes part of RFC 2893, which we believe it should not. > >I respect the v6ops WG chairs' decision on this, and withdraw >the question of standards-track publication. > >Fred Templin >osprey67@yahoo.com > >__________________________________________________ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Tue Dec 24 18:49:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15423 for ; Tue, 24 Dec 2002 18:49:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Qyok-00009t-00 for v6ops-data@psg.com; Tue, 24 Dec 2002 15:50:34 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18QyoN-000088-00 for v6ops@ops.ietf.org; Tue, 24 Dec 2002 15:50:11 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D2E904B25; Wed, 25 Dec 2002 08:50:08 +0900 (JST) To: Fred Templin Cc: Christian Huitema , Margaret Wasserman , v6ops@ops.ietf.org, Bob Fink , Randy Bush In-reply-to: osprey67's message of Tue, 24 Dec 2002 05:58:13 PST. <20021224135813.11984.qmail@web13008.mail.yahoo.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Request to Publish ISATAP From: itojun@iijlab.net Date: Wed, 25 Dec 2002 08:50:08 +0900 Message-Id: <20021224235008.D2E904B25@coconut.itojun.org> X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk on process details, i guess Margaret have answered. >> in 5.1, the document proposes a different handling of link-layer >> address option in ND from the normal ND. >This is explicitly *allowed* by RFC 2461, section 7.2.2, last paragraph >on P. 59. I won't cut-and-paste the tex for the sake of brevity, but the >normative text that allows what ISATAP is doing is plain for all to see. i don't think RFC2461 section 7.2.2 permits modification to link-layer address option handling in ISATAP. it only talks about the intended behavior of a node, like: - if dst = solicited-node multicast address, link-layer address option MUST be present - otherwise, it SHOULD be present - for unicast solicitation an implementation MAY omit it ISATAP, on the other hand, defines a new handling rule for link-layer address option in the very last paragraph of 5.1. it does not seem to me a permissible thing to do. >> also in 5.2, the document >> proposes special handling of router discovery. ND and router discovery >> have to be link-layer independent, and if we wish to make any changes >> to ND/autoconf, we must update RFC2461/2462, in link-layer independent >> manner. >Remember; this is an IPv6 over NBMA document. But, in RFC 2461, section 1, >we have the following text: > However, because ND uses link-layer multicast for some of its > services, it is possible that on some link types (e.g., NBMA links) > alternative protocols or mechanisms to implement those services will > be specified (in the appropriate document covering the operation of > IP over a particular link type). >Clearly, no updates to RFC2461 are necessary since ISATAP is exactly >such "the appropriate document..." as described above. the text right after the above-quoted part suggests me that "ND over NBMA is an area for further study". it suggests me the need to define "ND over NBMA", in a link-layer independent manner. the text does not permit you to define a new link-layer address option handling in ISATAP document. i guess IPv6 wg needs to provide "ND over NBMA" document, then ISATAP has to follow the ND sending/receiving rules in "ND over NBMA" document. >> in 5.1, paragraph 2, what does "enhanced address resolution" mean? >> is it documented in ISATAP document? if so, where? >This refers to the text exactly one sentence earlier, which says: > ISATAP hosts SHOULD enhance the static address resolution computation > with a unicast Neighbor Solicitation(NS)/Neighbor Advertisement(NA) >So, "simple address resolution" = static computation with no neighbor >discovery exchange, and "enhanced address resolution" = static computation >plus a unicast NS/NA exchange. How clear do we need to be? you did not define "enhanced address resolution" in the text. you should define a term whenever it is used for the first time in the document. otherwise the reference "enhanced address resolution" becomes ambiguous to readers. >> it is proposed that router discovery mechanism (near 5.2, find "PRL" >> for Potential Router List) would use DNS for discovering ISATAP router. > it creates circular dependency between link layer (ISATAP) and DNS. >> the use of DNS must be dropped from the router discovery mechanism. > >Yes, DNS is one alternative for discovering the ISATAP router - but >not the only one. Even so, the sequence a dual-stack node can use >the following bootstrapping procedure: > > - discover IPv4 address; DNS server > - configure the IPv4 stack > - wait for a while for native IPv6 RAs to arrive > - if no native v6 service: > - discover a domain name for the ISATAP service > - resolve the name into a list of IPv4 addresses > by name service lookup (could be DNS, could be > static file, ec.) > >Can you explain to me a scenario in which this would *not* work? if you assume the above scenario, the above bootstrap process should be documented (i.e. IPv4 DNS server must be known to the ISATAP node via DHCPv4 or whatever, before ISATAP router discovery process gets started). even with the above, once you discover IPv6 DNS server via DHCPv6- over-ISATAP or whatever, you create a circular dependency between link layer and DNS. circular dependency is bad as it could put your stack into deadlock situation (it would like to send DNS traffic out for "isatap.example.com" but it can't), and worse, could be used by malicious party to put your stack into deadlock situation. therefore, i strongry recommend dropping ISATAP router discovery using DNS. >> ISATAP router is a choke point wrt scalability of the mechanism >> (for instance, link speed of ISATAP router would be the bottleneck for >> all of the nodes in an ISATAP-based site). >> we might be able to achieve some level of load-balancing using >> coordinated advertisement of ISATAP router via PRL announcement, >> however, it is not enough. > >Talk about unsubsantiated opinions! This statement would have been >like the founding architects saying: "packet switching networks can >incur congestion in some cases, so let's not even bother building them". >Clearly, there is a need for better understanding of ISATAP's scaling >properties - but, that's what experiments are for! but what you have asked for was a standard-track publication, not experimental. and the scaling property of ISATAP i observed from the document has problem (even without experiment), as i stated above. >BTW, my belief is that the ISATAP scaling question is a non-issue. >Even if a site administrator felt the need to strategically deploy >equipment for fault tolerance, load balancing, etc. the specification >provides abundat flexibility to support this. It is left to implementors >to create robust products to satisfy the anticipated needs of customers; >the ISATAP specification has no business meddling in implementation >details. i tend to disagree - if there's obvious choke point in a specification we need to diagnose, we need to update specification, suggest operational workaround, or do whatever needed, to avoid that choke point. >> i can't really parse section 7 paragraph 2. what does it mean? >> > Appendix B proposes a specification for managing the IEEE OUI >> > assigned to IANA for EUI-64 interface identifier construction. This >> > specification is made freely available to IANA for any purpose they >> > may find useful. >Let me recommend that you give it 1-2 more re-reads, then skip ahead to >Appendix B. The meaning is there, and the words (while not optimal) seem >adequate to me. If you are still confused, let me assure you this text >has absolutely no operational bearing on the rest of the specification. I of course read appendix B. what i don't understand is "this specification is made freely available to IANA..." part. what is meant by "freely"? free of charge? freedom of use? free from IPR issues? what kind of control IANA would like to have over the EUI64 creation process in ISATAP document? i still don't understand what you are trying to mean. itojun From owner-v6ops@ops.ietf.org Mon Dec 30 23:47:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07786 for ; Mon, 30 Dec 2002 23:47:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18TEJO-000PRJ-00 for v6ops-data@psg.com; Mon, 30 Dec 2002 20:47:30 -0800 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.36 #2) id 18TEJM-000PR7-00 for v6ops@ops.ietf.org; Mon, 30 Dec 2002 20:47:28 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBV4lc819084 for ; Mon, 30 Dec 2002 22:47:38 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 30 Dec 2002 22:47:26 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Dec 2002 22:46:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt Date: Mon, 30 Dec 2002 20:46:02 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0175DA99@mvebe001.americas.nokia.com> Thread-Topic: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt Thread-Index: AcKqoAAU0ZjX4jS9Q8aoPobK8ZLRJwF5zYew From: To: , X-OriginalArrivalTime: 31 Dec 2002 04:46:03.0273 (UTC) FILETIME=[85DD1F90:01C2B087] X-Spam-Status: No, hits=1.3 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA07786 Hi, yep, I only did editorial nits, and tried to make it conformant with the ID nits. However, I did not split the references to normative and informative. The document is going to be Informational, and so I would guess that all references are informative by definition. (This would be my understanding.) Cheers, Jonne. > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, December 23, 2002 8:21 AM > To: v6ops@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt > > > On Mon, 23 Dec 2002 Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the IPv6 Operations Working > Group of the IETF. > > > > Title : Transition Scenarios for 3GPP Networks > > Author(s) : J. Soininen > > Filename : draft-ietf-v6ops-3gpp-cases-01.txt > > Pages : 10 > > Date : 2002-12-23 > > As the changes were very minor, I'm assuming this is to go to > W.G. last > call soonish. > > I'd check it against ID-nits, e.g. the references need to be > split up or > categorized. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Tue Dec 31 18:08:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00790 for ; Tue, 31 Dec 2002 18:08:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18TVWC-000OC7-00 for v6ops-data@psg.com; Tue, 31 Dec 2002 15:09:52 -0800 Received: from web13005.mail.yahoo.com ([216.136.174.15]) by psg.com with smtp (Exim 3.36 #2) id 18TVWA-000OBu-00 for v6ops@ops.ietf.org; Tue, 31 Dec 2002 15:09:50 -0800 Message-ID: <20021231230949.32247.qmail@web13005.mail.yahoo.com> Received: from [205.226.2.67] by web13005.mail.yahoo.com via HTTP; Tue, 31 Dec 2002 15:09:49 PST Date: Tue, 31 Dec 2002 15:09:49 -0800 (PST) From: Fred Templin Subject: Re: Request to Publish ISATAP To: itojun@iijlab.net Cc: Christian Huitema , Margaret Wasserman , v6ops@ops.ietf.org, Bob Fink , Randy Bush In-Reply-To: <20021224235008.D2E904B25@coconut.itojun.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.9 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Itojun, I will not go into the specifics of your message dated 12/24/02, but would ask that you review and comment on the latest version of the draft found at: http://www.geocities.com/osprey67/isatap-09.txt Margaret, In your message dated 12/23/02, you mentioned that the v6ops chairs would be expressing their opinion to the IESG in one week. Since the ID registrars are on vacation, I would like to humbly request that the wg chair defer their annoucement until the above draft can be submitted to the registrar. Sincerely, Fred L. Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com