From owner-v6ops@ops.ietf.org Mon Feb 2 07:14:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06281 for ; Mon, 2 Feb 2004 07:14:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Anckm-0008lz-TU for v6ops-data@psg.com; Mon, 02 Feb 2004 12:00:36 +0000 Received: from [66.111.4.25] (helo=out1.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ancka-0008ki-07 for v6ops@ops.ietf.org; Mon, 02 Feb 2004 12:00:24 +0000 Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by mail.messagingengine.com (Postfix) with ESMTP id 1B2074C0EFF; Mon, 2 Feb 2004 06:59:42 -0500 (EST) Received: by frontend3.messagingengine.com (Postfix, from userid 99) id 8C9542E; Mon, 2 Feb 2004 06:59:42 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.72; T1.001; A1.60; B2.21; Q2.21) From: "Chirayu Patel" To: "Pekka Savola" Date: Mon, 02 Feb 2004 17:29:42 +0530 X-Sasl-Enc: 99dzoTmITeAlTv8sax4CjA 1075723182 Cc: v6ops@ops.ietf.org, erik.nordmark@sun.com Subject: Re: mech-v2: multiple packet drops with ICMPv4 and ICMPv6 [Re: comments on mech-v2-01] References: In-Reply-To: Message-Id: <20040202115942.8C9542E@frontend3.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yup. It does capture the scenario adequately. CP On Wed, 28 Jan 2004 13:35:30 +0200 (EET), "Pekka Savola" said: > Hi, > > I added the text below at the end of section 3.4 on ICMP errors. > > Does this address your concern? Or would you propose alternative > text? > > Note that when IPv4 path MTU is exceeded, and ICMPv4 errors of only 8 > bytes of payload are generated, or ICMPv4 errors do not cause the > generation of ICMPv6 errors in case there is enough payload, there > will be at least two packet drops instead of at least one (the case > of a single layer of MTU discovery). Consider a case where a host is > connected to a router, which is connected to a network where an > ICMPv4 error about too big packet size is generated. First the > router needs to learn the tunnel (IPv4) MTU which causes at least one > packet loss, and then the host needs to learn the (IPv6) MTU from the > router which causes at least one packet loss. Still, in all cases > there can be more than one packet loss if there are multiple large > packets in flight at the same time. > > On Mon, 10 Nov 2003, Erik Nordmark wrote: > > > 1) A race is triggered when an IPv6 router that has a configured tunnel > > > with another router is doing dynamic mtu detection. The outcome of the > > > race is that one or more ICMPv6 "packet too big" message might not be > > > sent out to an host. > > > > > > Assume an IPv6 network like: > > > > > > [H1]-------->[R1]===========>[R2]--------->[H2] > > > > > 5. H1->R1 TCP packet of size 1400 (this is a retry) > > > 6. R1->H1 ICMPv6 "packet too big" with size 1300 > > > 7. H1->R1 TCP packet of size 1400 (this is a retry) > > > 8. ... (the above cycle might repeat if there are more IPv4 routers > > > that send ICMPv4 "fragmentation needed" with 8 bytes of payload) > > > > I don't understand how it can repeat. Do you think it can repeat forever? > > > > When the 8-byte payload ICMP errors are sent then R1 will effectively > > compute the minimum received (per IPv4 path MTU discovery). > > > > It is true that in the case of 8-byte payload ICMP errors you get at > > least two packet drops instead of at least one in the case of a single layer > > of MTU discovery (R1 needs to learn the tunnel MTU which causes at least one > > packet loss, and then H1 needs to learn the MTU from R1 which causes at > > least one packet loss. (And in all cases there can be more than one packet loss > > if there are multiple large packets in flight at the same time.) From owner-v6ops@ops.ietf.org Mon Feb 2 12:19:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23424 for ; Mon, 2 Feb 2004 12:19:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Anhce-0004pd-JZ for v6ops-data@psg.com; Mon, 02 Feb 2004 17:12:32 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnhcK-0004oL-3u for v6ops@ops.ietf.org; Mon, 02 Feb 2004 17:12:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i12HCA408817 for ; Mon, 2 Feb 2004 19:12:10 +0200 Date: Mon, 2 Feb 2004 19:12:10 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI. ---------- Forwarded message ---------- Date: Mon, 02 Feb 2004 10:48:25 -0500 From: internet-drafts@ietf.org To: IETF-Announce: ; Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in Seoul, Korea: February 9th: Cutoff Date for Initial Internet-Draft Submissions (new documents) All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be submitted by Monday, February 9th, at 09:00 ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval MUST be received by Wednesday, February 4th, at 09:00 ET. February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher) All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 16th, at 09:00 ET. Initial and revised Internet-Drafts received after their respective cutoff dates will NOT be made available in the Internet-Drafts directory OR announced, and will have to be resubmitted. Please do NOT wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 8th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. FYI: The Internet-Draft cutoff dates as well as other significant dates for the 59th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_59.html. From owner-v6ops@ops.ietf.org Mon Feb 2 16:12:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10967 for ; Mon, 2 Feb 2004 16:12:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnlHM-0007Ou-5b for v6ops-data@psg.com; Mon, 02 Feb 2004 21:06:48 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnlH0-0007MW-Gv for v6ops@ops.ietf.org; Mon, 02 Feb 2004 21:06:26 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09689; Mon, 2 Feb 2004 16:06:23 -0500 (EST) Message-Id: <200402022106.QAA09689@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-mech-v2-02.txt Date: Mon, 02 Feb 2004 16:06:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Transition Mechanisms for IPv6 Hosts and Routers Author(s) : E. Nordmark, R. Gilligan Filename : draft-ietf-v6ops-mech-v2-02.txt Pages : 29 Date : 2004-2-2 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, 'dual stack' and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-mech-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-mech-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-2151007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-mech-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-mech-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2151007.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Feb 5 10:46:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20206 for ; Thu, 5 Feb 2004 10:46:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AolRu-000OFS-Re for v6ops-data@psg.com; Thu, 05 Feb 2004 15:29:50 +0000 Received: from [62.241.160.9] (helo=shockwave.systems.pipex.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AolRa-000OBh-Nx for v6ops@ops.ietf.org; Thu, 05 Feb 2004 15:29:30 +0000 Received: from tom3 (1Cust70.tnt17.lnd4.gbr.da.uu.net [62.188.146.70]) by shockwave.systems.pipex.net (Postfix) with SMTP id 486071C0024C; Thu, 5 Feb 2004 15:29:19 +0000 (GMT) Message-ID: <002101c3ebfc$b1378e80$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Pekka Savola" , "v6ops" Subject: Re: mech-v2: decapsulation check updates Date: Thu, 5 Feb 2004 15:22:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A thought. The day before you sent this, I heard an interesting presentation at RIPE-47 on tunnel discovery which used host to router tunnels to find out how many tunnels there are in v6 (A: lots!) and also flagged some of the dangers, eg of ND packets sent direct from host to egress router. It recommended keeping tunnels to network edge and using GRE (didn't grasp why). I don't see anything in the stronger decapsulation checks that will stop this form of tunnel discovery although have a vague feeling that some would see this as an abuse of the tunnels and would like to stop it. The presentation (433KB) is at http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel- disco.pdf Tom Petch -----Original Message----- From: Pekka Savola To: v6ops@ops.ietf.org Date: 28 January 2004 14:38 Subject: mech-v2: decapsulation check updates >Hi, > >Since the last version of the transmech document, the decapsulation >checks have become much stronger: MUST check the v4 source of the >tunnel, MUST check the v6 source addresses for bogus addresses and >MAY/should use v4/v6 ingress filtering. > >Any objections to these changes? Other thoughts? > >========= >3.6. Decapsulation > > When an IPv6/IPv4 host or a router receives an IPv4 datagram that is > addressed to one of its own IPv4 addresses, and the value of the > protocol field is 41, the packet is potentially part of a tunnel and > needs to be verified to belong to one of the configured tunnel > interfaces (by checking source/destination addresses), reassembled > (if fragmented at the IPv4 level), have the IPv4 header removed and > the resulting IPv6 datagram be submitted to the IPv6 layer code on > the node. > > The decapsulator MUST verify that the tunnel source address is > correct before further processing packets, to mitigate the problems > with address spoofing (see section 4). This check also applies to > packets which are delivered to transport protocols on the > decapsulator. This is done by verifying that the source address is > the IPv4 address of the other end of a tunnel configured on the node. > Packets for which the IPv4 source address does not match MUST be > discarded; an ICMP message (whether IPv4 or IPv6) SHOULD NOT be > generated. > > A side effect of this address verification is that the node will > silently discard packets with a wrong source address, and packets > which were received by the node but not directly addressed to it > (e.g., broadcast addresses). > > In addition, the node MAY perform ingress filtering [RFC2827] on the > IPv4 source address, i.e., check that the packet is arriving from the > interface in the direction of the route towards the tunnel end-point, > similar to a Strict Reverse Path Forwarding (RPF) check [BCP38UPD]. > If done, it is RECOMMENDED that this check is disabled by default. > The packets caught by this check SHOULD be silently discarded. > >[[ skip paragraphs about MTU and figures..] > > After the decapsulation the node MUST silently discard a packet with > an invalid IPv6 source address. The list of invalid source addresses > SHOULD include at least: > > - all multicast addresses (FF00::/8) > > - the loopback address (::1) > > - all the IPv4-compatible IPv6 addresses [RFC3513] (::/96), > excluding the unspecified address for Duplicate Address > Detection (::/128) > > - all the IPv4-mapped IPv6 addresses (::ffff:0:0/96) > > In addition, the node should perform ingress filtering [RFC2827] on > the IPv6 source address, as on any of its interfaces, e.g.: > > - if the tunnel is towards the Internet, check that the site's > IPv6 prefixes are not used as the source addresses, or > > - if the tunnel is towards an edge network, check that the source > address belongs to that edge network. > > > From owner-v6ops@ops.ietf.org Thu Feb 5 11:12:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21469 for ; Thu, 5 Feb 2004 11:12:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aom34-0005OR-M5 for v6ops-data@psg.com; Thu, 05 Feb 2004 16:08:14 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aom2n-0005Kv-Jg for v6ops@ops.ietf.org; Thu, 05 Feb 2004 16:07:57 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id A3F52860B; Thu, 5 Feb 2004 17:07:52 +0100 (CET) From: "Jeroen Massar" To: "'Tom Petch'" , "'Pekka Savola'" , "'v6ops'" Subject: RE: mech-v2: decapsulation check updates Date: Thu, 5 Feb 2004 17:06:37 +0100 Organization: Unfix Message-ID: <00ab01c3ec02$0958cc50$210d640a@unfix.org> 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.4510 Importance: Normal In-Reply-To: <002101c3ebfc$b1378e80$0301a8c0@tom3> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Tom Petch wrote: > A thought. The day before you sent this, I heard an interesting > presentation at RIPE-47 on tunnel discovery which used host to router > tunnels to find out how many tunnels there are in v6 (A: lots!) and > also flagged some of the dangers, eg of ND packets sent direct from > host to egress router. It recommended keeping > tunnels to network edge and using GRE (didn't grasp why). I saw the presentation too and he recommended GRE because that isn't that easy to be spoofed. proto-41 tunnels can easily be spoofed by just sending your packets with a different source address. As most tunnelbrokers and other tunneled systems don't do any egress checks one can find very cheap and untraceable upstreams. Just start sending those packets with a known IPv4 source address. Getting to know the IPv4 source address is a bit hard though, he dug them all from the horribly trashy 6bone database and apparently about 80% of those tunnels didn't work at all. The only solution ofcourse is to get those **** ISP's to do egress filtering, thus them allowing only packets to go outward that are really assigned to the customer and nothing else. Many ISP's don't do this, thus this is at a complete loss. The fact that I see RFC1918 addresses on my adsl gateway tells enough ofcourse... btw. from his presentation I can conclude that either GARR or RIPE's networks allow spoofing of source IP's... For testing this is ofcourse not that bad, but DDOS anyone? > I don't see anything in the stronger decapsulation checks > that will stop this form of tunnel discovery although have a vague feeling > that some would see this as an abuse of the tunnels and would like to stop it. It certainly is abuse, but how can you check? The packet gets sent from source A, even though the real source is Z. This is a ISP security issue. Only thing one could do about this is add some kind of password or signature mechanism to defeat this. For instance with my heartbeat mechanism I know at least for sure that the source who is sending the packet also knows the password for the tunnel. The problem only is that proto-41 packets coming from that IP don't have any checks. Thus if someone figures out a source IPv4 + IPv6 then they can easily spoof that connection, even if it where only for outgoing packets. Doing proto-41 + a magic signature wouldn't harm anything except that it isn't deployed. I guess that is also one of the reasons why Pekka uses the pptp tunnels in his STEP document as these provide authentication, thus spoofing gets a bit harder. Note that we do employ egress filtering and only the IP's that are routed to the machine itself are allowed to be used as a source address, anything else is either admin-icmp'd or silently dropped depending on the POP. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQCJqDSmqKFIzPnwjEQLPogCcDbMImCKZsBJVBru+bluBHbkadkQAnj9L v8re3pjDJ7V09mKeIgvYMmhF =4MIp -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Thu Feb 5 15:51:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05889 for ; Thu, 5 Feb 2004 15:51:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AoqMM-000Mmv-HD for v6ops-data@psg.com; Thu, 05 Feb 2004 20:44:26 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AoqM2-000MjV-2x for v6ops@ops.ietf.org; Thu, 05 Feb 2004 20:44:06 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05306; Thu, 5 Feb 2004 15:44:03 -0500 (EST) Message-Id: <200402052044.PAA05306@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-isp-scenarios-analysis-01.txt Date: Thu, 05 Feb 2004 15:44:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Scenarios and Analysis for Introducing IPv6 into ISP Networks Author(s) : M. Lind Filename : draft-ietf-v6ops-isp-scenarios-analysis-01.txt Pages : 25 Date : 2004-2-5 This document first describes different scenarios for the introduction of IPv6 into an existing IPv4 ISP network without disrupting the IPv4 service. Then, this document analyses these scenarios and evaluates the suitability of the already defined transition mechanisms in this context. Known challenges are also identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-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-isp-scenarios-analysis-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-isp-scenarios-analysis-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: <2004-2-5155304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-isp-scenarios-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-5155304.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Feb 6 01:08:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00497 for ; Fri, 6 Feb 2004 01:08:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aoz1S-0000N9-GP for v6ops-data@psg.com; Fri, 06 Feb 2004 05:59:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aoz0n-0000IV-LJ for v6ops@ops.ietf.org; Fri, 06 Feb 2004 05:58:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i165wib04670; Fri, 6 Feb 2004 07:58:44 +0200 Date: Fri, 6 Feb 2004 07:58:44 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com, Subject: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, This is a WG Last Call for comments on sending draft-ietf-v6ops-isp-scenarios-analysis-01.txt, " Scenarios and Analysis for Introducing IPv6 into ISP Networks" to the IESG for consideration as BCP: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-01.txt Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. There has been a lack of extensive reviews from the start, so reviewing this document would be especially welcome. The last call will end in about 2.5 weeks, on 24th February. Pekka & Jonne From owner-v6ops@ops.ietf.org Fri Feb 6 04:43:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18026 for ; Fri, 6 Feb 2004 04:43:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ap2OX-0007Jw-Lj for v6ops-data@psg.com; Fri, 06 Feb 2004 09:35:29 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ap2O3-0007Ge-Of for v6ops@ops.ietf.org; Fri, 06 Feb 2004 09:34:59 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2004 10:35:36 +0100 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i169YXL1008564; Fri, 6 Feb 2004 10:34:34 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Feb 2004 09:34:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Date: Fri, 6 Feb 2004 09:34:55 -0000 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Thread-Index: AcPsd9U0tQRBAV8yTTqehFk1Qz6C9AAEPqcAAALl7pA= From: "Francois Le Faucheur (flefauch)" To: "Pekka Savola" , Cc: , , "FLF" X-OriginalArrivalTime: 06 Feb 2004 09:34:56.0778 (UTC) FILETIME=[7B7F96A0:01C3EC94] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, Below are some comments on section "4.1.1 MPLS Backbone". First paragraph: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - I think we should be talking about offering "IPv6 connectivity via = transport of IPv6 over MPLS" as opposed to offering "IPv6-over-MPLS = connectivity". - In addition to softwrae upgrade, I think it is worth conveying that = support of IPv6 MPLS in the core would involve complete control plane = upgrade including IPv6 routing if it is not there, configuration of IPv6 = label distribution, monitoring, operations, ... So, I would suggest enhancing enhancing 1st paragraph to: "If MPLS is already deployed in the backbone, it may be desirable to = provide IPv6 connectivity via transport of IPv6 over MPLS. However, = setting up an IPv6 Label Switched Path (LSP) requires support of the = corresponding control plane (routing, signaling) in the MPLS network; = both LDP and RSVP-TE can set up IPv6 LSPs, but this would require = corresponding upgrade (software, configuration, operations) in the MPLS = core network. " Second paragraph: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I suggest replacing "may be economically attractive" by "may be = attractive". This will make sure we have consistent terminology with previous = sentences (eg "approaches 1 and 2 are the most attractive") and avoid = confusion (eg what is "economically attractive" but inattractive from = other perspectives?). Last paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have a number of problems with that paragraph as it is worded: - "recommeding ... might not be such a good idea": I don't find this a = very precise recommendation. - "No particular reason exists to avoid adding IPv6". Shouldn't we = leave it to operators to decide for themselves whether = avoiding/postponing complete upgrade of the control plane of their core = (which may already be carrying L3VPN, L2VPN, Voice Trunking...) is a = valid reason or not? The previous paragraph attempts to provide a = balanced description of the pros and cons of each approach. It says = "Approach 4 may be attractive for an operator who does not wish to = upgrade the MPLS network and has a large-scale deployment." I think this = is a more accurate statement.=09 - "Software upgrades are commonplace in MPLS networks". Is this = suggesting that upgrades are more commonplace in MPLS networks than IP = networks offering enterprise services? Isn't there a distinction to be = made between upgrade on the edge when new services are added, and = upgrade to the core which is more and more "service-unaware" ? But I see two valid points in the paragraph: - [BGPTUNNEL] is primarily designed for migration period from existing = environments, as opposed to the grand scheme of things for the long term = future where IPv6 will be everywhere - where installed equipment has higher MPLS forwarding performance than = native IPv6 performance, carrying IPv6 over MPLS results in performance = benefits. My recommendation is to drop the last paragraph and capture these two = points by extending the last sentence of the second paragraph into: "Approach 4 may be attractive for an operator who does not wish to = upgrade the MPLS core network at this stage and/or who wants to take = advantage of higher MPLS forwarding performance on installed equipment, = and has a large-scale deployment. " Thanks Francois >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org=20 >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola >> Sent: vendredi 6 f=E9vrier 2004 06:59 >> To: v6ops@ops.ietf.org >> Cc: jonne.soininen@nokia.com; mikael.lind@teliasonera.com >> Subject: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt >>=20 >>=20 >> Hi all, >>=20 >> This is a WG Last Call for comments on sending >> draft-ietf-v6ops-isp-scenarios-analysis-01.txt, " Scenarios and >> Analysis for Introducing IPv6 into ISP Networks" to the IESG for >> consideration as BCP: >>=20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analys= is-01.txt Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this = document is ready to go to the IESG. There has been a lack of extensive reviews from the start, so=20 reviewing this document would be especially welcome. The last call will end in about 2.5 weeks, on 24th February. Pekka & Jonne From owner-v6ops@ops.ietf.org Fri Feb 6 04:49:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18154 for ; Fri, 6 Feb 2004 04:49:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ap2ZC-0008hs-Uw for v6ops-data@psg.com; Fri, 06 Feb 2004 09:46:30 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ap2Yy-0008fM-BU for v6ops@ops.ietf.org; Fri, 06 Feb 2004 09:46:16 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2004 10:46:53 +0100 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i169jnL3012241; Fri, 6 Feb 2004 10:45:50 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Feb 2004 09:46:12 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Date: Fri, 6 Feb 2004 09:46:11 -0000 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Thread-Index: AcPsd9U0tQRBAV8yTTqehFk1Qz6C9AAHVU9w From: "Francois Le Faucheur (flefauch)" To: "Pekka Savola" , Cc: , X-OriginalArrivalTime: 06 Feb 2004 09:46:12.0392 (UTC) FILETIME=[0E321A80:01C3EC96] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Suggestion for "8.2 Example 2" Perhaps=20 " IPv6 deployment might start with an upgrade of a couple of PE routers = to support [BGPTUNNEL], because this will allow large-scale IPv6 support = without hardware or software upgrades in the core. " would read better as: " IPv6 deployment might start with an upgrade of PE routers to support = [BGPTUNNEL] (starting perhaps by a couple PE routers and then extending = to other PEs as needed), because this will allow large-scale IPv6 = support without hardware or software upgrades in the core. " Otherwise, it sounds like deploying on two boxes gives "large scale = support". Cheers Francois >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org=20 >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola >> Sent: vendredi 6 f=E9vrier 2004 06:59 >> To: v6ops@ops.ietf.org >> Cc: jonne.soininen@nokia.com; mikael.lind@teliasonera.com >> Subject: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt >>=20 >>=20 >> Hi all, >>=20 >> This is a WG Last Call for comments on sending >> draft-ietf-v6ops-isp-scenarios-analysis-01.txt, " Scenarios and >> Analysis for Introducing IPv6 into ISP Networks" to the IESG for >> consideration as BCP: >>=20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analys= is-01.txt Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this = document is ready to go to the IESG. There has been a lack of extensive reviews from the start, so=20 reviewing this document would be especially welcome. The last call will end in about 2.5 weeks, on 24th February. Pekka & Jonne From owner-v6ops@ops.ietf.org Fri Feb 6 05:13:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18905 for ; Fri, 6 Feb 2004 05:13:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ap2vY-000CkJ-3r for v6ops-data@psg.com; Fri, 06 Feb 2004 10:09:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ap2vL-000Cis-6E for v6ops@ops.ietf.org; Fri, 06 Feb 2004 10:09:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i16A9Go09508; Fri, 6 Feb 2004 12:09:16 +0200 Date: Fri, 6 Feb 2004 12:09:16 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: "'Tom Petch'" , "'v6ops'" Subject: RE: mech-v2: decapsulation check updates In-Reply-To: <00ab01c3ec02$0958cc50$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, It's good to bring this up. In the current transmech document, the security-related parts have been rewritten. This threat has also been described at some length -- the stronger decapsulation checks help a lot, but other alternatives are also offered. I'd be interested in hearing suggestions if the language e.g. in security considerations could be strengthened. On Thu, 5 Feb 2004, Jeroen Massar wrote: > I saw the presentation too and he recommended GRE because that > isn't that easy to be spoofed. GRE is equally easy to spoof, unless GRE keying is used. And then you have to set up that keying. > Getting to know the IPv4 source address is a bit hard though, he > dug them all from the horribly trashy 6bone database and apparently > about 80% of those tunnels didn't work at all. Indeed, finding the address is the most difficult part. > The only solution ofcourse is to get those **** ISP's to do > egress filtering, thus them allowing only packets to go outward > that are really assigned to the customer and nothing else. > Many ISP's don't do this, thus this is at a complete loss. > The fact that I see RFC1918 addresses on my adsl gateway tells > enough ofcourse... Right. > It certainly is abuse, but how can you check? > The packet gets sent from source A, even though the > real source is Z. This is a ISP security issue. > Only thing one could do about this is add some kind > of password or signature mechanism to defeat this. Precisely: you either: 1) have to live with this threat (making it difficult to learn the source address of the tunnel; remember, that typically people WON'T put them in a public database, making the guessing very difficult!) 2) do something to stop/mitigate it, e.g.: a) run the tunneling only with inter-domain; b) perform ingress/egress filtering at the border of your domain c) something else -- note: a) + b) is a complete solution. 3) use some other mechanisms a) GRE with keying b) IPsec > I > guess that is also one of the reasons why Pekka uses the pptp > tunnels in his STEP document as these provide authentication, thus > spoofing gets a bit harder. Actually, STEP uses just plain proto-41 tunnels, and there is no authentication at all. But the work is scoped so that it isn't aimed at crossing ISP boundaries, so the ISP is just shooting himself in the foot unless he's doing very specific filtering (at least, killing proto-41 packets to the tunnel server from the upstreams). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Feb 6 05:28:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19360 for ; Fri, 6 Feb 2004 05:28:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ap3Au-000Fop-RP for v6ops-data@psg.com; Fri, 06 Feb 2004 10:25:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ap3Ah-000Flg-Di for v6ops@ops.ietf.org; Fri, 06 Feb 2004 10:25:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i16AP4209823; Fri, 6 Feb 2004 12:25:04 +0200 Date: Fri, 6 Feb 2004 12:25:04 +0200 (EET) From: Pekka Savola To: "Francois Le Faucheur (flefauch)" cc: v6ops@ops.ietf.org, , Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 6 Feb 2004, Francois Le Faucheur (flefauch) wrote: > - I think we should be talking about offering "IPv6 connectivity via > transport of IPv6 over MPLS" as opposed to offering "IPv6-over-MPLS > connectivity". Why? I don't see how this is a relevant distinction? > Second paragraph: > ================= > > I suggest replacing "may be economically attractive" by "may be attractive". > This will make sure we have consistent terminology with previous > sentences (eg "approaches 1 and 2 are the most attractive") and > avoid confusion (eg what is "economically attractive" but > inattractive from other perspectives?). Fine. > Last paragraph > ============== > I have a number of problems with that paragraph as it is worded: > > - "No particular reason exists to avoid adding IPv6". > Shouldn't we leave it to operators to decide for themselves whether > avoiding/postponing complete upgrade of the control plane of their > core (which may already be carrying L3VPN, L2VPN, Voice Trunking...) > is a valid reason or not? The previous paragraph attempts to provide > a balanced description of the pros and cons of each approach. It > says "Approach 4 may be attractive for an operator who does not wish > to upgrade the MPLS network and has a large-scale deployment." I > think this is a more accurate statement. There really doesn't seem to be any particular reason (except the one spelled out), so it seems appropriate to say it. > - "Software upgrades are commonplace in MPLS networks". Is > this suggesting that upgrades are more commonplace in MPLS networks > than IP networks offering enterprise services? Isn't there a > distinction to be made between upgrade on the edge when new services > are added, and upgrade to the core which is more and more > "service-unaware" ? I made a poll in NANOG list, asking whether the MPLS network core routers are upgraded. Every single MPLS operator (who answered) said they DO upgrade their core router software, for a number of reasons (including, fixing software bugs, adding support for newer hardware, adding features such as CoS or support for larger MTUs, etc.). This point was specifically added to kill the misconception that "MPLS == no software upgrades in the core". People will upgrade the software if they think they want the capabilities of the new software. People turn on new features if they think they need them. > But I see two valid points in the paragraph: > > - where installed equipment has higher MPLS forwarding > performance than native IPv6 performance, carrying IPv6 over MPLS > results in performance benefits. > > My recommendation is to drop the last paragraph and capture these > two points by extending the last sentence of the second paragraph > into: > > "Approach 4 may be attractive for an operator who does not wish to > upgrade the MPLS core network at this stage and/or who wants to take > advantage of higher MPLS forwarding performance on installed > equipment, and has a large-scale deployment. " I strongly disagree with this. Your rewording would obfuscate the very point of being made. Based on the feedback I've received, about the only reason people are requesting something like BGPTUNNEL is that their vendor has sold them crappy hardware which does not support IPv6 to a degree (e.g., line-rate) the folks want. That point must be stated very clearly (even clearer than now) when we're discussing different approaches to IPv6 in MPLS networks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Feb 6 05:31:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19425 for ; Fri, 6 Feb 2004 05:31:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ap3Eq-000GVM-RQ for v6ops-data@psg.com; Fri, 06 Feb 2004 10:29:32 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Ap3EZ-000GSB-5K for v6ops@ops.ietf.org; Fri, 06 Feb 2004 10:29:15 +0000 Received: (qmail 24618 invoked by uid 1007); 6 Feb 2004 10:29:13 -0000 Date: Fri, 6 Feb 2004 11:29:13 +0100 From: Gert Doering To: Tom Petch Cc: Pekka Savola , v6ops Subject: Re: mech-v2: decapsulation check updates Message-ID: <20040206102913.GT8040@Space.Net> References: <002101c3ebfc$b1378e80$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101c3ebfc$b1378e80$0301a8c0@tom3> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, Feb 05, 2004 at 03:22:57PM -0000, Tom Petch wrote: > A thought. The day before you sent this, I heard an interesting > presentation at RIPE-47 on tunnel discovery which used host to router > tunnels to find out how many tunnels > there are in v6 (A: lots!) and also flagged some of the dangers, eg of ND > packets sent direct from host to egress router. It recommended keeping > tunnels to network edge and using GRE (didn't grasp why). I've been there as well, and spent some time discussing this with the author. As far as I can see, the fears about "users could do bad things with ND and other 'link-local' things that way" are more due to "some fuzzy feeling that people could do bad things", and not based on hard facts. On the other hand, address spoofing is a real threat - and as Jeroen said, the only thing you can do about it is to make sure that IPv4 uRPF is widely deployed... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) 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 Fri Feb 6 09:57:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27528 for ; Fri, 6 Feb 2004 09:57:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ap7I5-0007wm-MH for v6ops-data@psg.com; Fri, 06 Feb 2004 14:49:09 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ap7Hn-0007ut-LO for v6ops@ops.ietf.org; Fri, 06 Feb 2004 14:48:51 +0000 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i16EmoOr026056 for ; Fri, 6 Feb 2004 14:48:50 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA05226 for ; Fri, 6 Feb 2004 14:48:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i16EmnH24846 for v6ops@ops.ietf.org; Fri, 6 Feb 2004 14:48:49 GMT Date: Fri, 6 Feb 2004 14:48:49 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Message-ID: <20040206144849.GH23604@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Why is BGPTUNNEL recommended in this analysis? Who is actually using it? Also, the draft version in the analysis should be 01 not 00, if it does stay in as a clearly marked last resort method... Tim On Fri, Feb 06, 2004 at 09:46:11AM -0000, Francois Le Faucheur (flefauch) wrote: > Hi, > > Suggestion for "8.2 Example 2" > > Perhaps > > " IPv6 deployment might start with an upgrade of a couple of PE routers to support [BGPTUNNEL], because this will allow large-scale IPv6 support without hardware or software upgrades in the core. " > > would read better as: > > " IPv6 deployment might start with an upgrade of PE routers to support [BGPTUNNEL] (starting perhaps by a couple PE routers and then extending to other PEs as needed), because this will allow large-scale IPv6 support without hardware or software upgrades in the core. " > > Otherwise, it sounds like deploying on two boxes gives "large scale support". > > Cheers > > Francois > > >> -----Original Message----- > >> From: owner-v6ops@ops.ietf.org > >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > >> Sent: vendredi 6 février 2004 06:59 > >> To: v6ops@ops.ietf.org > >> Cc: jonne.soininen@nokia.com; mikael.lind@teliasonera.com > >> Subject: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt > >> > >> > >> Hi all, > >> > >> This is a WG Last Call for comments on sending > >> draft-ietf-v6ops-isp-scenarios-analysis-01.txt, " Scenarios and > >> Analysis for Introducing IPv6 into ISP Networks" to the IESG for > >> consideration as BCP: > >> > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-01.txt > > Please review these documents carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this document > is ready to go to the IESG. > > There has been a lack of extensive reviews from the start, so > reviewing this document would be especially welcome. > > The last call will end in about 2.5 weeks, on 24th February. > > Pekka & Jonne > > > > From owner-v6ops@ops.ietf.org Fri Feb 6 17:23:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26001 for ; Fri, 6 Feb 2004 17:23:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ApEDX-0005dq-E3 for v6ops-data@psg.com; Fri, 06 Feb 2004 22:12:55 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ApEDE-0005cp-Nt for v6ops@ops.ietf.org; Fri, 06 Feb 2004 22:12:36 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id EAAA1103; Sat, 7 Feb 2004 07:12:35 +0900 (JST) To: gert@space.net Cc: nwnetworks@dial.pipex.com, pekkas@netcore.fi, v6ops@ops.ietf.org Subject: Re: mech-v2: decapsulation check updates In-Reply-To: Your message of "Fri, 6 Feb 2004 11:29:13 +0100" <20040206102913.GT8040@Space.Net> References: <20040206102913.GT8040@Space.Net> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040206221235.EAAA1103@coconut.itojun.org> Date: Sat, 7 Feb 2004 07:12:35 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Thu, Feb 05, 2004 at 03:22:57PM -0000, Tom Petch wrote: > > A thought. The day before you sent this, I heard an interesting > > presentation at RIPE-47 on tunnel discovery which used host to router > > tunnels to find out how many tunnels > > there are in v6 (A: lots!) and also flagged some of the dangers, eg of ND > > packets sent direct from host to egress router. It recommended keeping > > tunnels to network edge and using GRE (didn't grasp why). > > I've been there as well, and spent some time discussing this with the > author. do you know why the author recommeded GRE? there's no real difference between RFC2893 tunnel and GRE with respect to address spoofs and stuff, as far as i understand. itojun From owner-v6ops@ops.ietf.org Fri Feb 6 17:48:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26950 for ; Fri, 6 Feb 2004 17:48:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ApEhl-000AT1-IJ for v6ops-data@psg.com; Fri, 06 Feb 2004 22:44:09 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1ApEh6-000AMJ-HH for v6ops@ops.ietf.org; Fri, 06 Feb 2004 22:43:28 +0000 Received: (qmail 68100 invoked by uid 1007); 6 Feb 2004 22:43:27 -0000 Date: Fri, 6 Feb 2004 23:43:27 +0100 From: Gert Doering To: Jun-ichiro itojun Hagino Cc: gert@space.net, nwnetworks@dial.pipex.com, pekkas@netcore.fi, v6ops@ops.ietf.org Subject: Re: mech-v2: decapsulation check updates Message-ID: <20040206224327.GH8040@Space.Net> References: <20040206102913.GT8040@Space.Net> <20040206221235.EAAA1103@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040206221235.EAAA1103@coconut.itojun.org> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Sat, Feb 07, 2004 at 07:12:35AM +0900, Jun-ichiro itojun Hagino wrote: > > On Thu, Feb 05, 2004 at 03:22:57PM -0000, Tom Petch wrote: > > > A thought. The day before you sent this, I heard an interesting > > > presentation at RIPE-47 on tunnel discovery which used host to router > > > tunnels to find out how many tunnels [..] > > I've been there as well, and spent some time discussing this with the > > author. > > do you know why the author recommeded GRE? there's no real difference > between RFC2893 tunnel and GRE with respect to address spoofs and stuff, > as far as i understand. If I understood him correctly, because GRE can do sequence numbering and keying. So you need more information to successfully spoof that. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Mon Feb 9 00:04:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17947 for ; Mon, 9 Feb 2004 00:04:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aq3UK-000Px1-I6 for v6ops-data@psg.com; Mon, 09 Feb 2004 04:57:40 +0000 Received: from [202.106.187.156] (helo=sina.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1ApqkI-00092B-6j for v6ops@ops.ietf.org; Sun, 08 Feb 2004 15:21:18 +0000 Received: (qmail 59222 invoked from network); 8 Feb 2004 15:21:11 -0000 Received: from unknown (HELO summit) (211.150.241.208) by 202.106.187.156 with SMTP; 8 Feb 2004 15:21:11 -0000 Message-ID: <000801c3ee57$8589c570$d0f196d3@summit> From: "Green" To: Cc: , , , Subject: draft-ietf-v6ops-isp-scenarios-analysis-00.txt "IS-IS Dual Stack Convex Requirement" question Date: Sun, 8 Feb 2004 23:23:29 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN, HTML_MESSAGE autolearn=no version=2.61 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, all: in draft-ietf-v6ops-isp-scenarios-analysis-00.txt 4.3.1, it was written: Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6=20 topologies must be "convex", unless the Multiple-topology IS-IS=20 extensions [MTISIS] have been implemented. In simpler networks or=20 with careful planning of IS-IS link costs, it is possible to keep=20 even non-congruent IPv4/IPv6 topologies "convex". Well, I checked the refenced id = draft-ietf-isis-wg-multi-topology-06.txt, but I can't find an = explanation of the problem if non-convex MT with IPv4/v6 is present. I guess it would be quite helpful if you can explain the issue with some = word, so reader like meself can figure it out. To me, without knowing = other motive of the mt-isis design, I would certainly prefer to use ISIS = to run both IPv4 and V6 protocol, since ISIS is so widely deployed in = ISP Backbone. Running OSPFv3 in parallel or waiting for vendors to add = mt-isis support into their box and testing its stability must be painful = to time-to-market. I still don't know the problem yet. Please shed some light. Thanks and best regards. Green Ericsson China From owner-v6ops@ops.ietf.org Mon Feb 9 02:10:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02059 for ; Mon, 9 Feb 2004 02:09:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aq5VM-000GAl-1I for v6ops-data@psg.com; Mon, 09 Feb 2004 07:06:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aq5VA-000GA1-Ti for v6ops@ops.ietf.org; Mon, 09 Feb 2004 07:06:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1976HE13520; Mon, 9 Feb 2004 09:06:18 +0200 Date: Mon, 9 Feb 2004 09:06:17 +0200 (EET) From: Pekka Savola To: Green cc: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-isp-scenarios-analysis-00.txt "IS-IS Dual Stack Convex Requirement" question In-Reply-To: <000801c3ee57$8589c570$d0f196d3@summit> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [WG chair note: as you aren't subscribed, the approval of the message took a while. Also, it would be nice to turn of HTML in the messages posted.] On Sun, 8 Feb 2004, Green wrote: > Well, I checked the refenced id = > draft-ietf-isis-wg-multi-topology-06.txt, but I can't find an > explanation of the problem if non-convex MT with IPv4/v6 is present. > > I guess it would be quite helpful if you can explain the issue with some > word, so reader like meself can figure it out. To me, without knowing > other motive of the mt-isis design, I would certainly prefer to use ISIS > to run both IPv4 and V6 protocol, since ISIS is so widely deployed in > ISP Backbone. Running OSPFv3 in parallel or waiting for vendors to add > mt-isis support into their box and testing its stability must be painful > to time-to-market. Let me try to explain the convex requirement for single-topology IS-IS. This obviously needs some more text (or a diagram) in the memo as it has been brought up earlier. In short, this could be summarized as: 1) "any IP-independent path from an IPv4 router to any other IPv4 router must only go through routers which are IPv4 capable", and 2) "any IP-independent path from an IPv6 router to any other IPv6 router must only go through routers which are IPv6 capable". Note in particular, as IS-IS is based upon CLNS, these are NOT trivially accomplished. The single-topology IS-IS builds paths which are agnostic of IP versions. Consider an example scenario: cost 5 R4 cost 5 ,------- [v4/v6] -----. / \ [v4/v6] ------ [ v4 ] -----[v4/v6] R1 cost 3 R3 cost 3 R2 .. here the second requirement would not hold. IPv6 packets from R1 to R2 (or vice versa) would go through R3, which does not support IPv6, and the packets would get discarded. By reversing the costs between R1-R3,R3-R2 and R1-R4,R4-R2 the traffic would work in the normal case, but if a link fails and the routing moves to go through R3, you're again in trouble. Hopefully this clarifies the situation. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Feb 9 03:13:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06054 for ; Mon, 9 Feb 2004 03:13:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aq6Uy-000Omk-Nw for v6ops-data@psg.com; Mon, 09 Feb 2004 08:10:32 +0000 Received: from [131.115.230.133] (helo=tms002bb.han.telia.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aq6Un-000OlJ-AD for v6ops@ops.ietf.org; Mon, 09 Feb 2004 08:10:21 +0000 Received: from TMS061MB.tcad.telia.se ([131.115.230.182]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 09:10:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Date: Mon, 9 Feb 2004 09:10:19 +0100 Message-ID: <31ACB1372B7F274B8EDEBF21AD8795A022DD8D@TMS061MB.tcad.telia.se> Thread-Topic: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Thread-Index: AcPsw2u1OQL++ggwQbmeryMg/cef5wCH3lDg From: To: , Cc: X-OriginalArrivalTime: 09 Feb 2004 08:10:19.0729 (UTC) FILETIME=[2894A410:01C3EEE4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, See my comments below. >=20 > Why is BGPTUNNEL recommended in this analysis? It has not been our intention to recommend BGPTUNNEL, but I still believe it is a viable option and should be mentioned. Perhaps the text needs some polishing. =20 >=20 > Who is actually using it? I don't know who is using it right now but I do know it is being considered.=20 >=20 > Also, the draft version in the analysis should be 01 not 00, if it does > stay in as a clearly marked last resort method... Will be changed to "work in progress" Regards, Mikael From owner-v6ops@ops.ietf.org Mon Feb 9 06:42:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13520 for ; Mon, 9 Feb 2004 06:42:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aq9kS-0003JX-Ig for v6ops-data@psg.com; Mon, 09 Feb 2004 11:38:44 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aq9k1-000393-KI for v6ops@ops.ietf.org; Mon, 09 Feb 2004 11:38:17 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2004 12:38:53 +0100 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i19BbhL7013089; Mon, 9 Feb 2004 12:37:51 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Feb 2004 11:38:12 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Date: Mon, 9 Feb 2004 11:38:12 -0000 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Thread-Index: AcPsm4oMGpDpIyBUQP2tMGR2MqphmgAHLCaA From: "Francois Le Faucheur (flefauch)" To: "Pekka Savola" Cc: , , , "FLF" X-OriginalArrivalTime: 09 Feb 2004 11:38:12.0942 (UTC) FILETIME=[3331E6E0:01C3EF01] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Pekka, >>=20 >> On Fri, 6 Feb 2004, Francois Le Faucheur (flefauch) wrote: >> > - I think we should be talking about offering "IPv6=20 >> connectivity via >> > transport of IPv6 over MPLS" as opposed to offering "IPv6-over-MPLS >> > connectivity". >>=20 >> Why? I don't see how this is a relevant distinction? >> I believe the objective is to offer IPv6 connectivity to end users, whether this is achieved over MPLS or not is not directly relevant to the end user (ie they buy "IPv6" not really "IPv6-over-MPLS"). So I was proposing a wording which separates the service "offered" (IPv6 connectivity) from the way it is achieved (ie by carrying IPv6 over MPLS). This is no big deal. =20 >> > Second paragraph: >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > I suggest replacing "may be economically attractive" by=20 >> "may be attractive". >>=20 >> > This will make sure we have consistent terminology with previous >> > sentences (eg "approaches 1 and 2 are the most attractive") and >> > avoid confusion (eg what is "economically attractive" but >> > inattractive from other perspectives?). >>=20 >> Fine. >> =20 >> > Last paragraph >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > I have a number of problems with that paragraph as it is worded: >> > >> > - "No particular reason exists to avoid adding IPv6". >> > Shouldn't we leave it to operators to decide for themselves whether >> > avoiding/postponing complete upgrade of the control plane of their >> > core (which may already be carrying L3VPN, L2VPN, Voice=20 >> Trunking...) >> > is a valid reason or not? The previous paragraph attempts=20 >> to provide >> > a balanced description of the pros and cons of each approach. It >> > says "Approach 4 may be attractive for an operator who=20 >> does not wish >> > to upgrade the MPLS network and has a large-scale deployment." I >> > think this is a more accurate statement. >>=20 >> There really doesn't seem to be any particular reason (except the one >> spelled out), so it seems appropriate to say it. >>=20 >> > - "Software upgrades are commonplace in MPLS networks". Is >> > this suggesting that upgrades are more commonplace in MPLS networks >> > than IP networks offering enterprise services? Isn't there a >> > distinction to be made between upgrade on the edge when=20 >> new services >> > are added, and upgrade to the core which is more and more >> > "service-unaware" ? >>=20 >> I made a poll in NANOG list, asking whether the MPLS network core >> routers are upgraded. Every single MPLS operator (who answered) said >> they DO upgrade their core router software, for a number of reasons >> (including, fixing software bugs, adding support for newer hardware, >> adding features such as CoS or support for larger MTUs, etc.). =20 Yes, but my perception is that: - they would like to minimise the risks of having to do more such upgrades in the future.=20 - when having to do such upgrades, operators would rather minimise their impact. So for some operators, the concern is not so much to get a new software image loaded on the core routers, the concern is more that they would rather avoid activating new functionality/protocol/config/forwarding which could potentially impact the core for other services (and introduce their own new family of issues and bugs, which in turn forces future upgrades for fixes and so on ...). >> This >> point was specifically added to kill the misconception that "MPLS = =3D=3D >> no software upgrades in the core". >>=20 >> People will upgrade the software if they think they want the >> capabilities of the new software. People turn on new features if they >> think they need them. Sure.=20 But, given the choice, if a particular feature can be supported either (i) via a method which requires new software/routing/config/forwarding in the core or (ii) via a method which is transparent for the core, some people may be interested in the latter approach. Some operators with large scale MPLS VPN services are telling me that this is a meaningful consideration for them (just discussed it again Yesterday with one of them). I am not suggesting this applies to every MPLS operators, just that the document could leave it up to operators to decide whether this is a relevant consideration for them or not, rather than making the decision for them that it can not possibly be a relevant consideration. Cheers Francois >> > But I see two valid points in the paragraph: >> > >> > - where installed equipment has higher MPLS forwarding >> > performance than native IPv6 performance, carrying IPv6 over MPLS >> > results in performance benefits. >> >=20 >> > My recommendation is to drop the last paragraph and capture these >> > two points by extending the last sentence of the second paragraph >> > into: >> >=20 >> > "Approach 4 may be attractive for an operator who does not wish to >> > upgrade the MPLS core network at this stage and/or who=20 >> wants to take >> > advantage of higher MPLS forwarding performance on installed >> > equipment, and has a large-scale deployment. " >>=20 >> I strongly disagree with this. Your rewording would obfuscate the >> very point of being made. >>=20 >> Based on the feedback I've received, about the only reason people are >> requesting something like BGPTUNNEL is that their vendor has=20 >> sold them >> crappy hardware which does not support IPv6 to a degree (e.g., >> line-rate) the folks want. That point must be stated very clearly >> (even clearer than now) when we're discussing different approaches to >> IPv6 in MPLS networks. >> >> --=20 >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >>=20 >>=20 >>=20 From owner-v6ops@ops.ietf.org Mon Feb 9 07:50:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16533 for ; Mon, 9 Feb 2004 07:50:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqApP-000FqR-65 for v6ops-data@psg.com; Mon, 09 Feb 2004 12:47:55 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqAoq-000FcH-JL for v6ops@ops.ietf.org; Mon, 09 Feb 2004 12:47:20 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2004 13:47:56 +0100 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i19CksL1002399; Mon, 9 Feb 2004 13:46:54 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Feb 2004 12:47:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Date: Mon, 9 Feb 2004 12:47:17 -0000 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Thread-Index: AcPsw2u1OQL++ggwQbmeryMg/cef5wCH3lDgAAVIWdA= From: "Francois Le Faucheur (flefauch)" To: , , Cc: X-OriginalArrivalTime: 09 Feb 2004 12:47:17.0921 (UTC) FILETIME=[D9CB8110:01C3EF0A] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, >> > Why is BGPTUNNEL recommended in this analysis? >> It has not been our intention to recommend BGPTUNNEL, but I still >> believe it is a viable option and should be mentioned.=20 >> Perhaps the text >> needs some polishing. =20 >>=20 >> >=20 >> > Who is actually using it? >>=20 >> I don't know who is using it right now but I do know it is being >> considered.=20 =20 It is already deployed in large scale production (100+ PE devices).=20 As Mikael mentioned it is also planned or considered by other operators. Several commercial implementations are available and their intereoperability tested by several operators. I support Mikael's approach for isp-scenarios to indicate that BGPTUNNEL is a viable option. Francois From owner-v6ops@ops.ietf.org Mon Feb 9 08:43:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18300 for ; Mon, 9 Feb 2004 08:43:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqBf9-000PDG-VQ for v6ops-data@psg.com; Mon, 09 Feb 2004 13:41:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqBf4-000PCi-Rx for v6ops@ops.ietf.org; Mon, 09 Feb 2004 13:41:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i19DeUA21131; Mon, 9 Feb 2004 15:40:30 +0200 Date: Mon, 9 Feb 2004 15:40:30 +0200 (EET) From: Pekka Savola To: david@iprg.nokia.com, cc: iesg-secretary@ietf.org, Subject: Request to Advance "Basic Transition Mechanisms for IPv6 Hosts and Routers" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk David and Bert, On behalf of the v6ops WG, we'd like to request that the following document be published as Proposed Standard RFC: Basic Transition Mechanisms for IPv6 Hosts and Routers http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-02.txt The first working group last call for this document was completed on 25th November. It has since then been revised to close the issues raised in the Last Call. No objections were received during the another 1-week Last Call, which ended on 8th February. Thanks, Pekka & Jonne v6ops WG co-chairs From owner-v6ops@ops.ietf.org Mon Feb 9 09:53:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21867 for ; Mon, 9 Feb 2004 09:53:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqCkd-000BnZ-1h for v6ops-data@psg.com; Mon, 09 Feb 2004 14:51:07 +0000 Received: from [213.154.224.65] (helo=spock.rvdp.org) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqCkV-000Bmp-9S for v6ops@ops.ietf.org; Mon, 09 Feb 2004 14:50:59 +0000 Received: by spock.rvdp.org (Postfix, from userid 545) id 754291E6782; Mon, 9 Feb 2004 15:50:57 +0100 (CET) Date: Mon, 9 Feb 2004 15:50:57 +0100 From: Ronald van der Pol To: Pekka Savola Cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com, mikael.lind@teliasonera.com Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Message-ID: <20040209145056.GA555@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-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Feb 06, 2004 at 07:58:44 +0200, Pekka Savola wrote: > This is a WG Last Call for comments on sending > draft-ietf-v6ops-isp-scenarios-analysis-01.txt, ... Overall, I think the document is "good enough". I have three minor points. Section 4.3.1 has this sentence in the fifth paragraph: "Therefore, the use of same process is recommended especially for large ISPs intending to deploy, in the short-term, a fully dual- stack backbone infrastructure." I needed to read it several times. I think it says: "when deploying dual-stack in short-term, same process IS-IS is recommended." Maybe the sentence could be rephrased slightly to make it easier to read. Also, isn't same process IS-IS recommended in general because of operational benefits? It is easier to manage one protocol and topology than several. The need to run separate processes should be the exception. In section 5.2 it might be useful to explicitly describe the situation where a service is limited by ACLs to e.g. customers. When upgrading this service to dual-stack, the corresponding IPv6 ACLs should be added to avoid exposing the service worldwide. So, I am thinking about prefix filtering and "allow all" defaults. It would be useful to have a "recommendation" section which summarizes the missing features, i.e. the items the IETF should work on. That's the main purpose of this document, isn't it? I could only identify: - STEP/TSP - tunneling when dynamic IPv4 addresses are in use - authenticating when the customer connection network is shared - multi-homing rvdp From owner-v6ops@ops.ietf.org Mon Feb 9 16:25:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14359 for ; Mon, 9 Feb 2004 16:25:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqIqp-0001Iw-Qf for v6ops-data@psg.com; Mon, 09 Feb 2004 21:21:55 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqIqV-0001H0-EP for v6ops@ops.ietf.org; Mon, 09 Feb 2004 21:21:36 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13760; Mon, 9 Feb 2004 16:21:31 -0500 (EST) Message-Id: <200402092121.QAA13760@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-unmaneval-01.txt Date: Mon, 09 Feb 2004 16:21:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Evaluation of Transition Mechanisms for Unmanaged Networks Author(s) : C. Huitema Filename : draft-ietf-v6ops-unmaneval-01.txt Pages : 17 Date : 2004-2-9 In a companion paper we defined the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-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-unmaneval-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-unmaneval-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: <2004-2-9162048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unmaneval-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unmaneval-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9162048.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Feb 10 01:29:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19023 for ; Tue, 10 Feb 2004 01:29:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqRKq-000IXR-S7 for v6ops-data@psg.com; Tue, 10 Feb 2004 06:25:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqRKf-000IWA-Rs for v6ops@ops.ietf.org; Tue, 10 Feb 2004 06:25:18 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1A6PGi08934; Tue, 10 Feb 2004 08:25:16 +0200 Date: Tue, 10 Feb 2004 08:25:16 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com, Subject: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, This is a WG Last Call for comments on sending draft-ietf-v6ops-unmaneval-01.txt, "Evaluation of Transition Mechanisms for Unmanaged Networks" to the IESG for consideration as BCP: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-01.txt Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. The last call will end in about 2 weeks, on 26th February. Pekka & Jonne From owner-v6ops@ops.ietf.org Tue Feb 10 04:29:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07259 for ; Tue, 10 Feb 2004 04:29:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqU9s-0009RR-Iy for v6ops-data@psg.com; Tue, 10 Feb 2004 09:26:20 +0000 Received: from [131.115.230.133] (helo=tms002bb.han.telia.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqU9h-0009Qz-HG for v6ops@ops.ietf.org; Tue, 10 Feb 2004 09:26:09 +0000 Received: from TMS061MB.tcad.telia.se ([131.115.230.182]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 10:26:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Date: Tue, 10 Feb 2004 10:26:07 +0100 Message-ID: <31ACB1372B7F274B8EDEBF21AD8795A022DD99@TMS061MB.tcad.telia.se> Thread-Topic: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Thread-Index: AcPvHCGNcvHNuevrTceHNEMd17FTQAAmmhmw From: To: , Cc: , X-OriginalArrivalTime: 10 Feb 2004 09:26:07.0959 (UTC) FILETIME=[E9F33670:01C3EFB7] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable See comments inline.=20 > Section 4.3.1 has this sentence in the fifth paragraph: > "Therefore, the use of same process is recommended especially for > large ISPs intending to deploy, in the short-term, a fully dual- > stack backbone infrastructure." > I needed to read it several times. I think it says: "when deploying > dual-stack in short-term, same process IS-IS is recommended." Maybe > the sentence could be rephrased slightly to make it easier to read. > Also, isn't same process IS-IS recommended in general because of > operational benefits? It is easier to manage one protocol and topology > than several. The need to run separate processes should be the exception. Agreed, I will try to clarify.=20 >=20 > In section 5.2 it might be useful to explicitly describe the situation > where a service is limited by ACLs to e.g. customers. When upgrading > this service to dual-stack, the corresponding IPv6 ACLs should be > added to avoid exposing the service worldwide. So, I am thinking > about prefix filtering and "allow all" defaults. I think this is partially mentioned in 5.5 although nothing is mentioned about filtering of traffic going to the customer. >=20 > It would be useful to have a "recommendation" section which summarizes > the missing features, i.e. the items the IETF should work on. That's > the main purpose of this document, isn't it? I could only identify: > - STEP/TSP > - tunneling when dynamic IPv4 addresses are in use > - authenticating when the customer connection network is shared > - multi-homing Might be a good idea, we will look into this.=20 /Mikael From owner-v6ops@ops.ietf.org Tue Feb 10 05:14:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10066 for ; Tue, 10 Feb 2004 05:14:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqUst-000HsD-IF for v6ops-data@psg.com; Tue, 10 Feb 2004 10:12:51 +0000 Received: from [80.126.101.63] (helo=spock.rvdp.org) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqUsi-000HlH-Rt for v6ops@ops.ietf.org; Tue, 10 Feb 2004 10:12:41 +0000 Received: by spock.rvdp.org (Postfix, from userid 545) id 1C01F1E6BBD; Tue, 10 Feb 2004 11:12:40 +0100 (CET) Date: Tue, 10 Feb 2004 11:12:40 +0100 From: Ronald van der Pol To: Mikael.Lind@teliasonera.com Cc: Ronald.vanderPol@rvdp.org, pekkas@netcore.fi, v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Message-ID: <20040210101240.GA607@rvdp.org> References: <31ACB1372B7F274B8EDEBF21AD8795A022DD99@TMS061MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31ACB1372B7F274B8EDEBF21AD8795A022DD99@TMS061MB.tcad.telia.se> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Feb 10, 2004 at 10:26:07 +0100, Mikael.Lind@teliasonera.com wrote: > > In section 5.2 it might be useful to explicitly describe the situation > > where a service is limited by ACLs to e.g. customers. When upgrading > > this service to dual-stack, the corresponding IPv6 ACLs should be > > added to avoid exposing the service worldwide. So, I am thinking > > about prefix filtering and "allow all" defaults. > > I think this is partially mentioned in 5.5 although nothing is mentioned > about filtering of traffic going to the customer. I was thinking about news, streaming, etc servers that are available to customers only. This might be implemened with ACLs, giving access only to traffic with source prefixes belonging to customers. If IPv6 has "allow all" default (e.g. no ACLs), anyone can reach these services via IPv6 transport. Maybe this could be generalized with a recommendation: "each IPv4 ACL should probably have its corresponding IPv6 ACL". The difficult part is to keep both ACLs consistent :-) rvdp From owner-v6ops@ops.ietf.org Tue Feb 10 05:22:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10281 for ; Tue, 10 Feb 2004 05:22:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqV0c-000Iwo-7Y for v6ops-data@psg.com; Tue, 10 Feb 2004 10:20:50 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqV0R-000Itp-Dr for v6ops@ops.ietf.org; Tue, 10 Feb 2004 10:20:39 +0000 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i1AAKcOr003365 for ; Tue, 10 Feb 2004 10:20:38 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA15051 for ; Tue, 10 Feb 2004 10:20:36 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i1AAKaT17492 for v6ops@ops.ietf.org; Tue, 10 Feb 2004 10:20:36 GMT Date: Tue, 10 Feb 2004 10:20:36 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Message-ID: <20040210102036.GH15972@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <31ACB1372B7F274B8EDEBF21AD8795A022DD99@TMS061MB.tcad.telia.se> <20040210101240.GA607@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040210101240.GA607@rvdp.org> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Feb 10, 2004 at 11:12:40AM +0100, Ronald van der Pol wrote: > > I was thinking about news, streaming, etc servers that are available > to customers only. This might be implemened with ACLs, giving access > only to traffic with source prefixes belonging to customers. If IPv6 > has "allow all" default (e.g. no ACLs), anyone can reach these services > via IPv6 transport. Maybe this could be generalized with a recommendation: > "each IPv4 ACL should probably have its corresponding IPv6 ACL". The > difficult part is to keep both ACLs consistent :-) This is another one of those generic-to-all-four-scenarios things that should probably instead be covered in Pekka's firewalling draft? tim From owner-v6ops@ops.ietf.org Tue Feb 10 06:56:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13172 for ; Tue, 10 Feb 2004 06:56:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqWTJ-0009IT-BR for v6ops-data@psg.com; Tue, 10 Feb 2004 11:54:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqWT8-0009HV-Ix for v6ops@ops.ietf.org; Tue, 10 Feb 2004 11:54:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1ABsLv14600 for ; Tue, 10 Feb 2004 13:54:21 +0200 Date: Tue, 10 Feb 2004 13:54:21 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt In-Reply-To: <20040210102036.GH15972@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 10 Feb 2004, Tim Chown wrote: > On Tue, Feb 10, 2004 at 11:12:40AM +0100, Ronald van der Pol wrote: > > > > I was thinking about news, streaming, etc servers that are available > > to customers only. This might be implemened with ACLs, giving access > > only to traffic with source prefixes belonging to customers. If IPv6 > > has "allow all" default (e.g. no ACLs), anyone can reach these services > > via IPv6 transport. Maybe this could be generalized with a recommendation: > > "each IPv4 ACL should probably have its corresponding IPv6 ACL". The > > difficult part is to keep both ACLs consistent :-) > > This is another one of those generic-to-all-four-scenarios things that > should probably instead be covered in Pekka's firewalling draft? It doesn't hurt mentioning it here, but I guess adding it to something like draft-savola-v6ops-security-overview-00.txt might be appropriate (the firewalling document might be slightly wrong place for this). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Feb 10 11:39:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26410 for ; Tue, 10 Feb 2004 11:39:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqaqt-00088L-M0 for v6ops-data@psg.com; Tue, 10 Feb 2004 16:35:11 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqaqk-00087f-Oi for v6ops@ops.ietf.org; Tue, 10 Feb 2004 16:35:02 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1AGYncj008993; Tue, 10 Feb 2004 11:34:49 -0500 (EST) Date: Tue, 10 Feb 2004 11:34:46 -0500 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: Text on 3GPP UE tunneling Message-ID: <111160000.1076430886@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Friday, January 23, 2004 17:13:39 +0200 Pekka Savola wrote/a ecrit: > Hello, > > (wg co-chair hat on) > > The 3GPP analysis document is being finished, and as there was not so > much feedback, the chairs would like to avoid WG last-calling the > document again. > > However, to avoid document revision churn and get an acceptable > outcome, only the extensively discussed topic, UE tunneling, seems to > warrant some discussion before shipping the document, on Monday or > Tuesday. > > Below is a proposal on the wording to use (pay attention to the middle > paragraph). The intent is to try to document all the sides of the > argument and avoiding opening too many cans-of-worms, while being > brief. > > Please send feedback whether you think that OK or not on the list. If > you do not think it is appropriate, you MUST supply an alternative > wording. > > Thanks, > Pekka & Jonne > > [...] > The use of private IPv4 addresses in the UE depends on the support > of these addresses by the tunneling mechanism and the deployment > scenario. In some cases public IPv4 addresses are required, but if > the tunnel endpoints are in the same private domain, or the > tunneling mechanism works through IPv4 NAT, private IPv4 addresses > can be used. One deployment scenario example is using a laptop > computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in > IPv4 packets in the laptop computer and IPv4 PDP context is > activated. The used tunneling mechanism in that case depends on the > support of tunneling mechanisms in the laptop computer. Another > deployment scenario is making IPv6-in-IPv4 tunneling in the UE > itself. > > Closer details for an applicable tunneling mechanism are not > analyzed in this document. However, a simple host-to-router > (automatic) tunneling mechanism may be a good fit. There is not > yet consensus on the right approach. Primarily, ISATAP [ISATAP] > has been proposed, but some issues have been raised about it, > such as its unnecessary features and relative complexity for a > simple task like this, and its inadequacy in providing security > when crossing administrative domains. Proposed solution > alternatives have been (at least) a simplified, but probably > non-interoperable, version of ISATAP, and STEP [STEP]. TSP is another alternative and should be noted. Suggesting: version of ISATAP, STEP and TSP. Marc. >In any > case, further work is needed to find out the requirements for the > scenario and to specify the mechanism. > > To generally solve this problem (IPv6 not available in the 3GPP > network), this document strongly recommends the 3GPP operators to > deploy basic IPv6 support in their GPRS networks. That also makes > it possible to burden the transition effects in the network and > make the 3GPP UEs simpler. > [...] > > [STEP] refers to draft-savola-v6ops-conftun-setup-01.txt > > If the middle paragraph does not seem to be agreeable, we may use > something more generic, like: > > Closer details for an applicable tunneling mechanism are not > analyzed in this document. However, a simple host-to-router > (automatic) tunneling mechanism may be a good fit. Further > work is needed find out the requirements of the scenario > and to specify the mechanism. > > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Tue Feb 10 16:09:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15656 for ; Tue, 10 Feb 2004 16:09:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqf5c-0001MW-Vb for v6ops-data@psg.com; Tue, 10 Feb 2004 21:06:40 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqf5T-0001M8-IT for v6ops@ops.ietf.org; Tue, 10 Feb 2004 21:06:31 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15179; Tue, 10 Feb 2004 16:06:28 -0500 (EST) Message-Id: <200402102106.QAA15179@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-renumbering-procedure-00.txt Date: Tue, 10 Feb 2004 16:06:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Procedures for Renumbering an IPv6 Network without a Flag Day Author(s) : Filename : draft-ietf-v6ops-renumbering-procedure-00.txt Pages : 21 Date : 2004-2-10 This document describes the steps in a procedure that can be used to transition from the use of an existing prefix to a new prefix in a network. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-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-renumbering-procedure-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-renumbering-procedure-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10154729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-renumbering-procedure-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-renumbering-procedure-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10154729.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Feb 10 16:09:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15833 for ; Tue, 10 Feb 2004 16:09:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqf5n-0001ND-1S for v6ops-data@psg.com; Tue, 10 Feb 2004 21:06:51 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqf5f-0001Mh-Rw for v6ops@ops.ietf.org; Tue, 10 Feb 2004 21:06:44 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15214; Tue, 10 Feb 2004 16:06:40 -0500 (EST) Message-Id: <200402102106.QAA15214@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-6to4-security-01.txt Date: Tue, 10 Feb 2004 16:06:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Security Considerations for 6to4 Author(s) : P. Savola Filename : draft-ietf-v6ops-6to4-security-01.txt Pages : 41 Date : 2004-2-10 The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 Routers and Relay Routers, which accept and decapsulate IPv4 protocol-41 ('IPv6-in-IPv4') traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using 6to4 relays or routers as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 node. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-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-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-ietf-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: <2004-2-10154809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-6to4-security-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-security-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10154809.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Feb 10 16:09:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15897 for ; Tue, 10 Feb 2004 16:09:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqf5J-0001Lc-VN for v6ops-data@psg.com; Tue, 10 Feb 2004 21:06:21 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqf5C-0001LG-U3 for v6ops@ops.ietf.org; Tue, 10 Feb 2004 21:06:15 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15098; Tue, 10 Feb 2004 16:06:11 -0500 (EST) Message-Id: <200402102106.QAA15098@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-ent-scenarios-01.txt Date: Tue, 10 Feb 2004 16:06:11 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-01.txt Pages : 17 Date : 2004-2-10 This document describes the scenarios for IPv6 deployment within Enterprise networks. It will focus upon an Enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of Enterprise solutions in a later document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-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-ent-scenarios-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-ent-scenarios-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: <2004-2-10154715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-scenarios-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10154715.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 11 10:39:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05648 for ; Wed, 11 Feb 2004 10:39:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqwOm-0009MN-H2 for v6ops-data@psg.com; Wed, 11 Feb 2004 15:35:36 +0000 Received: from [213.154.224.65] (helo=spock.rvdp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqwOl-0009MA-Ea for v6ops@ops.ietf.org; Wed, 11 Feb 2004 15:35:35 +0000 Received: by spock.rvdp.org (Postfix, from userid 545) id 3ABEE1E81BD; Wed, 11 Feb 2004 16:35:32 +0100 (CET) Date: Wed, 11 Feb 2004 16:35:32 +0100 From: Ronald van der Pol To: jim.bound@hp.com Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt Message-ID: <20040211153532.GA409@rvdp.org> References: <200402102106.QAA15098@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402102106.QAA15098@ietf.org> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Feb 10, 2004 at 16:06:11 -0500, Internet-Drafts@ietf.org wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-01.txt section 3.1: **Note To V6ops WG: Would a network topology map be useful here? I don't think this is necessary in either one of the three scenarios. What would be useful is to better define "parallel" in scenario 1. E.g., what is the difference with "re-structuring" in scenario 3? Does "parallel" mean different links and routers or does it mean dual-stack (or both)? section 3.2: I think the term "address ownership" should be avoided. section 3.3: Is "Network A" an example of scenario 1, "Network B" of scenario 2 and "Network C" of scenario 3? If so, this could be made more clearly. section 4.3: **Note to V6ops WG: Should we discuss porting of applications too in the legacy section? I don't think so. Maybe just a reference to: draft-shin-v6ops-application-transition-02.txt section 5.1: **Note to V6ops WG: Should we get into other DNS issues? The sentence is quite terse, but I think it includes all issues. section 5.2: **Note to V6ops WG: Above is example of additional text we could add to each component we list here. Are there other Routing issues? The ISP draft has some nice text about IS-IS and OSPF with regard to one or two processes. But maybe that's something for the analysis document. section 5.3: **Note to V6ops WG: Should we get into other autoconfiguration issues? IPv6 statefull autoconfiguration does not give all information (e.g. DNS, NTP, etc servers). Maybe add what things should/could be autoconfigured. But maybe this is also something for the analysis draft. In v4 part of a /24 is sometimes used in ACLs. E.g., the upper /28 of a /24 is used for BOFHs by giving that /28 access to services. With autoconf you cannot do that. section 5.4: **Note to V6ops WG: Should we get into other security issues? The document describes the main requirements. More details could go in the analysis document. section 5.5: **Note to V6ops WG: Should we get into other application issues? Some applications cannot be ported (e.g., no source code). section 5.6: **Note to V6ops WG: Should we get into other Management issues? People need to be trained. section 5.7 **Note to V6ops WG: Should we get into other Address Planning issues? Maybe add that IPv6 has /48 and /64 defaults. Especially the /64 is quite different from v4, where one link can have a /24 and another a /28. **Note to V6ops WG: What other components are we missing? I think you have quite some items already. I think the focus should go now to the analysis draft. rvdp From owner-v6ops@ops.ietf.org Wed Feb 11 11:42:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08756 for ; Wed, 11 Feb 2004 11:41:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqxOI-000Iv1-8U for v6ops-data@psg.com; Wed, 11 Feb 2004 16:39:10 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqxOE-000IuZ-QS for v6ops@ops.ietf.org; Wed, 11 Feb 2004 16:39:06 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5AF7412F51; Wed, 11 Feb 2004 11:39:06 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Feb 2004 11:38:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt Date: Wed, 11 Feb 2004 11:38:57 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05837125@tayexc13.americas.cpqcorp.net> Thread-Topic: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt Thread-Index: AcPwtMdl4P71etsUTviSm3yddZRLkQACKC/w From: "Bound, Jim" To: "Ronald van der Pol" Cc: X-OriginalArrivalTime: 11 Feb 2004 16:38:58.0939 (UTC) FILETIME=[8C4604B0:01C3F0BD] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable just a question? these notes were in the previous draft I am confused. just checking. Questions still valid. =20 /jim > -----Original Message----- > From: Ronald van der Pol [mailto:Ronald.vanderPol@rvdp.org]=20 > Sent: Wednesday, February 11, 2004 10:36 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt >=20 >=20 > On Tue, Feb 10, 2004 at 16:06:11 -0500,=20 > Internet-Drafts@ietf.org wrote: >=20 > > A URL for this Internet-Draft is:=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-01. > > txt >=20 > section 3.1: >=20 > **Note To V6ops WG: Would a network topology map be useful here? >=20 > I don't think this is necessary in either one of the three scenarios. >=20 > What would be useful is to better define "parallel" in=20 > scenario 1. E.g., what is the difference with=20 > "re-structuring" in scenario 3? Does "parallel" mean=20 > different links and routers or does it mean dual-stack (or both)? >=20 > section 3.2: > I think the term "address ownership" should be avoided. >=20 > section 3.3: > Is "Network A" an example of scenario 1, "Network B" of=20 > scenario 2 and "Network C" of scenario 3? If so, this could=20 > be made more clearly. >=20 > section 4.3: > **Note to V6ops WG: Should we discuss porting of applications=20 > too in the legacy section? >=20 > I don't think so. Maybe just a reference to:=20 > draft-shin-v6ops-application-transition-02.txt >=20 > section 5.1: > **Note to V6ops WG: Should we get into other DNS issues? >=20 > The sentence is quite terse, but I think it includes all issues. >=20 > section 5.2: > **Note to V6ops WG: Above is example of additional text we could add > to each component we list here. Are there other Routing issues? >=20 > The ISP draft has some nice text about IS-IS and OSPF with=20 > regard to one or two processes. But maybe that's something=20 > for the analysis document. >=20 > section 5.3: > **Note to V6ops WG: Should we get into other autoconfiguration > issues? >=20 > IPv6 statefull autoconfiguration does not give all=20 > information (e.g. DNS, NTP, etc servers). Maybe add what=20 > things should/could be autoconfigured. But maybe this is also=20 > something for the analysis draft. >=20 > In v4 part of a /24 is sometimes used in ACLs. E.g., the=20 > upper /28 of a /24 is used for BOFHs by giving that /28=20 > access to services. With autoconf you cannot do that. >=20 > section 5.4: > **Note to V6ops WG: Should we get into other security issues?=20 > The document describes the main requirements. More details=20 > could go in the analysis document. >=20 > section 5.5: > **Note to V6ops WG: Should we get into other application=20 > issues? Some applications cannot be ported (e.g., no source code). >=20 > section 5.6: > **Note to V6ops WG: Should we get into other Management=20 > issues? People need to be trained. >=20 > section 5.7 > **Note to V6ops WG: Should we get into other Address Planning issues? >=20 > Maybe add that IPv6 has /48 and /64 defaults. Especially the=20 > /64 is quite different from v4, where one link can have a /24=20 > and another a /28. >=20 > **Note to V6ops WG: What other components are we missing? > I think you have quite some items already. I think the focus=20 > should go now to the analysis draft. >=20 > rvdp >=20 From owner-v6ops@ops.ietf.org Wed Feb 11 13:22:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12374 for ; Wed, 11 Feb 2004 13:22:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqyxK-0009LK-2c for v6ops-data@psg.com; Wed, 11 Feb 2004 18:19:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqyx8-0009KP-Un for v6ops@ops.ietf.org; Wed, 11 Feb 2004 18:19:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1BIJDf15567; Wed, 11 Feb 2004 20:19:13 +0200 Date: Wed, 11 Feb 2004 20:19:13 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: 3GPP UE Tunneling, Unmanaged tunnel service, etc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, As the 3GPP Analysis document has been shipped off already, and Unmanaged analysis is at last call, we thought it would be appropriate to try to start figuring out how to find out the specific solutions to non-"opportunistic" tunneling scenarios, such as: 1) 3GPP UE tunneling (between the UE and the 3GPP operator's tunnel service), 2) Unmanaged tunnel broker / tunnel service (between a host or router at the unmanaged site, and the ISP of the customer (or possibly some other ISP)), and maybe 3) Some tunneling inside an Enterprise (this does not seem to be clear yet) Main proposals appear to be ISATAP, STEP and TSP. We're soliciting input on how to best handle this situation. Please send feedback to the chairs or on the list. Tentatively, we're scheduling 20-30 minutes for discussion in Seoul, but how productive such discussion would be would depend on the framing and the contents of presentations and/or discussion. Please send your ideas (if any). Thanks, Pekka & Jonne From owner-v6ops@ops.ietf.org Wed Feb 11 13:22:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12394 for ; Wed, 11 Feb 2004 13:22:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqyz7-0009ng-9H for v6ops-data@psg.com; Wed, 11 Feb 2004 18:21:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqyz6-0009nM-4v for v6ops@ops.ietf.org; Wed, 11 Feb 2004 18:21:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1BILE615603; Wed, 11 Feb 2004 20:21:14 +0200 Date: Wed, 11 Feb 2004 20:21:14 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: IPv6 in MPLS Networks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, As ISP scenarios and analysis document is currently at last call, the biggest issue (excluding the tunnel service considerations, which need resolving in other documents as well) seems to be the recommendations/text about IPv6 deployment in MPLS networks. The possibilities (or a combination of these) include at least: 1) Requiring that MPLS networks deploy native IPv6 support or use configured tunneling to achieve IPv6, 2) Requiring that MPLS network support setting up IPv6 LSPs, and IPv6 connectivity is set up using these or configured tunneling, 3) Using only configured tunneling over IPv4 LSPs, or 4) Using something like [BGPTUNNEL] to automatically encapsulate IPv6 over IPv4 over MPLS to obtain IPv6 connectivity. Based on a quick operator poll, software upgrades in MPLS networks are acceptable. Due to that, the main reason to use a mechanism like BGPTUNNEL appears to be to get around the vendor's shortcomings in IPv6 forwarding performance in the core network, so marketing solution such as this might have disadvantages in the medium and long term, at least. We're soliciting input on how to best handle this situation. Please send feedback to the chairs or on the list. Tentatively, we're scheduling 20-30 minutes for discussion in Seoul, but how productive such discussion would be would depend on the framing and the contents of presentations and/or discussion. Please send your ideas (if any). Thanks, Pekka & Jonne From owner-v6ops@ops.ietf.org Wed Feb 11 13:24:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12472 for ; Wed, 11 Feb 2004 13:24:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqz1U-000A1C-8l for v6ops-data@psg.com; Wed, 11 Feb 2004 18:23:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqz1L-000A0U-SI for v6ops@ops.ietf.org; Wed, 11 Feb 2004 18:23:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1BINYx15638; Wed, 11 Feb 2004 20:23:34 +0200 Date: Wed, 11 Feb 2004 20:23:34 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: Opportunistic Tunneling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, As the Unmanaged Analysis document is currently at WG Last Call, the biggest issue appears to be the so-called "opportunistic tunneling", i.e., automatic tunneling which would be possible without set-up or ISP support. Examples of these are 6to4 and Teredo. (No other specific proposals have been made.) We need to figure out how to move forward. The critical questions are at least: 1) Do we agree that this is something we need in the first place? * Considering user-driven deployment, maybe not. - example: the user says "I want to use application X" or "I want to use functionality Y", where X or Y would require IPv6. * Considering large-scale vendor-centric deployment, probably yes. 2) What are the models for deploying relays, considering the economic or deployment considerations (in-host, in-site, network)? * And what are the implications of any approach? * Can we decide on the recommended model? 3) For NAT traversing, opportunistic tunneling, are there any features in Teredo which are missing or are unnecessary? I.e., how good a fit would it be? Are there alternatives? We're soliciting input on how to best handle this situation. Please send feedback to the chairs or on the list. Tentatively, we're scheduling 20-30 minutes for discussion in Seoul, but how productive such discussion would be would depend on the framing and the contents of presentations and/or discussion. Please send your ideas (if any). Thanks, Pekka & Jonne From owner-v6ops@ops.ietf.org Wed Feb 11 13:37:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12896 for ; Wed, 11 Feb 2004 13:37:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqzCo-000BP0-AB for v6ops-data@psg.com; Wed, 11 Feb 2004 18:35:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqzCm-000BOj-SF for v6ops@ops.ietf.org; Wed, 11 Feb 2004 18:35:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1BIZNY15893; Wed, 11 Feb 2004 20:35:23 +0200 Date: Wed, 11 Feb 2004 20:35:23 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: v6ops draft agenda for Seoul Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Below is a first draft of the agenda for Seoul. Please send feedback, agenda requests, etc. to the chairs. Thanks! ======================================== *DRAFT* *DRAFT* *DRAFT* v6ops agenda for Seoul IETF --------------------------- first session ============= Introduction and agenda bashing - 5 mins, Chairs/Jonne Document status - 10 mins, Chairs/Pekka - What has happened with WG documents lately - GOAL: show the status of WG documents ISP Scenarios/Solutions, 10 mins, M. Lind - draft-ietf-v6ops-isp-scenarios-analysis-01.txt - Discuss WG last call issues, try to build consensus if any hot issues - GOAL: Make it easier to revise the document and send it to the IESG Unmanaged Evaluation, 10 mins, one of the authors - draft-ietf-v6ops-unmaneval-01.txt - Discuss WG last call issues (if unresolved) - GOAL: Make it easier to revise the document and send it to the IESG Enterprise Scenarios, 10 mins, Chairs/Jonne? - draft-ietf-v6ops-ent-scenarios-01.txt - Discuss the changes, solicit feedback - GOAL: Prepare for WG Last Call. "Zero-configured" Tunneling Discussion, 30 mins, ???? - 3GPP UE Tunneling, Unmanaged tunnel service, something in enterprise? - [XXX: should this be held separately for each of the above?] - Main contenders: ISATAP, STEP, TSP, etc. - GOAL: try to be able to get closer to the consensus with the mechanisms than we are. Introducing IPv6 in MPLS Networks, 20 mins, ???? - Discuss the approaches: configured tunneling, signalling upgrade, BGP tunneling hacks, etc.? - GOAL: try to get closer to consensus on what's required to use IPv6 in MPLS-based networks. Opportunistic Tunneling (esp. NAT traversal) Discussion, 20 mins, ???? - Do we agree that this is something we need in the first place? * And if so, in which specific scenarios? - What are the models for deploying relays (in-host, in-site vs network)? What are the implications? - GOAL: try to get closer to consensus on what's the right approach for opportunistic tunneling. Quarantine Security Model - 10 mins, Satoshi Kando? - draft-kondo-quarantine-overview-00.txt - quick overview of a possible security model for IPv6 - GOAL: introduce the issue, to be fully discussed in security area another slot ============ [If good discussion is generated on the discussion items on the first session, add time to discuss those here] Transition mechanisms update, 10 mins, Chairs/Pekka? - draft-ietf-v6ops-mech-v2-02.txt - should be already at the IESG, discuss issues if any - Discuss implementation reports / interop testing - GOAL: Iron out last-minute issues, and make it easier to go to DS 6to4 Security Considerations, 10 mins, P. Savola - draft-ietf-v6ops-6to4-security-01.txt - discuss changes, solicit input whether the substantial changes to the document layout helped. - GOAL: prepare the document for WG last call Statistics from a 6to4 Relay - 5 mins, Pekka Savola - (no draft) - quick presentation on the usage statistics from a public 6to4 relay - GOAL: give the WG an impression about the traffic on 6to4 relays IPv6 Security Overview - 10 mins, Pekka Savola - draft-savola-v6ops-security-overview-01.txt - discuss changes. - GOAL: discuss whether something like this is needed as WG item, adapt if so. IPv6-on-by-Default/On-link-bydefault tradeoffs - 15 mins, Sebastien Roy? - draft-ietf-v6ops-v6onbydefault-xx.txt - draft-ietf-v6ops-onlinkassumption-xx.txt - discuss WG last call issues if held yet, or changes in general - GOAL: make it ready to ship these off after Seoul IPv6 Applications Transition, 10 mins, Myung-Ki Shin - draft-ietf-v6ops-application-transition-xx.txt - discuss issues, if any, prior to the last call. - GOAL: make it easier to ship the document to the IESG. IPv6 Renumbering Procedures, 10 mins, Fred Baker? - draft-ietf-v6ops-ipv6-renumber-procedure-00.txt - discuss changes, WG last call issues (if held yet) - GOAL: make it easier to ship the document to the IESG. From owner-v6ops@ops.ietf.org Wed Feb 11 15:19:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19675 for ; Wed, 11 Feb 2004 15:19:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar0n9-000Nv1-Qw for v6ops-data@psg.com; Wed, 11 Feb 2004 20:17:03 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar0my-000NuP-Rc for v6ops@ops.ietf.org; Wed, 11 Feb 2004 20:16:52 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 27929C3; Thu, 12 Feb 2004 05:16:52 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: Opportunistic Tunneling In-Reply-To: Your message of "Wed, 11 Feb 2004 20:23:34 +0200 (EET)" References: X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040211201652.27929C3@coconut.itojun.org> Date: Thu, 12 Feb 2004 05:16:52 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > As the Unmanaged Analysis document is currently at WG Last Call, the > biggest issue appears to be the so-called "opportunistic tunneling", > i.e., automatic tunneling which would be possible without set-up or > ISP support. Examples of these are 6to4 and Teredo. (No other > specific proposals have been made.) We need to figure out how to move > forward. The critical questions are at least: > > 1) Do we agree that this is something we need in the first place? > * Considering user-driven deployment, maybe not. > - example: the user says "I want to use application X" or "I > want to use functionality Y", where X or Y would require > IPv6. > * Considering large-scale vendor-centric deployment, probably > yes. > > 2) What are the models for deploying relays, considering the economic > or deployment considerations (in-host, in-site, network)? > * And what are the implications of any approach? > * Can we decide on the recommended model? > > 3) For NAT traversing, opportunistic tunneling, are there any > features in Teredo which are missing or are unnecessary? I.e., > how good a fit would it be? Are there alternatives? 4) security implication of such technology. for instance, 6to4 relay router can easily abused. how about Teredo, and other technologies? itojun From owner-v6ops@ops.ietf.org Wed Feb 11 16:29:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27311 for ; Wed, 11 Feb 2004 16:29:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar1sc-0006Hw-LR for v6ops-data@psg.com; Wed, 11 Feb 2004 21:26:46 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar1sb-0006GL-5f for v6ops@ops.ietf.org; Wed, 11 Feb 2004 21:26:45 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id BD253803E for ; Wed, 11 Feb 2004 22:26:42 +0100 (CET) From: "Jeroen Massar" To: Subject: Proposal for shutdown of ip6.int? Date: Wed, 11 Feb 2004 22:26:00 +0100 Organization: Unfix Message-ID: <00a001c3f0e5$a593cdd0$210d640a@unfix.org> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hi, Now that we have seen a RFC arise for e.f.f.3.ip6.arpa and there apparently will be a deployment shortly, wouldn't it be a good idea to start planning a closure of the usage of ip6.int ? ip6.arpa was set as a standard 2 years ago by RFC3152 which is also a BCP. All software vendors have to do is s/ip6.int/ip6.arpa/ in their code. They don't need any fallbacks to ip6.int thus there should be no big coding problem. As for the existing deployments, they already knew for 2 years that this was going to happen. To give the people in 6bone some time to create a ip6.arpa version of their zone by doing some mv's and reloading their nameserver and to, not forget, let the operators of e.f.f.3.ip6.arpa create the delegations to the pTLA's, which are going per 6/6/6 and let IANA have some time to actually delegate the tree a date should be picked somewhat over a year in the future. I propose 6/6/2005 as a nice cutoff date for ip6.int. This should give enough time to let above things happen. People not updating in this timeframe, won't update anyways. Greets, Jeroen PS: Yes, I am still using 6bone space myself. -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQCqd2ymqKFIzPnwjEQIILwCfXAjHwxVWXRHWhpHix6LlFUumwgEAnjpS AwC8XYmt02sXp3o7/aZ/SOVl =V1ve -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Feb 11 17:05:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01474 for ; Wed, 11 Feb 2004 17:05:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar2SF-000AxZ-5j for v6ops-data@psg.com; Wed, 11 Feb 2004 22:03:35 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar2SD-000AxE-EX for v6ops@ops.ietf.org; Wed, 11 Feb 2004 22:03:33 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1BM3Pf02501; Wed, 11 Feb 2004 23:03:25 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1BM3PSj076412; Wed, 11 Feb 2004 23:03:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402112203.i1BM3PSj076412@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jeroen Massar" cc: v6ops@ops.ietf.org Subject: Re: Proposal for shutdown of ip6.int? In-reply-to: Your message of Wed, 11 Feb 2004 22:26:00 +0100. <00a001c3f0e5$a593cdd0$210d640a@unfix.org> Date: Wed, 11 Feb 2004 23:03:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: To give the people in 6bone some time to create a ip6.arpa version of their zone by doing some mv's and reloading their nameserver and to, not forget, let the operators of e.f.f.3.ip6.arpa create the delegations to the pTLA's, which are going per 6/6/6 and let IANA have some time to actually delegate the tree a date should be picked somewhat over a year in the future. I propose 6/6/2005 as a nice cutoff date for ip6.int. => IMHO it will take more time to forget ip6.int than to move all 6bone nodes to RIR allocated stuff. So if we need easy to remember dates I think that 6/7/2008 is better. This should give enough time to let above things happen. People not updating in this timeframe, won't update anyways. => 5 year old is not very old for a box... PS: Yes, I am still using 6bone space myself. => me too (:-)! Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Feb 11 17:12:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02310 for ; Wed, 11 Feb 2004 17:12:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar2ZC-000CDT-CD for v6ops-data@psg.com; Wed, 11 Feb 2004 22:10:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar2ZB-000CDD-1J for v6ops@ops.ietf.org; Wed, 11 Feb 2004 22:10:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1BMAcD20688; Thu, 12 Feb 2004 00:10:38 +0200 Date: Thu, 12 Feb 2004 00:10:38 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org, Subject: Re: Opportunistic Tunneling In-Reply-To: <20040211201652.27929C3@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 12 Feb 2004, Jun-ichiro itojun Hagino wrote: [...] > > 4) security implication of such technology. for instance, 6to4 relay > router can easily abused. how about Teredo, and other technologies? Certainly, this is an important factor. However, problem with "security" is that we must somehow be able to quantify and evaluate it. How much is enough? A couple of possibilities w.r.t. deployment have been proposed earlier, which mitigate this; at least: a) don't deploy relays at all, period. Users of a transition mechanism can only talk to the users of the same transition mechanism. Creates separate IPv6 Internets, but is not necessarily only a bad thing. b) deploy relays, if possible "internal to the node". I.e., recommend that all dual-stack nodes include some kind of minimalistic relay functionality. Similar to above, implying that all nodes would act similarly has having all the transition mechanisms. (This works with Teredo, but not with 6to4.) c) deploy relays inside the dual-stack sites, not in the general Internet. This might lower the abuse problems a little bit. (The relay is held responsible for abuse.) [ and the current thinking, at least with 6to4 : ] d) deploy relays anywhere in the Internet. Only, options b) through d) seem to be against economic realities (see the unmanaged analysis document) and shifting the burden of transition mechanisms to those who implement proper dual-stack, and a) would be creating separate Internets. It's worth remembering my point about "user-centric" vs. "vendor-centric" deployment models. With vendor-centric, a mechanism like 6to4 or Teredo is a pretty much a must. With user-centric, that's not necessarily the case. We have only bad choices, I fear. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Feb 11 17:16:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03155 for ; Wed, 11 Feb 2004 17:16:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar2dZ-000Cjl-Pm for v6ops-data@psg.com; Wed, 11 Feb 2004 22:15:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar2dT-000Cis-UN for v6ops@ops.ietf.org; Wed, 11 Feb 2004 22:15:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1BMExw20778; Thu, 12 Feb 2004 00:14:59 +0200 Date: Thu, 12 Feb 2004 00:14:59 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: v6ops@ops.ietf.org Subject: Re: Proposal for shutdown of ip6.int? In-Reply-To: <00a001c3f0e5$a593cdd0$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Jeroen Massar wrote: > Now that we have seen a RFC arise for e.f.f.3.ip6.arpa > and there apparently will be a deployment shortly, > wouldn't it be a good idea to start planning a closure > of the usage of ip6.int ? Hasn't that closure already been planned a couple of years ago? Due to some techno-political crap it just never seems to happen :) As soon as the 6bone space is available through ip6.arpa, I think the resolvers should remove support for ip6.int. That'll force (more or less) people who wouldn't be otherwise bothered to change from ip6.int to ip6.arpa. Or, if that just doesn't seem to happen, just switch off ip6.int anyway. That should encourage (at least a bit) folks to run shut down their 6bone swamps. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Feb 11 17:33:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04431 for ; Wed, 11 Feb 2004 17:33:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar2sW-000EPv-CA for v6ops-data@psg.com; Wed, 11 Feb 2004 22:30:44 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Ar2sP-000EPA-2R for v6ops@ops.ietf.org; Wed, 11 Feb 2004 22:30:37 +0000 Received: (qmail 30464 invoked by uid 1007); 11 Feb 2004 22:30:35 -0000 Date: Wed, 11 Feb 2004 23:30:35 +0100 From: Gert Doering To: Francis Dupont Cc: Jeroen Massar , v6ops@ops.ietf.org Subject: Re: Proposal for shutdown of ip6.int? Message-ID: <20040211223035.GN8040@Space.Net> References: <00a001c3f0e5$a593cdd0$210d640a@unfix.org> <200402112203.i1BM3PSj076412@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402112203.i1BM3PSj076412@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, Feb 11, 2004 at 11:03:25PM +0100, Francis Dupont wrote: > I propose 6/6/2005 as a nice cutoff date for ip6.int. > > => IMHO it will take more time to forget ip6.int than to move > all 6bone nodes to RIR allocated stuff. So if we need easy to > remember dates I think that 6/7/2008 is better. Shutting down ip6.int has nothing to do with renumbering 6bone nodes. This is about reverse DNS only... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) 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 Wed Feb 11 17:46:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05666 for ; Wed, 11 Feb 2004 17:46:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar36V-000Fyd-2V for v6ops-data@psg.com; Wed, 11 Feb 2004 22:45:11 +0000 Received: from [80.126.101.63] (helo=spock.rvdp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar36R-000Fy7-3g for v6ops@ops.ietf.org; Wed, 11 Feb 2004 22:45:07 +0000 Received: by spock.rvdp.org (Postfix, from userid 545) id 1E0BD1E8355; Wed, 11 Feb 2004 23:45:05 +0100 (CET) Date: Wed, 11 Feb 2004 23:45:05 +0100 From: Ronald van der Pol To: "Bound, Jim" Cc: Ronald van der Pol , v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt Message-ID: <20040211224505.GA412@rvdp.org> References: <9C422444DE99BC46B3AD3C6EAFC9711B05837125@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B05837125@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Feb 11, 2004 at 11:38:57 -0500, Bound, Jim wrote: > just a question? these notes were in the previous draft I am confused. > just checking. Very interesting. I don't know what happened there. I got an old version, but I am quite sure I looked at the -01 version. Anyway, the URL now points to a version without ***Notes. I will read it tomorrow and comment on it. Sorry for the confusion. rvdp From owner-v6ops@ops.ietf.org Wed Feb 11 18:26:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09511 for ; Wed, 11 Feb 2004 18:26:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar3iS-000JEM-DG for v6ops-data@psg.com; Wed, 11 Feb 2004 23:24:24 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar3iR-000JEA-Ab for v6ops@ops.ietf.org; Wed, 11 Feb 2004 23:24:23 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 7F0871006; Thu, 12 Feb 2004 00:24:22 +0100 (CET) Date: Thu, 12 Feb 2004 00:24:22 +0100 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: Proposal for shutdown of ip6.int? Message-ID: <20040212002422.B6167@homebase.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: <00a001c3f0e5$a593cdd0$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: ; from pekkas@netcore.fi on Thu, Feb 12, 2004 at 12:14:59AM +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Feb 12, 2004 at 12:14:59AM +0200, Pekka Savola wrote: > As soon as the 6bone space is available through ip6.arpa, I think the > resolvers should remove support for ip6.int. That'll force (more or > less) people who wouldn't be otherwise bothered to change from ip6.int > to ip6.arpa. > > Or, if that just doesn't seem to happen, just switch off ip6.int > anyway. That should encourage (at least a bit) folks to run shut down > their 6bone swamps. Amen. I see no real problem in just shutting down ip6.int. We should get rid of it as quickly as possible. Those who care abour reverse DNS will already have ip6.arpa delegations or be very quick in getting one. Regards, Daniel From owner-v6ops@ops.ietf.org Wed Feb 11 18:28:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09833 for ; Wed, 11 Feb 2004 18:28:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar3lJ-000JQN-U0 for v6ops-data@psg.com; Wed, 11 Feb 2004 23:27:21 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar3lF-000JQ0-16 for v6ops@ops.ietf.org; Wed, 11 Feb 2004 23:27:17 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Feb 2004 15:27:16 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Feb 2004 15:28:01 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Feb 2004 15:27:15 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Feb 2004 15:27:12 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Feb 2004 15:27:14 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Feb 2004 15:27:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Opportunistic Tunneling Date: Wed, 11 Feb 2004 15:27:06 -0800 Message-ID: Thread-Topic: Opportunistic Tunneling Thread-Index: AcPw3gDODNmTKRsxTIWba0xjQETYiQAF8pOg From: "Christian Huitema" To: "Jun-ichiro itojun Hagino" , Cc: , X-OriginalArrivalTime: 11 Feb 2004 23:27:52.0097 (UTC) FILETIME=[AB2CD910:01C3F0F6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > As the Unmanaged Analysis document is currently at WG Last Call, the > > biggest issue appears to be the so-called "opportunistic tunneling", > > i.e., automatic tunneling which would be possible without set-up or > > ISP support. Examples of these are 6to4 and Teredo. (No other > > specific proposals have been made.) We need to figure out how to move > > forward. The critical questions are at least: > > > > 1) Do we agree that this is something we need in the first place? > > * Considering user-driven deployment, maybe not. > > - example: the user says "I want to use application X" or "I > > want to use functionality Y", where X or Y would require > > IPv6. > > * Considering large-scale vendor-centric deployment, probably > > yes. The reality is that 6to4 and Teredo solution are being deployed, so I wonder whether we really need a long discussion about whether or not they are needed. It would perhaps be more important to discuss how the deployment can be tuned... > > 2) What are the models for deploying relays, considering the economic > > or deployment considerations (in-host, in-site, network)? > > * And what are the implications of any approach? > > * Can we decide on the recommended model? The unmaneval draft includes a section that discussed these points. > > 3) For NAT traversing, opportunistic tunneling, are there any > > features in Teredo which are missing or are unnecessary? I.e., > > how good a fit would it be? Are there alternatives? > > 4) security implication of such technology. for instance, 6to4 > relay > router can easily abused. how about Teredo, and other > technologies? The Teredo draft includes a rather extensive security analysis. Obviously, we may have missed some threats, but we certainly thought hard about it. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Feb 11 18:30:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10049 for ; Wed, 11 Feb 2004 18:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar3nC-000JYE-OR for v6ops-data@psg.com; Wed, 11 Feb 2004 23:29:18 +0000 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Ar3n8-000JXR-0P for v6ops@ops.ietf.org; Wed, 11 Feb 2004 23:29:14 +0000 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 11 Feb 2004 23:29:12 +0000 (GMT) Date: Wed, 11 Feb 2004 23:29:12 +0000 From: David Malone To: Pekka Savola Cc: Jeroen Massar , v6ops@ops.ietf.org Subject: Re: Proposal for shutdown of ip6.int? Message-ID: <20040211232912.GA42477@walton.maths.tcd.ie> References: <00a001c3f0e5$a593cdd0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Feb 12, 2004 at 12:14:59AM +0200, Pekka Savola wrote: > As soon as the 6bone space is available through ip6.arpa, I think the > resolvers should remove support for ip6.int. That'll force (more or > less) people who wouldn't be otherwise bothered to change from ip6.int > to ip6.arpa. Is it my imagination, or are chunks of the ip6.int tree still broken by various odd deligations? y.ip6.int and z.ip6.int don't seem to agree with other name servers and are deligating to some lame servers. I'd guess this is a pretty strong motivation to move to ip6.arpa. David. servers: y.ip6.int z.ip6.int 7.0.1.0.0.2.ip6.int. 86400 IN NS auth03.ns.uu.net. 7.0.1.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 7.0.1.0.0.2.ip6.int. 86400 IN NS munnari.oz.au. 7.0.1.0.0.2.ip6.int. 86400 IN NS ns.apnic.net. Lame? 7.0.1.0.0.2.ip6.int. 86400 IN NS ns.ripe.net. 7.0.1.0.0.2.ip6.int. 86400 IN NS ns3.nic.fr. 7.0.1.0.0.2.ip6.int. 86400 IN NS sunic.sunet.se. 7.0.1.0.0.2.ip6.int. 86400 IN NS svc00.apnic.net. Lame? servers: ns3.nic.fr flag.ep.net ns.ripe.net munnari.oz.au 7.0.1.0.0.2.ip6.int. 432000 IN NS auth03.ns.uu.net. 7.0.1.0.0.2.ip6.int. 432000 IN NS munnari.oz.au. 7.0.1.0.0.2.ip6.int. 432000 IN NS ns.ripe.net. 7.0.1.0.0.2.ip6.int. 432000 IN NS ns3.nic.fr. 7.0.1.0.0.2.ip6.int. 432000 IN NS sec1.apnic.net. 7.0.1.0.0.2.ip6.int. 432000 IN NS sec3.apnic.net. 7.0.1.0.0.2.ip6.int. 432000 IN NS sunic.sunet.se. 7.0.1.0.0.2.ip6.int. 432000 IN NS tinnie.arin.net. From owner-v6ops@ops.ietf.org Wed Feb 11 22:20:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20889 for ; Wed, 11 Feb 2004 22:20:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar7LD-000DRR-Th for v6ops-data@psg.com; Thu, 12 Feb 2004 03:16:39 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar7LC-000DRF-N4 for v6ops@ops.ietf.org; Thu, 12 Feb 2004 03:16:38 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1C3Gacj010649 for ; Wed, 11 Feb 2004 22:16:36 -0500 (EST) Date: Wed, 11 Feb 2004 22:16:29 -0500 From: Marc Blanchet To: v6ops@ops.ietf.org Subject: I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-00.txt (fwd) Message-ID: <384900000.1076555789@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========245AE7105448038B8A84==========" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00, MIME_SUSPECT_NAME autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --==========245AE7105448038B8A84========== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit FYI, an update on TSP draft, as many requested. Marc. ---------- Forwarded Message ---------- Date: Tuesday, February 10, 2004 15:58:28 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce CC: Subject: I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP) Author(s) : M. Blanchet Filename : draft-blanchet-v6ops-tunnelbroker-tsp-00.txt Pages : 21 Date : 2004-2-10 A tunnel broker with the Tunnel Setup Protocol(TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negociate the tunnel with the broker. The negociation involves authentication, authorization, tunnel information such as IP addresses, prefixes when the client is a router, DNS information such as the NS for the inverse zone corresponding to the delegated prefix, etc. Some parameters may be proposed by the broker, such as the transport over UDP IPv4 where an IPv4 NAT is found in the path between the client and the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether he is on IPv4, IPv4 behind a NAT or on IPv6. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-tunnelbroker-tsp-0 0.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-blanchet-v6ops-tunnelbroker-tsp-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-blanchet-v6ops-tunnelbroker-tsp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- End Forwarded Message ---------- ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ --==========245AE7105448038B8A84========== Content-Type: message/rfc822; name="I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-00.txt" Return-Path: Received: from ex.hexago.com ([unix socket]) by ex.hexago.com (Cyrus v2.2.2-BETA) with LMTP; Tue, 10 Feb 2004 17:27:46 -0500 X-Sieve: CMU Sieve 2.2 Received: from sonata.hexago.com (sonata.hexago.com [IPv6:2001:5c0:0:1::2]) by ex.hexago.com ( hexago/8.12.9) with ESMTP id i1AMRkc6006980; Tue, 10 Feb 2004 17:27:46 -0500 (EST) (envelope-from owner-ietf-announce@ietf.org) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by sonata.hexago.com ( Hexago/8.12.8) with ESMTP id i1AMRdvZ041774; Tue, 10 Feb 2004 17:27:39 -0500 (EST) (envelope-from owner-ietf-announce@ietf.org) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1Aqeyr-0008Gi-Om for ietf-announce-list@asgard.ietf.org; Tue, 10 Feb 2004 15:59:41 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1Aqexi-0008B8-Fk for all-ietf@asgard.ietf.org; Tue, 10 Feb 2004 15:58:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14109 for ; Tue, 10 Feb 2004 15:58:28 -0500 (EST) Message-Id: <200402102058.PAA14109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-00.txt Date: Tue, 10 Feb 2004 15:58:28 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Virus-Flag: NO X-Spam-Flag: NO X-Spam-Score: 2.4 X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP) Author(s) : M. Blanchet Filename : draft-blanchet-v6ops-tunnelbroker-tsp-00.txt Pages : 21 Date : 2004-2-10 A tunnel broker with the Tunnel Setup Protocol(TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negociate the tunnel with the broker. The negociation involves authentication, authorization, tunnel information such as IP addresses, prefixes when the client is a router, DNS information such as the NS for the inverse zone corresponding to the delegated prefix, etc. Some parameters may be proposed by the broker, such as the transport over UDP IPv4 where an IPv4 NAT is found in the path between the client and the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether he is on IPv4, IPv4 behind a NAT or on IPv6. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-tunnelbroker-tsp-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-blanchet-v6ops-tunnelbroker-tsp-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-blanchet-v6ops-tunnelbroker-tsp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10154053.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-blanchet-v6ops-tunnelbroker-tsp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-blanchet-v6ops-tunnelbroker-tsp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10154053.I-D@ietf.org> --OtherAccess-- --NextPart-- --==========245AE7105448038B8A84==========-- From owner-v6ops@ops.ietf.org Thu Feb 12 01:58:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28084 for ; Thu, 12 Feb 2004 01:58:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArAl3-000IMo-IW for v6ops-data@psg.com; Thu, 12 Feb 2004 06:55:33 +0000 Received: from [213.200.88.213] (helo=mx1.ip.tiscali.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1ArAkm-000IFq-3Q for v6ops@ops.ietf.org; Thu, 12 Feb 2004 06:55:16 +0000 Received: (qmail 71262 invoked from network); 12 Feb 2004 06:55:13 -0000 Received: from unknown (HELO shekinah.ip.tiscali.net) (213.200.88.76) by smtp.ip.tiscali.net with SMTP; 12 Feb 2004 06:55:13 -0000 Received: from ako by shekinah.ip.tiscali.net with local (Exim 4.30 #1) id 1ArAkj-0007pg-MY; Thu, 12 Feb 2004 07:55:13 +0100 Date: Thu, 12 Feb 2004 07:55:13 +0100 From: Alexander Koch To: Jeroen Massar Cc: v6ops@ops.ietf.org Subject: Re: Proposal for shutdown of ip6.int? Message-ID: <20040212065513.GB30054@shekinah.ip.tiscali.net> References: <00a001c3f0e5$a593cdd0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a001c3f0e5$a593cdd0$210d640a@unfix.org> Organization: Tiscali International Network B.V. X-NCC-RegID: eu.nacnet User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 11 February 2004 22:26:00 +0100, Jeroen Massar wrote: > Now that we have seen a RFC arise for e.f.f.3.ip6.arpa > and there apparently will be a deployment shortly, > wouldn't it be a good idea to start planning a closure > of the usage of ip6.int ? Yes, I am all for it. I am sick of games here, and it might speed things up, so let us try to make it work right, and better, IMHO. -ako From owner-v6ops@ops.ietf.org Thu Feb 12 08:44:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23740 for ; Thu, 12 Feb 2004 08:44:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArH3U-000878-UX for v6ops-data@psg.com; Thu, 12 Feb 2004 13:39:00 +0000 Received: from [213.154.224.65] (helo=spock.rvdp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArH3R-00086m-Lh for v6ops@ops.ietf.org; Thu, 12 Feb 2004 13:38:57 +0000 Received: by spock.rvdp.org (Postfix, from userid 545) id 204EA1F06CC; Thu, 12 Feb 2004 14:38:53 +0100 (CET) Date: Thu, 12 Feb 2004 14:38:53 +0100 From: Ronald van der Pol To: "Bound, Jim" Cc: Ronald van der Pol , v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt Message-ID: <20040212133853.GA10836@rvdp.org> References: <9C422444DE99BC46B3AD3C6EAFC9711B05837125@tayexc13.americas.cpqcorp.net> <20040211224505.GA412@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040211224505.GA412@rvdp.org> User-Agent: Mutt/1.4.2i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Feb 11, 2004 at 23:45:05 +0100, Ronald van der Pol wrote: > I will read it tomorrow and comment > on it. Sorry for the confusion. General: I find it hard to comment in detail. Basically, the document is an extensive (and good) list of all the issues that must be handled when introducing IPv6 in an enterprise. However, many items are not "the business of the IETF". There are also few requirements written down. Much depends on how the analysis document handles all the issues. I think the focus should go now to the analysis. section 3.2: s/IPv6 address ownership/IPv6 address assignment/ In the 'Network Infrastructure Component 3" is says: - Other services (e.g. NTP, etc.........) Those ..... look like something to be filled in. Please remove in final version. section 3.3: _maybe_ s/Example Network A:/Example Network A (base scenario 1):/ etc. sections 4.1 to 4.3 seem to be analysis instead of requirements. I would like to see a preference for dual-stack and v4-in-v6 tunnels instead of translation, but this is something for the analysis document. Maybe sections 4.1 to 4.3 could mention the cases: node is v4-only, dual stack or v6-only and network is v4-only, dual stack or v6-only? section 5.8 Has also quite some analysis already. An interesting point would be: is there a requirement for v4-v6 multicast interoperability? If so, that could be a recommendation to the IETF. I miss thing like: renumbering, stable addresses and things like that. I thought ipv6 is working on non-routable unique addresses because of the strong demand from enterprises. Maybe a section about this could be added. (yes, I know; easier said than done :-) rvdp From owner-v6ops@ops.ietf.org Thu Feb 12 09:25:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25188 for ; Thu, 12 Feb 2004 09:25:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArHkU-000GEI-Ob for v6ops-data@psg.com; Thu, 12 Feb 2004 14:23:26 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArHkT-000GE5-KE for v6ops@ops.ietf.org; Thu, 12 Feb 2004 14:23:25 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id CF86F15B; Thu, 12 Feb 2004 23:23:24 +0900 (JST) To: jeroen@unfix.org Cc: v6ops@ops.ietf.org Subject: Re: Proposal for shutdown of ip6.int? In-Reply-To: Your message of "Wed, 11 Feb 2004 22:26:00 +0100" <00a001c3f0e5$a593cdd0$210d640a@unfix.org> References: <00a001c3f0e5$a593cdd0$210d640a@unfix.org> X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040212142324.CF86F15B@coconut.itojun.org> Date: Thu, 12 Feb 2004 23:23:24 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Now that we have seen a RFC arise for e.f.f.3.ip6.arpa > and there apparently will be a deployment shortly, > wouldn't it be a good idea to start planning a closure > of the usage of ip6.int ? > > ip6.arpa was set as a standard 2 years ago by RFC3152 > which is also a BCP. i believe it best to wait until e.f.f.3.ip6.arpa gets actually installed in some way (DNAME, two "master" config, whatever). at this point of time there's no e.f.f.3.ip6.arpa so 6bone address reverse resolution sorely depend on ip6.int. itojun From owner-v6ops@ops.ietf.org Thu Feb 12 14:05:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07415 for ; Thu, 12 Feb 2004 14:05:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArM5l-0006oP-2U for v6ops-data@psg.com; Thu, 12 Feb 2004 19:01:41 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArM5g-0006o9-PW for v6ops@ops.ietf.org; Thu, 12 Feb 2004 19:01:36 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 12 Feb 2004 20:02:11 +0100 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1CJ1AL1008469; Thu, 12 Feb 2004 20:01:10 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Feb 2004 19:01:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 in MPLS Networks Date: Thu, 12 Feb 2004 19:01:33 -0000 Message-ID: Thread-Topic: IPv6 in MPLS Networks Thread-Index: AcPwzCZv53VZx2hCQx+CbP+74P0SKgAtBIIg From: "Francois Le Faucheur (flefauch)" To: "Pekka Savola" , Cc: X-OriginalArrivalTime: 12 Feb 2004 19:01:33.0974 (UTC) FILETIME=[A1E28360:01C3F19A] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org=20 >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola >> Sent: mercredi 11 f=E9vrier 2004 19:21 >> To: v6ops@ops.ietf.org >> Cc: jonne.soininen@nokia.com >> Subject: IPv6 in MPLS Networks >>=20 >>=20 >> Hi, >>=20 >> As ISP scenarios and analysis document is currently at last=20 >> call, the=20 >> biggest issue (excluding the tunnel service considerations,=20 >> which need=20 >> resolving in other documents as well) seems to be the=20 >> recommendations/text about IPv6 deployment in MPLS networks. >>=20 >> The possibilities (or a combination of these) include at least: >>=20 >> 1) Requiring that MPLS networks deploy native IPv6 support or use >> configured tunneling to achieve IPv6, >>=20 >> 2) Requiring that MPLS network support setting up IPv6 LSPs, >> and IPv6 connectivity is set up using these or configured=20 >> tunneling, >>=20 >> 3) Using only configured tunneling over IPv4 LSPs, or >>=20 >> 4) Using something like [BGPTUNNEL] to automatically=20 >> encapsulate IPv6=20 >> over IPv4 over MPLS to obtain IPv6 connectivity. >>=20 >> Based on a quick operator poll, software upgrades in MPLS=20 >> networks are >> acceptable. =20 From the description of the question asked in the "poll", it seems to = indicates that software upgrades have been done in the past and probably = will have to be done again in the future to fix something or get some = new functionality (given no other choice). Sure. I believe a poll with additional questions would indicate that : (i) nonetheless, there is a strong desire to keep the MPLS core stable = and therefore, where possible, a preference for avoiding to activate new = functionality in that core; (ii) given the choice to start-off a new service via a method which = requires no new functionality in the core OR via another method which = requires activating new routing/config/forwarding, some of these = operators will be favoring a method which leaves the core untouched, at = least for some period of time. >>Due to that, the main reason to use a mechanism like >> BGPTUNNEL appears to be to get around the vendor's shortcomings in >> IPv6 forwarding performance in the core network,=20 Yes, taking advantage of MPLS performance when those are higher than = IPv6 performance on the installed equipment is a motivation. >>so=20 >> marketing solution >> such as this might have disadvantages in the medium and long term, at >> least. Yes, BGP-TUNNEL is a designed as a migration approach to handle current = situation. The proposal is to refer to it as a valid migration approach = to handle current situation. >>=20 >> We're soliciting input on how to best handle this situation. Please >> send feedback to the chairs or on the list. Tentatively, we're >> scheduling 20-30 minutes for discussion in Seoul, but how productive >> such discussion would be would depend on the framing and the contents >> of presentations and/or discussion. >> =20 I will not attend the Seoul meeting. So here's my suggestion again (and = then I'll shut up): I suggest that the isp-scenario draft indicates that BGP-TUNNEL is a = valid option where: - the MPLS operator wants to take advantage of higher MPLS forwarding = performance than IPv6 forwrading performance on installed core equipment = and/or - the MPLS operator wants to protect the stability of the core and, for = some time, avoid/postpone activating new routing/config/forwarding in = the core. Thanks Francois =20 >> =20 >> Please send your ideas (if any). >> =20 >> =20 >> Thanks, >> Pekka & Jonne >>=20 >>=20 >>=20 From owner-v6ops@ops.ietf.org Thu Feb 12 14:30:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08692 for ; Thu, 12 Feb 2004 14:30:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArMVh-000BqX-42 for v6ops-data@psg.com; Thu, 12 Feb 2004 19:28:29 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArMVe-000BqJ-SH for v6ops@ops.ietf.org; Thu, 12 Feb 2004 19:28:27 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08458; Thu, 12 Feb 2004 14:28:25 -0500 (EST) Message-Id: <200402121928.OAA08458@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-unmaneval-01.txt Date: Thu, 12 Feb 2004 14:28:25 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Evaluation of Transition Mechanisms for Unmanaged Networks Author(s) : C. Huitema Filename : draft-ietf-v6ops-unmaneval-01.txt Pages : 17 Date : 2004-2-9 In a companion paper we defined the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-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-unmaneval-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-unmaneval-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: <2004-2-12145320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unmaneval-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unmaneval-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-12145320.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Feb 13 08:49:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09205 for ; Fri, 13 Feb 2004 08:49:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArddP-000IQK-68 for v6ops-data@psg.com; Fri, 13 Feb 2004 13:45:35 +0000 Received: from [61.140.60.71] (helo=21cn.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1ArddI-000IPO-B2 for v6ops@ops.ietf.org; Fri, 13 Feb 2004 13:45:28 +0000 Received: from summit([127.0.0.1]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm0402d3a1e; Fri, 13 Feb 2004 21:38:31 +0800 Received: from summit([61.149.211.106]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Fri, 13 Feb 2004 21:38:31 +0800 Message-ID: <001701c3f237$f7dd1490$413fec96@summit> From: "Green" To: Cc: , , , Subject: draft-shirasaki-dualstack-service-02.txt CPE assigned Host Address Lifetime issue Date: Fri, 13 Feb 2004 21:41:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN, RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, all: I have a question regarding the following paragraph in draft-shirasaki-dualstack-service-02.txt: ==> 2.4. Address Assignment CPE assigns global-scope /64 prefixes subnetted from the delegated prefix to its downstream interfaces. In the case where the delegated prefix has infinite lifetimes, the preferred and valid lifetimes of assigned /64 prefixes should be their default values in [RFC2461]. ==> According to this draft, the CPE gets a (non-link-local) prefix (possibly /48) using DHCP from the BRAS after successful PPoE initiation. The CPE then delegate the prefix's subnet to its host-facing links. The subnet prefixes is advertised on the links using RA, with the prefered and valid lifetime using default values in rfc2461, which is 7days and 30 days. Certainly I understand these default value could be overrided by manual configuration on CPE router, but since CPE router is supposed to be an unmanaged device installed in customer home, such assumption can be dropped. Problem may arise when the PPPoE session is terminated between the CPE and BRAs, in a case other than CPE powering off or customer disconnect the hosts (PCs), and then the PPPoE session between the two gets re-established. In this case, the CPE will get a new prefix using DHCP from the BRAS (Although Radius extension can be configured to make sure the same customer line, or CPE MAC address, or user id will be assigned the same prefix in some cases, generally I think the CPE will just get a new Prefix just like nowadays's dial-up getting a new IPv4 address everytime you dial), and the CPE will delegate new subnet prefixes to its links. So now the hosts (PCs) will have an old non-link-local IPv6 address, with its lifetime still valid for the next week or month, and receives a new non-link-local IPv6 address. When sending out packets, it will have to make a default address selection based on the two source addresses. It will have good chance of selecting the old address, which the BRAS doesn't have a clue when forwarding packet back to this (destination) address. DHCPv6 can reclaim the assigned addresses from its clients, but stateless auto-configuration can't do the same, unless the Router Advertisement from which this Prefix Information option was obtained has been authenticated, (quoting from RFC 2462 - IPv6 Stateless Address Autoconfiguration 5.5.3 Router Advertisement Processing) which is obviously not the case between CPE and hosts (Home PC). So, the CPE can't force the hosts to make the old address expire explicitly, the above mentioned problem will occur. Please comment, I am eager to know the answer. And, I am very curious of the CPE used in NTT's deployment, is there any more information on that available? Green Guo Limin limin.guo@ericsson.com Ericsson China From owner-v6ops@ops.ietf.org Sun Feb 15 20:56:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07966 for ; Sun, 15 Feb 2004 20:56:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsXv7-000JNA-MY for v6ops-data@psg.com; Mon, 16 Feb 2004 01:51:37 +0000 Received: from [210.163.36.2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsXv3-000JMf-K7 for v6ops@ops.ietf.org; Mon, 16 Feb 2004 01:51:33 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [IPv6:2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 28BAA1FE47; Mon, 16 Feb 2004 10:51:31 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 70668125A33; Mon, 16 Feb 2004 10:51:31 +0900 (JST) Date: Mon, 16 Feb 2004 10:51:31 +0900 (JST) Message-Id: <20040216.105131.74697490.yasuhiro@nttv6.jp> To: quartets@21cn.com Cc: v6ops@ops.ietf.org, miyakawa@nttv6.jp, t.yamasaki@ntt.com, ayako.takenouchi@ntt.com Subject: Re: draft-shirasaki-dualstack-service-02.txt CPE assigned Host Address Lifetime issue From: SHIRASAKI Yasuhiro In-Reply-To: <001701c3f237$f7dd1490$413fec96@summit> References: <001701c3f237$f7dd1490$413fec96@summit> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 13 Feb 2004 21:41:24 +0800, "Green" wrote: > Problem may arise when the PPPoE session is terminated between the CPE and > BRAs, in a case other than CPE powering off or customer disconnect the hosts > (PCs), and then the PPPoE session between the two gets re-established. > > In this case, the CPE will get a new prefix using DHCP from the BRAS > (Although Radius extension can be configured to make sure the same customer > line, or CPE MAC address, or user id will be assigned the same prefix in > some cases, generally I think the CPE will just get a new Prefix just like > nowadays's dial-up getting a new IPv4 address everytime you dial), and the > CPE will delegate new subnet prefixes to its links. We've been using a Framed-IPv6-Prefix radius attribute for a persistent prefix assignment in our current service, so there has been no change of delegating prefixes. This is what infinity lifetimes of prefixes in the DHCPv6-PD means in our service. But we might need to think about the problem you pointed out when we'll start prefix-pool based service. > So now the hosts (PCs) will have an old non-link-local IPv6 address, with > its lifetime still valid for the next week or month, and receives a new > non-link-local IPv6 address. When sending out packets, it will have to make > a default address selection based on the two source addresses. It will have > good chance of selecting the old address, which the BRAS doesn't have a clue > when forwarding packet back to this (destination) address. I've just checked two implementations and noticed a different behavior against prefix changes. When the CPE changed advertising prefixes in a flash, one implementation did the things as you mentioned, but the another one has revoked an old prefix immidiately and started communications with a new prefix only. If all hosts behave as the latter implementation, we don't need any special treatment with prefix changes... Anyway, it's reasonable that CPEs have stable storage retain delegated prefixes and advertise old prefixes with pltime = 0, vltime = 2hour, when the delegated prefix was changed. -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Sun Feb 15 21:39:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10054 for ; Sun, 15 Feb 2004 21:39:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsYdm-0001pX-SG for v6ops-data@psg.com; Mon, 16 Feb 2004 02:37:46 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsYdl-0001pJ-OQ for v6ops@ops.ietf.org; Mon, 16 Feb 2004 02:37:45 +0000 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9F0CE15218; Mon, 16 Feb 2004 11:37:44 +0900 (JST) Date: Mon, 16 Feb 2004 11:37:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: SHIRASAKI Yasuhiro Cc: quartets@21cn.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp, t.yamasaki@ntt.com, ayako.takenouchi@ntt.com Subject: Re: draft-shirasaki-dualstack-service-02.txt CPE assigned Host Address Lifetime issue In-Reply-To: <20040216.105131.74697490.yasuhiro@nttv6.jp> References: <001701c3f237$f7dd1490$413fec96@summit> <20040216.105131.74697490.yasuhiro@nttv6.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (I've not fully been following this thread, but) >>>>> On Mon, 16 Feb 2004 10:51:31 +0900 (JST), >>>>> SHIRASAKI Yasuhiro said: >> So now the hosts (PCs) will have an old non-link-local IPv6 address, with >> its lifetime still valid for the next week or month, and receives a new >> non-link-local IPv6 address. When sending out packets, it will have to make >> a default address selection based on the two source addresses. It will have >> good chance of selecting the old address, which the BRAS doesn't have a clue >> when forwarding packet back to this (destination) address. > I've just checked two implementations and noticed a different behavior > against prefix changes. When the CPE changed advertising prefixes > in a flash, one implementation did the things as you mentioned, > but the another one has revoked an old prefix immidiately and started > communications with a new prefix only. If all hosts behave as > the latter implementation, we don't need any special treatment > with prefix changes... Please let me check, are you talking about a host that behaves like this? - the host receives a prefix P via RA from a router, and configures an address P:A. - then the router stops advertising the prefix P, and starts advertising another prefix Q. - the host receives the new RAs with prefix Q, and configures a new address Q:A. At this stage, the preferred and valid lifetimes of the old address does not expire. However, the host never uses the old address as the source address even if RFC3484 suggests the old address be preferred. If so, I'd say the host is not fully compliant (at least not compliant to RFC3484), and network operators should not assume such a behavior. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Sun Feb 15 23:39:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13026 for ; Sun, 15 Feb 2004 23:39:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsaTl-000Klr-Tg for v6ops-data@psg.com; Mon, 16 Feb 2004 04:35:33 +0000 Received: from [210.163.36.2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsaTb-000Kl4-8S for v6ops@ops.ietf.org; Mon, 16 Feb 2004 04:35:23 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [IPv6:2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id A40D01FE47; Mon, 16 Feb 2004 13:35:22 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 2765C125A33; Mon, 16 Feb 2004 13:35:22 +0900 (JST) Date: Mon, 16 Feb 2004 13:35:21 +0900 (JST) Message-Id: <20040216.133521.41684842.yasuhiro@nttv6.jp> To: jinmei@isl.rdc.toshiba.co.jp Cc: quartets@21cn.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp, t.yamasaki@ntt.com, ayako.takenouchi@ntt.com Subject: Re: draft-shirasaki-dualstack-service-02.txt CPE assigned Host Address Lifetime issue From: SHIRASAKI Yasuhiro In-Reply-To: References: <001701c3f237$f7dd1490$413fec96@summit> <20040216.105131.74697490.yasuhiro@nttv6.jp> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 16 Feb 2004 11:37:51 +0900, JINMEI Tatuya / $B?@L@C#:H(B wrote: > >> So now the hosts (PCs) will have an old non-link-local IPv6 address, with > >> its lifetime still valid for the next week or month, and receives a new > >> non-link-local IPv6 address. When sending out packets, it will have to make > >> a default address selection based on the two source addresses. It will have > >> good chance of selecting the old address, which the BRAS doesn't have a clue > >> when forwarding packet back to this (destination) address. > > > I've just checked two implementations and noticed a different behavior > > against prefix changes. When the CPE changed advertising prefixes > > in a flash, one implementation did the things as you mentioned, > > but the another one has revoked an old prefix immidiately and started > > communications with a new prefix only. If all hosts behave as > > the latter implementation, we don't need any special treatment > > with prefix changes... > > Please let me check, are you talking about a host that behaves like > this? > > - the host receives a prefix P via RA from a router, and configures an > address P:A. > - then the router stops advertising the prefix P, and starts > advertising another prefix Q. > - the host receives the new RAs with prefix Q, and configures a new > address Q:A. At this stage, the preferred and valid lifetimes of > the old address does not expire. However, the host never uses the > old address as the source address even if RFC3484 suggests the > old address be preferred. > > If so, I'd say the host is not fully compliant (at least not compliant > to RFC3484), and network operators should not assume such a behavior. Exactly. I got your point, but if so, in the situation where delegated prefix is volatile (like PD with prefix-pool, as Green mentioned), how CPE should do? - CPE sets preferred lifetime in RA with very small value (ex. 1 min) and advertises with a short period (20sec?). - CPE has a stable storage and advertises an old prefix with pltime = 0, when CPE reboots accidentally and a delegated prefix is changed. -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Mon Feb 16 00:17:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13905 for ; Mon, 16 Feb 2004 00:17:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asb6R-0001na-Vk for v6ops-data@psg.com; Mon, 16 Feb 2004 05:15:31 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asb6R-0001nM-3I for v6ops@ops.ietf.org; Mon, 16 Feb 2004 05:15:31 +0000 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5827315214; Mon, 16 Feb 2004 14:15:30 +0900 (JST) Date: Mon, 16 Feb 2004 14:15:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: SHIRASAKI Yasuhiro Cc: quartets@21cn.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp, t.yamasaki@ntt.com, ayako.takenouchi@ntt.com Subject: Re: draft-shirasaki-dualstack-service-02.txt CPE assigned Host Address Lifetime issue In-Reply-To: <20040216.133521.41684842.yasuhiro@nttv6.jp> References: <001701c3f237$f7dd1490$413fec96@summit> <20040216.105131.74697490.yasuhiro@nttv6.jp> <20040216.133521.41684842.yasuhiro@nttv6.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Mon, 16 Feb 2004 13:35:21 +0900 (JST), >>>>> SHIRASAKI Yasuhiro said: >> If so, I'd say the host is not fully compliant (at least not compliant >> to RFC3484), and network operators should not assume such a behavior. > Exactly. > I got your point, but if so, in the situation where delegated prefix is > volatile (like PD with prefix-pool, as Green mentioned), how CPE should do? > - CPE sets preferred lifetime in RA with very small value (ex. 1 min) > and advertises with a short period (20sec?). > - CPE has a stable storage and advertises an old prefix with pltime > = 0, when CPE reboots accidentally and a delegated prefix is changed. For the reboot case, perhaps a desirable behavior is: - detect the old prefix is now invalid (as described in Section 12.1 of RFC3633) - advertise the old prefix with zero lifetimes for a while. The zero preferred lifetime will deprecate the old address immediately. The zero valid lifetime will at least reduce the corresponding valid lifetime to two hours, and the old address will be removed in two hours. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Mon Feb 16 00:39:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14648 for ; Mon, 16 Feb 2004 00:39:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsbRO-0005qm-0r for v6ops-data@psg.com; Mon, 16 Feb 2004 05:37:10 +0000 Received: from [210.163.36.2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsbRD-0005hJ-Cw for v6ops@ops.ietf.org; Mon, 16 Feb 2004 05:36:59 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [IPv6:2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id A157F1FE47; Mon, 16 Feb 2004 14:36:58 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 29469125A33; Mon, 16 Feb 2004 14:36:58 +0900 (JST) Date: Mon, 16 Feb 2004 14:36:57 +0900 (JST) Message-Id: <20040216.143657.71140684.yasuhiro@nttv6.jp> To: jinmei@isl.rdc.toshiba.co.jp Cc: quartets@21cn.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp, t.yamasaki@ntt.com, ayako.takenouchi@ntt.com Subject: Re: draft-shirasaki-dualstack-service-02.txt CPE assigned Host Address Lifetime issue From: SHIRASAKI Yasuhiro In-Reply-To: References: <20040216.133521.41684842.yasuhiro@nttv6.jp> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 16 Feb 2004 14:15:36 +0900, JINMEI Tatuya / $B?@L@C#:H(B wrote: > >>>>> On Mon, 16 Feb 2004 13:35:21 +0900 (JST), > >>>>> SHIRASAKI Yasuhiro said: > > >> If so, I'd say the host is not fully compliant (at least not compliant > >> to RFC3484), and network operators should not assume such a behavior. > > > Exactly. > > > I got your point, but if so, in the situation where delegated prefix is > > volatile (like PD with prefix-pool, as Green mentioned), how CPE should do? > > > - CPE sets preferred lifetime in RA with very small value (ex. 1 min) > > and advertises with a short period (20sec?). > > - CPE has a stable storage and advertises an old prefix with pltime > > = 0, when CPE reboots accidentally and a delegated prefix is changed. > > For the reboot case, perhaps a desirable behavior is: > > - detect the old prefix is now invalid (as described in Section 12.1 > of RFC3633) > > - advertise the old prefix with zero lifetimes for a while. The zero > preferred lifetime will deprecate the old address immediately. The > zero valid lifetime will at least reduce the corresponding valid > lifetime to two hours, and the old address will be removed in two > hours. Agreed. so that, CPE must have a stable storage to store the old prefix. -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Mon Feb 16 10:36:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25698 for ; Mon, 16 Feb 2004 10:36:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AskjO-000FYT-8Z for v6ops-data@psg.com; Mon, 16 Feb 2004 15:32:22 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AskjK-000FY0-Tv for v6ops@ops.ietf.org; Mon, 16 Feb 2004 15:32:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24995; Mon, 16 Feb 2004 10:32:15 -0500 (EST) Message-Id: <200402161532.KAA24995@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-application-transition-01.txt Date: Mon, 16 Feb 2004 10:32:15 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Application Aspects of IPv6 Transition Author(s) : M. Shin Filename : draft-ietf-v6ops-application-transition-01.txt Pages : 30 Date : 2004-2-13 As IPv6 networks are deployed and the network transition discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and what is the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-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-application-transition-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-application-transition-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: <2004-2-16104524.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-application-transition-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-application-transition-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16104524.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Feb 16 15:43:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20619 for ; Mon, 16 Feb 2004 15:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AspWd-000POL-K3 for v6ops-data@psg.com; Mon, 16 Feb 2004 20:39:31 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AspWY-000PNJ-5d for v6ops@ops.ietf.org; Mon, 16 Feb 2004 20:39:26 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19726; Mon, 16 Feb 2004 15:39:23 -0500 (EST) Message-Id: <200402162039.PAA19726@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-v6onbydefault-01.txt Date: Mon, 16 Feb 2004 15:39:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Dual Stack IPv6 on by Default Author(s) : S. Roy Filename : draft-ietf-v6ops-v6onbydefault-01.txt Pages : 15 Date : 2004-2-16 This document discusses problems that can occur when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The problems include application connection delays, poor connectivity, and network security. Its purpose is to raise awareness of these problems so that they can be fixed or worked around. The purpose of this document is not to try to specify whether IPv6 should be enabled by default or not, but to raise awareness of the potential issues involved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-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-v6onbydefault-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-v6onbydefault-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: <2004-2-16122906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-v6onbydefault-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16122906.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Feb 16 17:18:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01923 for ; Mon, 16 Feb 2004 17:18:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asr1i-000AXE-D5 for v6ops-data@psg.com; Mon, 16 Feb 2004 22:15:42 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asr1g-000AWu-DC for v6ops@ops.ietf.org; Mon, 16 Feb 2004 22:15:40 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 20-md50000000315.tmp for ; Mon, 16 Feb 2004 23:19:55 +0100 Message-ID: <04c401c3f4da$fca07d50$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <200402161532.KAA24995@ietf.org> Subject: Re: I-D ACTION:draft-ietf-v6ops-application-transition-01.txt Date: Mon, 16 Feb 2004 23:19:45 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 16 Feb 2004 23:19:55 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Just found a couple of errors. 1. various kinds of transition mechanisms have been developed to migrate = to IPv6 network replace with "various kinds of transition mechanisms have been developed = to do the transition to IPv6 networks" or "various kinds of transition mechanisms have been developed for the = transition to IPv6 networks" (other combinations possible, key point is avoid using = "migration/migrate", and probably use networks instead of network) 3.2 DNS does not indicate which the IP version will be used replace with "DNS does not indicate which IP version will be used" Regards, Jordi ----- Original Message -----=20 From: To: Cc: Sent: Monday, February 16, 2004 4:32 PM Subject: I-D ACTION:draft-ietf-v6ops-application-transition-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : Application Aspects of IPv6 Transition > Author(s) : M. Shin > Filename : draft-ietf-v6ops-application-transition-01.txt > Pages : 30 > Date : 2004-2-13 >=20 > As IPv6 networks are deployed and the network transition discussed, > one should also consider how to enable IPv6 support in applications > running on IPv6 hosts, and what is the best strategy to develop IP > protocol support in applications. This document specifies > scenarios and aspects of application transition. It also proposes > guidelines on how to develop IP version-independent applications > during the transition period. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transiti= on-01.txt >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body of the = message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the = username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-v6ops-application-transition-01.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE = /internet-drafts/draft-ietf-v6ops-application-transition-01.txt". >=20 > 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. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Feb 17 03:48:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17253 for ; Tue, 17 Feb 2004 03:48:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1At0mj-000JLU-I6 for v6ops-data@psg.com; Tue, 17 Feb 2004 08:40:53 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At0mc-000JL8-Ij for v6ops@ops.ietf.org; Tue, 17 Feb 2004 08:40:46 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 13-md50000000322.tmp for ; Tue, 17 Feb 2004 09:45:04 +0100 Message-ID: <00e801c3f532$504c6660$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Opportunistic Tunneling Date: Tue, 17 Feb 2004 09:44:51 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 17 Feb 2004 09:45:04 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, I believe proto-41 is also one of the proposals on the table for both = unmanaged and 3GPP. For example, TSP can make use of it. We also have a Tunnel Broker = implementation that does. Trying to answer to your questions, in my opinion, and I know other = people with same or similar thoughts, this work for unmanaged, 3GPP and = other scenarios is required. When users start moving with IPv6 devices, we need to ensure that they = are able to use it, despite what network they are sitting on. I've this experience myself, traveling ... and I can solve it manually = most of the time, but the users don't know how to. It should be = automatic. There are already applications that only work with IPv6, a few at the = time being, but more coming, for sure. The reason is that you need = addresses, for example to access multiple devices that are located = behind a NAT box. If those devices have IPv6, even with a tunnel, that's fine, it works. I = can tell you as I know very well, I've my home connected like that :-) In Euro6IX we are already working around this idea, but we don't have a = draft ready for this meeting, unfortunately. Basically we call it = "auto-transition". We need to ensure that the best possible transition = mechanism work automatically at any time, in any network. At the same = time we need to look were to deploy the 6to4, Teredo, or other relays = (or equivalent), how to announce/select them even depending on their = load, bandwidth, ..., for example using BGP, anycast, DNS, .... We also = are studying the business case of that models (including deployment in = IXs). If needed, I've a few slides about this. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: Cc: Sent: Wednesday, February 11, 2004 7:23 PM Subject: Opportunistic Tunneling > Hi, >=20 > As the Unmanaged Analysis document is currently at WG Last Call, the > biggest issue appears to be the so-called "opportunistic tunneling", > i.e., automatic tunneling which would be possible without set-up or > ISP support. Examples of these are 6to4 and Teredo. (No other > specific proposals have been made.) We need to figure out how to move > forward. The critical questions are at least: >=20 > 1) Do we agree that this is something we need in the first place? > * Considering user-driven deployment, maybe not. > - example: the user says "I want to use application X" or "I=20 > want to use functionality Y", where X or Y would require=20 > IPv6. > * Considering large-scale vendor-centric deployment, probably=20 > yes. >=20 > 2) What are the models for deploying relays, considering the economic = > or deployment considerations (in-host, in-site, network)? > * And what are the implications of any approach? > * Can we decide on the recommended model? >=20 > 3) For NAT traversing, opportunistic tunneling, are there any=20 > features in Teredo which are missing or are unnecessary? I.e., > how good a fit would it be? Are there alternatives? >=20 > We're soliciting input on how to best handle this situation. Please > send feedback to the chairs or on the list. Tentatively, we're > scheduling 20-30 minutes for discussion in Seoul, but how productive > such discussion would be would depend on the framing and the contents > of presentations and/or discussion. > = =20 > Please send your ideas (if any). > = =20 > Thanks, > Pekka & Jonne > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Feb 18 12:44:31 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02041 for ; Wed, 18 Feb 2004 12:44:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtVgv-0006On-5b for v6ops-data@psg.com; Wed, 18 Feb 2004 17:40:57 +0000 Received: from [128.176.191.5] (helo=ovaron.join.uni-muenster.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsjzE-0004OP-Sv for v6ops@ops.ietf.org; Mon, 16 Feb 2004 14:44:41 +0000 Received: from LEMY.UNI-MUENSTER.DE (LEMY.UNI-MUENSTER.DE [128.176.184.238]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.10/8.12.9) with ESMTP id i1GEiY4h008925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 16 Feb 2004 15:44:39 +0100 (CET) Subject: Guide to map v4 addresses into v6 address space From: Christian Schild To: v6ops@ops.ietf.org Content-Type: text/plain Message-Id: <1076942674.18873.113.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-1mdk Date: Mon, 16 Feb 2004 15:44:34 +0100 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, when deploying IPv6 in a network the need arises to assign prefixes to present and future subnets and to split up the 16 bit of the users routing space in a hopefully systematic manner. While there are several ways to do so, one of them is to map the already used IPv4 adresses and subnets to IPv6 subnets. This will most probably happen in an environment where IPv6 functionality is added to a well deployed IPv4 infrastructure. We present a systematic method to map IPv4 addresses to IPv6 which will help adminstrators to do so and to decide if this method is a viable option for their needs and for their network. We'd love to get some feedback on this. Please find the summary and a link to the I-D below. So long, Christian ----- Title : Guide to Mapping IPv4 to IPv6 Subnets Author(s) : C. Schild, C. Strauf Filename : draft-schild-v6ops-guide-v4mapping-00.txt Pages : 20 Date : 2004-1-29 This document is intended to be a guide for network administrators of enterprise sized sites that employ the Internet Protocol Version 4 (IPv4) and who would like to introduce the Internet Protocol Version 6 (IPv6) dual-stack. It applies to scenarios where IPv4 subnets must be mapped to IPv6 subnets for management purposes while keeping the option to create IPv6 subnets in parallel and independently in the future with almost no restrictions; it is not meant to be applied to scenarios where a native IPv6 address plan can be created easily and without the need to map IPv4 subnets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schild-v6ops-guide-v4mapping-00.txt -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: schild@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653 From owner-v6ops@ops.ietf.org Wed Feb 18 12:44:36 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02059 for ; Wed, 18 Feb 2004 12:44:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtVhS-0006TP-Nb for v6ops-data@psg.com; Wed, 18 Feb 2004 17:41:30 +0000 Received: from [217.32.164.139] (helo=i2kc05-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At9Xs-000M3y-0I for v6ops@ops.ietf.org; Tue, 17 Feb 2004 18:02:08 +0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Feb 2004 18:02:06 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Feb 2004 18:02:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Date: Tue, 17 Feb 2004 18:02:06 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A70059D3962@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Thread-Index: AcPswbHAcFFQFCmwQKWIsYjfONVmTAAAfPIgAi84MuA= From: To: Cc: , X-OriginalArrivalTime: 17 Feb 2004 18:02:06.0586 (UTC) FILETIME=[279F0DA0:01C3F580] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Tim, Francois pointed out an email you commented on regarding who is actually = using it? Well be may not have it deployed, but this is something BT may consider = using to start IPv6 deployment in the future. However as you should = know it wont happen if the standards are not their. Well it doesn't = help, lets put it that way. Best Regards, Stuart -----Original Message----- From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 Sent: 06 February 2004 15:19 To: FLF Subject: FW: WG Last Call: = draft-ietf-v6ops-isp-scenarios-analysis-01.txt you guys may want to comment on that question? >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org=20 >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown >> Sent: vendredi 6 f=E9vrier 2004 15:49 >> To: v6ops@ops.ietf.org >> Subject: Re: WG Last Call:=20 >> draft-ietf-v6ops-isp-scenarios-analysis-01.txt >>=20 >>=20 >> Why is BGPTUNNEL recommended in this analysis? >>=20 >> Who is actually using it? >>=20 >> Also, the draft version in the analysis should be 01 not 00,=20 >> if it does >> stay in as a clearly marked last resort method... >>=20 >> Tim >>=20 >> On Fri, Feb 06, 2004 at 09:46:11AM -0000, Francois Le=20 >> Faucheur (flefauch) wrote: >> > Hi, >> >=20 >> > Suggestion for "8.2 Example 2" >> >=20 >> > Perhaps=20 >> >=20 >> > " IPv6 deployment might start with an upgrade of a couple=20 >> of PE routers to support [BGPTUNNEL], because this will=20 >> allow large-scale IPv6 support without hardware or software=20 >> upgrades in the core. " >> >=20 >> > would read better as: >> >=20 >> > " IPv6 deployment might start with an upgrade of PE=20 >> routers to support [BGPTUNNEL] (starting perhaps by a couple=20 >> PE routers and then extending to other PEs as needed),=20 >> because this will allow large-scale IPv6 support without=20 >> hardware or software upgrades in the core. " >> >=20 >> > Otherwise, it sounds like deploying on two boxes gives=20 >> "large scale support". >> >=20 >> > Cheers >> >=20 >> > Francois >> >=20 >> > >> -----Original Message----- >> > >> From: owner-v6ops@ops.ietf.org=20 >> > >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola >> > >> Sent: vendredi 6 f=E9vrier 2004 06:59 >> > >> To: v6ops@ops.ietf.org >> > >> Cc: jonne.soininen@nokia.com; mikael.lind@teliasonera.com >> > >> Subject: WG Last Call:=20 >> draft-ietf-v6ops-isp-scenarios-analysis-01.txt >> > >>=20 >> > >>=20 >> > >> Hi all, >> > >>=20 >> > >> This is a WG Last Call for comments on sending >> > >> draft-ietf-v6ops-isp-scenarios-analysis-01.txt, " Scenarios and >> > >> Analysis for Introducing IPv6 into ISP Networks" to the IESG for >> > >> consideration as BCP: >> > >>=20 >> >=20 >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scen arios-analysis-01.txt >=20 > Please review these documents carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this = document > is ready to go to the IESG. >=20 > There has been a lack of extensive reviews from the start, so=20 > reviewing this document would be especially welcome. >=20 > The last call will end in about 2.5 weeks, on 24th February. >=20 > Pekka & Jonne >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Feb 19 04:02:46 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06308 for ; Thu, 19 Feb 2004 04:02:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atk14-0002fn-FL for v6ops-data@psg.com; Thu, 19 Feb 2004 08:58:42 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtbkG-000Bzu-9Y for v6ops@ops.ietf.org; Thu, 19 Feb 2004 00:08:48 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1J08T828297; Wed, 18 Feb 2004 16:08:29 -0800 X-mProtect: <200402190008> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpde1qdpI; Wed, 18 Feb 2004 16:08:28 PST Message-Id: <4.3.2.7.2.20040212131502.02fae7f8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Feb 2004 16:04:54 -0800 To: Pekka Savola , jonne.soininen@nokia.com From: Bob Hinden Subject: Re: Opportunistic Tunneling Cc: v6ops@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka & Jonne, >As the Unmanaged Analysis document is currently at WG Last Call, the >biggest issue appears to be the so-called "opportunistic tunneling", >i.e., automatic tunneling which would be possible without set-up or >ISP support. Examples of these are 6to4 and Teredo. (No other >specific proposals have been made.) We need to figure out how to move I thought ISTAP fell into this category as well? There have been a seres of drafts. >forward. The critical questions are at least: > > 1) Do we agree that this is something we need in the first place? > * Considering user-driven deployment, maybe not. > - example: the user says "I want to use application X" or "I > want to use functionality Y", where X or Y would require > IPv6. > * Considering large-scale vendor-centric deployment, probably > yes. Yes, it is needed. Not all ISPs will initially offer IPv6 and having these tunneling mechanism will allow people to still use IPv6 without any direct action of their ISP. I think this is essential to getting IPv6 used by people and to encourage new applications. I also think it will have the effect of encouraging ISP to deploy native IPv6 once the see the automatic tunneled traffic growing. I don't think we want these "transition mechanisms" to be around forever (or even a long time) as we know their limitations, but I think they are very important the beginning of the transition. > 2) What are the models for deploying relays, considering the economic > or deployment considerations (in-host, in-site, network)? > * And what are the implications of any approach? > * Can we decide on the recommended model? I think the answer to this can be found by looking at what is deployed now. In any case, I didn't think the IETF needs to be discussion economic models. > 3) For NAT traversing, opportunistic tunneling, are there any > features in Teredo which are missing or are unnecessary? I.e., > how good a fit would it be? Are there alternatives? Given there is already a lot of operational experience we should standardize it now. It can be revised later based on additional operational experience. There isn't any reason to delay this further. >We're soliciting input on how to best handle this situation. Please I think that these mechanisms should be standardized as soon as possible. There is a need and people are already staring to ship these in products. There should be open standards for the mechanisms to allow everyone to deploy and use them if they want to. >send feedback to the chairs or on the list. Tentatively, we're >scheduling 20-30 minutes for discussion in Seoul, but how productive >such discussion would be would depend on the framing and the contents >of presentations and/or >discussion. > Thanks, Bob From owner-v6ops@ops.ietf.org Thu Feb 19 05:39:05 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13006 for ; Thu, 19 Feb 2004 05:39:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtlXi-000EFJ-Ma for v6ops-data@psg.com; Thu, 19 Feb 2004 10:36:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtlXf-000EEl-Ac for v6ops@ops.ietf.org; Thu, 19 Feb 2004 10:36:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1JAaQ318955 for ; Thu, 19 Feb 2004 12:36:26 +0200 Date: Thu, 19 Feb 2004 12:36:26 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: I-D ACTION:draft-savola-v6ops-security-overview-02.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI. ---------- Forwarded message ---------- Date: Wed, 18 Feb 2004 09:39:50 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-v6ops-security-overview-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Transition/Co-existence Security Considerations Author(s) : P. Savola Filename : draft-savola-v6ops-security-overview-02.txt Pages : 14 Date : 2004-2-18 The transition/co-existance from IPv4 to IPv4/IPv6 causes one to consider the security considerations of such a process. In this memo, I try to give an overview of different aspects relating to IPv6 grouped in three categories: issues due to IPv6 protocol itself, issues due to transition mechanisms, and issues due to IPv6 deployment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-security-overview-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-v6ops-security-overview-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-security-overview-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Thu Feb 19 05:56:43 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13637 for ; Thu, 19 Feb 2004 05:56:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atlpm-000GnR-IF for v6ops-data@psg.com; Thu, 19 Feb 2004 10:55:10 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atlpb-000GlW-3Z for v6ops@ops.ietf.org; Thu, 19 Feb 2004 10:54:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1JAsuX19155; Thu, 19 Feb 2004 12:54:56 +0200 Date: Thu, 19 Feb 2004 12:54:56 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: jonne.soininen@nokia.com, Subject: Re: Opportunistic Tunneling In-Reply-To: <4.3.2.7.2.20040212131502.02fae7f8@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for the feedback. Two comments inline. On Wed, 18 Feb 2004, Bob Hinden wrote: > >As the Unmanaged Analysis document is currently at WG Last Call, the > >biggest issue appears to be the so-called "opportunistic tunneling", > >i.e., automatic tunneling which would be possible without set-up or > >ISP support. Examples of these are 6to4 and Teredo. (No other > >specific proposals have been made.) We need to figure out how to move > > I thought ISTAP fell into this category as well? There have been a seres > of drafts. No, ISATAP is not really applicable AFAICS. Remember that the topic here is "opportunistic tunneling" -- with a requirement that the tunneling works independent of ISPs, automatically. ISATAP requires ISATAP router and set-up. On the other hand, when your ISP wants to give you IPv6 access using tunneling, ISATAP could be on the table (but that was a separate subject). [...] > > 2) What are the models for deploying relays, considering the economic > > or deployment considerations (in-host, in-site, network)? > > * And what are the implications of any approach? > > * Can we decide on the recommended model? > > I think the answer to this can be found by looking at what is deployed > now. In any case, I didn't think the IETF needs to be discussion economic > models. Economic models, to an extent, make deployments realistic (or not), so I personally think this is somewhat of a factor in the discussions whether to recommend some model for deployment. Of course, the IETF cannot _force_ anyone to a model. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Feb 19 09:37:32 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20126 for ; Thu, 19 Feb 2004 09:37:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtpG5-000Ola-4f for v6ops-data@psg.com; Thu, 19 Feb 2004 14:34:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtpG3-000OlD-EG for v6ops@ops.ietf.org; Thu, 19 Feb 2004 14:34:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1JEYOb21499; Thu, 19 Feb 2004 16:34:24 +0200 Date: Thu, 19 Feb 2004 16:34:24 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling In-Reply-To: <00e801c3f532$504c6660$870a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Responding a to few points you raised.. On Tue, 17 Feb 2004, JORDI PALET MARTINEZ wrote: > I believe proto-41 is also one of the proposals on the table for > both unmanaged and 3GPP. > > For example, TSP can make use of it. We also have a Tunnel Broker > implementation that does. Note that while proto-41 forwarding is probably useful in e.g. unmanaged scope in general, it is not really applicable to this specific topic, "opportunistic tunneling", where the tunneling is autoomatic, and requires no supporting ISPs. E.g., tunnel brokers are out of scope for this topic. Ignoring proto-41 however... [...] > When users start moving with IPv6 devices, we need to ensure that > they are able to use it, despite what network they are sitting on. > > I've this experience myself, traveling ... and I can solve it > manually most of the time, but the users don't know how to. It > should be automatic. > > There are already applications that only work with IPv6, a few at > the time being, but more coming, for sure. The reason is that you > need addresses, for example to access multiple devices that are > located behind a NAT box. I totally agree (about part of your statement) that tunneling should just work, whether the user is behind NAT or not. However, regarding this discussion, I'm not sure if you're actually taking a stance whether you you believe a mechanism like 6to4 or Teredo is *required*. That is, do you think the users must be able to switch on IPv6, without any interaction with any ISP, and have it work (at least with a subset of other IPv6 users)? Or do you think the user can be required to get a "tunnel broker" -like service (or whatever) from some ISP explicitly? [...] > In Euro6IX we are already working around this idea, but we don't > have a draft ready for this meeting, unfortunately. Basically we > call it "auto-transition". We need to ensure that the best possible > transition mechanism work automatically at any time, in any network. [...] Yep -- this is pretty important work, and one important issue in the unmanaged evaluation document (spanning both "opportunistic" and -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Feb 19 09:56:47 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21120 for ; Thu, 19 Feb 2004 09:56:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtpYr-00026u-ON for v6ops-data@psg.com; Thu, 19 Feb 2004 14:53:57 +0000 Received: from [62.225.183.202] (helo=mail1.telekom.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtpYp-00024G-IY for v6ops@ops.ietf.org; Thu, 19 Feb 2004 14:53:55 +0000 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 19 Feb 2004 15:53:54 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Feb 2004 15:53:54 +0100 Message-Id: From: "Bonness, Olaf" To: pekkas@netcore.fi, v6ops@ops.ietf.org Subject: AW: IPv6 in MPLS Networks Date: Thu, 19 Feb 2004 15:53:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, scanning my several mailing lists I found your email and want to provide my 2 cents to the discussion. IMHO the BGPTUNNEL approach is a solution which could serve ISPs with a very large MPLS infrastructure very well. The background of this is, that if a realy large ISP want's to implement a new service in it's platform (like IPv6) than it want's to touch as less as possible. BGPTUNNEL gives the ISP the possibility to leave the LSRs/PSs as they are (without any change in control or forwarding plane) and only the LERs/PEs have to be upgraded. The overhead for the IPv6 transport is only one MPLS label (which is IMHO acceptable) and this ensures that you get the same forwarding performance in the MPLS core (as for IPv4) and that you don't run in trouble with IPv6 routing insite your MPLS core. Besides that, the costs for updating the software of several thousands of routers are pretty high (in comparission to the actual IPv6 business case ;-), so that IMHO the BGPTUNNEL is a very good approach (at least for the first step !) for an IPv6 service offer based on a MPLS backbone. The later steps of an IPv6 integration could be than approach 2 and approach 1 from your email. (BTW sometimes you have to upgrade your HW as well if you want to realise "native" IPv6 MPLS and thats real expensive.) Best regards Olaf > -----Ursprungliche Nachricht----- > Von: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]Im > Auftrag von Pekka Savola > Gesendet: Mittwoch, 11. Februar 2004 19:21 > An: v6ops@ops.ietf.org > Cc: jonne.soininen@nokia.com > Betreff: IPv6 in MPLS Networks > > > Hi, > > As ISP scenarios and analysis document is currently at last call, the > biggest issue (excluding the tunnel service considerations, > which need > resolving in other documents as well) seems to be the > recommendations/text about IPv6 deployment in MPLS networks. > > The possibilities (or a combination of these) include at least: > > 1) Requiring that MPLS networks deploy native IPv6 support or use > configured tunneling to achieve IPv6, > > 2) Requiring that MPLS network support setting up IPv6 LSPs, > and IPv6 connectivity is set up using these or configured > tunneling, > > 3) Using only configured tunneling over IPv4 LSPs, or > > 4) Using something like [BGPTUNNEL] to automatically > encapsulate IPv6 > over IPv4 over MPLS to obtain IPv6 connectivity. > > Based on a quick operator poll, software upgrades in MPLS networks are > acceptable. Due to that, the main reason to use a mechanism like > BGPTUNNEL appears to be to get around the vendor's shortcomings in > IPv6 forwarding performance in the core network, so marketing solution > such as this might have disadvantages in the medium and long term, at > least. > > We're soliciting input on how to best handle this situation. Please > send feedback to the chairs or on the list. Tentatively, we're > scheduling 20-30 minutes for discussion in Seoul, but how productive > such discussion would be would depend on the framing and the contents > of presentations and/or discussion. > > > Please send your ideas (if any). > > > Thanks, > Pekka & Jonne > > From owner-v6ops@ops.ietf.org Thu Feb 19 12:15:19 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27618 for ; Thu, 19 Feb 2004 12:15:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atriz-000OlN-1p for v6ops-data@psg.com; Thu, 19 Feb 2004 17:12:33 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atrim-000Oh6-37 for v6ops@ops.ietf.org; Thu, 19 Feb 2004 17:12:20 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 19 Feb 2004 09:12:19 -0800 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Feb 2004 09:12:09 -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(6.0.3790.0); Thu, 19 Feb 2004 09:12:26 -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(6.0.3790.0); Thu, 19 Feb 2004 09:12:44 -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.3790.1069); Thu, 19 Feb 2004 09:12:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Opportunistic Tunneling Date: Thu, 19 Feb 2004 09:11:57 -0800 Message-ID: Thread-Topic: Opportunistic Tunneling Thread-Index: AcP214NFUoltjAdQSxiYFrPOVMvXZAAMrg9w From: "Christian Huitema" To: "Pekka Savola" , "Bob Hinden" Cc: , X-OriginalArrivalTime: 19 Feb 2004 17:12:22.0962 (UTC) FILETIME=[8A11A920:01C3F70B] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > I think the answer to this can be found by looking at what is deployed > > now. In any case, I didn't think the IETF needs to be discussion > economic > > models. >=20 > Economic models, to an extent, make deployments realistic (or not), so > I personally think this is somewhat of a factor in the discussions > whether to recommend some model for deployment. Of course, the IETF > cannot _force_ anyone to a model. I appreciate Pekka's concern for deployment, but I think that Bob is right. The bottom line is that the IETF is an engineering organization, and its members are not very qualified to assess business models, let alone mandate them. It certainly does not make sense to invest in a technology that cannot be deployed, and anyone designing a new protocol should concern themselves with deployment scenarios, e.g. what are the dependencies, do we need to boil the ocean for this thing to fly, and other such considerations. Indeed, when a technology requires third parties to deploy servers or other helpers, the technology promoters should have a plausible response to the question, "why would someone deploy your stuff". However, we have many examples of technologies that get deployed for entirely different reasons than those initially advanced. The Arpanet, for example, was supposed to provide better access to time-sharing mainframes, and we know what happened. So, while there is a need for some conscious reasoning about deployment, Bob's point is very valid. If a technology is in fact deployed, then the IETF should assume that someone somewhere saw a business case, and should not engage in a guessing exercise. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Feb 19 12:38:19 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28318 for ; Thu, 19 Feb 2004 12:38:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ats5i-0001rM-EM for v6ops-data@psg.com; Thu, 19 Feb 2004 17:36:02 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ats5g-0001r6-VR for v6ops@ops.ietf.org; Thu, 19 Feb 2004 17:36:01 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1JHZop12386; Thu, 19 Feb 2004 09:35:50 -0800 X-mProtect: <200402191735> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdohiKtH; Thu, 19 Feb 2004 09:35:47 PST Message-ID: <4034F400.90701@iprg.nokia.com> Date: Thu, 19 Feb 2004 09:36:00 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Bob Hinden , jonne.soininen@nokia.com, v6ops@ops.ietf.org, ftemplin@iprg.nokia.com Subject: Re: Opportunistic Tunneling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >No, ISATAP is not really applicable AFAICS. > Just to be sure we're on the same page, the current ISATAP draft version is: 'draft-ietf-ngtrans-isatap-20.txt'. Fred L. Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Feb 19 19:56:04 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07998 for ; Thu, 19 Feb 2004 19:56:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atyu1-0000Uz-9Q for v6ops-data@psg.com; Fri, 20 Feb 2004 00:52:25 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atytq-0000Tn-NL for v6ops@ops.ietf.org; Fri, 20 Feb 2004 00:52:14 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 42-md50000000006.tmp for ; Fri, 20 Feb 2004 01:56:36 +0100 Message-ID: <04af01c3f74c$581dd0b0$8d000a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Opportunistic Tunneling Date: Fri, 20 Feb 2004 01:56:14 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 20 Feb 2004 01:56:36 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, My reply in-line. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Thursday, February 19, 2004 3:34 PM Subject: Re: Opportunistic Tunneling > Responding a to few points you raised.. >=20 > On Tue, 17 Feb 2004, JORDI PALET MARTINEZ wrote: > > I believe proto-41 is also one of the proposals on the table for > > both unmanaged and 3GPP. > >=20 > > For example, TSP can make use of it. We also have a Tunnel Broker > > implementation that does. >=20 > Note that while proto-41 forwarding is probably useful in e.g.=20 > unmanaged scope in general, it is not really applicable to this=20 > specific topic, "opportunistic tunneling", where the tunneling is=20 > autoomatic, and requires no supporting ISPs. E.g., tunnel brokers are = > out of scope for this topic. >=20 > Ignoring proto-41 however... It will depend on what we consider "opportunistic". For me is clear that = we can have tunnel brokers that work like 6to4, i.e., no user = registration. Then you use proto-41 (or other means) ... also TSP here = can play the game, if no user authentication is required. >=20 > [...] > > When users start moving with IPv6 devices, we need to ensure that > > they are able to use it, despite what network they are sitting on. > >=20 > > I've this experience myself, traveling ... and I can solve it > > manually most of the time, but the users don't know how to. It > > should be automatic. > >=20 > > There are already applications that only work with IPv6, a few at > > the time being, but more coming, for sure. The reason is that you > > need addresses, for example to access multiple devices that are > > located behind a NAT box. >=20 > I totally agree (about part of your statement) that tunneling should=20 > just work, whether the user is behind NAT or not. >=20 > However, regarding this discussion, I'm not sure if you're actually=20 > taking a stance whether you you believe a mechanism like 6to4 or=20 > Teredo is *required*. That is, do you think the users must be able to = > switch on IPv6, without any interaction with any ISP, and have it work = > (at least with a subset of other IPv6 users)? Or do you think the=20 > user can be required to get a "tunnel broker" -like service (or=20 > whatever) from some ISP explicitly? Yes, I believe 6to4 and Teredo (or equivalent alternatives), are = required. And yes, users have the right to switch to IPv6 w/o any ISP interaction. Is the ISP business to provide a better service, add value, and gain or = lose users, and hopefully they will do, but not all them will do = initially until there is some number of users. The user can also choose to access via a TB or equivalent service. I'm not convinced however that we should have the users willing to = access IPv6 isolated from the rest of the IPv6 users ... > =20 > [...] > > In Euro6IX we are already working around this idea, but we don't > > have a draft ready for this meeting, unfortunately. Basically we > > call it "auto-transition". We need to ensure that the best possible > > transition mechanism work automatically at any time, in any network. > [...] >=20 > Yep -- this is pretty important work, and one important issue in the=20 > unmanaged evaluation document (spanning both "opportunistic" and=20 I miss the end of your sentence ;-) We will try to have something for the next San Diego meeting. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Feb 20 05:42:08 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14367 for ; Fri, 20 Feb 2004 05:42:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Au82J-000CMy-SN for v6ops-data@psg.com; Fri, 20 Feb 2004 10:37:35 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Au82I-000CMj-GG for v6ops@ops.ietf.org; Fri, 20 Feb 2004 10:37:34 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1KAbUT22198; Fri, 20 Feb 2004 12:37:30 +0200 (EET) X-Scanned: Fri, 20 Feb 2004 12:36:54 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1KAasQs000355; Fri, 20 Feb 2004 12:36:54 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00gcDNwj; Fri, 20 Feb 2004 12:36:53 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1KAam704319; Fri, 20 Feb 2004 12:36:48 +0200 (EET) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 20 Feb 2004 12:36:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Opportunistic Tunneling Date: Fri, 20 Feb 2004 12:36:46 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195B15F9B@esebe024.ntc.nokia.com> Thread-Topic: Opportunistic Tunneling Thread-Index: AcP214NFUoltjAdQSxiYFrPOVMvXZAAMrg9wACSogzA= From: To: , , Cc: X-OriginalArrivalTime: 20 Feb 2004 10:36:47.0432 (UTC) FILETIME=[7100F480:01C3F79D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, I think it is evident that the economical considerations are out of = IETF's scope. IETF is a global organization and even different countries = have different economical systems. In addition, different companies use = different models for their businesses. Of course, in the v6ops WG we have to use also the same principle as in = the other WGs: rough consensus, and runnig code. If there is deployment = there is definetely already running code.=20 Cheers, Jonne. > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 19 February, 2004 19:12 > To: Pekka Savola; Hinden Bob (Nokia-ES/MtView) > Cc: Soininen Jonne (Nokia-NET/Helsinki); v6ops@ops.ietf.org > Subject: RE: Opportunistic Tunneling >=20 >=20 >=20 > > > I think the answer to this can be found by looking at what is > deployed > > > now. In any case, I didn't think the IETF needs to be discussion > > economic > > > models. > >=20 > > Economic models, to an extent, make deployments realistic=20 > (or not), so > > I personally think this is somewhat of a factor in the discussions > > whether to recommend some model for deployment. Of course, the IETF > > cannot _force_ anyone to a model. >=20 > I appreciate Pekka's concern for deployment, but I think that Bob is > right. The bottom line is that the IETF is an engineering=20 > organization, > and its members are not very qualified to assess business models, let > alone mandate them. >=20 > It certainly does not make sense to invest in a technology that cannot > be deployed, and anyone designing a new protocol should concern > themselves with deployment scenarios, e.g. what are the=20 > dependencies, do > we need to boil the ocean for this thing to fly, and other such > considerations. Indeed, when a technology requires third parties to > deploy servers or other helpers, the technology promoters=20 > should have a > plausible response to the question, "why would someone deploy your > stuff". >=20 > However, we have many examples of technologies that get deployed for > entirely different reasons than those initially advanced. The Arpanet, > for example, was supposed to provide better access to time-sharing > mainframes, and we know what happened. So, while there is a need for > some conscious reasoning about deployment, Bob's point is=20 > very valid. If > a technology is in fact deployed, then the IETF should assume that > someone somewhere saw a business case, and should not engage in a > guessing exercise. >=20 > -- Christian Huitema >=20 From owner-v6ops@ops.ietf.org Sat Feb 21 23:49:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00600 for ; Sat, 21 Feb 2004 23:49:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AulTX-000L9N-Uu for v6ops-data@psg.com; Sun, 22 Feb 2004 04:44:19 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AulTW-000L9A-Pa for v6ops@ops.ietf.org; Sun, 22 Feb 2004 04:44:18 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i1M4iHN01186; Sat, 21 Feb 2004 20:44:17 -0800 From: bill Message-Id: <200402220444.i1M4iHN01186@karoshi.com> Subject: asn-pi-01.txt comments To: v6ops@ops.ietf.org, psavola@funet.fi Date: Sat, 21 Feb 2004 20:44:17 -0800 (PST) Cc: bmanning@karoshi.com ( bill ) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This looks like a derivative work. One might look at RFC 1897 for more details. --bill From owner-v6ops@ops.ietf.org Mon Feb 23 04:18:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14887 for ; Mon, 23 Feb 2004 04:18:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvCAe-000AKf-7l for v6ops-data@psg.com; Mon, 23 Feb 2004 09:14:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvCAc-000AKT-Nj for v6ops@ops.ietf.org; Mon, 23 Feb 2004 09:14:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1N9EWF25264; Mon, 23 Feb 2004 11:14:32 +0200 Date: Mon, 23 Feb 2004 11:14:32 +0200 (EET) From: Pekka Savola To: "Bonness, Olaf" cc: v6ops@ops.ietf.org Subject: Re: AW: IPv6 in MPLS Networks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Feb 2004, Bonness, Olaf wrote: [...] > Besides that, the costs for updating the software of several > thousands of routers are pretty high (in comparission to the actual > IPv6 business case ;-), so that IMHO the BGPTUNNEL is a very good > approach (at least for the first step !) for an IPv6 service offer > based on a MPLS backbone. The later steps of an IPv6 integration > could be than approach 2 and approach 1 from your email. (BTW > sometimes you have to upgrade your HW as well if you want to realise > "native" IPv6 MPLS and thats real expensive.) I think typically the number of PE routers is much higher than the number of core routers. This would seem to imply that upgrading the core is irrelevant nuisance compared to upgrading PE routers. That is, if you already have to upgrade 1000 PE routers -- and if v6 doesn't work properly, the customers attached to those are screwed anyway -- upgrading 50 core routers is not so big an issue, when put into the perspective. Further, all of this, the lack of business case etc., can be avoided by using configured tunneling instead. Until you have enough customers, etc., you could just set up a more hierarchical topology -- no need to bother with a full mesh. Simple and robust, requiring zero new mechanisms. In a few years time it might even be that those routers which were unable to do real IPv6 forwarding have been phased out and native IPv6 (or directly over MPLS) introduction in the core is possible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Feb 23 04:20:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14948 for ; Mon, 23 Feb 2004 04:20:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvCFF-000AeV-MF for v6ops-data@psg.com; Mon, 23 Feb 2004 09:19:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvCFE-000AeJ-HC for v6ops@ops.ietf.org; Mon, 23 Feb 2004 09:19:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1N9JGK25326; Mon, 23 Feb 2004 11:19:16 +0200 Date: Mon, 23 Feb 2004 11:19:16 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling In-Reply-To: <04af01c3f74c$581dd0b0$8d000a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 20 Feb 2004, JORDI PALET MARTINEZ wrote: > > Responding a to few points you raised.. > > > > On Tue, 17 Feb 2004, JORDI PALET MARTINEZ wrote: > > > I believe proto-41 is also one of the proposals on the table for > > > both unmanaged and 3GPP. > > > > > > For example, TSP can make use of it. We also have a Tunnel Broker > > > implementation that does. > > > > Note that while proto-41 forwarding is probably useful in e.g. > > unmanaged scope in general, it is not really applicable to this > > specific topic, "opportunistic tunneling", where the tunneling is > > autoomatic, and requires no supporting ISPs. E.g., tunnel brokers are > > out of scope for this topic. > > > > Ignoring proto-41 however... > > It will depend on what we consider "opportunistic". For me is clear > that we can have tunnel brokers that work like 6to4, i.e., no user > registration. Then you use proto-41 (or other means) ... also TSP > here can play the game, if no user authentication is required. I guess this could be possible in theory. User authentication will probably always be there, though. The user and the ISP have to set up some kind of authentication to ensure that nobody else can hijack the tunnel, at least -- not considering the non-technical requirements, such as the economic (non-incentive) for deploying such an anonymous tunnel service, which would probably lead to a lot of trouble in the long run (abuse reports from your netblock, increased traffic ~= bigger payments to your transit operators, etc.). So, this approach would seem to have both technical and non-technical constraints why its feasibility is a bit questionable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Feb 23 06:56:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20793 for ; Mon, 23 Feb 2004 06:56:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvEeQ-0000A9-L7 for v6ops-data@psg.com; Mon, 23 Feb 2004 11:53:30 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvEeO-00008m-3r for v6ops@ops.ietf.org; Mon, 23 Feb 2004 11:53:28 +0000 Received: from consulintel02 ([163.162.9.93]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 5-md50000000018.tmp for ; Mon, 23 Feb 2004 12:57:59 +0100 Message-ID: <093f01c3fa04$3bd16e20$0800000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-palet-v6ops-ipv6security-00 Date: Mon, 23 Feb 2004 12:57:35 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 23 Feb 2004 12:57:59 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 163.162.9.93 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, We have submitted this document late for the deadline, but I guess it = can be useful for the planned discussion, as suggested by the co-chairs. http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-ipv6security-00= .txt Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Feb 23 19:44:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05245 for ; Mon, 23 Feb 2004 19:44:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvQdA-00068R-9y for v6ops-data@psg.com; Tue, 24 Feb 2004 00:41:00 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvQd6-00066K-Ge for v6ops@ops.ietf.org; Tue, 24 Feb 2004 00:40:56 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8C4088383; Tue, 24 Feb 2004 01:40:59 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" Cc: Subject: RE: Opportunistic Tunneling Date: Tue, 24 Feb 2004 01:39:40 +0100 Organization: Unfix Message-ID: <029d01c3fa6e$b025ce00$210d640a@unfix.org> 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.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Pekka Savola wrote: A small non-techy, economic story... > such as the economic (non-incentive) for deploying such an anonymous > tunnel service, which would probably lead to a lot of trouble in the > long run (abuse reports from your netblock, increased traffic ~= > bigger payments to your transit operators, etc.). Seeing Tunnel Brokers like Freenet6, Hurricane, BTExact and SixXS being around for more than 3 years now does seem to answer the question if it is still feasible to provide such a service. The ISP's involved in these projects who are donating the bandwidth, resources and probably the most costly of them all, manpower, apparently have a benefit or don't see it as a big economic burden to run these services. I don't know how the other TB's are run, but SixXS is run purely on good will, the bandwidth and hardware are sponsored by the ISP's who run the POP. Currently it is doing about 10mbit/s in total across the POP's we run and most traffic stays local (non-transit) as we have multiple POP's in various countries and users get directed to the network-wise closest POP which is better for latency and costs. The ideal situation, like 6to4 relay's and webcaches etc. would of course be when every ISP would run an instance of a TB or 6to4 relay etc thus spreading the economic burden. Currently we try to keep users as local as possible, but countries like Poland and Italy have apparently a big userbase that want IPv6 but no (good) TB/6to4's there, as they come to us. Simple calculation of costs for the ISP having users wanting IPv6 and not having any IPv6 TB/6to4-relay: traffic will flow to other ISP's, these ISP's in turn will have the cost of inbound traffic and the cost of the TB/relay to the remote IPv6 host. When the TB/relay is local the ISP connecting the enduser won't have much costs as it is usually transit, when the traffic becomes transit and larger volumes the ISP will notice. Either way the ISP's who do not offer a TB/6to4 relay instance cheaply lift along with the ones that do. Thus it would be 'better' for the deployment when multiple instances of TB's or 6to4 relays would be deployed thus spreading the costs over these multiple ISP's. Currently there is still not much traffic and the traffic that is there is mostly local thus I don't think there is a big incensitive to do this for most ISP's and that really counts for the ISP's who don't want to take some time for even looking at IPv6 at all. But when the traffic rates will rise and the bigger sites start being available over IPv6 it will become costly to run TB's and 6to4's for the ISP's that are doing it for free now. Small tech note: we need to have this done seemlessly and easy for the enduser. As for the abuse reports: many TB's prohibit access to IRC servers by blocking ports 6600-7100 or something, the others handle a 'give us valid address and contacting data' and just instantly shutdown abusers on the first warning, doing the latter does make it more difficult to get a service but does keep the service a quality one and keeps abuse low and almost near nill. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQDqdSymqKFIzPnwjEQKe/wCfXdIqXmCJjhrsJZA8rCzDop3DRIgAnRGx WEPtXedbOme/lcS8faYZCVmS =IzBF -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Feb 23 20:37:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07135 for ; Mon, 23 Feb 2004 20:37:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvRTj-000DVP-3f for v6ops-data@psg.com; Tue, 24 Feb 2004 01:35:19 +0000 Received: from [4.65.25.155] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvRTi-000DVC-1j for v6ops@ops.ietf.org; Tue, 24 Feb 2004 01:35:18 +0000 Received: from eaglet (127.0.0.1:3773) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 23 Feb 2004 17:31:44 -0800 From: "Tony Hain" To: "'Pekka Savola'" , "'Bob Hinden'" Cc: , Subject: RE: Opportunistic Tunneling Date: Mon, 23 Feb 2004 17:35:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcP21yQQTzVl9l4PQRiH5SHufV5E2ADm4Fuw In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_RFCI,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Pekka Savola wrote: > No, ISATAP is not really applicable AFAICS. Remember that the topic > here is "opportunistic tunneling" -- with a requirement that the > tunneling works independent of ISPs, automatically. ISATAP requires > ISATAP router and set-up. Only to get out of the routing domain. ISATAP end systems will use opportunistic tunneling directly because ND is not required to acquire the IPv4 (link layer) address. > > On the other hand, when your ISP wants to give you IPv6 access using > tunneling, ISATAP could be on the table (but that was a separate > subject). ISATAP should never show up in the public network because it allows use of RFC1918 addresses. > Economic models, to an extent, make deployments realistic (or not), so > I personally think this is somewhat of a factor in the discussions > whether to recommend some model for deployment. Of course, the IETF > cannot _force_ anyone to a model. As Bob & Christian have said, the IETF is not in a position to recommend economic models. Entire industries like cable ISPs will have economic drivers (like the cost/operational complexity of whole-sale replacement of a cable modem plant) that will make technologies like 6to4 & Teredo much more attractive than they would be to a campus or transit ISP. Operating 6to4 or Teredo relays as an integral part of a cable infrastructure provides a very simple deployment path. At most the IETF might document that the IPv4 side of such relays should be restricted to local customers, but even that is really none of the IETF's business. Tony From owner-v6ops@ops.ietf.org Mon Feb 23 21:07:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07876 for ; Mon, 23 Feb 2004 21:07:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvRx5-000HwH-1X for v6ops-data@psg.com; Tue, 24 Feb 2004 02:05:39 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvRx3-000Hw5-SX for v6ops@ops.ietf.org; Tue, 24 Feb 2004 02:05:37 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1O24KvI000355; Mon, 23 Feb 2004 21:04:20 -0500 (EST) Date: Mon, 23 Feb 2004 21:04:17 -0500 From: Marc Blanchet To: Pekka Savola , v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: Re: Opportunistic Tunneling Message-ID: <82100000.1077588257@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Wednesday, February 11, 2004 20:23:34 +0200 Pekka Savola wrote/a ecrit: > Hi, > > As the Unmanaged Analysis document is currently at WG Last Call, the > biggest issue appears to be the so-called "opportunistic tunneling", > i.e., automatic tunneling which would be possible without set-up or > ISP support. Examples of these are 6to4 and Teredo. (No other > specific proposals have been made.) TSP. > We need to figure out how to move > forward. The critical questions are at least: > > 1) Do we agree that this is something we need in the first place? > * Considering user-driven deployment, maybe not. > - example: the user says "I want to use application X" or "I > want to use functionality Y", where X or Y would require > IPv6. > * Considering large-scale vendor-centric deployment, probably > yes. > > 2) What are the models for deploying relays, considering the economic > or deployment considerations (in-host, in-site, network)? > * And what are the implications of any approach? > * Can we decide on the recommended model? > > 3) For NAT traversing, opportunistic tunneling, are there any > features in Teredo which are missing or are unnecessary? I.e., > how good a fit would it be? Are there alternatives? TSP does nat traversal and does not have the same security concerns as teredo. in the anonymous mode of TSP, TSP is as automatic/opportunistic as teredo/6to4/isatap. all of them requires the prior (static) knowledge of an IPv4 address. Most of them may have some ways to get the nearest/best service, based on some techniques. Marc. > > We're soliciting input on how to best handle this situation. Please > send feedback to the chairs or on the list. Tentatively, we're > scheduling 20-30 minutes for discussion in Seoul, but how productive > such discussion would be would depend on the framing and the contents > of presentations and/or discussion. > > Please send your ideas (if any). > > Thanks, > Pekka & Jonne > > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Mon Feb 23 21:10:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07923 for ; Mon, 23 Feb 2004 21:10:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvS09-000IDX-B7 for v6ops-data@psg.com; Tue, 24 Feb 2004 02:08:49 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvS08-000IDI-9A for v6ops@ops.ietf.org; Tue, 24 Feb 2004 02:08:48 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1O27TvI000359; Mon, 23 Feb 2004 21:07:29 -0500 (EST) Date: Mon, 23 Feb 2004 21:07:26 -0500 From: Marc Blanchet To: Pekka Savola , JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling Message-ID: <85580000.1077588446@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Thursday, February 19, 2004 16:34:24 +0200 Pekka Savola wrote/a ecrit: > Responding a to few points you raised.. > > On Tue, 17 Feb 2004, JORDI PALET MARTINEZ wrote: >> I believe proto-41 is also one of the proposals on the table for >> both unmanaged and 3GPP. >> >> For example, TSP can make use of it. We also have a Tunnel Broker >> implementation that does. > > Note that while proto-41 forwarding is probably useful in e.g. > unmanaged scope in general, it is not really applicable to this > specific topic, "opportunistic tunneling", where the tunneling is > autoomatic, and requires no supporting ISPs. E.g., tunnel brokers are > out of scope for this topic. - why? - again, TSP in anonymous mode is as automatic as isatap/teredo/6to4: the clients all need the knowledge of at least one IPv4 address. (One of them needs two, but that is not the point). - with TSP, you could "upgrade" to authentication which would provide you additional functionalities, such as permanent ip address, prefix delegation for your mobile network, etc... Marc. > > Ignoring proto-41 however... > > [...] >> When users start moving with IPv6 devices, we need to ensure that >> they are able to use it, despite what network they are sitting on. >> >> I've this experience myself, traveling ... and I can solve it >> manually most of the time, but the users don't know how to. It >> should be automatic. >> >> There are already applications that only work with IPv6, a few at >> the time being, but more coming, for sure. The reason is that you >> need addresses, for example to access multiple devices that are >> located behind a NAT box. > > I totally agree (about part of your statement) that tunneling should > just work, whether the user is behind NAT or not. > > However, regarding this discussion, I'm not sure if you're actually > taking a stance whether you you believe a mechanism like 6to4 or > Teredo is *required*. That is, do you think the users must be able to > switch on IPv6, without any interaction with any ISP, and have it work > (at least with a subset of other IPv6 users)? Or do you think the > user can be required to get a "tunnel broker" -like service (or > whatever) from some ISP explicitly? > > [...] >> In Euro6IX we are already working around this idea, but we don't >> have a draft ready for this meeting, unfortunately. Basically we >> call it "auto-transition". We need to ensure that the best possible >> transition mechanism work automatically at any time, in any network. > [...] > > Yep -- this is pretty important work, and one important issue in the > unmanaged evaluation document (spanning both "opportunistic" and > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Mon Feb 23 21:19:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08131 for ; Mon, 23 Feb 2004 21:19:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvS97-000JBE-RD for v6ops-data@psg.com; Tue, 24 Feb 2004 02:18:05 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvS96-000JB2-PH for v6ops@ops.ietf.org; Tue, 24 Feb 2004 02:18:04 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1O29ivI000362; Mon, 23 Feb 2004 21:09:45 -0500 (EST) Date: Mon, 23 Feb 2004 21:09:42 -0500 From: Marc Blanchet To: Pekka Savola , JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling Message-ID: <88160000.1077588582@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Monday, February 23, 2004 11:19:16 +0200 Pekka Savola wrote/a ecrit: > On Fri, 20 Feb 2004, JORDI PALET MARTINEZ wrote: >> > Responding a to few points you raised.. >> > >> > On Tue, 17 Feb 2004, JORDI PALET MARTINEZ wrote: >> > > I believe proto-41 is also one of the proposals on the table for >> > > both unmanaged and 3GPP. >> > > >> > > For example, TSP can make use of it. We also have a Tunnel Broker >> > > implementation that does. >> > >> > Note that while proto-41 forwarding is probably useful in e.g. >> > unmanaged scope in general, it is not really applicable to this >> > specific topic, "opportunistic tunneling", where the tunneling is >> > autoomatic, and requires no supporting ISPs. E.g., tunnel brokers are >> > out of scope for this topic. >> > >> > Ignoring proto-41 however... >> >> It will depend on what we consider "opportunistic". For me is clear >> that we can have tunnel brokers that work like 6to4, i.e., no user >> registration. Then you use proto-41 (or other means) ... also TSP >> here can play the game, if no user authentication is required. > > I guess this could be possible in theory. User authentication will > probably always be there, though. The user and the ISP have to set up > some kind of authentication to ensure that nobody else can hijack the > tunnel, at least -- not considering the non-technical requirements, > such as the economic (non-incentive) for deploying such an anonymous > tunnel service, which would probably lead to a lot of trouble in the > long run (abuse reports from your netblock, increased traffic ~= > bigger payments to your transit operators, etc.). in TSP anonymous mode, one can filter TSP requests to his own autonomous system. This is really just a management function, not related to the TSP protocol itself. in TSP authentication mode, then the AAA database is used. > > So, this approach would seem to have both technical and non-technical > constraints why its feasibility is a bit questionable. TSP is deployed live in many organisations at this point. Marc. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Tue Feb 24 01:08:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16787 for ; Tue, 24 Feb 2004 01:08:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvVgU-000HtW-3T for v6ops-data@psg.com; Tue, 24 Feb 2004 06:04:46 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvVgS-000HtI-Qn for v6ops@ops.ietf.org; Tue, 24 Feb 2004 06:04:44 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 57B6DA7; Tue, 24 Feb 2004 15:04:43 +0900 (JST) To: jordi.palet@consulintel.es Cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-ipv6security-00 In-Reply-To: Your message of "Mon, 23 Feb 2004 12:57:35 +0100" <093f01c3fa04$3bd16e20$0800000a@consulintel.es> References: <093f01c3fa04$3bd16e20$0800000a@consulintel.es> X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040224060443.57B6DA7@coconut.itojun.org> Date: Tue, 24 Feb 2004 15:04:43 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > We have submitted this document late for the deadline, but I guess it can be useful for the planned discussion, as suggested by the co-chairs. > > http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-ipv6security-00.txt the biggest question i have with the document is, what do you mean by "security" here? there's no description given (as far as i see), so the definition of "security" is left unspecified. itojun From owner-v6ops@ops.ietf.org Tue Feb 24 01:36:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18700 for ; Tue, 24 Feb 2004 01:36:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvW8r-000KCi-Oj for v6ops-data@psg.com; Tue, 24 Feb 2004 06:34:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvW8q-000KCV-Kj for v6ops@ops.ietf.org; Tue, 24 Feb 2004 06:34:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1O6Y0w07715; Tue, 24 Feb 2004 08:34:00 +0200 Date: Tue, 24 Feb 2004 08:34:00 +0200 (EET) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org, Subject: Re: Opportunistic Tunneling In-Reply-To: <82100000.1077588257@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 23 Feb 2004, Marc Blanchet wrote: > TSP does nat traversal and does not have the same security concerns as > teredo. > > in the anonymous mode of TSP, TSP is as automatic/opportunistic as > teredo/6to4/isatap. all of them requires the prior (static) knowledge of an > IPv4 address. Most of them may have some ways to get the nearest/best > service, based on some techniques. I think there is something in the "opportunistic" vs "tunnel service" distinction that I haven't been able to make clear. TSP requires that ISPs set up tunnel servers and tunnel brokers. 6to4 and Teredo don't. (Teredo server doesn't pass through traffic so a couple may be enough.) 6to4 works automatically between other 6to4 nodes; TSP does not. Teredo works automatically between Teredo nodes after the server has been contacted to get the public IPv6 address. This is the distinction I tried to make with "Opportunistic Tunneling" vs "3GPP UE Tunneling, Unmanaged tunnel service". The tunnel broker set-up, even in anonymous mode, could possibly be pretty straightforward, but nowhere near the same as 6to4. (Which works even with relays between 6to4 nodes.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Feb 24 01:41:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18763 for ; Tue, 24 Feb 2004 01:41:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvWEa-000KdX-SX for v6ops-data@psg.com; Tue, 24 Feb 2004 06:40:00 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvWEZ-000KdD-Vu for v6ops@ops.ietf.org; Tue, 24 Feb 2004 06:40:00 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 343958D; Tue, 24 Feb 2004 15:39:57 +0900 (JST) To: Pekka Savola Cc: Marc Blanchet , v6ops@ops.ietf.org, jonne.soininen@nokia.com In-reply-to: pekkas's message of Tue, 24 Feb 2004 08:34:00 +0200. 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: Opportunistic Tunneling From: itojun@iijlab.net Date: Tue, 24 Feb 2004 15:39:57 +0900 Message-Id: <20040224063957.343958D@coconut.itojun.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >TSP requires that ISPs set up tunnel servers and tunnel brokers. >6to4 and Teredo don't. (Teredo server doesn't pass through traffic so >a couple may be enough.) 6to4 works automatically between other 6to4 >nodes; TSP does not. Teredo works automatically between Teredo nodes >after the server has been contacted to get the public IPv6 address. 6to4 requires 6to4 relay routers to be present on the internet, otherwise 6to4 won't work (or return route will be very inefficient). teredo requires teredo servers/relays to be present on the internet, otherwise teredo client won't work. i don't see significant difference between 6to4/teredo and TSP. itojun From owner-v6ops@ops.ietf.org Tue Feb 24 02:44:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05091 for ; Tue, 24 Feb 2004 02:44:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvXCq-000PYG-Qm for v6ops-data@psg.com; Tue, 24 Feb 2004 07:42:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvXCp-000PY2-Mm for v6ops@ops.ietf.org; Tue, 24 Feb 2004 07:42:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1O7fuO08568; Tue, 24 Feb 2004 09:41:57 +0200 Date: Tue, 24 Feb 2004 09:41:56 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: Marc Blanchet , , Subject: Re: Opportunistic Tunneling In-Reply-To: <20040224063957.343958D@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Feb 2004 itojun@iijlab.net wrote: > >TSP requires that ISPs set up tunnel servers and tunnel brokers. > >6to4 and Teredo don't. (Teredo server doesn't pass through traffic so > >a couple may be enough.) 6to4 works automatically between other 6to4 > >nodes; TSP does not. Teredo works automatically between Teredo nodes > >after the server has been contacted to get the public IPv6 address. > > 6to4 requires 6to4 relay routers to be present on the internet, > otherwise 6to4 won't work (or return route will be very inefficient). > teredo requires teredo servers/relays to be present on the internet, > otherwise teredo client won't work. Relay routers are needed to communicate with native Internet, not between the users of the same transition technology. Both 6to4 and Teredo can work, to an extent, when relay routers don't exist. TSP can't. There is path optimization between 6to4 nodes and between Teredo nodes. There is no such thing with TSP (for the good and the bad). I.e., all the traffic must pass through the server/broker. These are the main differences with "opportunistic" vs "non-opportunistic" methods. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Feb 24 02:45:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05133 for ; Tue, 24 Feb 2004 02:45:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvXEq-000PfA-Mm for v6ops-data@psg.com; Tue, 24 Feb 2004 07:44:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvXEp-000Peu-Cc for v6ops@ops.ietf.org; Tue, 24 Feb 2004 07:44:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1O7iIS08615 for ; Tue, 24 Feb 2004 09:44:18 +0200 Date: Tue, 24 Feb 2004 09:44:18 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: WG Last Call reminder Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) Remember that WG last calls for the Unmanaged Analysis document and the ISP scenarios/analysis document are ending very soon this week. There has been only a little feedback (except on MPLS networks in the ISP scope). Please review the documents and send feedback! Thanks! From owner-v6ops@ops.ietf.org Tue Feb 24 02:47:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05161 for ; Tue, 24 Feb 2004 02:47:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvXGr-000Pqc-Hp for v6ops-data@psg.com; Tue, 24 Feb 2004 07:46:25 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvXGo-000Ppg-6h for v6ops@ops.ietf.org; Tue, 24 Feb 2004 07:46:22 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8187D8D; Tue, 24 Feb 2004 16:46:19 +0900 (JST) To: Pekka Savola Cc: Marc Blanchet , v6ops@ops.ietf.org, jonne.soininen@nokia.com In-reply-to: pekkas's message of Tue, 24 Feb 2004 09:41:56 +0200. 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: Opportunistic Tunneling From: itojun@iijlab.net Date: Tue, 24 Feb 2004 16:46:19 +0900 Message-Id: <20040224074619.8187D8D@coconut.itojun.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> >TSP requires that ISPs set up tunnel servers and tunnel brokers. >> >6to4 and Teredo don't. (Teredo server doesn't pass through traffic so >> >a couple may be enough.) 6to4 works automatically between other 6to4 >> >nodes; TSP does not. Teredo works automatically between Teredo nodes >> >after the server has been contacted to get the public IPv6 address. >> >> 6to4 requires 6to4 relay routers to be present on the internet, >> otherwise 6to4 won't work (or return route will be very inefficient). >> teredo requires teredo servers/relays to be present on the internet, >> otherwise teredo client won't work. > >Relay routers are needed to communicate with native Internet, not >between the users of the same transition technology. > >Both 6to4 and Teredo can work, to an extent, when relay routers don't >exist. TSP can't. how useful is the IPv6 internet if you can talk with 6to4 users only? i think the argument is bogus. >There is path optimization between 6to4 nodes and between Teredo >nodes. There is no such thing with TSP (for the good and the bad). >I.e., all the traffic must pass through the server/broker. i think it causes serious misunderstanding if we characterize this property as indication of "opportunistic". optimization property has to be discussed under separate thread. itojun From owner-v6ops@ops.ietf.org Tue Feb 24 03:31:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06518 for ; Tue, 24 Feb 2004 03:31:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvXwV-0002nN-OX for v6ops-data@psg.com; Tue, 24 Feb 2004 08:29:27 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvXwU-0002n3-1R for v6ops@ops.ietf.org; Tue, 24 Feb 2004 08:29:26 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 25-md50000000013.tmp for ; Tue, 24 Feb 2004 09:33:56 +0100 Message-ID: <013401c3fab0$f09858d0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <093f01c3fa04$3bd16e20$0800000a@consulintel.es> <20040224060443.57B6DA7@coconut.itojun.org> Subject: Re: draft-palet-v6ops-ipv6security-00 Date: Tue, 24 Feb 2004 09:33:53 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 24 Feb 2004 09:33:56 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Itojun, You're right. We will add our "security" definition in the next release. Regards, Jordi ----- Original Message -----=20 From: "Jun-ichiro itojun Hagino" To: Cc: Sent: Tuesday, February 24, 2004 7:04 AM Subject: Re: draft-palet-v6ops-ipv6security-00 > > We have submitted this document late for the deadline, but I guess = it can be useful for the planned discussion, as suggested by the = co-chairs. > >=20 > > = http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-ipv6security-00= .txt >=20 > the biggest question i have with the document is, what do you mean by > "security" here? there's no description given (as far as i see), so > the definition of "security" is left unspecified. >=20 > itojun > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Feb 24 03:42:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07113 for ; Tue, 24 Feb 2004 03:42:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvY7m-0003pX-Sw for v6ops-data@psg.com; Tue, 24 Feb 2004 08:41:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvY7l-0003pK-Db for v6ops@ops.ietf.org; Tue, 24 Feb 2004 08:41:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1O8f0K09361; Tue, 24 Feb 2004 10:41:00 +0200 Date: Tue, 24 Feb 2004 10:41:00 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling In-Reply-To: <20040224074619.8187D8D@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Tailed down Cc: a bit.. On Tue, 24 Feb 2004 itojun@iijlab.net wrote: > >Both 6to4 and Teredo can work, to an extent, when relay routers don't > >exist. TSP can't. > > how useful is the IPv6 internet if you can talk with 6to4 users only? > i think the argument is bogus. Based on the deployments of Microsoft I guess some do view this as a sufficient first step.. because you can still use IPv4 to those native IPv6 users. I'm not sure whether I agree this kind of fragmentation is a good idea, but if the intent IPv6 deployment is host-vendor -driven (as noted in the first message of this thread), mainly based on the desire to run p2p applications directly, this may be a real consideration. > >There is path optimization between 6to4 nodes and between Teredo > >nodes. There is no such thing with TSP (for the good and the bad). > >I.e., all the traffic must pass through the server/broker. > > i think it causes serious misunderstanding if we characterize this > property as indication of "opportunistic". optimization property > has to be discussed under separate thread. I believe the word, "opportunistic" was in this context coined up by Rob Austein, and should be interpreted in the similar way as "opportunistic IPsec". That is, you can talk directly with others, not just a [tunnel] server. By that definition, the "path optimization" seems to be an integral property of "opportunistic" methods.. because there are other methods, which require more infrastructure (e.g., tunnel service such as STEP, TSP, ISATAP etc.) which can be basically close to zero-configured. I agree that "opportunistic" is probably a confusing term, but I haven't been able to think of a better one. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Feb 24 03:53:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07340 for ; Tue, 24 Feb 2004 03:53:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvYHz-0004bt-FD for v6ops-data@psg.com; Tue, 24 Feb 2004 08:51:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvYHy-0004bf-1S for v6ops@ops.ietf.org; Tue, 24 Feb 2004 08:51:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1O8pWM09514; Tue, 24 Feb 2004 10:51:32 +0200 Date: Tue, 24 Feb 2004 10:51:32 +0200 (EET) From: Pekka Savola To: Tony Hain cc: "'Bob Hinden'" , , Subject: Cable transition [RE: Opportunistic Tunneling] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I think the most interesting discussion is what you say about cable transition.. but I'm responding to a few other issues for clarification as well. On Mon, 23 Feb 2004, Tony Hain wrote: > Pekka Savola wrote: > > No, ISATAP is not really applicable AFAICS. Remember that the topic > > here is "opportunistic tunneling" -- with a requirement that the > > tunneling works independent of ISPs, automatically. ISATAP requires > > ISATAP router and set-up. > > Only to get out of the routing domain. ISATAP end systems will use > opportunistic tunneling directly because ND is not required to acquire the > IPv4 (link layer) address. Yep - ISATAP includes the concept of intra-site opportunism. But as it is not opportunistic in inter-domain (which was the point here, the ISPs not offering service), it does not seem too interesting. > As Bob & Christian have said, the IETF is not in a position to recommend > economic models. I have to disagree with the way people have framed the IETF position, while I agree with your statement above. But I don't think this is something to continue on this thread. > Entire industries like cable ISPs will have economic > drivers (like the cost/operational complexity of whole-sale replacement of a > cable modem plant) that will make technologies like 6to4 & Teredo much more > attractive than they would be to a campus or transit ISP. Operating 6to4 or > Teredo relays as an integral part of a cable infrastructure provides a very > simple deployment path. At most the IETF might document that the IPv4 side > of such relays should be restricted to local customers, but even that is > really none of the IETF's business. Is there anything fundamentally unworkable in the model where the cable modem users would use a tool such as ISATAP, STEP or TSP to connect to the tunnel server of the cable modem ISP for their connectivity? This seems to fail in three cases only: 1) if the cable ISP doesn't want to provide IPv6 in the first place (not even providing 6to4 relay or whatever). Based on your comment, this doesn't seem a bad concern. 2) if the traffic between the users at the same ISP grows so high that a tunnel server (or multiple servers) cannot carry all the traffic, i.e., path optimization would be required. Personally, I see this as an indication that IPv6 would be in serious use and the cable ISP would want to start offering native IPv6. So, this would only seem to be the case, if the cable ISP wanted to avoid transition to native IPv6 altogether, sticking to 6to4/Teredo for forever .. which is not what we want. 3) if the mechanism (ISATAP, STEP, TSP, whatever) is not implemented widely enough in the host software so that it's unavailable to the users. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Feb 24 12:02:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29479 for ; Tue, 24 Feb 2004 12:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvftY-000PHT-3v for v6ops-data@psg.com; Tue, 24 Feb 2004 16:58:56 +0000 Received: from [62.225.183.202] (helo=mail1.telekom.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvftW-000PH9-0i for v6ops@ops.ietf.org; Tue, 24 Feb 2004 16:58:54 +0000 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 24 Feb 2004 17:58:52 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 17:58:52 +0100 Message-Id: From: "Bonness, Olaf" To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: AW: AW: IPv6 in MPLS Networks Date: Tue, 24 Feb 2004 17:58:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, within a complex ISP network you will never switch on IPv6 with one finger snip. You will choose a staged approach were you can scale according to the real requirements. Besides that you will for sure leave the core routers untouched as long as you can, because an error within this core router does you much more harm than a problem in one PE. Furthermore MPLS has per definition a very flexibel and powerful label stack principle that allows us to implement new services based on it. Why not use this approach in a first step for offering IPv6 at the edges and than integrate it in the MPLS core sometimes in the future. The whole IPv6 migration is only a question of using the right mechanism at the right time ;-). Besides that this MPLS label stack is more flexibel than (configured) tunnels and has as well less overhead. Regards Olaf > -----Ursprungliche Nachricht----- > Von: Pekka Savola [mailto:pekkas@netcore.fi] > Gesendet: Montag, 23. Februar 2004 10:15 > An: Bonne?, Olaf > Cc: v6ops@ops.ietf.org > Betreff: Re: AW: IPv6 in MPLS Networks > > > On Thu, 19 Feb 2004, Bonness, Olaf wrote: > [...] > > Besides that, the costs for updating the software of several > > thousands of routers are pretty high (in comparission to the actual > > IPv6 business case ;-), so that IMHO the BGPTUNNEL is a very good > > approach (at least for the first step !) for an IPv6 service offer > > based on a MPLS backbone. The later steps of an IPv6 integration > > could be than approach 2 and approach 1 from your email. (BTW > > sometimes you have to upgrade your HW as well if you want to realise > > "native" IPv6 MPLS and thats real expensive.) > > I think typically the number of PE routers is much higher than the > number of core routers. This would seem to imply that upgrading the > core is irrelevant nuisance compared to upgrading PE routers. That > is, if you already have to upgrade 1000 PE routers -- and if v6 > doesn't work properly, the customers attached to those are screwed > anyway -- upgrading 50 core routers is not so big an issue, when put > into the perspective. > > Further, all of this, the lack of business case etc., can be avoided > by using configured tunneling instead. Until you have enough > customers, etc., you could just set up a more hierarchical topology -- > no need to bother with a full mesh. Simple and robust, requiring zero > new mechanisms. > > In a few years time it might even be that those routers which were > unable to do real IPv6 forwarding have been phased out and native IPv6 > (or directly over MPLS) introduction in the core is possible. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From owner-v6ops@ops.ietf.org Tue Feb 24 13:29:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02979 for ; Tue, 24 Feb 2004 13:29:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvhGz-000957-6Y for v6ops-data@psg.com; Tue, 24 Feb 2004 18:27:13 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvhGx-00094r-93 for v6ops@ops.ietf.org; Tue, 24 Feb 2004 18:27:11 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:27:10 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Feb 2004 10:27:10 -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(6.0.3790.1069); Tue, 24 Feb 2004 10:27:07 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:27:10 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Feb 2004 10:27:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Opportunistic Tunneling Date: Tue, 24 Feb 2004 10:26:48 -0800 Message-ID: Thread-Topic: Opportunistic Tunneling Thread-Index: AcP6srwsWYTg2ixORmmVnLHGgWJzCQATC46A From: "Christian Huitema" To: "Pekka Savola" , Cc: X-OriginalArrivalTime: 24 Feb 2004 18:27:09.0616 (UTC) FILETIME=[D0637B00:01C3FB03] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On Tue, 24 Feb 2004 itojun@iijlab.net wrote: > > >Both 6to4 and Teredo can work, to an extent, when relay routers don't > > >exist. TSP can't. > > > > how useful is the IPv6 internet if you can talk with 6to4 users only? > > i think the argument is bogus. >=20 > Based on the deployments of Microsoft I guess some do view this as a > sufficient first step.. because you can still use IPv4 to those native > IPv6 users. Or you push those native users who want connectivity to deploy their own "local gateways". After all, any host or any site that has dual connectivity can be "multi-homed" to 6to4 and native, and can run a local Teredo relay.=20 But this "local relay" solution has an important drawback: if we deploy millions a relays in millions of sites, then we will have a hard time rolling back the transition technology when it is not needed any more.=20 In contrast, if IPv6 providers do provide relays, then hosts and sites don't have to "run their own", and the "transition out of the transition" will be easier. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Feb 24 15:21:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09056 for ; Tue, 24 Feb 2004 15:21:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avj1X-000K69-Si for v6ops-data@psg.com; Tue, 24 Feb 2004 20:19:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avj1T-000K5h-Vn for v6ops@ops.ietf.org; Tue, 24 Feb 2004 20:19:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1OKJIg17841; Tue, 24 Feb 2004 22:19:18 +0200 Date: Tue, 24 Feb 2004 22:19:18 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: IETF59 v6ops agenda Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (writing as co-chair) Below is the v6ops agenda for IETF59. Some minor changes may still occur e.g., due to uncertainties of presenters etc. Any omissions, glitches, suggestions, etc.? Send them to us! :) -------8<------- Monday, 1st Mar: 1530-1730 ========================== Introduction and agenda bashing - 5 mins, Chairs/Jonne - Scribes! (Jabber also?) Document status - 10 mins, Chairs/Pekka - What has happened with WG documents lately - GOAL: show the status of WG documents "Zero-configured" Tunneling Discussion, 20 mins - 3GPP UE Tunneling, Unmanaged tunnel service, something in enterprise? - Main contenders: ISATAP, STEP, TSP, etc. - GOAL: try to be able to get closer to the consensus with the mechanisms than we are. Introducing IPv6 in MPLS Networks, 20 mins - Discuss the approaches: configured tunneling, signalling upgrade, BGP tunneling hacks, etc.? - GOAL: try to get closer to consensus on what's required to use IPv6 in MPLS-based networks. Opportunistic Tunneling (esp. NAT traversal) Discussion, 20 mins - Do we agree that this is something we need in the first place? * And if so, in which specific scenarios? - What are the models for deploying relays (in-host, in-site vs network)? What are the implications? - GOAL: try to get closer to consensus on what's the right approach for opportunistic tunneling. IPv6 Distributed Security Requirements - 10 mins, J. Palet - http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-ipv6security-00.txt - quick overview of new kind of security requirements - GOAL: introduce the issue Quarantine Security Model - 10 mins, S. Kondo - draft-kondo-quarantine-overview-00.txt - quick overview of a possible security model for IPv6 - GOAL: introduce the issue, to be fully discussed in security area IPv6 Security Overview - 10 mins, P. Savola - draft-savola-v6ops-security-overview-02.txt - introduce the approach; discuss changes. - GOAL: discuss whether something like this is needed as WG item, adapt if so. Thursday, 4th Mar: 1530-1730 ============================ [If good discussion is generated on the discussion items on the first session, add time to discuss those here] Enterprise Scenarios, 5 mins, Chairs/Jonne - draft-ietf-v6ops-ent-scenarios-01.txt - Discuss the changes, solicit feedback - GOAL: Prepare for WG Last Call. ISP Scenarios/Solutions, 15 mins, M. Lind - draft-ietf-v6ops-isp-scenarios-analysis-01.txt - Discuss WG last call issues, try to build consensus if any hot issues - GOAL: Make it easier to revise the document and send it to the IESG Unmanaged Evaluation, 5 mins, Chairs? - draft-ietf-v6ops-unmaneval-01.txt - Discuss WG last call issues (if unresolved) - GOAL: Make it easier to revise the document and send it to the IESG Transition mechanisms update, 10 mins, Chairs/Pekka - draft-ietf-v6ops-mech-v2-02.txt - draft-savola-v6ops-mechv2-interop-impl-template-00.txt - should be already at the IESG, discuss issues if any - Discuss implementation reports / interop testing - GOAL: Iron out last-minute issues, and make it easier to go to DS 6to4 Security Considerations, 10 mins, P. Savola - draft-ietf-v6ops-6to4-security-01.txt - discuss changes, solicit input whether the substantial changes to the document layout helped. - GOAL: prepare the document for WG last call Statistics from a 6to4 Relay - 5 mins, P. Savola - (no draft) - quick presentation on the usage statistics from a public 6to4 relay - GOAL: give the WG an impression about the traffic on 6to4 relays IPv6 Applications Transition, 10 mins, M. Shin - draft-ietf-v6ops-application-transition-01.txt - discuss issues, if any, prior to the WG last call. - GOAL: make it easier to ship the document to the IESG. IPv6 Renumbering Procedures, 10 mins, F. Baker - draft-ietf-v6ops-ipv6-renumber-procedure-00.txt - discuss changes, solicit input - GOAL: prepare for WG last call IPv6-on-by-Default - 10 mins, A. Durand - draft-ietf-v6ops-v6onbydefault-01.txt - discuss changes and open issues (if any) - GOAL: make it ready to ship these off after Seoul IPv6 Mobility Scenarios/Requirements in 3GPP, 10 mins, C. Williams - loosely based on draft-yamamoto-mipv6node-v4trav-00.txt - discuss 3GPP2 IPv6 mobility and transition issues - GOAL: understand the scenario and its requirements From owner-v6ops@ops.ietf.org Tue Feb 24 18:51:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17696 for ; Tue, 24 Feb 2004 18:51:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvmIG-000He8-M8 for v6ops-data@psg.com; Tue, 24 Feb 2004 23:48:52 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvmID-000Hdf-OP for v6ops@ops.ietf.org; Tue, 24 Feb 2004 23:48:49 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1ONmadO021722; Tue, 24 Feb 2004 15:48:37 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1ONmYQ24806; Wed, 25 Feb 2004 00:48:34 +0100 (MET) Date: Tue, 24 Feb 2004 15:48:39 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Opportunistic Tunneling To: Pekka Savola Cc: Marc Blanchet , v6ops@ops.ietf.org, jonne.soininen@nokia.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I think there is something in the "opportunistic" vs "tunnel service" > distinction that I haven't been able to make clear. > > TSP requires that ISPs set up tunnel servers and tunnel brokers. > 6to4 and Teredo don't. (Teredo server doesn't pass through traffic so > a couple may be enough.) 6to4 works automatically between other 6to4 > nodes; TSP does not. Teredo works automatically between Teredo nodes > after the server has been contacted to get the public IPv6 address. Pekka, It seems odd to say that the criteria is "nodes that implement X can talk to other nodes which implement X without extra infrastructure" when extra infrastructure is needed for nodes that implement X to be able to communicate with nodes that have native IPv6 service. That seems to forget that the goal is to move towards IPv6 and not stay with X forever. TSP, teredo and 6to4 all need some infrastructure to be able communicate with nodes that do native IPv6. Why is it important to make any finer grain distinction? Erik From owner-v6ops@ops.ietf.org Tue Feb 24 21:52:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23277 for ; Tue, 24 Feb 2004 21:52:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avp6j-000Caf-HV for v6ops-data@psg.com; Wed, 25 Feb 2004 02:49:09 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avp6h-000CaG-HU for v6ops@ops.ietf.org; Wed, 25 Feb 2004 02:49:07 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1P2movI001558; Tue, 24 Feb 2004 21:48:50 -0500 (EST) Date: Tue, 24 Feb 2004 09:19:43 -0500 From: Marc Blanchet To: Pekka Savola , Marc Blanchet cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: Opportunistic Tunneling Message-ID: <49980000.1077632383@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Tuesday, February 24, 2004 08:34:00 +0200 Pekka Savola wrote/a ecrit: > On Mon, 23 Feb 2004, Marc Blanchet wrote: >> TSP does nat traversal and does not have the same security concerns as >> teredo. >> >> in the anonymous mode of TSP, TSP is as automatic/opportunistic as >> teredo/6to4/isatap. all of them requires the prior (static) knowledge of >> an IPv4 address. Most of them may have some ways to get the nearest/best >> service, based on some techniques. > > I think there is something in the "opportunistic" vs "tunnel service" > distinction that I haven't been able to make clear. > > TSP requires that ISPs set up tunnel servers and tunnel brokers. > 6to4 6to4 client needs a relay. Teredo client needs both servers and relays. they both have the property of having assymetric routing. TSP needs a broker/server. Broker can assign tunnels to the nearest tunnel server. TSP configures static tunnels. static tunnels have much less/no issues regarding security in relays and open transits. 6to4 and teredo need relays that are open for transit traffic. The client rely on the reliability and the overall performance of those for their traffic. However, nor the client, nor the provider of the client are able to control these. So, user experience might be/is terrible. TSP gives you a production address, not bound to the IPv4 address you have (temporarily). It also does not expose the NAT mapping in the IPv6 address. If the node moves to a new subnet, the IPv4 address changes, so the IPv6 address. >and Teredo don't. (Teredo server doesn't pass through traffic so > a couple may be enough.) 6to4 works automatically between other 6to4 > nodes; TSP does not. Teredo works automatically between Teredo nodes > after the server has been contacted to get the public IPv6 address. not quite that simple. Teredo relays are used a lot. see all the interactions between the nodes. Teredo does not cross symmetric NATs, while TSP does. If the node is moving to different point of attachments and one of them is behind a symmetric NAT, no service with Teredo. > > This is the distinction I tried to make with "Opportunistic Tunneling" > vs "3GPP UE Tunneling, Unmanaged tunnel service". > > The tunnel broker set-up, even in anonymous mode, could possibly be > pretty straightforward, but nowhere near the same as 6to4. why? small piece of code. only need one IPv4 address. that is. both same level of "straightforwardness". > (Which > works even with relays between 6to4 nodes.) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Feb 25 01:29:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00154 for ; Wed, 25 Feb 2004 01:29:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvsUj-00092m-Gl for v6ops-data@psg.com; Wed, 25 Feb 2004 06:26:09 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avp6w-000CdW-6R for v6ops@ops.ietf.org; Wed, 25 Feb 2004 02:49:22 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1P2movM001558; Tue, 24 Feb 2004 21:48:51 -0500 (EST) Date: Tue, 24 Feb 2004 09:41:10 -0500 From: Marc Blanchet To: Pekka Savola , itojun@iijlab.net cc: Marc Blanchet , v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: Opportunistic Tunneling Message-ID: <63160000.1077633670@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [[ list moderator note: non-member submission to the list ]] -- Tuesday, February 24, 2004 09:41:56 +0200 Pekka Savola wrote/a ecrit: > On Tue, 24 Feb 2004 itojun@iijlab.net wrote: >> > TSP requires that ISPs set up tunnel servers and tunnel brokers. >> > 6to4 and Teredo don't. (Teredo server doesn't pass through traffic so >> > a couple may be enough.) 6to4 works automatically between other 6to4 >> > nodes; TSP does not. Teredo works automatically between Teredo nodes >> > after the server has been contacted to get the public IPv6 address. >> >> 6to4 requires 6to4 relay routers to be present on the internet, >> otherwise 6to4 won't work (or return route will be very inefficient). >> teredo requires teredo servers/relays to be present on the internet, >> otherwise teredo client won't work. > > Relay routers are needed to communicate with native Internet, not > between the users of the same transition technology. > > Both 6to4 and Teredo can work, to an extent, when relay routers don't > exist. TSP can't. > > There is path optimization between 6to4 nodes and between Teredo This optimisation is only between nodes that have same technology. Now, if a 6to4 node wants to talk to a Teredo node, at least 2 relays will be involved. The actual path will be much worst than with TSP in the worst case of TSP deployment. Moreover, for Teredo, optimisation works only with some assumptions. If two teredo nodes are behind a NAT and are not on the same link, then no optimisation; moreover, depending on the kind of NAT, they might not be able to communicate at all! > nodes. There is no such thing with TSP (for the good and the bad). > I.e., all the traffic must pass through the server/broker. TSP works in all cases: with or without NAT, with a symmetric NAT, etc... Teredo does not work with symmetric NAT. 6to4 does not traverse NAT. > > These are the main differences with "opportunistic" vs > "non-opportunistic" methods. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Feb 25 03:27:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03124 for ; Wed, 25 Feb 2004 03:27:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvuMN-000Lrj-RK for v6ops-data@psg.com; Wed, 25 Feb 2004 08:25:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvuMM-000LrP-JY for v6ops@ops.ietf.org; Wed, 25 Feb 2004 08:25:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1P8Pa530647; Wed, 25 Feb 2004 10:25:36 +0200 Date: Wed, 25 Feb 2004 10:25:36 +0200 (EET) From: Pekka Savola To: "Bonness, Olaf" cc: v6ops@ops.ietf.org Subject: Re: AW: AW: IPv6 in MPLS Networks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Feb 2004, Bonness, Olaf wrote: > within a complex ISP network you will never switch on IPv6 with one > finger snip. You will choose a staged approach were you can scale > according to the real requirements. Sure, the introduction of IPv6 is always gradual -- how fast each step can be done (or is feasible to do) is a different issue, of course. > Besides that you will for sure > leave the core routers untouched as long as you can, because an > error within this core router does you much more harm than a problem > in one PE. It's not as black and white. The complexity at the PE vs the core is also a factor. That is, if the changes in the core are very simple (compared to changes in the PEs, for example), making changes in the core start to be increasingly attractive as the number of PEs which need modification grow. That is, when the number of modified PEs is high, a problem in the IPv6 code of those PEs would cause a similarly large amount of harm. > Furthermore MPLS has per definition a very flexibel and powerful > label stack principle that allows us to implement new services based > on it. Why not use this approach in a first step for offering IPv6 > at the edges and than integrate it in the MPLS core sometimes in the > future. I have no objection to putting IPv6 directly on top of MPLS. However, I greatly detest hacks which would include additional encapsulation in IPv4 at the BGP/IGP/whatever control plane. > The whole IPv6 migration is only a question of using the > right mechanism at the right time ;-). Precisely :). Configured tunneling at the start, when there are only few customers, and when the relevance grows, migration to IPv6-over-MPLS or real dual-stack? Seems to fill these requirements pretty neatly :) > Besides that this MPLS label > stack is more flexibel than (configured) tunnels and has as well > less overhead. Agreed -- the question is of course whether the flexibility is essential. That is, tunnels eat 20 bytes off your IPv6 MTU, MPLS does not -- and MPLS LPSs would require set-up. Those seem to be basically the only differences, protocol-wise. But practically the IPv6 MTU at the moment is already 1480 bytes due to tunnels so there's little lost there :). So it might be that tunnels are preferable to direct MPLS encapsulation because direct encapsulation does not give sufficient additional benefits in the first step. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Feb 25 04:08:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04051 for ; Wed, 25 Feb 2004 04:08:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avv03-0000mU-By for v6ops-data@psg.com; Wed, 25 Feb 2004 09:06:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avv01-0000lw-T9 for v6ops@ops.ietf.org; Wed, 25 Feb 2004 09:06:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1P96Yu31185; Wed, 25 Feb 2004 11:06:34 +0200 Date: Wed, 25 Feb 2004 11:06:34 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Tailed down Cc: a bit. On Tue, 24 Feb 2004, Erik Nordmark wrote: > It seems odd to say that the criteria is "nodes that implement > X can talk to other nodes which implement X without extra infrastructure" > when extra infrastructure is needed for nodes that implement X > to be able to communicate with nodes that have native IPv6 service. > That seems to forget that the goal is to move towards IPv6 > and not stay with X forever. Yes, this seems odd, and is very unfortunate, causing a "transition mechanism lock-in" of two sorts: requirement for implementing everything, and requirement for keeping everything enabled for a long time. However, unfortunately that seems to be the direction at least some of the deployment is heading.. Do you see feasible-to-deploy methods which would allow basically everyone to obtain IPv6 service independent of their ISP? I'd certainly want to see one -- as it appears, we only seem to have bad choices. Because that seems to be the requirement (with the additional argument, 1), below) causing the inevitability of the abovementioned effect.. > TSP, teredo and 6to4 all need some infrastructure to be able > communicate with nodes that do native IPv6. > Why is it important to make any finer grain distinction? Thanks for bringing this up. I think there are basically two kinds of assumptions which argue for the more fine-grained distinction. Let's try to see if there are others, or if people disagree about these. 1) that the traffic between the users of the same mechanism (or opportunistic mechanisms or dual-stack in general, with glue) would be such that tunnel-brokered model would not be sufficient when the tunnel termination does not occur close to the sources. That is, the prime reasons here are probably: - using applications with heavy bandwidth requirements, causing load to the tunnel servers, causing increased costs to the operators of such servers, even making it unfeasible. With high latency (see below), it might also be impossible to even achieve sufficient bandwidth without major rigging of TCP timers. - using applications with delay requirements, implying that a direct path between two nodes would be preferred. This would rule out tunnel broker/server -like deployments if the deployment is not widespread enough. Tunnel broker in the US would be unacceptable for European users, for example -- and a tunnel broker in the neighboring EU country might even be similarly unacceptable if you wanted to do VoIP with your neighbor. So, this assumption basically implies that if we can reduce the amount of traffic that has to go through the infrastructure, either bandwidth or latency-wise, it might be more feasible to deploy this infrastructure. (One might be able to compare this to the SIP model where the control traffic goes through some intermediaries, but media goes through a more direct route.) 2) 6to4 and Teredo (to a lesser degree AFAIK) are pretty anonymous services. When someone abuses using those addresses, there is no ISP "hosting" the service which would get abuse etc. reports, get blacklisted if someone behaves badly, etc. -- on the other hand, if the ISP offers the service to outsiders using its RIR address space, this will certainly lead to all kinds of nasty administrative actions.. sooner or later raising the question, "why are we even providing this kind of service to outsiders for free, if we get nothing but trouble!?!" Actually, as mentioned in the unmanaged connectivity requirements drafts, if we assume that third parties would be giving away tunnel service for free to anyone, a level of anonymity is desirable (e.g., in our network, we do run 6to4 relay, but we will never run a tunnel broker (well, we could consider tunnel broker for our own customers, but that's beside the point here)). Obviously, this requirement is different if your own ISP is offering this kind of service, or you're entering a contract with the ISP, but the whole point of this "opportunistic" discussion was being able to cope in the scenario when your ISP does NOT offer IPv6 services, and you not being required to "fill any forms" to get IPv6 connectivity. This is why the fundamental first question in considering the "opportunistic" tunneling is whether you consider the deployment to be "vendor-driven" or "user-driven". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Feb 25 17:07:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18121 for ; Wed, 25 Feb 2004 17:07:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw78A-000IyA-CY for v6ops-data@psg.com; Wed, 25 Feb 2004 22:03:50 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw789-000Ixp-Fo for v6ops@ops.ietf.org; Wed, 25 Feb 2004 22:03:49 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1PM3edO022174; Wed, 25 Feb 2004 14:03:40 -0800 (PST) Received: from lillen (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1PM3bQ01563; Wed, 25 Feb 2004 23:03:37 +0100 (MET) Date: Wed, 25 Feb 2004 14:02:01 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Opportunistic Tunneling To: Pekka Savola Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Obviously, this requirement is different if your own ISP is offering > this kind of service, or you're entering a contract with the ISP, but > the whole point of this "opportunistic" discussion was being able to > cope in the scenario when your ISP does NOT offer IPv6 services, and > you not being required to "fill any forms" to get IPv6 connectivity. Should I take the above to be the definition of "opportunistic tunneling"? I'm struggling to understand the motivation for inventing this category thus having a definition of what it means would be helpful. Can you also clarify what "fill in any forms" means. Last time I installed software (I think it was a new version of realplayer) I was asked to register with name and email address. I wouldn't be surprised if the same thing is the case when I e.g. upgrade an operating system. So why is this considered to be too cumbersome given that users already do it? Based on my current understanding the "opportunistic" tunneling as a category doesn't make sense to me. Once I understand your perspective better I'll try to respond to your other comments. Erik From owner-v6ops@ops.ietf.org Wed Feb 25 18:40:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23859 for ; Wed, 25 Feb 2004 18:40:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw8bj-0005x2-S2 for v6ops-data@psg.com; Wed, 25 Feb 2004 23:38:27 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw8bi-0005wo-QG for v6ops@ops.ietf.org; Wed, 25 Feb 2004 23:38:26 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 1C5A9B9; Thu, 26 Feb 2004 08:38:26 +0900 (JST) To: pekkas@netcore.fi Cc: Erik.Nordmark@sun.com, v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling In-Reply-To: Your message of "Wed, 25 Feb 2004 11:06:34 +0200 (EET)" References: X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040225233826.1C5A9B9@coconut.itojun.org> Date: Thu, 26 Feb 2004 08:38:26 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > 2) 6to4 and Teredo (to a lesser degree AFAIK) are pretty anonymous > services. When someone abuses using those addresses, there is no ISP > "hosting" the service which would get abuse etc. reports, get > blacklisted if someone behaves badly, etc. -- on the other hand, if > the ISP offers the service to outsiders using its RIR address space, > this will certainly lead to all kinds of nasty administrative > actions.. sooner or later raising the question, "why are we even > providing this kind of service to outsiders for free, if we get > nothing but trouble!?!" as mentioned in (already expired) transition-abuse draft, 6to4 relay routers (provided by ISPs) will get abused by malicious parties, and ISPs get blamed for the traffic being generated by the abuse. i strongly disagree with the above statement. itojun From owner-v6ops@ops.ietf.org Wed Feb 25 21:13:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00038 for ; Wed, 25 Feb 2004 21:13:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwAz1-0001GI-Ir for v6ops-data@psg.com; Thu, 26 Feb 2004 02:10:39 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwAz0-0001G6-L7 for v6ops@ops.ietf.org; Thu, 26 Feb 2004 02:10:38 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 18:11:09 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 25 Feb 2004 18:09:12 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 25 Feb 2004 18:10:37 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 18:10:37 -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(6.0.3790.1069); Wed, 25 Feb 2004 18:10:35 -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.3790.1069); Wed, 25 Feb 2004 18:10:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Opportunistic Tunneling Date: Wed, 25 Feb 2004 18:10:14 -0800 Message-ID: Thread-Topic: Opportunistic Tunneling Thread-Index: AcP7+XTRaykqlNS7TrKcO5E8D4JA/AAEiFjA From: "Christian Huitema" To: "Jun-ichiro itojun Hagino" , Cc: , X-OriginalArrivalTime: 26 Feb 2004 02:10:31.0078 (UTC) FILETIME=[B5C3AC60:01C3FC0D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > 2) 6to4 and Teredo (to a lesser degree AFAIK) are pretty anonymous > > services. When someone abuses using those addresses, there is no ISP > > "hosting" the service which would get abuse etc. reports, get > > blacklisted if someone behaves badly, etc. -- on the other hand, if > > the ISP offers the service to outsiders using its RIR address space, > > this will certainly lead to all kinds of nasty administrative > > actions.. sooner or later raising the question, "why are we even > > providing this kind of service to outsiders for free, if we get > > nothing but trouble!?!" >=20 > as mentioned in (already expired) transition-abuse draft, 6to4 relay > routers (provided by ISPs) will get abused by malicious parties, and > ISPs get blamed for the traffic being generated by the abuse. i > strongly disagree with the above statement. Please note that this is mostly a 6to4 issue. Teredo requires a three-ways handshake before sending data through a relay, which makes attacks much harder. For 6to4, Pekka has proposed a solution: that relay routers source packets from the reserved address 192.88.99.1. This solution certainly solves the "ISP get blamed" part, since the 6to4 packets will not identify a specific relay.=20 The solution also has the potential of solving the abuse scenario in which a 3rd party obtains the IPv4 address of a relay and uses it to send traffic: since the relays are only listening to the anycast address, they can only receive traffic from networks to which they advertise the anycast address. We would also achieve some protection against spoofing if we requested that 6to4 routers only accept "native IPv6 packets" from the anycast relay. Hackers will have to be able to spoof IPv4 in order to spoof IPv6. (Another way to solve this issue is to require a 3-ways handshake similar to Teredo; we could require it if the packet comes from another address.) In any case, we should all be aware that hackers do not need to be able to spoof addresses in order to mount a DDOS attack. The recent attacks mounted by the MYDOOM worm consisted of establishing TCP connections to a target site, and loading a page from the site. No spoofing, just very many connections from very many zombies.=20 -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Feb 26 01:09:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08105 for ; Thu, 26 Feb 2004 01:09:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwEdt-0007JL-4i for v6ops-data@psg.com; Thu, 26 Feb 2004 06:05:05 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw9KW-000CHp-1s for v6ops@ops.ietf.org; Thu, 26 Feb 2004 00:24:44 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1Q0OYm09238; Wed, 25 Feb 2004 16:24:34 -0800 X-mProtect: <200402260024> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdJSAWLI; Wed, 25 Feb 2004 16:24:31 PST Message-Id: <4.3.2.7.2.20040225083102.0255c3f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Feb 2004 16:20:41 -0800 To: Pekka Savola From: Bob Hinden Subject: Re: Opportunistic Tunneling Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [[ mailing-list moderator note: non-member submission ]] Pekka, >This is why the fundamental first question in considering the >"opportunistic" tunneling is whether you consider the deployment to be >"vendor-driven" or "user-driven". I don't understand the distinction you suggest between "vendor-driven" or "user-driven". Vendors will supply the products that most people will use independent of how the products are used. Most "users" don't write specifications or write code. Is the distinction whether the transition is driven from the middle (i.e., an ISP providing native IPv6) or from the edge (via automatic tunneling where the users ISP doesn't yet support native IPv6)? Or something else? Bob From owner-v6ops@ops.ietf.org Thu Feb 26 01:27:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08534 for ; Thu, 26 Feb 2004 01:27:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwEx2-0009N1-3f for v6ops-data@psg.com; Thu, 26 Feb 2004 06:24:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwEx0-0009MO-Sa for v6ops@ops.ietf.org; Thu, 26 Feb 2004 06:24:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1Q6NpI16771; Thu, 26 Feb 2004 08:24:07 +0200 Date: Thu, 26 Feb 2004 08:23:51 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: Erik.Nordmark@sun.com, Subject: Re: Opportunistic Tunneling In-Reply-To: <20040225233826.1C5A9B9@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 26 Feb 2004, Jun-ichiro itojun Hagino wrote: > > 2) 6to4 and Teredo (to a lesser degree AFAIK) are pretty anonymous > > services. When someone abuses using those addresses, there is no ISP > > "hosting" the service which would get abuse etc. reports, get > > blacklisted if someone behaves badly, etc. -- on the other hand, if > > the ISP offers the service to outsiders using its RIR address space, > > this will certainly lead to all kinds of nasty administrative > > actions.. sooner or later raising the question, "why are we even > > providing this kind of service to outsiders for free, if we get > > nothing but trouble!?!" > > as mentioned in (already expired) transition-abuse draft, 6to4 relay > routers (provided by ISPs) will get abused by malicious parties, and > ISPs get blamed for the traffic being generated by the abuse. i > strongly disagree with the above statement. As stated earlier, using 192.88.99.1 fixes some of that. Of course, if you source that traffic towards your neighbor, he could send abuse report anyway ("your network is sending something weird at us!") -- which using a neutral source address obviously does not fix. I assume you disagree with "no ISP is hosting the service to get abuse reports". Because I'm sure you'll agree the implied fact that if the ISP has to choose between: 1) providing 6to4 relay to anonymous outsiders, with 192.88.99.1 address, or 2) providing tunnel service to anonymous outsiders, with its own address space 1) seems to be significantly simpler to handle abuse-wise. Many ISPs could do 1), but would never do 2). This is the critical point. If we don't do something like 6to4, there must be a lot of anonymous ISPs offering similar, free and easy-to-setup tunnel-broker -like service. Comparison of 1) and 2) implies that that such a tunnel server model would be unfeasible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Feb 26 01:37:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09220 for ; Thu, 26 Feb 2004 01:37:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwF6I-000Aj1-Du for v6ops-data@psg.com; Thu, 26 Feb 2004 06:34:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwF6G-000Aii-W6 for v6ops@ops.ietf.org; Thu, 26 Feb 2004 06:34:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1Q6YGJ16895; Thu, 26 Feb 2004 08:34:16 +0200 Date: Thu, 26 Feb 2004 08:34:16 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: Erik Nordmark , Subject: Re: Opportunistic Tunneling In-Reply-To: <4.3.2.7.2.20040225083102.0255c3f0@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, 25 Feb 2004, Bob Hinden wrote: > >This is why the fundamental first question in considering the > >"opportunistic" tunneling is whether you consider the deployment to be > >"vendor-driven" or "user-driven". > > I don't understand the distinction you suggest between "vendor-driven" or > "user-driven". I tried to briefly describe this in the first message of the thread: ==== 1) Do we agree that this is something we need in the first place? * Considering user-driven deployment, maybe not. - example: the user says "I want to use application X" or "I want to use functionality Y", where X or Y would require IPv6. * Considering large-scale vendor-centric deployment, probably yes. ==== maybe this needs to be expanded; I have tried to describe this at more length below. > Vendors will supply the products that most people will use > independent of how the products are used. Most "users" don't write > specifications or write code. Of course. > Is the distinction whether the transition is driven from the middle (i.e., > an ISP providing native IPv6) or from the edge (via automatic tunneling > where the users ISP doesn't yet support native IPv6)? Or something else? Pretty close, yes. I think this can be looked at from the perspective of who is driving the IPv6 deployment. If the user wants to use an application (or something else) which requires or would profit from IPv6, I consider the case "user-driven". The user says, "I want to do X", where X requires IPv6. As the user has motivation for getting IPv6 connectivity, (s)he will be willing to do some effort to make it happen: e.g., contact his ISP, asking for a tunnel or native service, contact a tunnel broker, or whatever. This is the model we've started with, I think. Automatic mechanisms can help here as well, but they aren't strictly required IMHO. Now, let's look at this from the different angle. A vendor wants to start using IPv6 in its products for some specific reason, independent of what the user thinks. For example, to simplify its peer-to-peer applications. To be able to deploy the new version of the products/applications in any meaningful way, the vendor requires that IPv6 connectivity must be available to all or at least significant portion of the user base. As there are thousands of ISPs in the world, with only a few offering IPv6, "managed methods" as described above are a non-starter. The vendor requires *something* which will be able to kickstart IPv6 deployment. The deployment of automatic tunneling mechanisms is this something. Hope this clarifies.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Feb 26 01:41:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09445 for ; Thu, 26 Feb 2004 01:41:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwFAf-000BGc-CO for v6ops-data@psg.com; Thu, 26 Feb 2004 06:38:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwFAe-000BGP-66 for v6ops@ops.ietf.org; Thu, 26 Feb 2004 06:38:56 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1Q6crK16970; Thu, 26 Feb 2004 08:38:53 +0200 Date: Thu, 26 Feb 2004 08:38:53 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 25 Feb 2004, Erik Nordmark wrote: > > Obviously, this requirement is different if your own ISP is offering > > this kind of service, or you're entering a contract with the ISP, but > > the whole point of this "opportunistic" discussion was being able to > > cope in the scenario when your ISP does NOT offer IPv6 services, and > > you not being required to "fill any forms" to get IPv6 connectivity. > > Should I take the above to be the definition of "opportunistic tunneling"? > I'm struggling to understand the motivation for inventing this category thus > having a definition of what it means would be helpful. I'm having trouble defining it myself, but I think it's probably pretty close. See also the concerns of path optimization which relate to this. > Can you also clarify what "fill in any forms" means. Last time I installed > software (I think it was a new version of realplayer) I was asked to register > with name and email address. I wouldn't be surprised if the same thing > is the case when I e.g. upgrade an operating system. > So why is this considered to be too cumbersome given that users already > do it? This is a good point, but I think this is obvious. If the deployment is "user-driven", that's fine. If the deployment is "vendor-driven", that seems unacceptable. (See the note to Bob Hinden about elaboration of these.) That is, if the vendor enables IPv6 on the host, the user won't appreciate a pop-up message, requiring him to fill in some details -- "IPv6 -- never heard of that!?!?". Likewise, the vendor can't fill them either, at least without resulting to forgery or spoofing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Feb 26 07:05:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06737 for ; Thu, 26 Feb 2004 07:05:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwKCY-000NbA-4D for v6ops-data@psg.com; Thu, 26 Feb 2004 12:01:14 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwKCW-000NZv-Pd for v6ops@ops.ietf.org; Thu, 26 Feb 2004 12:01:12 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QC1Bt20783 for ; Thu, 26 Feb 2004 14:01:11 +0200 (EET) X-Scanned: Thu, 26 Feb 2004 14:01:02 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1QC126l028463 for ; Thu, 26 Feb 2004 14:01:02 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 009e2cKk; Thu, 26 Feb 2004 14:01:01 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QC11O29203 for ; Thu, 26 Feb 2004 14:01:01 +0200 (EET) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 14:01:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: V6ops: Calling for Scribes Date: Thu, 26 Feb 2004 14:00:55 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195B15FE2@esebe024.ntc.nokia.com> Thread-Topic: V6ops: Calling for Scribes Thread-Index: AcP7yERBvrn1JQiJRP+i1LzT4/AFvg== From: To: X-OriginalArrivalTime: 26 Feb 2004 12:01:01.0124 (UTC) FILETIME=[33B7A840:01C3FC60] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello everybody, I'm approaching you all to find some happy volunteers for a two nice = jobs:=20 1) A scribe - preferably native English speaker to write the minutes of = the v6ops sessions. 2) A jabber scribe The pay is the normal IETF pay: honour and the admiration of your follow = IETFers. Cheers, Jonne. --------------------- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com=20 From owner-v6ops@ops.ietf.org Thu Feb 26 11:50:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23717 for ; Thu, 26 Feb 2004 11:49:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwOeJ-0003B5-H9 for v6ops-data@psg.com; Thu, 26 Feb 2004 16:46:11 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwO67-000PdJ-26 for v6ops@ops.ietf.org; Thu, 26 Feb 2004 16:10:51 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1QGAfvI003097; Thu, 26 Feb 2004 11:10:41 -0500 (EST) Date: Thu, 26 Feb 2004 11:10:39 -0500 From: Marc Blanchet To: Pekka Savola , Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling Message-ID: <53000000.1077811839@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [[ note: post by non-subscriber ]] -- Thursday, February 26, 2004 08:38:53 +0200 Pekka Savola wrote/a ecrit: > On Wed, 25 Feb 2004, Erik Nordmark wrote: >> > Obviously, this requirement is different if your own ISP is offering >> > this kind of service, or you're entering a contract with the ISP, but >> > the whole point of this "opportunistic" discussion was being able to >> > cope in the scenario when your ISP does NOT offer IPv6 services, and >> > you not being required to "fill any forms" to get IPv6 connectivity. >> >> Should I take the above to be the definition of "opportunistic >> tunneling"? I'm struggling to understand the motivation for inventing >> this category thus having a definition of what it means would be helpful. > > I'm having trouble defining it myself, then I would suggest that you write a draft. >but I think it's probably > pretty close. See also the concerns of path optimization which relate > to this. > >> Can you also clarify what "fill in any forms" means. Last time I >> installed software (I think it was a new version of realplayer) I was >> asked to register with name and email address. I wouldn't be surprised >> if the same thing is the case when I e.g. upgrade an operating system. >> So why is this considered to be too cumbersome given that users already >> do it? > > This is a good point, but I think this is obvious. If the deployment > is "user-driven", that's fine. If the deployment is "vendor-driven", > that seems unacceptable. I'm even more confused about your statement on user/vendor. Does not seem to me relevent to our technical discussion. > (See the note to Bob Hinden about elaboration > of these.) > > That is, if the vendor enables IPv6 on the host, the user won't > appreciate a pop-up message, requiring him to fill in some details -- > "IPv6 -- never heard of that!?!?". well, yes, we all want ipv6 to not be shown on the user interface. However, playing devil's advocate, it happens a lot in IPv4 and it happened to me on a cell phone recently... oh well... that is "life"... seriously, I think we agree that ipv6 connectivity and addressing should be as transparent to the user as possible. However, I don't understand where you are going to. To me, the different tools we are talking about are similar to that respect: isatap, 6to4, teredo, TSP are all, from the user point of view (i.e. the cell phone user), a "driver" in the operating system: i.e. they don't care and don't have to manage it. And the infrastructure and services to make them usable are provided by some downstream providers, either the direct one, or another one downstream. Marc. > Likewise, the vendor can't fill > them either, at least without resulting to forgery or spoofing. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Thu Feb 26 13:05:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00147 for ; Thu, 26 Feb 2004 13:05:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwPqt-000Cke-HV for v6ops-data@psg.com; Thu, 26 Feb 2004 18:03:15 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwPqs-000CkH-Jj for v6ops@ops.ietf.org; Thu, 26 Feb 2004 18:03:14 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1QI34D31182; Thu, 26 Feb 2004 10:03:04 -0800 X-mProtect: <200402261803> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvvjQrd; Thu, 26 Feb 2004 10:03:02 PST Message-ID: <403E34E4.1070501@iprg.nokia.com> Date: Thu, 26 Feb 2004 10:03:16 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Blanchet CC: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling References: <53000000.1077811839@classic.viagenie.qc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Marc, Marc Blanchet wrote: >However, I don't understand where you are going to. > I have also been struggling to understand this distinction. >To me, the different >tools we are talking about are similar to that respect: isatap, 6to4, >teredo, TSP are all, from the user point of view (i.e. the cell phone >user), a "driver" in the operating system: i.e. they don't care and don't >have to manage it. And the infrastructure and services to make them usable >are provided by some downstream providers, either the direct one, or >another one downstream. > I agree, however it seems that TSP takes the "high road" and negotiates tunnel configuration via TCP connections and XML exchanges while the other mechanisms take the "low road" and use, e.g., IPv6 ND messages. Under TSP, the number of messages involved in setting up and tearing down TCP connections, sending the XML, etc. can seemingly become quite high. So, if nodes require short-lived tunnels and/or many tunnels to many different endpoints there could be a significant efficiency advantage in using the "low road" mechanisms. Whether this can be seen as a measure of "opportunism" I cannot say? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Feb 26 14:51:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05346 for ; Thu, 26 Feb 2004 14:51:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwRVT-000O9K-J6 for v6ops-data@psg.com; Thu, 26 Feb 2004 19:49:15 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwQTF-000GaX-Py for v6ops@ops.ietf.org; Thu, 26 Feb 2004 18:42:53 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1QIgRvO003203; Thu, 26 Feb 2004 13:42:36 -0500 (EST) Date: Thu, 26 Feb 2004 13:42:25 -0500 From: Marc Blanchet To: Fred Templin cc: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling Message-ID: <8120000.1077820945@classic.viagenie.qc.ca> In-Reply-To: <403E34E4.1070501@iprg.nokia.com> References: <53000000.1077811839@classic.viagenie.qc.ca> <403E34E4.1070501@iprg.nokia.com> X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Thursday, February 26, 2004 10:03:16 -0800 Fred Templin wrote/a ecrit: > Hello Marc, > > Marc Blanchet wrote: > >> However, I don't understand where you are going to. >> > > I have also been struggling to understand this distinction. > >> To me, the different >> tools we are talking about are similar to that respect: isatap, 6to4, >> teredo, TSP are all, from the user point of view (i.e. the cell phone >> user), a "driver" in the operating system: i.e. they don't care and don't >> have to manage it. And the infrastructure and services to make them >> usable are provided by some downstream providers, either the direct one, >> or another one downstream. >> > > I agree, however it seems that TSP takes the "high road" and negotiates > tunnel configuration via TCP connections or UDP. for nat traversal, it does tsp over udp. > and XML exchanges while the > other mechanisms take the "low road" and use, e.g., IPv6 ND messages. > Under TSP, the number of messages involved one "request" message in XML, one "reply" message in XML. >in setting up and tearing > down TCP connections, sending the XML, etc. can seemingly become > quite high. - udp is pretty light. - define high?. XML takes more bytes than binary. But XML is more extensible. TSP/XML gives you the ability to negociate things that are useful/required for some scenarios, such as DNS names, dns delegation, prefix delegation, etc.. Pros and cons. > > So, if nodes require short-lived tunnels and/or many tunnels to many > different endpoints there could be a significant efficiency advantage > in using the "low road" mechanisms. Whether this can be seen as > a measure of "opportunism" I cannot say? looks more as how many bytes you care about consuming for your control connection. Remember that TSP is only involved at the setup of the tunnel. So the cost is pretty low compared with the traffic itself. Marc. > > Fred > ftemplin@iprg.nokia.com > From owner-v6ops@ops.ietf.org Thu Feb 26 15:48:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09020 for ; Thu, 26 Feb 2004 15:48:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwSOZ-0004lC-My for v6ops-data@psg.com; Thu, 26 Feb 2004 20:46:11 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwSOT-0004kh-9m for v6ops@ops.ietf.org; Thu, 26 Feb 2004 20:46:05 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1QKjtm04326; Thu, 26 Feb 2004 12:45:55 -0800 X-mProtect: <200402262045> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEwY2rN; Thu, 26 Feb 2004 12:45:53 PST Message-ID: <403E5B0F.3080901@iprg.nokia.com> Date: Thu, 26 Feb 2004 12:46:07 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Blanchet CC: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling References: <53000000.1077811839@classic.viagenie.qc.ca> <403E34E4.1070501@iprg.nokia.com> <8120000.1077820945@classic.viagenie.qc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marc, Marc Blanchet wrote: >- define high?. XML takes more bytes than binary. But XML is more >extensible. > Yes, the tradeoff between efficiency and extensibility is a familiar one and worth noting. >TSP/XML gives you the ability to negociate things that are >useful/required for some scenarios, such as DNS names, dns delegation, >prefix delegation, etc.. Pros and cons. > But, these things can also be negotiated in other ways. As you say, pros and cons. >>So, if nodes require short-lived tunnels and/or many tunnels to many >>different endpoints there could be a significant efficiency advantage >>in using the "low road" mechanisms. Whether this can be seen as >>a measure of "opportunism" I cannot say? >> >> > >looks more as how many bytes you care about consuming for your control >connection. Remember that TSP is only involved at the setup of the tunnel. >So the cost is pretty low compared with the traffic itself. > The key point here is amortization of the control traffic wrt the user traffic. For short-lived tunnels and/or dynamic management of many tunnels to many different endpoints, the amout of control traffic would seem to matter. Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Feb 27 00:37:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00687 for ; Fri, 27 Feb 2004 00:37:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwacE-000B8n-W7 for v6ops-data@psg.com; Fri, 27 Feb 2004 05:32:50 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwacD-000B8H-7m for v6ops@ops.ietf.org; Fri, 27 Feb 2004 05:32:49 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1R5WjvI003647 for ; Fri, 27 Feb 2004 00:32:46 -0500 (EST) Date: Fri, 27 Feb 2004 00:32:43 -0500 From: Marc Blanchet To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt Message-ID: <76170000.1077859963@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit good work and document. extracted text with comments tagged with and suggestion of text. Marc. ============ A) a gateway which does not provide IPv6 at all; B) a dual-stack gateway connected to a dual-stack ISP; C) a dual-stack gateway connected to an IPv4-only ISP; and D) a gateway connected to an IPv6-only ISP. in both the scenario and the eval, the term "dual-stack" ISP is used. just wondering if an ISP network can really be named "dual-stack". Would "dual protocol network" be more appropriate name? During the transition phase from IPv4 to IPv6 there will be IPv4- only, dual-stack or IPv6-only nodes. In this document, we make the s/or/and/ 2.1 Comparing automatic and configured solutions It is possible to broadly classify tunneling solutions as either "automatic" or "configured". "configured' is used in other ietf documents to denote manually configured static tunnels. However, in this document, configured usually means the tunnel broker configured tunnels, either with the web or the TSP model; since the manually configured static tunnels is obviously not an unmanaged solution. However, sometimes the comments on configured tunnels are related to the manually configured static tunnels. To avoid confusion, it was suggested during a presentation in Vienna, the word "negociated tunnels" to denote the kind of configured tunnels set by tunnel brokers and the like. Would suggest "negociated tunnels" to be used in the document, so the reader will understand the difference with the manually configured static tunnels. Suggesting to s/configured tunnels/negociated tunnels/g throughout the text In an automatic solution, a host or a router builds an IPv6 address or an IPv6 prefix by combining a pre- defined prefix with some local attribute, such as local IPv4 address [6TO4] or the combination of an address and a port number [Teredo]. Another typical and very important characteristic of an automatic solution is they aim to work with a minimal amount of support or infrastructure for IPv6 in the local or remote ISPs. In a configured solution, a host or a router identifies itself to a tunneling service to set up a "configured tunnel" with an explicitly defined "tunnel router". negociated tunnels have the same aim to work ... than automatic tunnel. Suggesting text to replace "Another typical ... "tunnel router": For negociated tunnels, a host or a router receives an IPv6 address or an IPv6 prefix from its tunnel broker, such as [TUNNELS] and [TSP]. Another typical and very important characteristic of an automatic or negociated solution is they aim to work with a minimal amount of support or infrastructure for IPv6 in the local or remote ISPs. workarounds are probably possible). However, automatic tunnels have other advantages. They are obviously easier to configure, since there is no need of an explicit relation with a tunnel service. 6to4, teredo and [TSP] all require a single IPv4 address to be configured. Moreover, one of the "automatic" tunneling technique requires the configuration and knowledge of 2 IPv4 addresses. So this comment is not appropriate. Suggesting text: "However, automatic tunnels and negociated tunnels are easier to configure." In automatic tunnels like [Teredo] and [6to4], the bulk of the traffic between two nodes using the same technology is exchanged on Is "direct path always possible in all cases between Teredo nodes? a direct path between the endpoints, using the IPv4 services to which the endpoints already subscribe. By contrast, the configured tunnel servers carry all the traffic exchanged by the tunnel client. Path optimization is not a big issue if the tunnel server is close to the client, on the natural path between the client and its peers. However, if the tunnel server is operated by a third party, this third party will have to bear the cost of provisioning the bandwidth used by the client. The associated costs can be significant. what is this cost compared/different to running a relay for 6to4 or Teredo? Not clear to me what is the argument here. Suggesting: s/The associated costs can be significant// ... 2.1.2 Automatic tunnels and relays The economics arguments related to path optimization favor either configured tunnels provided by the local ISP or automatic tunneling regardless of the co-operation of ISPs. However, automatic solutions require that relays be configured throughout the Internet. If a host that obtained connectivity through an automatic tunnel service wants to communicate with a "native" host, s/"native" host/"native host or another host using another automatic tunnel service"/ it will need to use a relay service, and someone will have to provide and pay for that service. We cannot escape economic considerations for the deployment of these relays. ... 2.1.3 The risk of several parallel IPv6 Internets In an early deployment of the Teredo service by Microsoft, s/Microsoft/one vendor/ ... communications between 6to4 hosts. This will create an incentive for native hosts to somehow "multi-home" to 6to4, de facto creating two parallel Internets, 6to4 and native. This risk will only be mitigated if there is a sufficient deployment of 6to4 relays. Suggesting to add the following text: Negociated tunnels, such as [TUNNELS] or [TSP] do not have this risk of several parallel IPv6 Internets. 2.1.4 Lifespan of transition technologies A related issue is the lifespan of the transition solutions. Since automatic tunneling technologies enable an automatic deployment, there is a risk that some hosts never migrate out of the transition. The risk is arguably less for explicit tunnels: the ISPS who provide the tunnels have an incentive to replace them with a native solution as soon as possible. Many implementations of automatic transition technologies incorporate an "implicit sunset" mechanism: the hosts will not configure a transition technology address if they have native connectivity; the address selection mechanisms will prefer native addresses when available. The transition technologies will stop being used eventually, when native connectivity has been deployed everywhere. However, the "implicit sunset" mechanism does not provide any hard guarantee that transition will be complete at a certain date. Yet, the support of transition technologies has a cost for the entire network: native IPv6 ISPS have to support relays in order to provide good performance and avoid the "parallel Internet" syndrome. These costs may be acceptable during an initial deployment phase, but they can certainly not be supported for an indefinite period. The "implicit sunset" mechanisms may not be sufficient to guarantee a finite lifespan of the transition. 2.2 Cost and benefits of NAT traversal During the transition, some hosts will be located behind IPv4 NATs. In order to participate in the transition, these hosts will have to use a tunneling mechanism designed to traverse NAT. We may ask whether NAT traversal should be a generic property of any transition technology, or whether it makes sense to develop two types of technologies, some "NAT capable" and some not. An important question is also which kinds of NAT boxes one should be able to traverse. One should probably also consider whether it is necessary to build an IPv6 specific NAT traversal mechanism, or whether it is possible to combine an existing IPv4 NAT traversal mechanism with some form of IPv6 in IPv4 tunneling. There are many IPv4 NAT traversal mechanisms; thus one may ask whether these need re-invention, especially when they are already complex. A related question is whether the NAT traversal technology should use automatic tunnels or configured tunnels. We saw in the previous section that one can argue both sides of this issue. In fact, there are already deployed automatic and configured solutions, so the reality is that we will probably see both. Huitema et al. [Page 5] INTERNET DRAFT Unmanaged Networks Transition Tools February 4, 2004 2.2.1 Cost of NAT traversal NAT traversal technologies generally involve encapsulating IPv6 packets inside a transport protocol that is known to traverse NAT, such as UDP or TCP. These transport technologies require significantly more overhead than the simple tunneling over IPv4 used in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on UDP require the frequent transmission of "keep alive" packets to maintain a "mapping" in the NAT; solutions based on TCP may not require such mechanism, but they incur the risk of "head of queue blocking", which may translate in poor performances. Given the difference in performance, it makes sense to consider two types of transition technologies, some capable of traversing NAT and some aiming at the best performance. 2.2.2 Types of NAT There are many kinds of NAT on the market. Different models implement different strategies for address and port allocations, and also different types of timers. It is desirable to find solutions that cover "almost all" models of NAT. It appears to me that the goal is to cover _all_ models/behaviors of NAT, not "almost all". Because the end user does not know behind which kind of NAT he is, and we don't want him to know. However, the end-user wants to have connectivity in all cases. I can't imagine my laptop not getting IPv6 connectivity with a non-complete NAT traversal solution, where, in one specific hotel room, they are using a NAT which does not work with the NAT traversal solution in my laptop. Suggesting: s/cover "almost all"/cover all/. ... by many applications, e.g., networked games or voice over IP. The experience shows that most recent "home routers" are designed to support these applications. In some edge cases, the automatic solutions will require explicit configuration of a port in the home router, using the so-called "DMZ" functions. only works for one single node. Moreover, it should be noted that this explicit configuration is completly out of the _unmanaged_ goal. Suggesting text: using the so-called "DMZ" functions". These cases are obviously out of scope of the unmanaged network scenario and only work for a single node behind the NAT. 2.3 Development of transition mechanisms The previous sections make the case for the development of four transition mechanism, covering the following 4 configuration: - Configured tunnel over IPv4 in the absence of NAT; - Automatic tunnel over IPv4 in the absence of NAT; - Configured tunnel across a NAT; - Automatic tunnel across a NAT. Teredo is an example of already designed solution for automatic tunnel across a NAT; 6to4 is an example of solution for automatic tunnel over IPv4 in the absence of NAT. all solutions should be mentionned. Suggesting to add this text: s/absence of NAT./absence of NAT. [TSP] is an example of solution of negociated tunnel over IPv4 in the absence of NAT and negociated tunnel across a NAT. 3.1 Evaluation of connectivity mechanisms In case A, IPv6 capable hosts seek IPv6 connectivity in order to communicate with applications in the global IPv6 Internet. The connectivity requirement can be met using either configured tunnels or automatic tunnels. An automatic solution like Teredo appears to be a good fit for providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 deployment. The service is designed for minimizing the cost of deploying the server, which matches the requirement of minimizing the cost of the "supporting infrastructure". I don't understand why TSP was not suggested here at the same level of Teredo as "good fit". Suggesting text: s/An automatic solution like Teredo appears/Teredo and TSP appear/ 3.2 Security considerations in case A A characteristic of case A is that an isolated host acquires global text should be provided about the need of the relay function for teredo and 6to4 and the security considerations of those relays. ... 4.3.1 Provisioning the address of a DNS resolver In an unmanaged environment, IPv4 hosts usually obtain the address of the local DNS resolver through DHCPv4; the DHCPv4 service is generally provided by the gateway. The gateway will also use DHCPv4 to obtain the address of a suitable resolver from the local Internet service provider. The DHCPv4 solution will suffice in practice for the gateway and also for the dual-stack hosts. There is evidence that even the simple DNS resolvers present in small gateways can relay arbitrary DNS requests and serve arbitrary DNS records, including AAAA records. I'm not sure I really understand or agree on the above paragraph. I understand the comment as if the small gateway IP address is put in the resolv.conf file of the node and that small gateway will relay requests and response. My experience with small gateways and cable/dsl operators is that the small gateway is not involved as relay for dns requests/answers. DNS request go directly from node to DNS server of the ISP. 4.3.2 Publishing IPv6 addresses to the Internet ... Dynamic configuration using the same type of ad hoc protocols that are common today is indeed possible, but the IETF should encourage the use of standard solutions based on Dynamic DNS (DDNS). TSP does the configuration of Ipv6 address of the tunnel endpoint (as well as the dns reverse tree in case of prefix delegation). Suggesting text: Tunnel Brokers[TSP or TUNNELS] do provide the publication of the IPv6 addresses as part of the establishment of the tunnel. 5.1 Connectivity Connectivity in case C requires some form of tunneling of IPv6 over IPv4. The various tunneling solutions are discussed in section 2. The requirements of case C can be solved by an automatic tunneling mechanism such as 6to4 [6TO4]. An alternative may be the use of a configured tunnels mechanism [TUNNELS], but as the local ISP does is not IPv6-enabled this may not be feasible. do not agree with this conclusion: the local ISP might not have upgraded its access infrastructure, but might have backbone or a cloud which is IPv6. Moreover, the upstream ISP might be IPv6. Suggesting to: replace "such as 6to4 [6TO4]. An alternative ... feasible." by: such as 6to4 [6TO4] or tunnel broker [TSP,TUNNELS]. (and remove the "alternative way" sentence. The practical conclusion of our analysis is that "upgraded gateways" will probably support the 6to4 technology, and will have an optional configuration option for "configured tunnels". seems to imply many things about how vendors package their product. not sure that is the "business" of IETF. Would suggest to change the wording to: s/will probably support the 6to4 technology and will have ...tunnels"./ might support 6to4 or TSP/ The tunnel broker technology should be augmented, to include support for some form of automatic configuration. do not agree. TSP tunnel broker in anonymous auth mode is as automatic as teredo or 6to4. Suggesting to remove the sentence "The tunnel broker ... configuration". Due to concerns with potential overload of public 6to4 relays, the 6to4 implementations should include a configuration option that let user take advantage of specific relays. 6 Meeting the case D requirements In case D, the ISP only provides IPv6 services. 6.1 IPv6 addressing requirements 6.2 IPv4 connectivity requirements Local IPv4 capable hosts may want to still access IPv4-only services. The proper way to do this for dual-stack nodes in the unmanaged network is to develop a form of "IPv4 over IPv6" tunneling. This tunneling protocol need to be standardized. Part of the standardization will have to cover configuration issues, i.e., how to provision the IPv4 capable hosts with the address of the local IPv4 tunnel servers. do not agree, seems to imply there are no solutions in place. There are DSTM and TSP. TSP works today with this. Suggesting to replace: "This tunneling ... tunnel servers." by: TSP tunnel broker and DSTM are available for this purpose. TSP provides a ubiquitous way to provide v6 in v4 with or without NAT and v4 in v6. After a careful analysis of the possible solutions, we can list a set of recommendations for the V6OPS working group: 1- To meet case A and case C requirements, we need to develop, or continue to develop, four types of tunneling technologies: automatic tunnels without NAT traversal such as [6TO4], automatic tunnels with NAT traversal such as [TEREDO], configured tunnels without NAT traversal such as [TUNNELS] and configured tunnels with NAT traversal. s/configured tunnels without NAT traversal such as [TUNNELS]/ configured tunnels without NAT traversal such as [TUNNELS,TSP], configured tunnels with NAT traversal[TSP] and IPv4 in IPv6 tunnels with [TSP]./ 2- To meet case B "informal prefix sharing" requirements, we would need a standardized way to perform "ND proxy", possibly as part of a "multi-link subnet" specification. (The explicit prefix delegation can be accomplished through [PREFIXDHCPV6].) 3- To meet case B naming requirements we need to proceed with the standardization of LLMNR. (The provisioning of DNS parameters can be accomplished through [DNSDHCPV6].) 4- To meet case D IPv4 connectivity requirement, we need to standardize an IPv4 over IPv6 tunneling mechanism, as well as the associated configuration services. again, do not agree. already in place. Suggesting to delete 4- since text is added in 1- for that purpose. 8 Security considerations This memo describes the general requirements for transition mechanisms. Specific security issues should be studied and addressed during the development of the specific mechanisms. a discussion and reference to draft on security of relays should be provided here 13 References Normative references to add: [TSP] Blanchet, M. "IPv6 tunnel broker with Tunnel Setup Protocol (TSP)", Work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00. would suggest to add draft filenames in references to make easier to find the documents From owner-v6ops@ops.ietf.org Fri Feb 27 00:46:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01121 for ; Fri, 27 Feb 2004 00:46:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Awanl-000CiA-Ml for v6ops-data@psg.com; Fri, 27 Feb 2004 05:44:45 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwS1a-0002G7-G2 for v6ops@ops.ietf.org; Thu, 26 Feb 2004 20:22:26 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1QKMFJ00978; Thu, 26 Feb 2004 12:22:15 -0800 X-mProtect: <200402262022> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdrSQvL1; Thu, 26 Feb 2004 12:22:12 PST Message-Id: <4.3.2.7.2.20040226115859.03fddc88@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Feb 2004 12:18:24 -0800 To: Pekka Savola From: Bob Hinden Subject: Re: Opportunistic Tunneling Cc: Bob Hinden , Erik Nordmark , In-Reply-To: References: <4.3.2.7.2.20040225083102.0255c3f0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [[ list administrator note: non-member submission ]] Pekka, >I think this can be looked at from the perspective of who is driving >the IPv6 deployment. > >If the user wants to use an application (or something else) which >requires or would profit from IPv6, I consider the case "user-driven". >The user says, "I want to do X", where X requires IPv6. As the user >has motivation for getting IPv6 connectivity, (s)he will be willing to >do some effort to make it happen: e.g., contact his ISP, asking for a >tunnel or native service, contact a tunnel broker, or whatever. This >is the model we've started with, I think. Automatic mechanisms can >help here as well, but they aren't strictly required IMHO. > >Now, let's look at this from the different angle. A vendor wants to >start using IPv6 in its products for some specific reason, independent >of what the user thinks. For example, to simplify its peer-to-peer >applications. To be able to deploy the new version of the >products/applications in any meaningful way, the vendor requires that >IPv6 connectivity must be available to all or at least significant >portion of the user base. As there are thousands of ISPs in the >world, with only a few offering IPv6, "managed methods" as described >above are a non-starter. The vendor requires *something* which will >be able to kickstart IPv6 deployment. The deployment of automatic >tunneling mechanisms is this something. > >Hope this clarifies.. Actually, it doesn't. I think they are the same. The vendor supplies the application requires (or benefits) from IPv6 that the user wants to use. The vendor can supply it so it requires the user to acquire IPv6 service, or it build into its product the ability to detect existing IPv6 connectivity on the users system and if there isn't there, initiate create it via one of the automatic tunneling mechanisms. Both scenarios are vendor and user. The only difference I can see is if the vendor includes the capability to automatically create IPv6 connectivity. Both are driven by the user (wanting to use an application) and enabled by the vendor (including it in the product). The vendor can't make the user do anything (or even buy it's products). I don't see the distinction you are proposing as being useful. More importantly in the current world, a vendor who doesn't include the capability to create IPv6 connectivity where it doesn't exist isn't going to see very much IPv6 application usage. The number of users on the Internet who will know to ask for IPv6 (or anything else technical like public addresses in IPv4) is very very small. How many even know they have a NAT.... This is also why I think that standardizing the current set of automatic tunneling (or whatever we want to call it) mechanisms is very important. We should stop analyzing the requirements and publish the specifications ASAP. Bob From owner-v6ops@ops.ietf.org Fri Feb 27 01:31:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02314 for ; Fri, 27 Feb 2004 01:31:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwbUj-000IJv-M2 for v6ops-data@psg.com; Fri, 27 Feb 2004 06:29:09 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwbUi-000IJe-Qv for v6ops@ops.ietf.org; Fri, 27 Feb 2004 06:29:08 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1R6SQvI003683; Fri, 27 Feb 2004 01:28:27 -0500 (EST) Date: Fri, 27 Feb 2004 01:28:23 -0500 From: Marc Blanchet To: v6ops@ops.ietf.org cc: Pekka Savola , jonne.soininen@nokia.com, mikael.lind@teliasonera.com Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Message-ID: <11510000.1077863303@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit good document and work. quoted text provided with comments in and with suggested text when appropriate. Marc. ---------------------- It is also outside the scope of this document to describe different types of access or network technologies. to be more precise, suggesting: s/of access or network technologies/of layer1-2 access or network technologies/. ... 3.2.1 Stage 1 Scenarios: Launch ... The immediate first step consists of getting a prefix allocation (typically a /32) from the appropriate RIR according to allocation procedures. while clearly a good advice, not sure really useful to discuss here given the objective of the document. The selection of one candidate depends largely on the presence or absence of NATs between the two tunnel end-points and whether the user's IPv4 tunnel end-point address is static or dynamic. In most cases, 6to4 and ISATAP are incompatible with NATs, and UDP encapsulation for configured tunnels has not been specified. configured tunnels with tunnel brokers [TSP] is specified for NAT traversal. However, NAT traversal can be avoided if the NAT supports forwarding protocol-41 [PROTO41]. s/protocol-41/protocol-41 and configured to do so./ The connectivity mechanisms can be categorized as "managed" or "opportunistic." The former consist of native service or a configured tunnel (with or without a tunnel broker); the latter include 6to4 and, e.g., Teredo; they provide "short-cuts" between nodes using the same mechanisms and are available without contracts with the ISP. Teredo needs a Teredo server located outside of the NAT, which means in the architecture presented in section 2, as customer connection network. Most interesting are the managed services. When dual-stack is not an option, a form of tunneling must be used. When configured tunneling is not an option (e.g., due to dynamic IPv4 addressing), some form of automation has to be used. The options are basically either to deploy an L2TP architecture (whereby the customers would run L2TP clients and PPP over it to initiate IPv6 sessions) or to deploy a tunnel configuration service. The prime candidates for tunnel configuration are STEP [STEP] and TSP [TSP], which are not analyzed further in this document. would also add that these services are able to do NAT traversal. Suggesting: s/are STEP and TSP , providing tunnels with or without the presence of NAT./ Note that when customers use dynamic IPv4 addresses, the tunneling techniques may be more difficult to deploy at the ISP's end, especially if a protocol including authentication (like PPP for IPv6) is not used. This may need to be considered in more detail with tunneling mechanisms. disagree for TSP. TSP re-establish the tunnel automatically in the event of a change of IPv4 address Suggesting replacing text: Note that when customers use dynamic IPv4 addresses, manually configured tunneling techniques may be more difficult to deploy at the ISP's end, especially if a protocol including authentication (like PPP for IPv6) is not used. However, [TSP] does support automatic re-establishment of the tunnel when the IPv4 address change. 5.2 Access Control Requirements When a provider does not wish to give its IPv4 customers automatic access to IPv6 services, specific IPv6 access control must be performed in parallel with the IPv4 access control. This does not imply that different user authentication must be performed for IPv6, but merely that the authentication process may lead to different results for IPv4 and IPv6 access. to add: The [TSP] tunnel broker provides the AAA capabilities to manage this access control if desired. Note that when the customer connection network is shared between the users or the ISPs, and not just a point-to-point link, authenticating the configuration of the parameters (esp. prefix delegation) requires further study. TSP does it. to add: TSP tunnel broker does prefix delegation in this context This can be done, for example, by mapping a DHCP response to a physical connection and storing this in a database. It can also be done by assigning a static address or prefix to the customer. to add: TSP Tunnel broker provides this binding between user and address and prefix delegated. 8.1 Example 1 Customers (with some exceptions) are not connected using a tunnel broker, because offering native service faster is considered more important -- and then there will not be unnecessary parallel infrastructures to tear down later on. However, a 6to4 relay is provided in the meantime for optimized 6to4 connectivity. don't understand that argument. if "offering native service faster is considered more important, then why care about 6to4 at all? 6to4 relay should be considered similar to tunnel broker in terms of ways to provide ipv6 through the not-yet-upgraded-ipv4 network. [V6SEC] P. Savola, "IPv6 Transition/Co-existence Security Considerations" Work in progress adding tsp as reference [TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup Protocol(TSP)", work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00, feb 2004 ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Fri Feb 27 01:45:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02717 for ; Fri, 27 Feb 2004 01:45:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwbiC-000KFP-Ea for v6ops-data@psg.com; Fri, 27 Feb 2004 06:43:04 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwbTr-000IEQ-Gd for v6ops@ops.ietf.org; Fri, 27 Feb 2004 06:28:15 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1R6RpvI003680; Fri, 27 Feb 2004 01:27:54 -0500 (EST) Date: Fri, 27 Feb 2004 01:27:46 -0500 From: Marc Blanchet To: v6ops@ops.ietf.org cc: Pekka Savola , jonne.soininen@nokia.com, mikael.lind@teliasonera.com Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Message-ID: <9330000.1077863266@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit good document and work. quoted text provided with comments in and with suggested text when appropriate. Marc. ---------------------- It is also outside the scope of this document to describe different types of access or network technologies. to be more precise, suggesting: s/of access or network technologies/of layer1-2 access or network technologies/. ... 3.2.1 Stage 1 Scenarios: Launch ... The immediate first step consists of getting a prefix allocation (typically a /32) from the appropriate RIR according to allocation procedures. while clearly a good advice, not sure really useful to discuss here given the objective of the document. The selection of one candidate depends largely on the presence or absence of NATs between the two tunnel end-points and whether the user's IPv4 tunnel end-point address is static or dynamic. In most cases, 6to4 and ISATAP are incompatible with NATs, and UDP encapsulation for configured tunnels has not been specified. configured tunnels with tunnel brokers [TSP] is specified for NAT traversal. However, NAT traversal can be avoided if the NAT supports forwarding protocol-41 [PROTO41]. s/protocol-41/protocol-41 and configured to do so./ The connectivity mechanisms can be categorized as "managed" or "opportunistic." The former consist of native service or a configured tunnel (with or without a tunnel broker); the latter include 6to4 and, e.g., Teredo; they provide "short-cuts" between nodes using the same mechanisms and are available without contracts with the ISP. Teredo needs a Teredo server located outside of the NAT, which means in the architecture presented in section 2, as customer connection network. Most interesting are the managed services. When dual-stack is not an option, a form of tunneling must be used. When configured tunneling is not an option (e.g., due to dynamic IPv4 addressing), some form of automation has to be used. The options are basically either to deploy an L2TP architecture (whereby the customers would run L2TP clients and PPP over it to initiate IPv6 sessions) or to deploy a tunnel configuration service. The prime candidates for tunnel configuration are STEP [STEP] and TSP [TSP], which are not analyzed further in this document. would also add that these services are able to do NAT traversal. Suggesting: s/are STEP and TSP , providing tunnels with or without the presence of NAT./ Note that when customers use dynamic IPv4 addresses, the tunneling techniques may be more difficult to deploy at the ISP's end, especially if a protocol including authentication (like PPP for IPv6) is not used. This may need to be considered in more detail with tunneling mechanisms. disagree for TSP. TSP re-establish the tunnel automatically in the event of a change of IPv4 address Suggesting replacing text: Note that when customers use dynamic IPv4 addresses, manually configured tunneling techniques may be more difficult to deploy at the ISP's end, especially if a protocol including authentication (like PPP for IPv6) is not used. However, [TSP] does support automatic re-establishment of the tunnel when the IPv4 address change. 5.2 Access Control Requirements When a provider does not wish to give its IPv4 customers automatic access to IPv6 services, specific IPv6 access control must be performed in parallel with the IPv4 access control. This does not imply that different user authentication must be performed for IPv6, but merely that the authentication process may lead to different results for IPv4 and IPv6 access. to add: The [TSP] tunnel broker provides the AAA capabilities to manage this access control if desired. Note that when the customer connection network is shared between the users or the ISPs, and not just a point-to-point link, authenticating the configuration of the parameters (esp. prefix delegation) requires further study. TSP does it. to add: TSP tunnel broker does prefix delegation in this context This can be done, for example, by mapping a DHCP response to a physical connection and storing this in a database. It can also be done by assigning a static address or prefix to the customer. to add: TSP Tunnel broker provides this binding between user and address and prefix delegated. 8.1 Example 1 Customers (with some exceptions) are not connected using a tunnel broker, because offering native service faster is considered more important -- and then there will not be unnecessary parallel infrastructures to tear down later on. However, a 6to4 relay is provided in the meantime for optimized 6to4 connectivity. don't understand that argument. if "offering native service faster is considered more important, then why care about 6to4 at all? 6to4 relay should be considered similar to tunnel broker in terms of ways to provide ipv6 through the not-yet-upgraded-ipv4 network. [V6SEC] P. Savola, "IPv6 Transition/Co-existence Security Considerations" Work in progress adding tsp as reference [TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup Protocol(TSP)", work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00, feb 2004 From owner-v6ops@ops.ietf.org Fri Feb 27 02:38:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18693 for ; Fri, 27 Feb 2004 02:38:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwcXJ-0000sf-3a for v6ops-data@psg.com; Fri, 27 Feb 2004 07:35:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwcXE-0000s9-Sl for v6ops@ops.ietf.org; Fri, 27 Feb 2004 07:35:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1R7ZlN06060; Fri, 27 Feb 2004 09:35:47 +0200 Date: Fri, 27 Feb 2004 09:35:46 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling In-Reply-To: <4.3.2.7.2.20040226115859.03fddc88@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 26 Feb 2004, Bob Hinden wrote: > The vendor supplies the application requires (or benefits) from IPv6 that > the user wants to use. The vendor can supply it so it requires the user to > acquire IPv6 service, or it build into its product the ability to detect > existing IPv6 connectivity on the users system and if there isn't there, > initiate create it via one of the automatic tunneling mechanisms. (For clarification, in my mail I implied that both the app and the host OS is provided by the same vendor. They could be separate as well, of course. If they are separate, the process is clearly user-driven.) > Both scenarios are vendor and user. The only difference I can see is if > the vendor includes the capability to automatically create IPv6 > connectivity. Both are driven by the user (wanting to use an application) > and enabled by the vendor (including it in the product). The vendor can't > make the user do anything (or even buy it's products). I don't see the > distinction you are proposing as being useful. I think there is a distinction. There seems to be a lot of difference between: 1) the vendor pushing an updated (free) product to its customers, "forcing it down their throat for their own best", which requires IPv6 connectivity, and 2) the vendor supplying a new application, or an application developer supplying an application, which the user may (or may not) want to use, which would require or profit from IPv6 connectivity. (IMHO, this is comparable to Erik's RealPlayer point.) The former, I consider "host-vendor -driven". The latter, "user-driven". (Of course, the vendor will play some role here as well, but the role is entirely different from 1). The practical implication I see here is that for 1), automatic tunneling mechanisms are a strict requirement; tunnel-broker -like models are optional, but not adequate on their own. For 2), automatic tunneling mechanisms may be useful, but not a strict requirement. Tunnel-broker -like models are a a possible way to achieve the solution. > More importantly in the current world, a vendor who doesn't include the > capability to create IPv6 connectivity where it doesn't exist isn't going > to see very much IPv6 application usage. Agree. But remembering the distinction above, the tools which might be acceptable to create that connectivity vary depending on whether the user wants to use an application or not. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Feb 27 04:23:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21635 for ; Fri, 27 Feb 2004 04:23:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Awe9n-000Fbw-R5 for v6ops-data@psg.com; Fri, 27 Feb 2004 09:19:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Awe9k-000Fbi-Lq for v6ops@ops.ietf.org; Fri, 27 Feb 2004 09:19:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1R9Jci07593; Fri, 27 Feb 2004 11:19:38 +0200 Date: Fri, 27 Feb 2004 11:19:38 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com, Myung-Ki Shin Subject: WG Last Call: draft-ietf-v6ops-application-transition-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, This is a WG Last Call for comments on sending draft-ietf-v6ops-application-transition-01.txt, "Application Aspects of IPv6 Transition", to the IESG for consideration as Informational: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-01.txt Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. The last call will end in about 3 weeks (due to the IETF), on 20th March. Pekka & Jonne From owner-v6ops@ops.ietf.org Fri Feb 27 04:32:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22466 for ; Fri, 27 Feb 2004 04:32:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AweK1-000Grm-DI for v6ops-data@psg.com; Fri, 27 Feb 2004 09:30:17 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AweJy-000Gqa-Hw for v6ops@ops.ietf.org; Fri, 27 Feb 2004 09:30:14 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 29-md50000000136.tmp for ; Fri, 27 Feb 2004 10:34:51 +0100 Message-ID: <05c601c3fd14$f04fa2f0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt Date: Fri, 27 Feb 2004 10:34:44 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 27 Feb 2004 10:34:51 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, I sent 2 wording comments in the previous release, and have not been = addressed. I sent those again a few days ago. I never got a reply to any of my emails. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: Cc: ; "Myung-Ki Shin" Sent: Friday, February 27, 2004 10:19 AM Subject: WG Last Call: draft-ietf-v6ops-application-transition-01.txt > Hi all, >=20 > This is a WG Last Call for comments on sending > draft-ietf-v6ops-application-transition-01.txt, "Application Aspects > of IPv6 Transition", to the IESG for consideration as Informational: >=20 > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transiti= on-01.txt >=20 > Please review the document carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this = document > is ready to go to the IESG. >=20 > The last call will end in about 3 weeks (due to the IETF), on 20th=20 > March. >=20 > Pekka & Jonne > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Feb 27 06:44:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26604 for ; Fri, 27 Feb 2004 06:44:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwgLP-0009Ct-1b for v6ops-data@psg.com; Fri, 27 Feb 2004 11:39:51 +0000 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwgLN-0009Ca-0P for v6ops@ops.ietf.org; Fri, 27 Feb 2004 11:39:49 +0000 Received: from pec.etri.re.kr (mkshin.etri.re.kr [129.254.112.163]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id i1RBuBfM001330; Fri, 27 Feb 2004 20:56:11 +0900 (KST) Message-ID: <403F2C87.2AAE013D@pec.etri.re.kr> Date: Fri, 27 Feb 2004 20:39:51 +0900 From: Myung-Ki Shin Organization: ETRI X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt References: <05c601c3fd14$f04fa2f0$8700000a@consulintel.es> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Jordi, I think your previous comments were some editorial things. I will keep all of these comments. Thanks, Myung-Ki. JORDI PALET MARTINEZ wrote: > Hi Pekka, > > I sent 2 wording comments in the previous release, and have not been addressed. I sent those again a few days ago. > > I never got a reply to any of my emails. > > Regards, > Jordi > > ----- Original Message ----- > From: "Pekka Savola" > To: > Cc: ; "Myung-Ki Shin" > Sent: Friday, February 27, 2004 10:19 AM > Subject: WG Last Call: draft-ietf-v6ops-application-transition-01.txt > > > Hi all, > > > > This is a WG Last Call for comments on sending > > draft-ietf-v6ops-application-transition-01.txt, "Application Aspects > > of IPv6 Transition", to the IESG for consideration as Informational: > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-01.txt > > > > Please review the document carefully, and send your feedback to the > > list. Please also indicate whether or not you believe that this document > > is ready to go to the IESG. > > > > The last call will end in about 3 weeks (due to the IETF), on 20th > > March. > > > > Pekka & Jonne From owner-v6ops@ops.ietf.org Fri Feb 27 09:26:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03702 for ; Fri, 27 Feb 2004 09:26:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwisT-0005XO-Tm for v6ops-data@psg.com; Fri, 27 Feb 2004 14:22:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwisR-0005X2-UW for v6ops@ops.ietf.org; Fri, 27 Feb 2004 14:22:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1RELsm11799; Fri, 27 Feb 2004 16:21:54 +0200 Date: Fri, 27 Feb 2004 16:21:54 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt In-Reply-To: <05c601c3fd14$f04fa2f0$8700000a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Feb 2004, JORDI PALET MARTINEZ wrote: > I sent 2 wording comments in the previous release, and have not been > addressed. I sent those again a few days ago. > > I never got a reply to any of my emails. Thanks for persisting :) The second comment has been addressed already, and the first one was: 1. various kinds of transition mechanisms have been developed to migrate to IPv6 network replace with "various kinds of transition mechanisms have been developed to do the transition to IPv6 networks" or "various kinds of transition mechanisms have been developed for the transition to IPv6 networks" (other combinations possible, key point is avoid using "migration/migrate", and probably use networks instead of network) I agree that we should replace: In addition, various kinds of transition mechanisms have been developed to migrate to IPv6 network. with e.g.: In addition, various kinds of transition mechanisms have been developed for the transition to an IPv6 network. > ----- Original Message ----- > From: "Pekka Savola" > To: > Cc: ; "Myung-Ki Shin" > Sent: Friday, February 27, 2004 10:19 AM > Subject: WG Last Call: draft-ietf-v6ops-application-transition-01.txt > > > > Hi all, > > > > This is a WG Last Call for comments on sending > > draft-ietf-v6ops-application-transition-01.txt, "Application Aspects > > of IPv6 Transition", to the IESG for consideration as Informational: > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-01.txt > > > > Please review the document carefully, and send your feedback to the > > list. Please also indicate whether or not you believe that this document > > is ready to go to the IESG. > > > > The last call will end in about 3 weeks (due to the IETF), on 20th > > March. > > > > Pekka & Jonne > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Feb 27 12:40:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15434 for ; Fri, 27 Feb 2004 12:40:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwluE-0007dS-NE for v6ops-data@psg.com; Fri, 27 Feb 2004 17:36:10 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwluD-0007dD-Pn for v6ops@ops.ietf.org; Fri, 27 Feb 2004 17:36:09 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1RHZu0J019277; Fri, 27 Feb 2004 09:35:57 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1RHZrQ17351; Fri, 27 Feb 2004 18:35:53 +0100 (MET) Date: Fri, 27 Feb 2004 09:35:56 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Opportunistic Tunneling To: Bob Hinden Cc: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20040226115859.03fddc88@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Actually, it doesn't. I think they are the same. > > The vendor supplies the application requires (or benefits) from IPv6 that > the user wants to use. The vendor can supply it so it requires the user to > acquire IPv6 service, or it build into its product the ability to detect > existing IPv6 connectivity on the users system and if there isn't there, > initiate create it via one of the automatic tunneling mechanisms. > > Both scenarios are vendor and user. The only difference I can see is if > the vendor includes the capability to automatically create IPv6 > connectivity. Both are driven by the user (wanting to use an application) > and enabled by the vendor (including it in the product). The vendor can't > make the user do anything (or even buy it's products). I don't see the > distinction you are proposing as being useful. Agree on all points. I think vendors can provide the infrastructure in their software that Bob talks about (detecting existing IPv6 connectivity and prompting the user with "cool application X needs IPv6 connectivity - should I set up such connectivity?"). Having vendors provide a common framework for this would make their platform attractive to 3rd party application developpers which want to take advantage the p2p possibilities with IPv6. Erik From owner-v6ops@ops.ietf.org Fri Feb 27 12:42:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15622 for ; Fri, 27 Feb 2004 12:42:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwlyY-0008Dp-8n for v6ops-data@psg.com; Fri, 27 Feb 2004 17:40:38 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwlyW-0008DN-L1 for v6ops@ops.ietf.org; Fri, 27 Feb 2004 17:40:36 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1RHePdO015123; Fri, 27 Feb 2004 09:40:25 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1RHeNQ17641; Fri, 27 Feb 2004 18:40:23 +0100 (MET) Date: Fri, 27 Feb 2004 09:40:27 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Opportunistic Tunneling To: Pekka Savola Cc: Bob Hinden , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I think there is a distinction. There seems to be a lot of difference > between: > > 1) the vendor pushing an updated (free) product to its customers, > "forcing it down their throat for their own best", which requires IPv6 > connectivity, and Do you have an example where enabling this would be a desirable thing? The examples I can come up with have big brother connotations hence I don't see why we need to solve this problem. Applications and services can drive IPv6 deployment but it requires that the applications/services are interesting to the users. If they are not, why should we piggyback "forcing IPv6 down the user's throat" on somebody elses desire to "force XYZ down the user's throat"? That doesn't seem to be in the benefit of the users that IPv6 is intended to serve. Erik From owner-v6ops@ops.ietf.org Sun Feb 29 00:48:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23767 for ; Sun, 29 Feb 2004 00:48:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxJk1-000FZ6-DN for v6ops-data@psg.com; Sun, 29 Feb 2004 05:43:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxJjw-000FTj-CB for v6ops@ops.ietf.org; Sun, 29 Feb 2004 05:43:48 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T5hdp13362; Sun, 29 Feb 2004 07:43:39 +0200 Date: Sun, 29 Feb 2004 07:43:39 +0200 (EET) From: Pekka Savola To: ftemplin@iprg.nokia.com cc: v6ops@ops.ietf.org Subject: isatap-20 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [as the applicability of different solutions is being evaluated, it's probably OK to use the WG list for discussions as long as they don't too out of hand.. :)] Some comments on the latest ISATAP spec. substantial ----------- 1) there seems to be a lot of stuff, which doesn't appear to be fundamental to ISATAP itself, like: - "Considerations for anycast", - "must implement basic and advanced API" - ICMP code handling in section 8.6, point 5. - that pref lifetime mustn't be greater than valid lifetime (sect 9.2.1) - the ICMP code updates are duplicated from the ICMP spec revision (sect 11, appendix D) - IPv6 minimum MTU is kind of obvious, in appendix B (but it's in appendix so it's not as big an issue) maybe these should be removed if their relevance to ISATAP in particular is not made clearer. 2) the specification (sect 7.4) appears to default to forward between interfaces -- was this intentional ?? 3) the specification appears to incorporate a lot separate ideas about topics which really seem to have very little to do with ISATAP, such as: - new IPv4 packet reassembly algorithms (section 8.2, first point) - advanced MTU handling mechanisms - some address rewriting stuff (sect 8.6, point 4, 2nd paragraph) - how advertised MTU doesn't affect link MTU (9.2.2.3), but is used between hosts - (some MANET derivative work?) These should probably be out of scope for the base spec, and pursued separately. Beware of the feature creep.... 4) you mention authenticated RA, but don't specify how: 6. If the packet is "INCOMPLETE" (see section 8.2) prepare an authenticated, unsolicited Router Advertisement message [...] 5) as mentioned before, security considerations should list implications of administrators not properly maintaining the PRL lists, and what actions they must take, precisely, to prevent anything bad from happening. Also, now that the mechanism includes NAT traversal to cross site boundaries (well, the boundaries can be crossed otherwise as well, but you stated this in the draft), such considerations should be called out in the security considerations. 6) Very important pieces of the spec appear to be more or less "obfuscated" under the management/configuration requirements section, section 7 -- while almost none of the issues there are really such requirements. (I'd also specify the MIB objects etc. in another document, as appears to be the custom.) 7) As the ISATAP model has changed quite a bit during the drafts, I think section 4 or the like should probably include a bit more verbose "overview of the protocol operation" in the most common cases. semi-editorial -------------- The following example diagram depicts the ISATAP conceptual model: ==> well, at least I had trouble figuring out what the figure wanted to represent... +-------+-------+-------+-------+-------+-------+-------+--------+ | Type |Length | 0 | 0 | IPv4 Address | +-------+-------+-------+-------+-------+-------+-------+--------+ ==> might make sense to represent similarly as SLLA/TLLA options in ND spec, or at least add "0", "31" and "63" bits at appropriate places.. Native IPv6 and/or ip-protocol-41 encapsulation provides sufficient functionality to support communications between peers that reside within the same site (i.e., the same enterprise network). When the remote peer is in a different site, NAT traversal via UDP/IPv4 encapsulation MAY be necessary. ==> unless you're excluding to enterprise network (no objections from me :-), "i.e." should be "e.g.". ==> s/MAY/may/ ? 8.1.2 Multicast ISATAP interfaces encapsulate packets with IPv6 multicast destination addresses using a mapped Organization-Local Scope IPv4 multicast address ([RFC2529], section 6) as the destination address in the encapsulating IPv4 header. ==> might not hurt to spell this assumption about v4 multicast better. For packets received on an ISATAP interface, the IPv4 source address is correct if: [...] - the IPv6 source address is the address of an IPv6 neighbor on an ISATAP interface associated with the locator that matched the packet (see: section 7.2.3), or: ==> I didn't understand what this implied, precisely. Section 7.2 was difficult to understand anyway. 4. Perform IPv4 ingress filtering (optional; disabled by default) ==> it might not hurt to specify what exactly you mean with ingress filtering.. it's used in many different ways, so folks may have different assumptions about what it entails.. 6. If the packet is "INCOMPLETE" (see section 8.2) prepare an authenticated, unsolicited Router Advertisement message ([RFC2461], section 6.2.4) with an MTU option that encodes the maximum of "ACTUAL_BYTES" and (68 bytes minus the size of encapsulating headers.) ==> IPv6 MTUs lower than 1280 are ignored so 68 bytes minus anything is a no-op. This might fail otherwise as well. FQDNs are established via manual configuration or an unspecified alternate method. ==> might be pretty important for interop purposes. Normative References ==> there is a very high number of references, even rather obvious ones (like "UDP" or "IP"). I'm not sure if this is a big issue, but IMHO at least the normative references section could be a bit shorter. Maybe some of these could be removed, or moved to informational references. editorial --------- (very good editorial quality -- thanks!) an IPv4 address-to-interface mapping, i.e., a node's IPv4 address and the index for it's associated interface. ==> s/it's/its/ See: Appendix C for additional non-normative details. ==> s/See:/See/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Feb 29 01:00:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24105 for ; Sun, 29 Feb 2004 01:00:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxJy1-000HfV-IQ for v6ops-data@psg.com; Sun, 29 Feb 2004 05:58:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxJxt-000Hes-GV for v6ops@ops.ietf.org; Sun, 29 Feb 2004 05:58:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T5vrP13616; Sun, 29 Feb 2004 07:57:54 +0200 Date: Sun, 29 Feb 2004 07:57:53 +0200 (EET) From: Pekka Savola To: Marc.Blanchet@hexago.com cc: v6ops@ops.ietf.org Subject: TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for updating the spec -- it has been a long time :). A few comments below. I'm commenting on the spec itself only, not the deployment model (at this point). very substantial ---------------- 1) The specification is rather intuitive and easy to read and get a grasp on, but as it is, I don't think it is has enough details to build an interoperable implementation. For example: - the heartbeat mechanism which is mentioned, appears to be non-specified - a lot of error codes are listed in the end, but there is no specification except about the first couple of them when they are to be returned, etc. -- I think you're able to guess that, though. - there are some references to UDP as a control plane mechanism, but no real specification. There was also a mention of "UDP-reliable", which was not elaborated further.. 2) There seems to be something fishy about mobility. The user is expected to give an IP address, which (supposedly) is used to identify the user. But if the IP address of the user changes, how can such identification be done? All in all, it seems like the mobility was not really described at length either... 3) TSP specifies a lot of custom ways of signalling. Maybe this is more of a philosophical argument of building from pieces vs. designing the whole system, but I think some might have preferred using existing heartbeat (ND), prefix delegation, DNS resolving and delegation etc. mechanisms. And if those are not sufficient (e.g., prefix delegation is too complex), shouldn't we specify a simpler version? While I don't have a really strong opinion here, some consideration wrt. "reuse" vs "redesign to fit" will undoubtedly come up. 4) SASL doesn't work with UDP, so my guess is that the whole UDP signalling must have been some kind of glitch in the spec. semi-substantial/semi-editorial ------------------------------- Abstract ==> it is maybe a bit too long; fitting on the "cover page" would be very preferable. ==> no references in the abstract. to have up to 4 parties involved: 1- the tsp client, 2- controlling the requesting tunnel end-point, 3- the tsp server, 4- controlling the receiving tunnel end-point. 1,3 and 4 is the Tunnel Broker model. 1 and 2 can be on the same node, as well as 3 and 4 can be on the same node. ==> s/tsp/TSP/ ==> I think you should reword this to make clearer what 2) and 4) meant. I only (think I) understood this after reading the whole spec. 3. Advantages of TSP o A signaling protocol to establish the tunnel: no need to change kernels, routing... ==> I do not understand what you mean by this advantage. Perhaps you should elaborate or reword. o routing negociation ==> again, it is not clear what you mean by this; perhaps needs to be expanded. o two to four tier tunnel broker model ==> is this an advantage? I'd maybe count this as a drawback :-) C: Content-length: 234 CR LF
1.1.1.1
2.3.4.5
2.3.4.6
3ffe:0c00::1
 ==> umm.. why is the client requesting DNS server addresses like this -- doesn't seem to make sense! 3ffe:0b00:c18:1234:: ==> the prefix length is 48, but the prefix is 64 -- glitch or intentional?
fe80:0000:0000:0000:0000:0000:0000:0001
==> why advertise its own link-local address? C:Content-length: ... CR LF ==> it appears that the other examples wouldn't have worked through NAT. Automation of the prefix assignment and DNS delegation, done by TSP, is a very important feature for a provider in order to substantially decrease support costs. The provider can use the same authentication database that is used to authenticate the IPv4 users. ==> there is not even a hint how TSP could use the same databases as with v4 authentication :-) 5.5 Applicability of TSP in Unmanaged networks ==> many of these are actually the same scenarios as identifier earlier, this one is pretty close to 5.2. There's some other overlap as well -- might be worth compressing these a bit... Static tunnels are created when the TSP negociation is terminated. Static tunnels are not open gateways and exhibit less security issues than automated tunnels. Static IPv6 in IPv4 tunnels security considerations are described in [RFC2893]. ==> there's some very important stuff in the mech-v2 document as well. References ==> split the references to Normative and Informative [5] Hagino, J., "Possible abuse against IPv6 transition technologies", July 2000. ==> this wasn't refererred to in the draft, so remove? ==> is that "1440" here intentional ??? ==> I don't think there's need for "as", nor is it mentioned elsewhere in the document. Full Copyright Statement ==> please add IPR section prior to this section editorial --------- A tunnel broker with the Tunnel Setup Protocol(TSP) enables the ==> s/(TSP)/ (TSP)/ (multiple times) used by the tunnel client to negociate the tunnel with the broker. ==> s/negociate/negotiate/ (also a lot of times) networks whether he is on IPv4, IPv4 behind a NAT or on IPv6. A ==> s/he/it/ This document first describes the TSP framework as well as the different profiles used. It then describes the applicability of TSP in different environments, some were described in the v6ops scenario documents. ==> s/some/some of which/ ? o IP address allocation for the tunnel endpoints ==> s/allocation/assignment/ o IPv6 prefix assignment when the client is a router and has a network behind ==> s/behind/behind itself/ The TSP connexion can be established between two nodes, where each ==> s/connexion/connection/ (multiple times AFAIR?) established. On the IPv6 layer, there are no mobility seen. ==> s/there are no mobility seen/no mobility is needed/ ? When a tunnel endpoint changes its underlying IP address (i.e. change of its IPv4 address when doing IPv6 in IPv4 encapsulation), the keepalive mechanism fail and the TSP client reconnects to the ==> s/fail/fails/ (there were a LOT of stuff like this..) 4.1 Terminology Tunnel Broker (TB) In a Tunnel Broker model, the broker is taking ==> s/TB)/TB):/ (similar later) Clients (TC). Tunnel clients query brokers for a tunnel and the broker find a suitable tunnel server, ask the Tunnel server to setup the tunnel and send the tunnel information to the Tunnel Client. ==> s/find/finds/, s/ask/asks/ service to a Tunnel Client. It can reveive the tunnel request ==> s/reveive/receive/ Authentication phase: The Authentication phase is when the Tunnel Brokers/Servers advertises their capability to Tunnel Clients and when Tunnel clients authenticate to the server. ==> s/advertises/advertise/ ==> s|server|server/broker| (based on the picture at least...) Response phase: The response phase is where the respond to the client ==> something missing between "the respond" ? For each command sent by a Tunnel Client their is an expected response by the server. ==> s/their/there/ When a TCP (or UDP-reliable) session is established to a Tunnel ==> uh-oh, the infamous UDP-reliable.. :) adevertised mechanism. If the authentication fails the server sends ==> s/ade/ad/ If the authentication succeed, the server sends a success return code and the protocol enter the Command phase. [...] Upon successful authentication the protocol enters the command phase as described in the next section. ==> one of these is probably redundant ==> s/succeed/succeeds/, s/enter/enters/ 4.6.4 broker element ==> s/broker element/Broker Element/ (similar elsewhere) The 'broker' element will contain a series of 'address' element. ==> s/element/element(s)/ ? In a provider network where IPv4 is dominant, a tunnelled infrastructure can be used to provider IPv6 services to the ==> s/provider/provide/ TSP server can be put in the core, in the aggregation points or in the pops to offer the service to the customers. IPv6 over IPv4 ==> s/pop/PoP/ mobile hosts to have IPv6 connectivity wherever they are, by having the TSP client sends updated information of the new environment to the TSP server, when a change occur. Together with NAT discovery, ==> s/sends/send/, s/occur/occurs/ tonegociate tunnel parameters, as well as prefix assignment, dns ==> s/tonegociate/to negotiate/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Feb 29 01:37:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25081 for ; Sun, 29 Feb 2004 01:37:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxKXg-000MI6-U6 for v6ops-data@psg.com; Sun, 29 Feb 2004 06:35:12 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxKXe-000MHu-V9 for v6ops@ops.ietf.org; Sun, 29 Feb 2004 06:35:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T6Z9U14017 for ; Sun, 29 Feb 2004 08:35:09 +0200 Date: Sun, 29 Feb 2004 08:35:09 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: [dnsop] comments about draft-huston-6to4-reverse-dns (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI -- it's a nice to see a realistic, deployable proposal out which would provide 6to4 reverse DNS. My gut feeling is that the right place for this is the DNSOP WG, but this might be interesting to those not subscribed to dnsop as well. ---------- Forwarded message ---------- Date: Sun, 29 Feb 2004 07:34:28 +0200 (EET) From: Pekka Savola To: gih@telstra.com Cc: dnsop@lists.uoregon.edu Subject: [dnsop] comments about draft-huston-6to4-reverse-dns Thanks for this document. I think this should be implemented ASAP. What should be the forum for advancement of this specification? DNSOP? I don't recall it being on agenda, at least. Maybe it could still be introduced there (5+ mins) if that's the right venue? If not, a presentation at v6ops session is also fine by me. substantial comments -------------------- 1) The memo has some language which seems to indicate that the author believes 6to4 using DHCP-learned IPv4 addresses may be inappropriate. I completely disagree with this, and I think more justification is needed, or this text should be removed. In: o IPv4 DHCP-based 6to4 sites could inherit nonsense reverse entries. It is not clear that using 6to4 services in such environments is entirely appropriate. In any case the client site could request delegation of the reverse zone as required. and: It is envisaged that scenarios that would motive this concern would include when the IPv4 provider is also offering an IPv6 service, and native IPv6 should be deployed instead of 6to4, or when the service provider has dynamically allocated (via DHCP) IPv4 and wishes to block customers' ability to use this scheme on those addresses. 2) The memo states that the service should only be available over IPv6 (except for the instructions), from the 6to4 addresses which associate to the the prefix. However, I see no technical reason for this restriction. For security purposes, it is sufficient that the user is presented with the 6to4 reverse delegation set-up screen which corresponds to the IPv4 address used. However, if the 6to4 address usage is desirable for other purposes (for example, not allowing the editing for those which haven't even activated 6to4), this should be stated explicitly as a goal ("make your 6to4 active first, and get an IPv6 enabled web browser before coming here.."). 3) Similarly, the memo states that the management service should have local access to a 6to4 relay. Actually, it would be best if the service was available at: 1) an IPv4 address, 2) a native IPv6 address, and 3) a 6to4 address. By adding 3), the 6to4 users wouldn't have to use the service through the relay, and the traffic would be optimized. This would seem to be desirable to me. 4) The memo allows (or doesn't specify it as a matter of fact), when editing the authoritative DNS server information, to insert any IP address as the DNS server. This would seem to assume that the threat related to users putting bogus information there, i.e., making the management DNS servers send DNS queries to any address they want, is not a significant risk. Except for something like multicast addresses, I probably agree with this -- but this issue should probably be called out explicitly, here and in security considerations. In: When accessed by a 6to4 source address, the interface presented by the delegation server is a standard DNS delegation interface, allowing the client to enter the details of a number of DNS servers for the corresponding reverse domain. The servers are checked by the delegation manager to ensure that they are responding, [...]. 5) The memo does not specify or discuss at all how the TTL information of the DNS records should be added. Obviously, this should not be too long.. 6) The memo does not discuss how old information is scrubbed out of the database. That is, the user enters information -- and when his IP address for whatever reason changes, we can't any longer remove it, exploding the database after some time! :-) I have a proposal for this: the management system must check periodically (e.g., 1/day or 1/week, depending on how long stale information is acceptable to hang around) from the configured DNS servers that they still remain authoritative for the zone. If they fail, the delegation is automatically removed, and the servers are no longer tried. A warning message can also be sent if this is deemed necessary (to the SOA email address). This keeps the reverses moderately "clean" and removes dangling reverse pointers associated with e.g. DHCP IPv4 addresses. This method does not address the case where the administrator of the DNS server is willfully trying to spoof the reverses it no longer should own. That is, consider a dynamically changing IP address which is delegated to a server. When the IP address changes, the DNS server admin changes the zone information as well, removing the old, unnecessary one. The DNS administrator gets no joy of polluting his own DNS server by keeping old zones hanging around :-). One additional consideration are the wildcard records. Should the DNS consistency check try to figure out whether the pesky administrator would have configured itself autorative for all of 2.0.0.2.ip6.arpa (or a subset of it). For example, if a user uses DHCP from a block 1.1.0.0/16, configure all of the reverses there to point to his personal reverses -- to avoid ever having to rig the zone files, just update the pointer to the authorative DNS servers in the management tool? 7) I believe IANA considerations was already done by an already-published BCP document by Randy -- or were I misremembering something? IANA is instructed to delegate the zone 2.0.0.2.ipv6.arpa to the Number Resource Organization, the cooperative operational entity that the Regional Internet Registries use for coordinated common activities. editorial comments: ------------------- 6to4 Reverse DNS ==> a slightly more descriptive title might be preferable :) the 6 to4 reverse zone file. The proposed mechanism is a conventional ==> s/6 to4/6to4/ Some assumptions have been concerning the nature of deployment of 6to4 gateways and comment relating to the validity of these ==> something missing after "have been concerning" ? Internet-Draft 6to4rev January 2004 ==> now this is the place where something terse as "6to4 Reverse DNS" might fit in... :-) There are a number of approaches to this problem, ranging from a conventional explicit delegation structure through to various forms of modified server behaviours that attempt to guess the location of ==> isn't "through" there redundant? IPv6 space the upstream is not using Ipv6 and therefore would not be ==> s/Ipv6/IPv6/ A 6to4 client network is an isolated V6 network composed as a set of V6 hosts and a dual stack (V4 and V6) local gateway connected to the local V6 network and the external V4 network. ==> s/V4/IPv4/, s/V6/IPv6/ (everywhere :-) +-------------+ 6over4 packets (A)| | v6 packets -------------------| 6to4gateway |-------------------------- | | | | | | | +-------------+ local V6 clients ==> you should use something like "v6-over-v4" or "IPv6-in-IPv4" instead of "6over4" because that's another transition mechanism altogether :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-v6ops@ops.ietf.org Sun Feb 29 08:32:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21370 for ; Sun, 29 Feb 2004 08:32:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxQzE-000HR1-Bw for v6ops-data@psg.com; Sun, 29 Feb 2004 13:28:04 +0000 Received: from [81.228.10.111] (helo=av5-2-sn4.m-sp.skanova.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxQzA-000HQe-W8 for v6ops@ops.ietf.org; Sun, 29 Feb 2004 13:28:01 +0000 Received: by av5-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 1D09637EAC; Sun, 29 Feb 2004 14:28:00 +0100 (CET) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av5-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 0DA4D37E4C for ; Sun, 29 Feb 2004 14:28:00 +0100 (CET) Received: from lord.fakat.com (h80n1fls302o1033.telia.com [81.226.50.80]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 8253237E47 for ; Sun, 29 Feb 2004 14:27:59 +0100 (CET) Received: from lord.fakat.com (lord.fakat.com [81.226.50.80]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id i1TDRkw5071699 for ; Sun, 29 Feb 2004 14:27:46 +0100 (CET) (envelope-from jasko@fakat.com) Date: Sun, 29 Feb 2004 14:27:46 +0100 (CET) From: Jasminko Mulahusic To: v6ops@ops.ietf.org Subject: Re: Opportunistic Tunneling In-Reply-To: Message-ID: <20040229134756.N69205@lord.fakat.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I think vendors can provide the infrastructure in their software that Bob talks > about (detecting existing IPv6 connectivity and prompting the user with "cool > application X needs IPv6 connectivity - should I set up such connectivity?"). would such a framework be a superset of the existing tranisition mechanisms, where the mechanism to be used would be selected based upon .... ? or would this actually be a new mechanism? isn't there one software vendor that is already doing something similar when the user chooses to activate ipv6? is it something that needs to be standardized in the ietf? jasminko From owner-v6ops@ops.ietf.org Sun Feb 29 16:35:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11090 for ; Sun, 29 Feb 2004 16:35:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxYWe-000Mzq-OV for v6ops-data@psg.com; Sun, 29 Feb 2004 21:31:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxYWc-000MzE-9r for v6ops@ops.ietf.org; Sun, 29 Feb 2004 21:31:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1TLUww22323; Sun, 29 Feb 2004 23:30:58 +0200 Date: Sun, 29 Feb 2004 23:30:58 +0200 (EET) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org, , Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt In-Reply-To: <9330000.1077863266@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for your feedback! A few comments on your comments below. Jordi, there is one comment on proto-41 forwardaring below which is not IMHO clear -- could you check ? On Fri, 27 Feb 2004, Marc Blanchet wrote: > 3.2.1 Stage 1 Scenarios: Launch > ... > > The immediate first step consists of getting a prefix allocation > (typically a /32) from the appropriate RIR according to allocation > procedures. > > while clearly a good advice, not sure really useful to discuss here > given the objective of the document. There have been a couple of comments to even expand this, so I think this is probably a good pointer to start with.. not something that can or should be fully discussed, through. > The selection of one candidate depends largely on the presence or > absence of NATs between the two tunnel end-points and whether the > user's IPv4 tunnel end-point address is static or dynamic. In most > cases, 6to4 and ISATAP are incompatible with NATs, and UDP > encapsulation for configured tunnels has not been specified. > > configured tunnels with tunnel brokers [TSP] is specified for > NAT traversal. > True, but the issue remains: [MECH] or MECH-v2 doesn't do UDP. > However, NAT traversal can be avoided if the NAT supports > forwarding protocol-41 [PROTO41]. > > s/protocol-41/protocol-41 and configured to do so./ This is a point which I've tried to raise is that I think most protocol-41 forwarding implementations do automatically forward protocol-41 without any configuration -- just as they forward ICMP. If setting up proto-41 forwarding requires manual set-up (as discussed in a few places in the proto-41 forwarding draft), then it certainly would not be an option. Perhaps Jordi can clarify (and post an updated draft! :-) > The connectivity mechanisms can be categorized as "managed" or > "opportunistic." The former consist of native service or a > configured tunnel (with or without a tunnel broker); the latter > include 6to4 and, e.g., Teredo; they provide "short-cuts" between > nodes using the same mechanisms and are available without contracts > with the ISP. > > Teredo needs a Teredo server located outside of the NAT, which means > in the architecture presented in section 2, as customer connection network. > Teredo server doesn't have to be near the customer, it can be anywhere at all -- I wouldn't expect any ISPs to deploy it, in the short term at least. Suggested text? > Most interesting are the managed services. When dual-stack is not an > option, a form of tunneling must be used. When configured tunneling > is not an option (e.g., due to dynamic IPv4 addressing), some form of > automation has to be used. The options are basically either to deploy > an L2TP architecture (whereby the customers would run L2TP clients > and PPP over it to initiate IPv6 sessions) or to deploy a tunnel > configuration service. The prime candidates for tunnel configuration > are STEP [STEP] and TSP [TSP], which are not analyzed further in this > document. > > would also add that these services are able to do NAT traversal. > Suggesting: > s/are STEP and TSP , providing tunnels with or without the presence of NAT./ > Seems to make sense to say that explicitly. > Note that when customers use dynamic IPv4 addresses, the > tunneling techniques may be more difficult to deploy at the ISP's > end, especially if a protocol including authentication (like PPP for > IPv6) is not used. This may need to be considered in more detail > with tunneling mechanisms. > > disagree for TSP. TSP re-establish the tunnel automatically in the > event of a change of IPv4 address > Suggesting replacing text: > > Note that when customers use dynamic IPv4 addresses, manually configured > tunneling techniques may be more difficult to deploy at the ISP's > end, especially if a protocol including authentication (like PPP for > IPv6) is not used. However, [TSP] does support automatic re-establishment > of the tunnel when the IPv4 address change. > I have to disagree with this -- STEP or TSP are not analyzed further in the document, at this point. Of course, they might be in the future, and if so, the feature(s) of TSP would certainly be mentioned. > 5.2 Access Control Requirements > > > When a provider does not wish to give its IPv4 customers > automatic access to IPv6 services, specific IPv6 access control must > be performed in parallel with the IPv4 access control. This does not > imply that different user authentication must be performed for IPv6, > but merely that the authentication process may lead to different > results for IPv4 and IPv6 access. > > to add: > The [TSP] tunnel broker provides the AAA capabilities to manage this > access control if desired. > Similarly, at the moment, I think TSP/STEP/ISATAP/etc. -specific issues are out of scope. This might change, based on this IETF though.. > Note that when the customer connection network is shared between the > users or the ISPs, and not just a point-to-point link, authenticating > the configuration of the parameters (esp. prefix delegation) requires > further study. > TSP does it. to add: > TSP tunnel broker does prefix delegation in this context > Same as above. > This can be done, for example, by mapping a DHCP response to a > physical connection and storing this in a database. It can also be > done by assigning a static address or prefix to the customer. > > to add: TSP Tunnel broker provides this binding between user and > address and prefix delegated. Likewise. > 8.1 Example 1 > > Customers (with some exceptions) are not connected using a tunnel > broker, because offering native service faster is considered more > important -- and then there will not be unnecessary parallel > infrastructures to tear down later on. However, a 6to4 relay is > provided in the meantime for optimized 6to4 connectivity. > > don't understand that argument. if "offering native service faster > is considered more important, then why care about 6to4 at all? > 6to4 relay should be considered similar to tunnel broker in terms > of ways to provide ipv6 through the not-yet-upgraded-ipv4 network. > This has come through from a couple of operators. They don't want to build tunnels etc. architecture because the difficult part about IPv6 is considered to be the process/administrative issues, and it takes time to move from "hacks" to "real solutions" when the time comes -- so they're going to "real solutions" as the first step. Of course, this could also be just an excuse :-). 6to4 relay can be used for two purposes: 1) to optimize the return routing between the native IPv6 users in your network and 6to4 users [this example], and 2) to optimize the use of 6to4 when your customers support it (this requires no support from the ISP, but offers the users better IPv6). This was not the main intent of the statement above, but comes in as a bonus. Suggestions for clarification? > adding tsp as reference > > [TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup > Protocol(TSP)", > work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00, feb 2004 > Right .. apparently these weren't added even though there is a reference in the text. Add STEP as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Feb 29 17:17:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12607 for ; Sun, 29 Feb 2004 17:17:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxZDY-00040G-9W for v6ops-data@psg.com; Sun, 29 Feb 2004 22:15:24 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxZDV-0003zo-Uk for v6ops@ops.ietf.org; Sun, 29 Feb 2004 22:15:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1TMFHs22978; Mon, 1 Mar 2004 00:15:17 +0200 Date: Mon, 1 Mar 2004 00:15:17 +0200 (EET) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: <76170000.1077859963@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for your feedback. I'm responding on some non-trivial issues inline .. some of this will no doubt be discussed at the IETF as well.. In short, I think I agree to some degree in most places where you raise issues -- that some text changes are needed -- but don't often agree on your specific proposals as being too solution-centric.. :-) On Fri, 27 Feb 2004, Marc Blanchet wrote: > A) a gateway which does not provide IPv6 at all; > B) a dual-stack gateway connected to a dual-stack ISP; > C) a dual-stack gateway connected to an IPv4-only ISP; and > D) a gateway connected to an IPv6-only ISP. > > in both the scenario and the eval, the term "dual-stack" ISP > is used. just wondering if an ISP network can really be named > "dual-stack". Would "dual protocol network" be more appropriate name? Dual-stack is a well-established term already (IMHO), so using that is probably preferable. > 2.1 Comparing automatic and configured solutions > > > It is possible to broadly classify tunneling solutions as either > "automatic" or "configured". > > "configured' is used in other ietf documents to denote manually > configured static tunnels. However, in this document, configured > usually means the tunnel broker configured tunnels, either with > the web or the TSP model; since > the manually configured static tunnels is obviously not an unmanaged > solution. However, sometimes the comments on configured tunnels are related > to the manually configured static tunnels. > To avoid confusion, it was > suggested during a presentation in Vienna, the word > "negociated tunnels" to denote the kind of configured tunnels set by > tunnel brokers and the like. Would suggest "negociated tunnels" to be > used in the document, so the reader will understand the difference with > the manually configured static tunnels. > > Suggesting to s/configured tunnels/negociated tunnels/g throughout the text > "negotiated" is misleading, as it's possible that the tunnel requires no negotiation all (see STEP). I haven't been able to find a good term either -- as a working term, I've used "(zero-)configured tunnels" a few times, implying that setting up something like that doesn't *have* to require any configuration. It would be nice if someone could come up with a good term here.. > In an automatic solution, a host or a > router builds an IPv6 address or an IPv6 prefix by combining a pre- > defined prefix with some local attribute, such as local IPv4 address > [6TO4] or the combination of an address and a port number [Teredo]. > Another typical and very important characteristic of an automatic > solution is they aim to work with a minimal amount of support or > infrastructure for IPv6 in the local or remote ISPs. In a configured > solution, a host or a router identifies itself to a tunneling > service to set up a "configured tunnel" with an explicitly defined > "tunnel router". > > negociated tunnels have the same aim to work ... than automatic tunnel. > Suggesting text to replace "Another typical ... "tunnel router": > > For negociated tunnels, a host or a router receives an IPv6 address > or an IPv6 prefix from its tunnel broker, such as [TUNNELS] and [TSP]. > Another typical and very important characteristic of an automatic > or negociated solution is they aim to work with a minimal amount > of support or infrastructure for IPv6 in the local or remote ISPs. > No, I believe this is misleading. Tunnel-brokering -like solution requires more infrastructure than 6to4 or Teredo. So you can't say these solution aim to work with a minimal amount of infra in the local or remote ISPs. However, some rewording to take account the (upcoming) results of the "zero-configured" discussions should probably go in here. > workarounds are probably possible). However, automatic tunnels have > other advantages. They are obviously easier to configure, since > there is no need of an explicit relation with a tunnel service. > > 6to4, teredo and [TSP] all require a single IPv4 address to be > configured. Moreover, one of the "automatic" tunneling technique > requires the configuration and knowledge of 2 IPv4 addresses. > So this comment is not appropriate. > > Suggesting text: > > "However, automatic tunnels and negociated tunnels are easier to > configure." This is incorrect, IMHO. All the traffic goes through the tunnel endpoint with a bidirectional tunneling, only some with automatic tunneling. > In automatic tunnels like [Teredo] and [6to4], the bulk of the > traffic between two nodes using the same technology is exchanged on > a direct path between the endpoints, using the IPv4 services to > which the endpoints already subscribe. By contrast, the configured > tunnel servers carry all the traffic exchanged by the tunnel client. > > Is "direct path always possible in all cases between Teredo nodes? > It isn't and this should be reflected here. > Path optimization is not a big issue if the tunnel server is close > to the client, on the natural path between the client and its peers. > However, if the tunnel server is operated by a third party, this > third party will have to bear the cost of provisioning the bandwidth > used by the client. The associated costs can be significant. > > what is this cost compared/different to running a relay for 6to4 or > Teredo? Not clear to me what is the argument here. > Suggesting: s/The associated costs can be significant// > Both models for "3rd party infrastructures" have disadvantages for all of 6to4, Teredo and tunnel broker. But these are different. This needs to be discussed more. For 6to4 and Teredo?, the users don't use your IPv6 prefix, just your bandwidth for non-direct traffic. For tunnel broker model, people both use your prefix (think of abuse reports, etc.), and use more of your bandwidth (depending on how much of the traffic could be direct) as well. > 2.1.2 Automatic tunnels and relays > > The economics arguments related to path optimization favor either > configured tunnels provided by the local ISP or automatic tunneling > regardless of the co-operation of ISPs. However, automatic solutions > require that relays be configured throughout the Internet. If a host > that obtained connectivity through an automatic tunnel service wants > to communicate with a "native" host, > > s/"native" host/"native host or another host using another automatic > tunnel service"/ > True, but this should probably include text about local relays as well. > ... > communications between 6to4 hosts. This will create an incentive for > native hosts to somehow "multi-home" to 6to4, de facto creating two > parallel Internets, 6to4 and native. This risk will only be > mitigated if there is a sufficient deployment of 6to4 relays. > > Suggesting to add the following text: > Negociated tunnels, such as [TUNNELS] or [TSP] do not have this risk > of several parallel IPv6 Internets. > With some rewording, this could be added. > implement different strategies for address and port allocations, and > also different types of timers. It is desirable to find solutions > that cover "almost all" models of NAT. > > It appears to me that the goal is to cover _all_ models/behaviors > of NAT, not "almost all". Because the end user does not know behind > which kind of NAT he is, and we don't want him to know. However, the > end-user wants to have connectivity in all cases. I can't imagine > my laptop not getting IPv6 connectivity with a non-complete NAT traversal > solution, where, in one specific hotel room, they are using a NAT which > does not work with the NAT traversal solution in my laptop. > > Suggesting: s/cover "almost all"/cover all/. > Whether the solution must cover absolutely every NAT model or not is certainly a tradeoff to consider. Depends on the deployment model. > ... > by many applications, e.g., networked games or voice over IP. The > experience shows that most recent "home routers" are designed to > support these applications. In some edge cases, the automatic > solutions will require explicit configuration of a port in the home > router, using the so-called "DMZ" functions. > > only works for one single node. Moreover, it should be noted that this > explicit configuration is completly out of the _unmanaged_ goal. > > Suggesting text: > using the so-called "DMZ" functions". These cases are obviously out of > scope of the unmanaged network scenario and only work for a single node > behind the NAT. > Good point. > - Configured tunnel over IPv4 in the absence of NAT; > - Automatic tunnel over IPv4 in the absence of NAT; > - Configured tunnel across a NAT; > - Automatic tunnel across a NAT. > > Teredo is an example of already designed solution for automatic > tunnel across a NAT; 6to4 is an example of solution for automatic > tunnel over IPv4 in the absence of NAT. > > all solutions should be mentionned. Suggesting to add this text: > > s/absence of NAT./absence of NAT. [TSP] is an example of solution of > negociated tunnel over IPv4 in the absence of NAT and negociated tunnel > across a NAT. > In case we really want to go down this rathole, this should list at least STEP as well. The reason why 6to5/Teredo were mentioned that there is no other proposals in that area, and the question is not about the technology as such but whether it is needed in the first place. > An automatic solution like Teredo appears to be a good fit for > providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 > deployment. The service is designed for minimizing the cost of > deploying the server, which matches the requirement of minimizing > the cost of the "supporting infrastructure". > > I don't understand why TSP was not suggested here at the same > level of Teredo as "good fit". Suggesting text: > > s/An automatic solution like Teredo appears/Teredo and TSP appear/ Would you appreciate your tunnel broker address being glued into 20 million nodes, all of them contacting you for an anonymous tunnel, and would put their traffic over your links? It's not feasible as such. This is why we need to understand the "opportunistic" requirements better. The text should be tuned, but the right language will not be as simple as you propose. > 3.2 Security considerations in case A > > A characteristic of case A is that an isolated host acquires global > > text should be provided about the need of the relay function for > teredo and 6to4 and the security considerations of those relays. > > Yep. > The DHCPv4 solution will suffice in practice for the gateway and > also for the dual-stack hosts. There is evidence that even the > simple DNS resolvers present in small gateways can relay arbitrary > DNS requests and serve arbitrary DNS records, including AAAA > records. > > I'm not sure I really understand or agree on the above paragraph. > I understand the comment as if the small gateway IP address is put > in the resolv.conf file of the node and that small gateway will > relay requests and response. My experience with small gateways and > cable/dsl operators is that the small gateway is not involved as > relay for dns requests/answers. DNS request go directly from node to > DNS server of the ISP. > IMHO, you certainly can't assume that your DSL box will act as a DNS "forwarder", but if it does, it will be protocol-independent. I think the text above needs to be tuned to be in line with that.. a lot as you say. > Dynamic configuration using the same type of ad hoc protocols that > are common today is indeed possible, but the IETF should encourage > the use of standard solutions based on Dynamic DNS (DDNS). > > TSP does the configuration of Ipv6 address of the tunnel endpoint > (as well as the dns reverse tree in case of prefix delegation). > Suggesting text: > > Tunnel Brokers[TSP or TUNNELS] do provide the publication of the IPv6 > addresses as part of the establishment of the tunnel. > The TEP configuration is not releant here, but the reverse tree delegation could be. I'm not sure where this would fit best. A slightly different wording would probably be useful. > 5.1 Connectivity > > Connectivity in case C requires some form of tunneling of IPv6 over > IPv4. The various tunneling solutions are discussed in section 2. > The requirements of case C can be solved by an automatic tunneling > mechanism such as 6to4 [6TO4]. An alternative may be the use of a > configured tunnels mechanism [TUNNELS], but as the local ISP does is > not IPv6-enabled this may not be feasible. > > do not agree with this conclusion: the local ISP might not have > upgraded its access infrastructure, but might have backbone or a > cloud which is IPv6. Moreover, the upstream ISP might be IPv6. > Suggesting to: > replace "such as 6to4 [6TO4]. An alternative ... feasible." > by: > such as 6to4 [6TO4] or tunnel broker [TSP,TUNNELS]. > (and remove the "alternative way" sentence. I agree with your first points, but I don't agree with your wording suggestion -- it doesn't cover the different issues at sufficient detail. > The practical conclusion > of our analysis is that "upgraded gateways" will probably support > the 6to4 technology, and will have an optional configuration option > for "configured tunnels". > > seems to imply many things about how vendors package their product. > not sure that is the "business" of IETF. Would suggest to change the > wording to: > s/will probably support the 6to4 technology and will have ...tunnels"./ > might support 6to4 or TSP/ > I agree that this kind of language should probably be tuned a bit. > The tunnel broker technology should be augmented, to include support > for some form of automatic configuration. > > do not agree. TSP tunnel broker in anonymous auth mode is as > automatic as teredo or 6to4. > Suggesting to remove the sentence "The tunnel broker ... configuration". > I think you misunderstood the point. How can the user discover which tunnel broker to use? Browsing the web? The point is that for Tunnel Broker to be usable more widely, there has to be a "discovery function" which can be coded in by the *vendors* which then finds a good tunnel broker. Gluing in the freenet6 broker address is a non-starter for a couple of dozen million hosts ;-) > 6.2 IPv4 connectivity requirements > > Local IPv4 capable hosts may want to still access IPv4-only > services. The proper way to do this for dual-stack nodes in the > unmanaged network is to develop a form of "IPv4 over IPv6" > tunneling. This tunneling protocol need to be standardized. Part of > the standardization will have to cover configuration issues, i.e., > how to provision the IPv4 capable hosts with the address of the > local IPv4 tunnel servers. > > do not agree, seems to imply there are no solutions in place. > There are DSTM and TSP. TSP works today with this. > Suggesting to replace: "This tunneling ... tunnel servers." > by: > TSP tunnel broker and DSTM are available for this purpose. TSP provides > a ubiquitous way to provide v6 in v4 with or without NAT and v4 in v6. > There are no standardized solutions, which is what it says. Moreover, I don't think people have even stopped to think for very long what's actually needed here. Some text about current solutions of approaches should probably be included though. > 1- To meet case A and case C requirements, we need to develop, or > continue to develop, four types of tunneling technologies: automatic > tunnels without NAT traversal such as [6TO4], automatic tunnels with > NAT traversal such as [TEREDO], configured tunnels without NAT > traversal such as [TUNNELS] and configured tunnels with NAT > traversal. > > s/configured tunnels without NAT traversal such as [TUNNELS]/ > configured tunnels without NAT traversal such as [TUNNELS,TSP], > configured tunnels with NAT traversal[TSP] and IPv4 in IPv6 tunnels > with [TSP]./ > Disagree with this. > 4- To meet case D IPv4 connectivity requirement, we need to > standardize an IPv4 over IPv6 tunneling mechanism, as well as the > associated configuration services. > > again, do not agree. already in place. > Suggesting to delete 4- since text is added in 1- for that purpose. > IMHO, 4) should stay, for reasons described above. > 8 Security considerations > > This memo describes the general requirements for transition > mechanisms. Specific security issues should be studied and addressed > during the development of the specific mechanisms. > > a discussion and reference to draft on security of relays should > be provided here There is no such draft unfortunately. (on 6to4 security only) > Normative references > > to add: > > [TSP] Blanchet, M. "IPv6 tunnel broker with Tunnel Setup Protocol (TSP)", > Work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00. > Might be useful for Informative section, but not in Normative, I think. > would suggest to add draft filenames in references to make easier > to find the documents Might not hurt, but would have to update them too then ;-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Feb 29 17:18:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12660 for ; Sun, 29 Feb 2004 17:18:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxZEl-0004Bg-E4 for v6ops-data@psg.com; Sun, 29 Feb 2004 22:16:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxZEk-000491-4g for v6ops@ops.ietf.org; Sun, 29 Feb 2004 22:16:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1TMGbx23019 for ; Mon, 1 Mar 2004 00:16:37 +0200 Date: Mon, 1 Mar 2004 00:16:37 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: security considerations comments on draft-ietf-v6ops-unmaneval-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I do not believe these were addressed in the revision. ---------- Forwarded message ---------- Date: Tue, 15 Jul 2003 10:53:02 -0400 From: Bill Sommerfeld To: v6ops@ops.ietf.org Subject: security considerations comments on draft-ietf-v6ops-unmaneval-00.txt 1) section 4.3: tunnel-related security considerations really apply to all four scenarios; while it is less likely that tunnels will be used in the other scenarios, it's not impossible. suggested edit: pull the meat of section 4.3 into the main security considerations section and make it clearly applicable to any situation where tunnels are in use. 2) section 2.2: On dual-stack nodes, similar security policy should be applied to ipv4 and ipv6 communications; if strict policy is applied only to v6 traffic, this will provide no additional security (as the node will likely still be vulnerable through the v4 side). As a non-security matter, migration to v6 will be discouraged if common apps work over v4 but fail over v6. suggested edit: replace last sentance of 2.2 with: Security policy which prevents use of v6 while allowing v4 will discourage migration to v6 without significantly improving security. Developers and administrators should make sure that global Internet connectivity through either IPv4 or IPv6 is restricted to only those applications that are expressly designed for global Internet connectivity. - Bill From owner-v6ops@ops.ietf.org Sun Feb 29 17:22:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12776 for ; Sun, 29 Feb 2004 17:22:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxZIV-0004fv-Td for v6ops-data@psg.com; Sun, 29 Feb 2004 22:20:31 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxZIU-0004fd-FP for v6ops@ops.ietf.org; Sun, 29 Feb 2004 22:20:30 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1TMD9vM005766; Sun, 29 Feb 2004 17:13:10 -0500 (EST) Date: Sun, 29 Feb 2004 17:12:39 -0500 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com, mikael.lind@teliasonera.com Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Message-ID: <310130000.1078092759@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Sunday, February 29, 2004 23:30:58 +0200 Pekka Savola wrote/a ecrit: > Thanks for your feedback! > > A few comments on your comments below. > > >> Note that when customers use dynamic IPv4 addresses, the >> tunneling techniques may be more difficult to deploy at the ISP's >> end, especially if a protocol including authentication (like PPP for >> IPv6) is not used. This may need to be considered in more detail >> with tunneling mechanisms. >> >> disagree for TSP. TSP re-establish the tunnel automatically in the >> event of a change of IPv4 address >> Suggesting replacing text: >> >> Note that when customers use dynamic IPv4 addresses, manually >> configured tunneling techniques may be more difficult to deploy at >> the ISP's end, especially if a protocol including authentication >> (like PPP for IPv6) is not used. However, [TSP] does support >> automatic re-establishment of the tunnel when the IPv4 address change. >> > > I have to disagree with this -- STEP or TSP are not analyzed further > in the document, at this point. Of course, they might be in the > future, and if so, the feature(s) of TSP would certainly be mentioned. I don't understand here. Why 6to4 and Teredo are analysed and not TSP and STEP? >> >> Customers (with some exceptions) are not connected using a tunnel >> broker, because offering native service faster is considered more >> important -- and then there will not be unnecessary parallel >> infrastructures to tear down later on. However, a 6to4 relay is >> provided in the meantime for optimized 6to4 connectivity. >> >> don't understand that argument. if "offering native service faster >> is considered more important, then why care about 6to4 at all? >> 6to4 relay should be considered similar to tunnel broker in terms >> of ways to provide ipv6 through the not-yet-upgraded-ipv4 network. >> > > This has come through from a couple of operators. They don't want to > build tunnels etc. - agree if large number of manually configured tunnels. - disagree if tunnels are managed by tunnel brokers. We have many operators as customers who are using tunnel broker at this moment. Different operators, I guess, different views. > architecture because the difficult part about IPv6 > is considered to be the process/administrative issues, and it takes > time to move from "hacks" to "real solutions" when the time comes -- > so they're going to "real solutions" as the first step. Of course, > this could also be just an excuse :-). > > 6to4 relay can be used for two purposes: > 1) to optimize the return routing between the native IPv6 users in > your network and 6to4 users [this example], and > 2) to optimize the use of 6to4 when your customers support it (this > requires no support from the ISP, but offers the users better IPv6). > This was not the main intent of the statement above, but comes in as a > bonus. > Marc. From owner-v6ops@ops.ietf.org Sun Feb 29 17:23:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12802 for ; Sun, 29 Feb 2004 17:23:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxZJT-0004rw-FT for v6ops-data@psg.com; Sun, 29 Feb 2004 22:21:31 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxZJS-0004rX-7M for v6ops@ops.ietf.org; Sun, 29 Feb 2004 22:21:30 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i1TMD9vO005766; Sun, 29 Feb 2004 17:13:11 -0500 (EST) Date: Sun, 29 Feb 2004 17:12:58 -0500 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments Message-ID: <310770000.1078092778@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Sunday, February 29, 2004 07:57:53 +0200 Pekka Savola wrote/a ecrit: > Thanks for updating the spec -- it has been a long time :). (well, v6ops was not supposed to work on protocols... ;-))) > A few > comments below. thanks, appreciated. > > I'm commenting on the spec itself only, not the deployment model (at this > point). > > very substantial > ---------------- > > 1) The specification is rather intuitive and easy to read and get a grasp > on, but as it is, I don't think it is has enough details to build an > interoperable implementation. For example: > > - the heartbeat mechanism which is mentioned, appears to be non-specified > - a lot of error codes are listed in the end, but there is no > specification except about the first couple of them when they are to be > returned, etc. -- I think you're able to guess that, though. > - there are some references to UDP as a control plane mechanism, but no > real specification. There was also a mention of > "UDP-reliable", which was not elaborated further.. all agreed that they were not enough specified. This initial submission was mostly a merge of the 4 old drafts altogether. I will submit a new version with this info (it was already on my todo) > > 2) There seems to be something fishy about mobility. not intended! > The user is expected > to give an IP address, which (supposedly) is used to identify the user. no. IP address is used to create the tunnel on both end. User authentication is used to identify the user. > But if the IP address of the user changes, how can such identification be > done? if user have used authentication, the broker stores that information and then can be resend to the user the next time he comes, even with a new v4 address. > All in all, it seems like the mobility was not really described at > length either... ok. sorry. will do better in the next version. > > 3) TSP specifies a lot of custom ways of signalling. Maybe this is more > of a philosophical argument of building from pieces vs. designing the > whole system, but I think some might have preferred using existing > heartbeat (ND), prefix delegation, DNS resolving and delegation etc. > mechanisms. And if those are not sufficient (e.g., prefix delegation is > too complex), shouldn't we specify a simpler version? tsp was based on users input and requests, starting from early 1999. Still now, basic requirements for users are similar. - an important requirement was that these days (because of IPv6... ;-))), users have a network instead of a host. A network means prefix delegation, etc... - for the provider perspective (provider in the sense of the tsp tunnel broker provider: it could be ISP, enterprise, ...), tsp tunnel broker enables fast deployment. By having these additional functions, it enables the provider to offer a full set of services while not have to upgrade right away its infrastructure (eg. including DNS). - the user is authenticated in the TSP session (in non-anonymous mode): this enables the assignments of prefixes and dns stuff, since they need some kind of authentication. If we do it out of TSP (which is possible today with TSP: just don't request/use these TSP functions), then another authentication infrastructure must be put in place. > > While I don't have a really strong opinion here, some consideration wrt. > "reuse" vs "redesign to fit" will undoubtedly come up. > > 4) SASL doesn't work with UDP, so my guess is that the whole UDP > signalling must have been some kind of glitch in the spec. I will improve in next version. (it works, I'm using it every day...) > > semi-substantial/semi-editorial > ------------------------------- > > Abstract > > ==> it is maybe a bit too long; fitting on the "cover page" would be very > preferable. ok. > ==> no references in the abstract. > > to have up to 4 parties involved: 1- the tsp client, 2- controlling > the requesting tunnel end-point, 3- the tsp server, 4- controlling > the receiving tunnel end-point. 1,3 and 4 is the Tunnel Broker > model. 1 and 2 can be on the same node, as well as 3 and 4 can be on > the same node. > > ==> s/tsp/TSP/ > ==> I think you should reword this to make clearer what 2) and 4) meant. I > only (think I) understood this after reading the whole spec. ok. > > 3. Advantages of TSP > > o A signaling protocol to establish the tunnel: no need to change > kernels, routing... > > ==> I do not understand what you mean by this advantage. Perhaps you > should elaborate or reword. ok. what was meant is that it is "just" a signaling protocol: it is on the control plane. No modifications needed elsewhere. > > o routing negociation > > ==> again, it is not clear what you mean by this; perhaps needs to be > expanded. ok. > > o two to four tier tunnel broker model > > ==> is this an advantage? I'd maybe count this as a drawback :-) say an option. > > C: Content-length: 234 CR LF > > >
1.1.1.1
> > > >
2.3.4.5
>
2.3.4.6
>
3ffe:0c00::1
> > > > > ==> umm.. why is the client requesting DNS server addresses like this -- > doesn't seem to make sense! might not have been clear enough. He was sending _his_ dns server addresses for the inverse tree delegation. Will add. > > > 3ffe:0b00:c18:1234:: > > ==> the prefix length is 48, but the prefix is 64 -- glitch or > intentional? sorry. typo. > >
type="ipv6">fe80:0000:0000:0000:0000:0000:0000:0001
> > ==> why advertise its own link-local address? > > C:Content-length: ... CR LF > > > ==> it appears that the other examples wouldn't have worked through NAT. these are many variations or examples. > > Automation of the prefix assignment and DNS delegation, done by TSP, > is a very important feature for a provider in order to substantially > decrease support costs. The provider can use the same authentication > database that is used to authenticate the IPv4 users. > > ==> there is not even a hint how TSP could use the same databases as with > v4 authentication :-) ok. answer was "radius"... Will add. > > 5.5 Applicability of TSP in Unmanaged networks > > > ==> many of these are actually the same scenarios as identifier earlier, > this one is pretty close to 5.2. There's some other overlap as well -- > might be worth compressing these a bit... > > Static tunnels are created when the TSP negociation is terminated. > Static tunnels are not open gateways and exhibit less security issues > than automated tunnels. Static IPv6 in IPv4 tunnels security > considerations are described in [RFC2893]. > > ==> there's some very important stuff in the mech-v2 document as well. > > References > > ==> split the references to Normative and Informative > > [5] Hagino, J., "Possible abuse against IPv6 transition > technologies", July 2000. > > ==> this wasn't refererred to in the draft, so remove? > > > > ==> is that "1440" here intentional ??? yes. default lifetime. > > > > ==> I don't think there's need for "as", nor is it mentioned elsewhere in > the document. from old versions. will cut. > > Full Copyright Statement > > ==> please add IPR section prior to this section humm. automation. I probably need to update my version xml2rfc, which would do it... ;-))) > > > editorial > --------- will do these. Marc. From owner-v6ops@ops.ietf.org Sun Feb 29 17:27:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12919 for ; Sun, 29 Feb 2004 17:27:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxZNd-0005eF-3y for v6ops-data@psg.com; Sun, 29 Feb 2004 22:25:49 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxZNb-0005de-FZ for v6ops@ops.ietf.org; Sun, 29 Feb 2004 22:25:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1TMPhj23227; Mon, 1 Mar 2004 00:25:43 +0200 Date: Mon, 1 Mar 2004 00:25:43 +0200 (EET) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org, , Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt In-Reply-To: <310130000.1078092759@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 29 Feb 2004, Marc Blanchet wrote: > > I have to disagree with this -- STEP or TSP are not analyzed further > > in the document, at this point. Of course, they might be in the > > future, and if so, the feature(s) of TSP would certainly be mentioned. > > I don't understand here. Why 6to4 and Teredo are analysed and not TSP and > STEP? Because we don't want to repeat the same, generic arguments multiple times -- the same ones we're having with the unmanaged document. Discussion should be added before the document is published though -- or we'll just publish a more generic document only. 6to4 and Teredo are a bit easier as there is no "competition". > >> don't understand that argument. if "offering native service faster > >> is considered more important, then why care about 6to4 at all? > >> 6to4 relay should be considered similar to tunnel broker in terms > >> of ways to provide ipv6 through the not-yet-upgraded-ipv4 network. > >> > > > > This has come through from a couple of operators. They don't want to > > build tunnels etc. > > - agree if large number of manually configured tunnels. > - disagree if tunnels are managed by tunnel brokers. We have many operators > as customers who are using tunnel broker at this moment. Different > operators, I guess, different views. Different operators certainly have different views -- these also extend to tunnel brokering. Any infrastructure can be considered "bad". Whether this is a real argument is different, of cours.e -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Feb 29 17:46:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13671 for ; Sun, 29 Feb 2004 17:46:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxZeW-0008VT-3H for v6ops-data@psg.com; Sun, 29 Feb 2004 22:43:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxZeU-0008V7-NF for v6ops@ops.ietf.org; Sun, 29 Feb 2004 22:43:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1TMhBR23522; Mon, 1 Mar 2004 00:43:11 +0200 Date: Mon, 1 Mar 2004 00:43:11 +0200 (EET) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org Subject: Re: TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments In-Reply-To: <310770000.1078092778@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 29 Feb 2004, Marc Blanchet wrote: > > Thanks for updating the spec -- it has been a long time :). > > (well, v6ops was not supposed to work on protocols... ;-))) But individuals are welcome to :-) > > The user is expected > > to give an IP address, which (supposedly) is used to identify the user. > > no. IP address is used to create the tunnel on both end. User > authentication is used to identify the user. Ok -- I think the problem is that the document does not describe other than which authentication mechanisms are used -- nothing at what key/account material or procedures are used prior to the mechanical authentication algorithm use. > > 4) SASL doesn't work with UDP, so my guess is that the whole UDP > > signalling must have been some kind of glitch in the spec. > > I will improve in next version. (it works, I'm using it every day...) Hmm.. unless I looked at it wrong, the SASL spec disagrees with you :-). > > 3. Advantages of TSP > > > > o A signaling protocol to establish the tunnel: no need to change > > kernels, routing... > > > > ==> I do not understand what you mean by this advantage. Perhaps you > > should elaborate or reword. > > ok. what was meant is that it is "just" a signaling protocol: it is on the > control plane. No modifications needed elsewhere. UDP encapsulation, at least, is a (minor) modification. > > Automation of the prefix assignment and DNS delegation, done by TSP, > > is a very important feature for a provider in order to substantially > > decrease support costs. The provider can use the same authentication > > database that is used to authenticate the IPv4 users. > > > > ==> there is not even a hint how TSP could use the same databases as with > > v4 authentication :-) > > ok. answer was "radius"... Will add. and which attributes, etc -- I think some details are needed so that this could work interoperably. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Feb 29 19:37:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19055 for ; Sun, 29 Feb 2004 19:37:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxbO7-0001rn-UV for v6ops-data@psg.com; Mon, 01 Mar 2004 00:34:27 +0000 Received: from [218.37.228.191] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxbO5-0001rF-JN for v6ops@ops.ietf.org; Mon, 01 Mar 2004 00:34:25 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i210TLau008279; Mon, 1 Mar 2004 09:29:21 +0900 (KST) Date: Mon, 01 Mar 2004 09:29:21 +0900 From: Florent Parent To: Pekka Savola cc: Marc Blanchet , v6ops@ops.ietf.org Subject: Re: TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments Message-ID: <256680000.1078100960@blues.hexago.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, March 01, 2004 00:43:11 +0200 Pekka Savola wrote: > On Sun, 29 Feb 2004, Marc Blanchet wrote: snip... >> no. IP address is used to create the tunnel on both end. User >> authentication is used to identify the user. > > Ok -- I think the problem is that the document does not describe other > than which authentication mechanisms are used -- nothing at what > key/account material or procedures are used prior to the mechanical > authentication algorithm use. understood. Will add in next rev. >> > 4) SASL doesn't work with UDP, so my guess is that the whole UDP >> > signalling must have been some kind of glitch in the spec. >> >> I will improve in next version. (it works, I'm using it every day...) > > Hmm.. unless I looked at it wrong, the SASL spec disagrees with you > :-). SASL spec supports "connection-based protocols". Using UDP requires you to establish and maintain a "connection" for the duration of the authentication exchange and tunnel setup. This will be explain in the next rev., along with the "reliable UDP" stuff. snip... >> > ==> there is not even a hint how TSP could use the same databases as >> > with v4 authentication :-) >> >> ok. answer was "radius"... Will add. > > and which attributes, etc -- I think some details are needed so that > this could work interoperably. agreed. Will add. Florent From owner-v6ops@ops.ietf.org Sun Feb 29 20:41:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21580 for ; Sun, 29 Feb 2004 20:41:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxcOQ-000EFR-L1 for v6ops-data@psg.com; Mon, 01 Mar 2004 01:38:50 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxcON-000EEz-RM for v6ops@ops.ietf.org; Mon, 01 Mar 2004 01:38:47 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i211ccdO003981; Sun, 29 Feb 2004 17:38:39 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i211caQ29678; Mon, 1 Mar 2004 02:38:36 +0100 (MET) Date: Sun, 29 Feb 2004 17:09:08 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Opportunistic Tunneling To: Jasminko Mulahusic Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20040229134756.N69205@lord.fakat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > I think vendors can provide the infrastructure in their software that Bob > talks > about (detecting existing IPv6 connectivity and prompting the user > with "cool > application X needs IPv6 connectivity - should I set up such > connectivity?"). > > would such a framework be a superset of the existing tranisition > mechanisms, where the mechanism to be used would be selected based upon > .... ? or would this actually be a new mechanism? > > isn't there one software vendor that is already doing something similar > when the user chooses to activate ipv6? is it something that needs to be > standardized in the ietf? I don't think this is something that needs to be standardized; this is merely an issue of how the different software components (applications and the protocol stack) on an implementation interact. Erik From owner-v6ops@ops.ietf.org Sun Feb 29 20:50:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22423 for ; Sun, 29 Feb 2004 20:50:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxcXa-000G7i-JS for v6ops-data@psg.com; Mon, 01 Mar 2004 01:48:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxcXX-000G6w-0s for v6ops@ops.ietf.org; Mon, 01 Mar 2004 01:48:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i211m9M25707; Mon, 1 Mar 2004 03:48:10 +0200 Date: Mon, 1 Mar 2004 03:48:09 +0200 (EET) From: Pekka Savola To: Florent Parent cc: Marc Blanchet , Subject: Re: TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments In-Reply-To: <256680000.1078100960@blues.hexago.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 1 Mar 2004, Florent Parent wrote: > >> > 4) SASL doesn't work with UDP, so my guess is that the whole UDP > >> > signalling must have been some kind of glitch in the spec. > >> > >> I will improve in next version. (it works, I'm using it every day...) > > > > Hmm.. unless I looked at it wrong, the SASL spec disagrees with you > > :-). > > SASL spec supports "connection-based protocols". Using UDP requires you to > establish and maintain a "connection" for the duration of the > authentication exchange and tunnel setup. > > This will be explain in the next rev., along with the "reliable UDP" stuff. Why exactly is UDP used here? For signalling, TCP should be fine, and the actual tunnel doesn't use SASL in any case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Feb 29 21:17:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24239 for ; Sun, 29 Feb 2004 21:17:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxcxA-000LbQ-4r for v6ops-data@psg.com; Mon, 01 Mar 2004 02:14:44 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axcx7-000Lau-IQ for v6ops@ops.ietf.org; Mon, 01 Mar 2004 02:14:42 +0000 Received: from consulintel02 ([218.37.225.193]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 53-md50000000178.tmp for ; Mon, 01 Mar 2004 03:19:25 +0100 Message-ID: <016301c3ff33$94e73060$c1e125da@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt Date: Mon, 1 Mar 2004 11:18:53 +0900 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 01 Mar 2004 03:19:25 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 218.37.225.193 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, I see your point. As more routers I try, more I find when isn't needed to configure = anything: Is forwarded the same way as ICMP or other protocols. But of course, this depends on each manufacturer, and even it can = change. I also find some where ICMP is disabled by default ;-) I think this is clearly a generic configuration issue in any "network = box". Even it may depend in who install the router. For example, some = ISPs change the manufacturer's default configuration. We will post an updated version most probably after this meeting, and = will including a clarification on this. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "Marc Blanchet" Cc: ; ; = Sent: Monday, March 01, 2004 6:30 AM Subject: Re: WG Last Call: = draft-ietf-v6ops-isp-scenarios-analysis-01.txt > Thanks for your feedback! >=20 > A few comments on your comments below. >=20 > Jordi, there is one comment on proto-41 forwardaring below which is > not IMHO clear -- could you check ? >=20 > On Fri, 27 Feb 2004, Marc Blanchet wrote: > > 3.2.1 Stage 1 Scenarios: Launch=20 > > ...=20 > > =20 > > The immediate first step consists of getting a prefix allocation = =20 > > (typically a /32) from the appropriate RIR according to = allocation =20 > > procedures.=20 > >=20 > > while clearly a good advice, not sure really useful to discuss = here > > given the objective of the document. >=20 > There have been a couple of comments to even expand this, so I think=20 > this is probably a good pointer to start with.. not something that=20 > can or should be fully discussed, through. >=20 > > The selection of one candidate depends largely on the presence or = =20 > > absence of NATs between the two tunnel end-points and whether the = =20 > > user's IPv4 tunnel end-point address is static or dynamic. In = most =20 > > cases, 6to4 and ISATAP are incompatible with NATs, and UDP =20 > > encapsulation for configured tunnels has not been specified. > >=20 > > configured tunnels with tunnel brokers [TSP] is specified for > > NAT traversal. > > =20 >=20 > True, but the issue remains: [MECH] or MECH-v2 doesn't do UDP. >=20 > > However, NAT traversal can be avoided if the NAT supports =20 > > forwarding protocol-41 [PROTO41].=20 > >=20 > > s/protocol-41/protocol-41 and configured to do so./ >=20 > This is a point which I've tried to raise is that I think most=20 > protocol-41 forwarding implementations do automatically forward=20 > protocol-41 without any configuration -- just as they forward ICMP. >=20 > If setting up proto-41 forwarding requires manual set-up (as discussed = > in a few places in the proto-41 forwarding draft), then it certainly=20 > would not be an option. >=20 > Perhaps Jordi can clarify (and post an updated draft! :-) >=20 > > The connectivity mechanisms can be categorized as "managed" or=20 > > "opportunistic." The former consist of native service or a=20 > > configured tunnel (with or without a tunnel broker); the latter=20 > > include 6to4 and, e.g., Teredo; they provide "short-cuts" between = > > nodes using the same mechanisms and are available without = contracts=20 > > with the ISP.=20 > >=20 > > Teredo needs a Teredo server located outside of the NAT, which = means > > in the architecture presented in section 2, as customer connection = network. > > >=20 > Teredo server doesn't have to be near the customer, it can be anywhere = > at all -- I wouldn't expect any ISPs to deploy it, in the short term=20 > at least. Suggested text? >=20 > > Most interesting are the managed services. When dual-stack is not = an=20 > > option, a form of tunneling must be used. When configured = tunneling=20 > > is not an option (e.g., due to dynamic IPv4 addressing), some = form of=20 > > automation has to be used. The options are basically either to = deploy=20 > > an L2TP architecture (whereby the customers would run L2TP = clients=20 > > and PPP over it to initiate IPv6 sessions) or to deploy a tunnel=20 > > configuration service. The prime candidates for tunnel = configuration=20 > > are STEP [STEP] and TSP [TSP], which are not analyzed further in = this=20 > > document.=20 > >=20 > > would also add that these services are able to do NAT traversal. > > Suggesting: > > s/are STEP and TSP , providing tunnels with or without the presence = of NAT./ > > >=20 > Seems to make sense to say that explicitly. >=20 > > Note that when customers use dynamic IPv4 addresses, the =20 > > tunneling techniques may be more difficult to deploy at the ISP's = > > end, especially if a protocol including authentication (like PPP = for > > IPv6) is not used. This may need to be considered in more detail = =20 > > with tunneling mechanisms. =20 > >=20 > > disagree for TSP. TSP re-establish the tunnel automatically in = the > > event of a change of IPv4 address > > Suggesting replacing text: > >=20 > > Note that when customers use dynamic IPv4 addresses, manually = configured > > tunneling techniques may be more difficult to deploy at the ISP's = > > end, especially if a protocol including authentication (like PPP = for > > IPv6) is not used. However, [TSP] does support automatic = re-establishment > > of the tunnel when the IPv4 address change. > > >=20 > I have to disagree with this -- STEP or TSP are not analyzed further=20 > in the document, at this point. Of course, they might be in the=20 > future, and if so, the feature(s) of TSP would certainly be mentioned. >=20 > > 5.2 Access Control Requirements =20 > > =20 > > =20 > > When a provider does not wish to give its IPv4 customers =20 > > automatic access to IPv6 services, specific IPv6 access control = must=20 > > be performed in parallel with the IPv4 access control. This does = not=20 > > imply that different user authentication must be performed for = IPv6,=20 > > but merely that the authentication process may lead to different=20 > > results for IPv4 and IPv6 access. =20 > >=20 > > to add: > > The [TSP] tunnel broker provides the AAA capabilities to manage this > > access control if desired. > > >=20 > Similarly, at the moment, I think TSP/STEP/ISATAP/etc. -specific=20 > issues are out of scope. This might change, based on this IETF=20 > though.. >=20 > > Note that when the customer connection network is shared between = the=20 > > users or the ISPs, and not just a point-to-point link, = authenticating=20 > > the configuration of the parameters (esp. prefix delegation) = requires=20 > > further study.=20 > > TSP does it. to add: > > TSP tunnel broker does prefix delegation in this context > > >=20 > Same as above. >=20 > > This can be done, for example, by mapping a DHCP response to a = =20 > > physical connection and storing this in a database. It can also = be =20 > > done by assigning a static address or prefix to the customer.=20 > >=20 > > to add: TSP Tunnel broker provides this binding between user and > > address and prefix delegated. >=20 > Likewise. >=20 > > 8.1 Example 1 =20 > > =20 > > Customers (with some exceptions) are not connected using a tunnel = > > broker, because offering native service faster is considered more = > > important -- and then there will not be unnecessary parallel=20 > > infrastructures to tear down later on. However, a 6to4 relay is=20 > > provided in the meantime for optimized 6to4 connectivity. > >=20 > > don't understand that argument. if "offering native service = faster > > is considered more important, then why care about 6to4 at all? > > 6to4 relay should be considered similar to tunnel broker in terms > > of ways to provide ipv6 through the not-yet-upgraded-ipv4 network. > > >=20 > This has come through from a couple of operators. They don't want to=20 > build tunnels etc. architecture because the difficult part about IPv6=20 > is considered to be the process/administrative issues, and it takes=20 > time to move from "hacks" to "real solutions" when the time comes --=20 > so they're going to "real solutions" as the first step. Of course,=20 > this could also be just an excuse :-). >=20 > 6to4 relay can be used for two purposes: > 1) to optimize the return routing between the native IPv6 users in=20 > your network and 6to4 users [this example], and > 2) to optimize the use of 6to4 when your customers support it (this=20 > requires no support from the ISP, but offers the users better IPv6). =20 > This was not the main intent of the statement above, but comes in as a = > bonus. >=20 > Suggestions for clarification? >=20 > > adding tsp as reference > >=20 > > [TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup > > Protocol(TSP)", > > work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00, = feb 2004 > > >=20 > Right .. apparently these weren't added even though there is a=20 > reference in the text. Add STEP as well. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.