From owner-v6ops@ops.ietf.org Mon Mar 1 03:26: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 DAA01610 for ; Mon, 1 Mar 2004 03:26:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxigX-000IOh-27 for v6ops-data@psg.com; Mon, 01 Mar 2004 08:21:57 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axhay-0009i9-Rd for v6ops@ops.ietf.org; Mon, 01 Mar 2004 07:12:08 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Feb 2004 23:12:07 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 29 Feb 2004 23:12:08 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Feb 2004 23:12:07 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Feb 2004 23:12:20 -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); Sun, 29 Feb 2004 23:12:02 -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: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt Date: Sun, 29 Feb 2004 23:12:01 -0800 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt Thread-Index: AcP/EnGWUcyBglKjQjep3OOAznkP7gASHHYg From: "Christian Huitema" To: "Pekka Savola" , "Marc Blanchet" Cc: X-OriginalArrivalTime: 01 Mar 2004 07:12:02.0031 (UTC) FILETIME=[7E7707F0:01C3FF5C] 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 A couple of quick points regarding Teredo: =20 > > 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? > > >=20 > It isn't and this should be reflected here. Actually, in the current design either all traffic will go on the direct path, or no traffic will be exchanged at 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. > > >=20 > Good point. I agree that in the absence of automatic support through UPNP, DMZ functions are indeed not your typical unmanaged service. But the point is at least partially incorrect. First, it is possible in some cases to use automatic procedures to "DMZ" a port (e.g., using the UPNP "internet gateway device" service). Second, the procedure that absolutely work for more than one node -- just pick a different port for each node.=20 In any case, the work done in the MIDCOM working group shows that the number of symmetric NAT in the market is rapidly decreasing. See draft-jennings-midcom-stun-results-00.txt -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Mar 1 05:18: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 FAA07217 for ; Mon, 1 Mar 2004 05:18:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxkS7-0006Wn-OS for v6ops-data@psg.com; Mon, 01 Mar 2004 10:15:11 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxkS5-0006W1-BW for v6ops@ops.ietf.org; Mon, 01 Mar 2004 10:15:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i21AFOrq002859; Mon, 1 Mar 2004 11:15:26 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <200402102106.QAA15214@ietf.org> References: <200402102106.QAA15214@ietf.org> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4D7E370C-6B69-11D8-9DA7-000A95CD987A@muada.com> Content-Transfer-Encoding: quoted-printable Cc: Pekka Savola From: Iljitsch van Beijnum Subject: Re: I-D ACTION:draft-ietf-v6ops-6to4-security-01.txt Date: Mon, 1 Mar 2004 11:15:02 +0100 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.612) 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: quoted-printable On 10-feb-04, at 22:06, Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security=20 > -01.txt Comments: "The 6to4 specification outlined quite a few security considerations, but it has been shown that in practice some of them have been difficult to get implemented due to their abstract nature." How do you implement a consideration? And what exactly are you =20 referring to? This is from RFC 3056: "In any case, any 6to4 traffic whose source or destination address embeds a V4ADDR which is not in the format of a global unicast address MUST be silently discarded by both encapsulators and decapsulators. Specifically, this means that IPv4 addresses defined in [RFC 1918], broadcast, subnet broadcast, multicast and loopback addresses are unacceptable." I don't find this particularly abstract, and apparently implementers =20 didn't have much trouble with it either, this is from FreeBSD: # netstat -rnf inet6 Destination=A0=A0=A0=A0=A0=A0=A0Gateway=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0Flags=A0=A0=A0=A0=A0Netif Expire default=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A02002:c058:6301::=A0=A0=A0=A0=A0UGS= c=A0=A0=A0=A0=A0=A0stf0 2002::/24=A0=A0=A0=A0=A0=A0=A0=A0=A0::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0UGRSc=A0=A0=A0=A0=A0=A0lo0 =3D> 2002::/16=A0=A0=A0=A0=A0=A0=A0=A0=A02002:dfe0:e1e2::1=A0=A0=A0=A0Uc=A0=A0=A0= =A0=A0=A0=A0=A0stf0 2002:7f00::/24=A0=A0=A0=A0::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0UGRSc=A0=A0=A0=A0=A0=A0lo0 2002:dfe0:e1e2::1=A0=A0link#7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0UHL= =A0=A0=A0=A0=A0=A0=A0=A0lo0 2002:e000::/20=A0=A0=A0=A0::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0UGRSc=A0=A0=A0=A0=A0=A0lo0 2002:ff00::/24=A0=A0=A0=A0::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0UGRSc=A0=A0=A0=A0=A0=A0lo0 As you can see they filter 0.0.0.0/8, 127.0.0.0/8, 224.0.0.0/4 and =20 255.0.0.0/8. (That last one is probably a bit excessive, =20 255.255.255.255/32 should be enough.) Linux also filters RFC 1918, =20 169.254.0.0/16 and 240.0.0.0/4: # ip -6 route ::/96 via :: dev tun6to4=A0metric 256=A0mtu 1480 advmss 1420 unreachable ::/96 dev lo=A0metric 1024=A0error -101 mtu 16436 advmss = 16376 unreachable ::ffff:0.0.0.0/96 dev lo=A0metric 1024=A0error -101 mtu = 16436 =20 advmss 16376 unreachable 2002:a00::/24 dev lo=A0metric 1024=A0error -101 mtu 16436 =20= advmss 16376 unreachable 2002:7f00::/24 dev lo=A0metric 1024=A0error -101 mtu 16436 =20= advmss 16376 unreachable 2002:a9fe::/32 dev lo=A0metric 1024=A0error -101 mtu 16436 =20= advmss 16376 unreachable 2002:ac10::/28 dev lo=A0metric 1024=A0error -101 mtu 16436 =20= advmss 16376 unreachable 2002:c0a8::/32 dev lo=A0metric 1024=A0error -101 mtu 16436 =20= advmss 16376 unreachable 2002:e000::/19 dev lo=A0metric 1024=A0error -101 mtu 16436 =20= advmss 16376 2002::/16 dev tun6to4=A0proto kernel=A0metric 256=A0mtu 1480 advmss 1420 unreachable 3ffe:ffff::/32 dev lo=A0metric 1024=A0error -101 mtu 16436 =20= advmss 16376 default via ::192.88.99.1 dev tun6to4=A0metric 1024=A0mtu 1480 advmss = 1420 (This doesn't show up in either the routing table or firewalling rules. =20= Also note their take on the ::/96 address space.) The draft talks about "6to4 routers" without specifying what those are. =20= This confusing, as many systems that run 6to4 don't act as routers. "If the 6to4 router established a BGP session between all the = possible 6to4 relays," This is of course both insane scalability-wise and impossible in the =20 presence of RFC 3068 relays as anycasting isn't compatible with the use =20= of TCP. "o Disallow traffic from 6to4 routers where the IPv4 tunnel source address does not match the 6to4 prefix." Source or destination isn't specified. See discussion below. "The 6to4 router will also perform security checks on traffic that it will receive from other 6to4 relays, or 6to4 routers, or from within the 6to4 site. These checks include:" Is this the current situation? If so, where is it specified? If not, is =20= this draft specifying that this must be done? There is no =20 justification. "o Disallow traffic transmission to other 6to4 domains through 6to4 relay router or via some third party 6to4 router. o Discard traffic received from other 6to4 domains via a 6to4 relay router." I believe older versions of Linux did this as they were unable to =20 properly tunnel to other 6to4 routers or hosts directly. If this isn't =20= allowed, it should be spelled out very specifically. "o Disallow traffic from 6to4 routers where the IPv4 tunnel source address does not match the 6to4 prefix." Is it mandated that only the host holding the corresponding IPv4 =20 address may tunnel packets with 6to4 IPv6 addresses? It is conceivable =20= that due to internal routing issues packets may flow over an =20 alternative 6to4 router in sites that use more than one. "o Disallow traffic where the destination IPv6 address is not a global address; in particular, e.g. link-local addresses, mapped addresses and such should not be used. Note, this check might be incorrect if 6to4 were to be used." Huh??? This last sentence doesn't compute. "o Discard traffic received from 6to4 routers with the destination = as a 6to4 prefix." Reuse your code. "This section describes attacks against 6to4 networks. Attacks which legerate 6to4 networks" "Legerate" isn't an English word. "Leverage", maybe? "It is possible to conduct a variety of attacks on the 6to4 nodes. These attacks are: 1. Attacks with Neighbor Discovery (ND) Messages" Finally, but not before page 12, something that isn't blatantly =20 obvious. However, there is no description of how such an attack would =20= work and what bad stuff would be the result. "The attacker - a malicious IPv4 or IPv6 node - can send packets with spoofed source address to a 6to4 node to accomplish a DoS attack." It isn't clearly specified what kind of DoS attack. What I get from the =20= discussion below this is that third party hosts reachable over 6to4 can =20= be used to hide the identity of the attacker, but the sentence above =20 seems to indicate something very different. "4.1.4 Local IPv4 Broadcast Attack" This is covered in the original RFC and it's handled appropriately in =20= at least the FreeBSD implementation. (I can tell you it works too - I =20= accidentally messed up my subnet mask at some point so that my IP =20 address was a broadcast address and 6to4 wouldn't work.) So why are we =20= talking about this? "6to4 relays have only one significant security check they must perform for general safety: when decapsulating IPv4 packets, check that 2002:V4ADDR::/48 and V4ADDR match." Are we talking about the source addresses here? I don't believe it is a =20= requirement that packets arriving over 6to4 must have an IPv4 source =20 address that matches the 6to4 source address. However, it may be =20 reasonable to impose such a requirement, but in that case it must be =20= spelled out such that it's impossible to miss so that implementers and =20= operators know it. But I think it's meaningless anyway as an attacker =20= then simply spoofs both source addresses. "6to4 relay should not relay packets between 6to4 addresses." Again, reuse your code. It's worse than useless to talk about the same =20= thing twice in the same document. See above for my objections. "4.2.1 Attacks with ND Messages These attacks are the same as employed against 6to4 routers as described in Section 4.1.1." Then why talk about it again??? Note that this isn't just me being =20 annoyed over wasting time reading the same thing: having the same thing =20= in a specification more than once is also a great way to introduce =20 errors in new versions of documents and in implementations (speaking =20 from painful experience here). As a more general note: the draft spends too much time discussing =20 things that are "not really useful", taking away focus from stuff that =20= we need to do something about. It would probably be useful to separate three aspects of the problem, =20= possibly to the degree of having separate documents: - 6to4 end-user issues - 6to4 relay operator issues - implementation issues "1. Usage of access lists in the relay to limit access." Announcing reachability to 2002::/16 and 192.88.99.1 and then deploy =20 filters is inappropriate, as it can lead to black holes if the routing =20= information leaks beyond what the relay expects. Since whether this =20 happens is beyond the direct control of the relay operator, this can =20 easily happen. So either the relay should be prepared to handle =20 unexpected traffic or it shouldn't announce those routes outside its =20 AS. Alternatively, we may want to rethink the prohibition on announcing =20 more specifics for 2002::/16 as this is an effective way to limit =20 access to a relay. "Such attacks can easily be thwarted by implementing protocol-41 filtering in IPv4 nodes or sites that do not implement IPv6 over = IPv4 tunneling." This is either useless or dangerous. Useless in the case of hosts, =20 which already throw out packets for protocols they don't run, and =20 dangerous in the case of sites, because it makes it impossible to do =20 any kind of IPv6inIP tunneling, defeating the purpose of transition =20 mechanisms. "4.4 Summary of the Attacks" Skipping this part, see notes on duplication of content. Under "5.1 Encapsulating IPv6 into IPv4": "ipv4 address embedded in src_v6 MUST match src_v4" Either there is no IPv4 header so the check is meaningless or one has =20= just been added, so checking yourself is redundant. Dropping packets with non-6to4 source addresses is unacceptable, as =20 this creates black holes and isn't compatible with the practice of =20 setting up a private relay to have better connectivity towards 6to4 =20 hosts. "5.2 Decapsulating IPv4 into IPv6 The checks described in this section are to be performed when decapsulating IPv4 into IPv6. They will be performed in both the 6to4 router and relay." This isn't a good idea as regular 6to4 hosts and routers need to be =20 more restrictive than relays. To be more specific: in the case of a =20 6to4 host or router the destination IPv6 address must be a 6to4 address =20= for which the corresponding IPv4 address is assigned to the host or =20 router. Any other destination address, be it multicast, non-global =20 scope, regular unicast space or any other 6to4 addresses, must be =20 discarded. (Also note that as with any other external facing interface, it is =20 always prudent to filter out packets that come in with source addresses =20= that are known to be internal.) "The disallowed addresses include those defined in [13], and others widely used and known not to be global." I strongly object to the fact that all kinds of filtering is =20 expected/mandated without justification. Filtering isn't free; it =20 should only be done if there is a compelling benefit. For instance, =20 while it is perfectly fine if operators choose to filter RFC 1918 =20 source addresses, it would be a mistake to mandate that implementations =20= do this automatically as implementations must handle packets coming =20 from non-existing sources anyway so the need to get rid of a known =20 subsection of these is debatable, which means the user must be able to =20= make the tradeoff. "6.2 Anyone Pretending to Be a 6to4 Relay Even though this was already discussed in Section 4.1.2, it bears some additional elaboration as it was the only problem which cannot be even partially solved." And then the draft goes on to try and solve it, the cure being worse =20 than the disease as it breaks 6to4 as it exists today. Our efforts =20 would be much better spent by moving people to native IPv6 or at least =20= configured tunnels. Then most 6to4 issues go away. "o Every dual-stack site (or even ISP) would be required to have their own 6to4 relay." What about IPv6-only parts of the network? From owner-v6ops@ops.ietf.org Mon Mar 1 10:18: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 KAA01033 for ; Mon, 1 Mar 2004 10:18:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axp8B-0001Yt-IE for v6ops-data@psg.com; Mon, 01 Mar 2004 15:14:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axp86-0001XE-6n for v6ops@ops.ietf.org; Mon, 01 Mar 2004 15:14:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i21FEfd06129; Mon, 1 Mar 2004 17:14:41 +0200 Date: Mon, 1 Mar 2004 17:14:41 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-6to4-security-01.txt In-Reply-To: <4D7E370C-6B69-11D8-9DA7-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.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 a lot of good comments. I didn't know which of the comments were commentary in genreal, or where you were proposing a different text. That is, it wasn't always clear what you were expecting the text to be. But I'll try to address the issues the best way I can... On Mon, 1 Mar 2004, Iljitsch van Beijnum wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security > > -01.txt > > Comments: > > "The 6to4 specification outlined quite a few security considerations, > but it has been shown that in practice some of them have been > difficult to get implemented due to their abstract nature." > > How do you implement a consideration? And what exactly are you > referring to? This is from RFC 3056: The the text you quoted below, and then some more: > "In any case, any 6to4 traffic whose source or destination address > embeds a V4ADDR which is not in the format of a global unicast > address MUST be silently discarded by both encapsulators and > decapsulators. Specifically, this means that IPv4 addresses defined > in [RFC 1918], broadcast, subnet broadcast, multicast and loopback > addresses are unacceptable." And: By default, 6to4 traffic will be accepted and decapsulated from any source from which regular IPv4 traffic is accepted. If this is for any reason felt to be a security risk (for example, if IPv6 spoofing is felt to be more likely than IPv4 spoofing), then additional source address based packet filtering could be applied. A possible plausibility check is whether the encapsulating IPv4 address is consistent with the encapsulated 2002:: address. If this check is applied, exceptions to it must be configured to admit traffic from relay routers (Section 5). 2002:: traffic must also be excepted from checks applied to prevent spoofing of "6 over 4" traffic [6OVER4]. > I don't find this particularly abstract, and apparently implementers > didn't have much trouble with it either, this is from FreeBSD: > > # netstat -rnf inet6 [..] The reject routes that are automatically installed only handle *encapsulation*, not *decapsulation* (which is done in the stf pseudointerface on BSD). The decapsulation part, is by far the most troublesome one. In short, the reject route is only preventing your site from doing harm or misconfiguration, but does not protect you from misuse. > The draft talks about "6to4 routers" without specifying what those are. > This confusing, as many systems that run 6to4 don't act as routers. RFC3056 specifies them, and it's a normative reference: 6to4 router (or 6to4 border router): an IPv6 router supporting a 6to4 pseudo-interface. It is normally the border router between an IPv6 site and a wide-area IPv4 network. This also includes (with some wiggling) the "host" problem. Functionally, the description of '6to4 router' should be change "an IPv6 router" in above to "in IPv6 node". > "If the 6to4 router established a BGP session between all the possible > 6to4 relays," > > This is of course both insane scalability-wise Certainly, this has some serious issues -- but at least today, there are about 27 or so relays in the network -- not that high a number, really. In the long run, this probably isn't a solution though. > and impossible in the > presence of RFC 3068 relays as anycasting isn't compatible with the use > of TCP. Nothing excludes such routers from having multiple addresses, and running the BGP sessions between those addresses. > "o Disallow traffic from 6to4 routers where the IPv4 tunnel source > address does not match the 6to4 prefix." > > Source or destination isn't specified. See discussion below. I don't see what's unclear here. The source address is the IPv4 source where you receive the 6to4 encapsulated traffic? > "The 6to4 router will also perform security checks on traffic that it > will receive from other 6to4 relays, or 6to4 routers, or from within > the 6to4 site. These checks include:" > > Is this the current situation? If so, where is it specified? If not, is > this draft specifying that this must be done? There is no > justification. Yes, this should be the current situation. It's stated in the security considerations, and this is just continuation of the checks described there. The whole reason for this document in the first place was to re-write the security considerations to be actually useful. If 6to4 is revised, these are probably clarified a LOT. > "o Disallow traffic transmission to other 6to4 domains through 6to4 > relay router or via some third party 6to4 router. > > o Discard traffic received from other 6to4 domains via a 6to4 relay > router." > > I believe older versions of Linux did this as they were unable to > properly tunnel to other 6to4 routers or hosts directly. No, this has never been done on Linux. I seem to recall this issue, but that it was caused by something else altogether. > "o Disallow traffic from 6to4 routers where the IPv4 tunnel source > address does not match the 6to4 prefix." > > Is it mandated that only the host holding the corresponding IPv4 > address may tunnel packets with 6to4 IPv6 addresses? Yes. >It is conceivable > that due to internal routing issues packets may flow over an > alternative 6to4 router in sites that use more than one. Yep, it's conceivable. "Don't do that." > "o Disallow traffic where the destination IPv6 address is not a > global address; in particular, e.g. link-local addresses, mapped > addresses and such should not be used. Note, this check might be > incorrect if 6to4 were to be used." > > Huh??? This last sentence doesn't compute. True. Must be an editing glitch from the major overhaul. Will remove. > "o Discard traffic received from 6to4 routers with the destination as > a 6to4 prefix." > > Reuse your code. Sorry, I didn't get your point? > "This section describes attacks against 6to4 networks. Attacks which > legerate 6to4 networks" > > "Legerate" isn't an English word. "Leverage", maybe? Yep. > "It is possible to conduct a variety of attacks on the 6to4 nodes. > These attacks are: > > 1. Attacks with Neighbor Discovery (ND) Messages" > > Finally, but not before page 12, something that isn't blatantly > obvious. The first pages are a better introduction to 6to4 that 6to4 spec is currently h > However, there is no description of how such an attack would > work and what bad stuff would be the result. There's some 4.1.1, but the more elaborate version was removed AFAIR. Will add back. > "The attacker - a malicious IPv4 or IPv6 node - can send packets with > spoofed source address to a 6to4 node to accomplish a DoS attack." > > It isn't clearly specified what kind of DoS attack. What I get from the > discussion below this is that third party hosts reachable over 6to4 can > be used to hide the identity of the attacker, but the sentence above > seems to indicate something very different. Yep, the description of the attack should certainly be more descriptive. > "4.1.4 Local IPv4 Broadcast Attack" > > This is covered in the original RFC and it's handled appropriately in > at least the FreeBSD implementation. (I can tell you it works too - I > accidentally messed up my subnet mask at some point so that my IP > address was a broadcast address and 6to4 wouldn't work.) So why are we > talking about this? It's an important example of a check AFAIK only very few implement -- only, it isn't described clearly enough that it shouldn't exist if the current spec was followed :) > "6to4 relays have only one significant security check they must > perform for general safety: when decapsulating IPv4 packets, check > that 2002:V4ADDR::/48 and V4ADDR match." > > Are we talking about the source addresses here? Yep. > I don't believe it is a > requirement that packets arriving over 6to4 must have an IPv4 source > address that matches the 6to4 source address. Well, you could mince words over this but RFC 3056 sect 5.3 states along the lines of: ADDITIONAL DECAPSULATION RULE for 6to4 routers [MUST] apply any security checks (see Section 8); where sect 8 meant to refer to security considerations, but the section itself is immensely vague what the actual required checks are. As said, the current 6to4 spec from security POV is pretty .. bad quality. > However, it may be > reasonable to impose such a requirement, but in that case it must be > spelled out such that it's impossible to miss so that implementers and > operators know it. If we revise 6to4 spec, that's certainly number 1 consideration. But this doc is meant as a "security update" -- isn't it enough? > But I think it's meaningless anyway as an attacker > then simply spoofs both source addresses. Sure, but that's a different threat. > "6to4 relay should not relay packets between 6to4 addresses." > > Again, reuse your code. It's worse than useless to talk about the same > thing twice in the same document. See above for my objections. This is grinding it in, slowly, by inches, so that everyone understands what this means. It didn't seem to be clear from the first, so just saying it once would probably lead to misunderstandings and missing the point. > "4.2.1 Attacks with ND Messages > > These attacks are the same as employed against 6to4 routers as > described in Section 4.1.1." > > Then why talk about it again??? This is just one sentence. For completeness. > Note that this isn't just me being > annoyed over wasting time reading the same thing: having the same thing > in a specification more than once is also a great way to introduce > errors in new versions of documents and in implementations (speaking > from painful experience here). I can certainly agree that duplication is problematic in many aspects, but here we aren't actually doing any duplication, just referring to the problem mentioned in the referred section. Or maybe you were commenting on general, e.g., 4.2.2 vs 4.1.2 or the like. The threats are indeed similar, but the prevuous input -- leading to restructuring the document -- was that the different cases should be separate. > As a more general note: the draft spends too much time discussing > things that are "not really useful", taking away focus from stuff that > we need to do something about. They are there for the completeness. > It would probably be useful to separate three aspects of the problem, > possibly to the degree of having separate documents: > > - 6to4 end-user issues > - 6to4 relay operator issues > - implementation issues I think the last one is already explained in a bit of detail, but I agre that the first two are not explicitly described as a "target audience". Attacks are separated between whether they are targeted at 6to4 or native v6 (or v4) networks. > "1. Usage of access lists in the relay to limit access." > > Announcing reachability to 2002::/16 and 192.88.99.1 and then deploy > filters is inappropriate, as it can lead to black holes if the routing > information leaks beyond what the relay expects. Since whether this > happens is beyond the direct control of the relay operator, this can > easily happen. So either the relay should be prepared to handle > unexpected traffic or it shouldn't announce those routes outside its > AS. If you read the following header, it said: Attempts to use the relay's IPv4 address instead of 192.88.99.1 can be mitigated in the following ways: Such access lists would just concern those that do not use 192.88.99.1. > Alternatively, we may want to rethink the prohibition on announcing > more specifics for 2002::/16 as this is an effective way to limit > access to a relay. Well, this has been pointed out in other contexts, before, but with little traction. Folks didn't want the v6 routing table to include v4 as well :-). The policy is supposed to be ensured by limiting the visibility of the route using some other mechanisms. (e.g., not exporting it anywhere, or sending it with no-export). > "Such attacks can easily be thwarted by implementing protocol-41 > filtering in IPv4 nodes or sites that do not implement IPv6 over IPv4 > tunneling." > > This is either useless or dangerous. Useless in the case of hosts, > which already throw out packets for protocols they don't run, Well, it depends on whether you want to be seeing those packets in your logs or not (assuming that your zone-alarm or whatever barfs every time someone sends you bad packets). They're thrown out, with or without "ICMP protocol unreachable" message back. > and > dangerous in the case of sites, because it makes it impossible to do > any kind of IPv6inIP tunneling, defeating the purpose of transition > mechanisms. True, which is IMHO this is probably a bad tradeoff -- which should be made clearer. > "4.4 Summary of the Attacks" > > Skipping this part, see notes on duplication of content. I guess one can't please everyone. Better a slightly verbose, or terse to the point of being difficult to read if you are not a subject matter expert in the area. > Under "5.1 Encapsulating IPv6 into IPv4": > > "ipv4 address embedded in src_v6 MUST match src_v4" > > Either there is no IPv4 header so the check is meaningless or one has > just been added, so checking yourself is redundant. > > Dropping packets with non-6to4 source addresses is unacceptable, as > this creates black holes and isn't compatible with the practice of > setting up a private relay to have better connectivity towards 6to4 > hosts. Good catch! My co-author messed up that section by mistake :-). The correct one is like: src and dst MUST pass ipv6-sanity checks, else drop if src=2002 src MUST match src_v4 elif dst=2002 (accept) else drop fi accept this works in the case you describe as well :-) > "5.2 Decapsulating IPv4 into IPv6 > > The checks described in this section are to be performed when > decapsulating IPv4 into IPv6. They will be performed in both the > 6to4 router and relay." > > This isn't a good idea as regular 6to4 hosts and routers need to be > more restrictive than relays. To be more specific: in the case of a > 6to4 host or router the destination IPv6 address must be a 6to4 address > for which the corresponding IPv4 address is assigned to the host or > router. Any other destination address, be it multicast, non-global > scope, regular unicast space or any other 6to4 addresses, must be > discarded. The point is that the implementation does not, generally, know whether it's a router or relay -- that's decided by the routing table. Routers could probably have additional checks, but those are probably outside of the scope of this document -- those are probably quite similar to what you will want to configure in any of your border routers. > "The disallowed addresses include those defined > in [13], and others widely used and known not to be global." > > I strongly object to the fact that all kinds of filtering is > expected/mandated without justification. Filtering isn't free; it > should only be done if there is a compelling benefit. For instance, > while it is perfectly fine if operators choose to filter RFC 1918 > source addresses, it would be a mistake to mandate that implementations > do this automatically as implementations must handle packets coming > from non-existing sources anyway so the need to get rid of a known > subsection of these is debatable, which means the user must be able to > make the tradeoff. These are already specified by the 6to4 spec -- I don't see the reason for objection? > "6.2 Anyone Pretending to Be a 6to4 Relay > > Even though this was already discussed in Section 4.1.2, it bears > some additional elaboration as it was the only problem which cannot > be even partially solved." > > And then the draft goes on to try and solve it, the cure being worse > than the disease as it breaks 6to4 as it exists today. Yep, each proposal has its tradeoffs. Can't be helped. > Our efforts > would be much better spent by moving people to native IPv6 or at least > configured tunnels. Then most 6to4 issues go away. I certainly don't disagree with that, but some people are not complying. :-) > "o Every dual-stack site (or even ISP) would be required to have > their own 6to4 relay." > > What about IPv6-only parts of the network? That's the "end-game" case. Either there are (public) network relays, or those can't talk (if 6to4 is even used anymore). -- 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 Mar 1 10:29: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 KAA05915 for ; Mon, 1 Mar 2004 10:29:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxpKI-0003KU-27 for v6ops-data@psg.com; Mon, 01 Mar 2004 15:27:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxpD1-0002Fb-Bf for v6ops@ops.ietf.org; Mon, 01 Mar 2004 15:19:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i21FJo806180; Mon, 1 Mar 2004 17:19:50 +0200 Date: Mon, 1 Mar 2004 17:19:50 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: Marc Blanchet , Subject: RE: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.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 On Sun, 29 Feb 2004, Christian Huitema wrote: > > > 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. > > Actually, in the current design either all traffic will go on the direct > path, or no traffic will be exchanged at all. It is true that this is an all-traffic/no-traffic issue (the latter caused by a flavor of NATs). But aren't the latter ones, still, by definition Teredo nodes? > > > ... > > > 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. > > I agree that in the absence of automatic support through UPNP, DMZ > functions are indeed not your typical unmanaged service. But the point > is at least partially incorrect. First, it is possible in some cases to > use automatic procedures to "DMZ" a port (e.g., using the UPNP "internet > gateway device" service). Second, the procedure that absolutely work for > more than one node -- just pick a different port for each node. I'm not sure that UPNP is a solution we can be referring to. > In any case, the work done in the MIDCOM working group shows that the > number of symmetric NAT in the market is rapidly decreasing. See > draft-jennings-midcom-stun-results-00.txt Sigh -- replacing "secure" NAT boxes with "insecure" ones. Now I'm done -- I said "secure NAT"! :-) -- 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 Mar 1 10:33: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 KAA08042 for ; Mon, 1 Mar 2004 10:33:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxpO6-00040f-7v for v6ops-data@psg.com; Mon, 01 Mar 2004 15:31:22 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxpO1-000405-Ir for v6ops@ops.ietf.org; Mon, 01 Mar 2004 15:31:17 +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 i21FV6vI006411; Mon, 1 Mar 2004 10:31:07 -0500 (EST) Date: Mon, 01 Mar 2004 10:30:53 -0500 From: Marc Blanchet To: Pekka Savola , Christian Huitema cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt Message-ID: <137940000.1078155053@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 -- Monday, March 01, 2004 17:19:50 +0200 Pekka Savola wrote/a ecrit: > On Sun, 29 Feb 2004, Christian Huitema wrote: >> > > ... >> > > 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. >> >> I agree that in the absence of automatic support through UPNP, DMZ >> functions are indeed not your typical unmanaged service. But the point >> is at least partially incorrect. First, it is possible in some cases to >> use automatic procedures to "DMZ" a port (e.g., using the UPNP "internet >> gateway device" service). Second, the procedure that absolutely work for >> more than one node -- just pick a different port for each node. > > I'm not sure that UPNP is a solution we can be referring to. agree. unless I'm not aware, UPNP is not an IETF standard? > >> In any case, the work done in the MIDCOM working group shows that the >> number of symmetric NAT in the market is rapidly decreasing. See >> draft-jennings-midcom-stun-results-00.txt > > Sigh -- replacing "secure" NAT boxes with "insecure" ones. > Now I'm done -- I said "secure NAT"! :-) agree. - this argument of "most are not" does not go far to me. We are talking about a protocol proposal which is based on some proportion of market place and some internal behavior of devices that were never specified before implemented and that we don't know what is out there. In the case that these devices happen to exist (which is the case), the protocol proposal does not work. 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 Mon Mar 1 12:09:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22813 for ; Mon, 1 Mar 2004 12:09:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxqrX-000JSN-Ar for v6ops-data@psg.com; Mon, 01 Mar 2004 17:05:51 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxqrU-000JS6-CV for v6ops@ops.ietf.org; Mon, 01 Mar 2004 17:05:48 +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); Mon, 1 Mar 2004 09:05:47 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Mar 2004 09:05:48 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 09:06:00 -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); Mon, 1 Mar 2004 09:05:47 -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); Mon, 1 Mar 2004 09:05:46 -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: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt Date: Mon, 1 Mar 2004 09:04:24 -0800 Message-ID: Thread-Topic: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt thread-index: AcP/okHKRsPbkdxPQQGHJhrJNZafHQADE7Dg From: "Christian Huitema" To: "Marc Blanchet" , "Pekka Savola" Cc: X-OriginalArrivalTime: 01 Mar 2004 17:05:46.0791 (UTC) FILETIME=[707A0370:01C3FFAF] 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 agree that in the absence of automatic support through UPNP, DMZ > >> functions are indeed not your typical unmanaged service. But the point > >> is at least partially incorrect. First, it is possible in some cases to > >> use automatic procedures to "DMZ" a port (e.g., using the UPNP > "internet > >> gateway device" service). Second, the procedure that absolutely work > for > >> more than one node -- just pick a different port for each node. > > > > I'm not sure that UPNP is a solution we can be referring to. >=20 > agree. unless I'm not aware, UPNP is not an IETF standard? NAT is not an IETF standard either. On the other hand, the UPNP IGD spec is publicly available and can certainly be referenced in an informative section.=20 > >> In any case, the work done in the MIDCOM working group shows that the > >> number of symmetric NAT in the market is rapidly decreasing. See > >> draft-jennings-midcom-stun-results-00.txt > > > > Sigh -- replacing "secure" NAT boxes with "insecure" ones. > > Now I'm done -- I said "secure NAT"! :-) >=20 > agree. > - this argument of "most are not" does not go far to me. We are talking > about a protocol proposal which is based on some proportion of market > place > and some internal behavior of devices that were never specified before > implemented and that we don't know what is out there. In the case that > these devices happen to exist (which is the case), the protocol proposal > does not work. Look, we have shipped about 1M copies of Teredo already, and we are on a pace to make it available on every Windows XP PC. It certainly "works" in a large fraction of the cases, and this fraction is so large already that it creates expectations. Customers expect applications and video games to work; these applications are based on Teredo or similar technologies (e.g. STUN and variations of echo services); hence NAT vendors are busy upgrading their symmetric NAT to "port restricted" NAT, which are arguably just as secure but don't mess with the applications quite as much. -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Mar 1 14:22: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 OAA28885 for ; Mon, 1 Mar 2004 14:22:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axswm-000GAq-PG for v6ops-data@psg.com; Mon, 01 Mar 2004 19:19:24 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Axswl-000GAb-9s for v6ops@ops.ietf.org; Mon, 01 Mar 2004 19:19:23 +0000 Received: (qmail 31108 invoked by uid 417); 1 Mar 2004 19:19:22 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 1 Mar 2004 19:19:22 -0000 Received: from XPNERICK ([139.92.208.161]) by softhome.net with esmtp; Mon, 01 Mar 2004 12:19:14 -0700 Message-ID: <007f01c3ffc2$07d8e8a0$a1d05c8b@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: Subject: IPv6 Task Force: Feedback requested Date: Mon, 1 Mar 2004 21:18:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I thought I would pass this on for anyone that did not recieve it. ISOC Public Policy Activities IPv6 Task Force: Feedback requested The U.S. Department of Commerce has formed an IPv6 Task Force to study deployment issues. The Task Force is requesting comments from interested parties to comment on a variety of IPv6-related issues. Please see: The deadline for comments is March 8, 2004. ISOC hopes that its members will take advantage of this opportunity and provide comments. From owner-v6ops@ops.ietf.org Tue Mar 2 04:53: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 EAA29878 for ; Tue, 2 Mar 2004 04:53:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay6Vp-000ILa-8n for v6ops-data@psg.com; Tue, 02 Mar 2004 09:48:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay6Vk-000IKw-Ho for v6ops@ops.ietf.org; Tue, 02 Mar 2004 09:48:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i229mLF23414; Tue, 2 Mar 2004 11:48:21 +0200 Date: Tue, 2 Mar 2004 11:48:21 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: Work on MPLS and tunneling approaches in scenarios 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.7 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) At v6ops meeting on Monday, there seemed to be rough consensus that: - IPv6 in MPLS networks work is carried forward, (some objection) - "Opportunistic" tunneling work needs to go forward, (minor objection) - "Zero-configured" tunneling work needs to go forward. (unanimous) (Unfortunately, the latter two are a bit fuzzy concepts.) This is message is sent to verify the rough consensus in the WG. If you have objections, please raise them now. For those not attending, the slides of the presentation are temporarily available at: http:/www.netcore.fi/pekkas/ietf/temp/v6ops-mpls.pdf http:/www.netcore.fi/pekkas/ietf/temp/v6ops-tunneling.pdf (Sorry, no minutes yet.) From owner-v6ops@ops.ietf.org Tue Mar 2 10:01:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12711 for ; Tue, 2 Mar 2004 10:01:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyBLh-0000gA-4j for v6ops-data@psg.com; Tue, 02 Mar 2004 14:58:21 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyBLc-0000fQ-CF for v6ops@ops.ietf.org; Tue, 02 Mar 2004 14:58:16 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i22Ew6HI020146; Tue, 2 Mar 2004 14:58:06 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i22Ew9h0279338; Tue, 2 Mar 2004 15:58:09 +0100 Received: from zurich.ibm.com (sig-9-145-139-114.de.ibm.com [9.145.139.114]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA49188; Tue, 2 Mar 2004 15:58:02 +0100 Message-ID: <4044A11C.FD86A781@zurich.ibm.com> Date: Tue, 02 Mar 2004 15:58:36 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: Work on MPLS and tunneling approaches in scenarios References: 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 I would suggest that the chairs and ADs think for a few minutes about whether these items belong in v6ops or in an ad hoc WG (v6tuns?). Brian Pekka Savola wrote: > > Hi, > > (co-chair hat on) > > At v6ops meeting on Monday, there seemed to be rough consensus that: > > - IPv6 in MPLS networks work is carried forward, (some objection) > - "Opportunistic" tunneling work needs to go forward, (minor objection) > - "Zero-configured" tunneling work needs to go forward. (unanimous) > > (Unfortunately, the latter two are a bit fuzzy concepts.) > > This is message is sent to verify the rough consensus in the WG. If > you have objections, please raise them now. > > For those not attending, the slides of the presentation are > temporarily available at: > > http:/www.netcore.fi/pekkas/ietf/temp/v6ops-mpls.pdf > http:/www.netcore.fi/pekkas/ietf/temp/v6ops-tunneling.pdf > > (Sorry, no minutes yet.) -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-v6ops@ops.ietf.org Tue Mar 2 10:39:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15742 for ; Tue, 2 Mar 2004 10:39:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyBxS-0007KL-4b for v6ops-data@psg.com; Tue, 02 Mar 2004 15:37:22 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyBxL-0007G3-Rj for v6ops@ops.ietf.org; Tue, 02 Mar 2004 15:37:16 +0000 Received: from consulintel02 ([211.235.31.11]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 22-md50000000255.tmp for ; Tue, 02 Mar 2004 16:41:34 +0100 Message-ID: <072d01c4006c$cb4967b0$ade325da@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: IPv6 Distributed Security draft Date: Wed, 3 Mar 2004 00:41:00 +0900 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, Tue, 02 Mar 2004 16:41:34 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 211.235.31.11 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 all, We have uploaded the yesterday slides on this draft to = http://www.euro6ix.org/standardization/ipv6_security_ietf59.zip. The draft is also at = http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-ipv6security-00= .txt. Somebody commented in the mic something that I could not catch = completely. I hope he is the list or his name is captured in the = minutes, so he can provide exact pointers that I should look at. Thanks = in advance ! 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 Tue Mar 2 12:59:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21303 for ; Tue, 2 Mar 2004 12:59:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyE82-0007fY-T0 for v6ops-data@psg.com; Tue, 02 Mar 2004 17:56:26 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyE81-0007fA-Qc for v6ops@ops.ietf.org; Tue, 02 Mar 2004 17:56:25 +0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2004 10:02:55 +0000 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 i22Htp25022832; Tue, 2 Mar 2004 18:55:55 +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); Tue, 2 Mar 2004 17:56:19 +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: Work on MPLS and tunneling approaches in scenarios Date: Tue, 2 Mar 2004 17:56:18 -0000 Message-ID: Thread-Topic: Work on MPLS and tunneling approaches in scenarios Thread-Index: AcQAPGAT/K9fUpO1QfeBAij+d1x+FQAP6Wcg From: "Francois Le Faucheur (flefauch)" To: "Pekka Savola" , Cc: X-OriginalArrivalTime: 02 Mar 2004 17:56:19.0126 (UTC) FILETIME=[AA4D5D60:01C4007F] 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 Content-Transfer-Encoding: quoted-printable Hello Pekka, >> For those not attending, the slides of the presentation are >> temporarily available at: >>=20 http:/www.netcore.fi/pekkas/ietf/temp/v6ops-mpls.pdf http:/www.netcore.fi/pekkas/ietf/temp/v6ops-tunneling.pdf Your slides said: "bgp-tunnel relationship to Cisco 6PE is unclear" "bgp-tunnel" is generic and specifies several flavors of how to interconnect IPv6 island over an IPv4 cloud with BGP (eg. "MP-BGP over IPv4" as well as "MP-BGP over IPv6" , eg. "Tunneling over IPv4/GRE tunnels" as well as "Tunneling over MPLS LSPs"). Cisco 6PE implements one specific flavor of "bgp-tunnel" (eg. "MP-BGP over IPv4" using "Tunneling over MPLS LSPs"). It is compliant to the specification of that flavor in "bgp-tunnel". Let me know if anything is still unclear. Your slides said: "some think bgp-tunnel has some cruft in it and would need a cleanup" Because it specifies something for which there are multiple commercial implementations and multiple deployments in the field, the authors of bgp-tunnel have been trying very hard to get a WG home for this document in order to get feed-back on how to clean it up and finalise it. But the IETF decision was to hold onto that until the isp-scenario-analysis work is complete and identifies bgp-tunnel as a useful mechanism.=20 I understand that we will be able to discuss/progress bgp-tunnel in IETF (v6ops?) as soon as the isp-scenario-analysis document is completed. Do I understand the situation correctly? In the meantime, I'd like to invite folks who have identified cruft in bgp-tunnel to send comments on the list so we can start the potential cleanup process. Thanks Francois From owner-v6ops@ops.ietf.org Tue Mar 2 19:21:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12305 for ; Tue, 2 Mar 2004 19:21:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyK6A-000PIK-02 for v6ops-data@psg.com; Wed, 03 Mar 2004 00:18:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyK68-000PEy-Ac for v6ops@ops.ietf.org; Wed, 03 Mar 2004 00:18:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i230ITe04135; Wed, 3 Mar 2004 02:18:29 +0200 Date: Wed, 3 Mar 2004 02:18:29 +0200 (EET) From: Pekka Savola To: "Francois Le Faucheur (flefauch)" cc: v6ops@ops.ietf.org, Subject: BGPTUNNEL [RE: Work on MPLS and tunneling approaches in scenarios] 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.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 2 Mar 2004, Francois Le Faucheur (flefauch) wrote: > "bgp-tunnel" is generic and specifies several flavors of how to > interconnect IPv6 island over an IPv4 cloud with BGP (eg. "MP-BGP over > IPv4" as well as "MP-BGP over IPv6" , eg. "Tunneling over IPv4/GRE > tunnels" as well as "Tunneling over MPLS LSPs"). > > Cisco 6PE implements one specific flavor of "bgp-tunnel" (eg. "MP-BGP > over IPv4" using "Tunneling over MPLS LSPs"). It is compliant to the > specification of that flavor in "bgp-tunnel". At this point, I think there is only requirement on "6PE", i.e., MPLS LSPs. Other stuff could be specified in an extension document later on if needed. > Your slides said: > "some think bgp-tunnel has some cruft in it and would need a cleanup" > > Because it specifies something for which there are multiple commercial > implementations and multiple deployments in the field, the authors of > bgp-tunnel have been trying very hard to get a WG home for this document > in order to get feed-back on how to clean it up and finalise it. But the > IETF decision was to hold onto that until the isp-scenario-analysis work > is complete and identifies bgp-tunnel as a useful mechanism. > I understand that we will be able to discuss/progress bgp-tunnel in IETF > (v6ops?) as soon as the isp-scenario-analysis document is completed. Do > I understand the situation correctly? Yes, I think this is correct. Unless there are objections raised about WG rough consnsus call, we're going forward with this. The question is just where (formally) -- here, in a new WG or a routing area WG. This is currently being considered, but if a routing area WG would be willing to accept this, it would probably be best. I think we (the IETF in general, or v6ops in particilar) want to ship off the document to the IESG before the next IETF. > In the meantime, I'd like to invite folks who have identified cruft in > bgp-tunnel to send comments on the list so we can start the potential > cleanup process. Agreed --the first step would probably need to be to remove the other mechanisms than which "6PE" has, because we're only interested in that specific scenario (and possibly the case where the MPLS control plane has been upgraded to support IPv6 LSPs -- I don't know how this relates to BGPTUNNEL spec, though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Mar 2 19:26: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 TAA12711 for ; Tue, 2 Mar 2004 19:26:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyKBh-0000Rc-UM for v6ops-data@psg.com; Wed, 03 Mar 2004 00:24:37 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyKBd-0000Oi-Gs for v6ops@ops.ietf.org; Wed, 03 Mar 2004 00:24:33 +0000 Received: from consulintel02 ([218.37.227.173]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 58-md50000000269.tmp for ; Wed, 03 Mar 2004 01:27:49 +0100 Message-ID: <0aa201c400b6$4eb2b900$ade325da@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: IPv6 Overall Status document Date: Wed, 3 Mar 2004 09:27:23 +0900 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, Wed, 03 Mar 2004 01:27:49 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 218.37.227.173 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, We have published a new edition of a document that try to collect the = status of the different deployment activities in the world: http://www.ipv6tf-sc.org/html/public/ipv6tf-sc_pu_d3_4v1_3.pdf The document is being updated periodically (next review in 2 months), so = if you have any amendment, updated information, or proposal to add or = change something, please, let me know. Related web sites are http://www.ipv6tf.org, = http://www.ipv6tf.org/europe.php and http://www.eu.ipv6tf.org. Regards, Jordi PS: This is not an IETF activity, but I guess is interesting for this = group anyway. ********************************** 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 Mar 3 04:20:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13144 for ; Wed, 3 Mar 2004 04:20:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AySU3-000AYo-HY for v6ops-data@psg.com; Wed, 03 Mar 2004 09:16:07 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AySU2-000AYb-7n for v6ops@ops.ietf.org; Wed, 03 Mar 2004 09:16:06 +0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2004 01:22:47 +0000 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 i239Eq1x000398; Wed, 3 Mar 2004 10:15:36 +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); Wed, 3 Mar 2004 09:15:34 +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: BGPTUNNEL [RE: Work on MPLS and tunneling approaches in scenarios] Date: Wed, 3 Mar 2004 09:15:33 -0000 Message-ID: Thread-Topic: BGPTUNNEL [RE: Work on MPLS and tunneling approaches in scenarios] Thread-Index: AcQAtSAZUh5OLWtJRGC2MaNwxu/PDwASI8vw From: "Francois Le Faucheur (flefauch)" To: "Pekka Savola" Cc: , X-OriginalArrivalTime: 03 Mar 2004 09:15:34.0584 (UTC) FILETIME=[15845B80:01C40100] 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 Content-Transfer-Encoding: quoted-printable Hello Pekka, >> Agreed --the first step would probably need to be to remove the other >> mechanisms than which "6PE" has, because we're only=20 >> interested in that >> specific scenario Alright. >> (and possibly the case where the MPLS control plane >> has been upgraded to support IPv6 LSPs -- I don't know how this >> relates to BGPTUNNEL spec, though. =20 Use of IPv6 LSPs is already fully specified as part of the existing MPLS specs (LDP, RSVP-TE) and MP-BGP for IPv6. So bgp-tunnel need not be discussing that. The isp-scenario-analysis could refer to bgp-tunnel when mentioning "IPv6 over IPv4 MPLS" and could refer directly to the existing LDP/RSVP-TE/MP-BGP specs when mentioning "IPv6 LSPs". All the other points you mentioned sound good to me. Cheers Francois >> --=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 From owner-v6ops@ops.ietf.org Wed Mar 3 19:38:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10198 for ; Wed, 3 Mar 2004 19:38:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aygo3-000Gr7-Ei for v6ops-data@psg.com; Thu, 04 Mar 2004 00:33:43 +0000 Received: from [81.228.11.107] (helo=av1-1-sn1.fre.skanova.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aygo2-000Gqi-0P for v6ops@ops.ietf.org; Thu, 04 Mar 2004 00:33:42 +0000 Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 114E737EDD; Thu, 4 Mar 2004 01:33:41 +0100 (CET) Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id EE39237E4B; Thu, 4 Mar 2004 01:33:40 +0100 (CET) Received: from lord.fakat.com (h80n1fls302o1033.telia.com [81.226.50.80]) by smtp4.hy.skanova.net (8.12.11/8.12.11) with ESMTP id i240XeUm025196; Thu, 4 Mar 2004 01:33:40 +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 i240XQw5049525; Thu, 4 Mar 2004 01:33:26 +0100 (CET) (envelope-from jasko@fakat.com) Date: Thu, 4 Mar 2004 01:33:26 +0100 (CET) From: Jasminko Mulahusic To: Pekka Savola Cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: Work on MPLS and tunneling approaches in scenarios In-Reply-To: Message-ID: <20040304011202.G49173@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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > At v6ops meeting on Monday, there seemed to be rough consensus that: > > - IPv6 in MPLS networks work is carried forward, (some objection) > - "Opportunistic" tunneling work needs to go forward, (minor objection) > - "Zero-configured" tunneling work needs to go forward. (unanimous) > > (Unfortunately, the latter two are a bit fuzzy concepts.) > > This is message is sent to verify the rough consensus in the WG. If > you have objections, please raise them now. > i think we are moving a bit fast here. following would be a more reasonable way to go: 1/ finish scenario/analysis work. 2/ review the results of that work and see if there are any missing mechanisms. 3/ document those missing pieces along with their requirements, potential usage cases, etc. 4/ ask the wg/ad:s how/where to proceed. [and as brian pointed out, maybe a new wg might be a better place]. now, nobody has said that some of the above cannot be done i parallel, but doing 4/ without finishing 1/ first seems premature thing to do. imho. why such a hurry? jasminko From owner-v6ops@ops.ietf.org Wed Mar 3 21:06: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 VAA15591 for ; Wed, 3 Mar 2004 21:06:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyiDw-000D2p-Tw for v6ops-data@psg.com; Thu, 04 Mar 2004 02:04:32 +0000 Received: from [66.218.79.74] (helo=web80504.mail.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AyiDv-000D2a-Sr for v6ops@ops.ietf.org; Thu, 04 Mar 2004 02:04:31 +0000 Message-ID: <20040304020431.85028.qmail@web80504.mail.yahoo.com> Received: from [192.100.104.18] by web80504.mail.yahoo.com via HTTP; Wed, 03 Mar 2004 18:04:31 PST Date: Wed, 3 Mar 2004 18:04:31 -0800 (PST) From: Fred Templin Subject: Re: isatap-20 comments To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, Thanks for the comments. Sorry for the delay, but I arrived late at the IETF and this is my first opportunity to respond (see below): Fred L. Templin osprey67@yahoo.com --- Pekka Savola wrote: > [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) Agree that it is preferrable to pick up functionality from normative references whenever possible, but some documents are currently undergoing revision, i.e., a timing issue. > - IPv6 minimum MTU is kind of obvious, in appendix B (but it's in appendix > so it's not as big an issue) "Obvious" would seem to depend very much on the reader in this case; IMO, some readers will find this informative text useful. > 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 ?? The text says: "ISATAP interfaces are configured as advertising IPv6 interfaces". Not sure where you derive "default to forward between interfaces"? > 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?) The fragmentation/reassembly/MTU section provides considerations for avoiding harmful network-based IPv4 fragmentation, whereas other mechanisms tend to simply set LinkMTU to 1280 and congratulate themselves on a job well done. IMO, these considerations need to be spelled out somwehere. About address rewriting, it seems this will be necessary for NAT traversal. About MANET derivative work, need some more context to understand this. > 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 > [...] Perhaps a forward reference to section 9 would fix this? > 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. It seems there may be another document that already speaks to this; perhaps a reference to the other document would suffice? > 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. Suggestions? > 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.) Agree that important pieces of the spec are in section 7. Agree also on observing the normal custom and specifying MIB objects in another document. > 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. OK. > 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... Any suggestions on what to do with the figure? > +-------+-------+-------+-------+-------+-------+-------+--------+ > | 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.. OK. > 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.". OK. > ==> s/MAY/may/ ? OK. > 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. It seems that any assumption made today might be obsoleted tomorrow through operatonal practices. Prefer to leave this as-is. > 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. The implication is similar to the "weak/strong" end system model as defined by STD3 (referenced under "terminology"), i.e., it should be permissible to accept a packet from a neighbor even if it arrives on a different interface attached to the same site. > 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.. The meaning here is exactly the same as for RFC2827 IPv4 ingress filtering as specified in ([MECH], section 3.6), which is referenced normatively. > 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. As long as we also specify how RAs received on ISATAP interfaces are processed it should be OK - right? > FQDNs are established via manual configuration or an unspecified > alternate method. > > ==> might be pretty important for interop purposes. Suggestions? > 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. Agree. > 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/ OK. > See: Appendix C for additional non-normative details. > > ==> s/See:/See/ OK. > -- > 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 Mar 3 21:14: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 VAA16168 for ; Wed, 3 Mar 2004 21:14:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyiLn-000F4d-86 for v6ops-data@psg.com; Thu, 04 Mar 2004 02:12:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyiLl-000F47-Lz for v6ops@ops.ietf.org; Thu, 04 Mar 2004 02:12:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i242CTc29371; Thu, 4 Mar 2004 04:12:29 +0200 Date: Thu, 4 Mar 2004 04:12:29 +0200 (EET) From: Pekka Savola To: Jasminko Mulahusic cc: v6ops@ops.ietf.org, Subject: Re: Work on MPLS and tunneling approaches in scenarios In-Reply-To: <20040304011202.G49173@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.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 On Thu, 4 Mar 2004, Jasminko Mulahusic wrote: > following would be a more reasonable way to go: > > 1/ finish scenario/analysis work. > 2/ review the results of that work and see if there are any missing > mechanisms. > 3/ document those missing pieces along with their requirements, potential > usage cases, etc. Actually, the scenarios/analysis work is actually meant to capture all of that. For the specific case of IPv6 over MPLS, I think these have been explicitly documented in a lot of detail already. The others may need a bit improvement (which will be done in the revision of the documents), but these will elaborated a bit on today's session. This will be discussed at a lot of length in the session today. > 4/ ask the wg/ad:s how/where to proceed. [and as brian pointed out, maybe > a new wg might be a better place]. > > now, nobody has said that some of the above cannot be done i parallel, but > doing 4/ without finishing 1/ first seems premature thing to do. imho. why > such a hurry? People have been had to wait (more or less) for about 2 years or so, and aren't happy. We must hurry. The important thing is that the work gets done, which WG it will be at is secondary -- but that is being discussed. The analysis documents are much more useful to the audience if they in fact include the analysis. 3 of them are past WG last call already. Therefore, I'm quite confident that those can be finished within a month or so, and if we manage 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 Mar 4 01:59: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 BAA07130 for ; Thu, 4 Mar 2004 01:59:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aymma-000M8i-5D for v6ops-data@psg.com; Thu, 04 Mar 2004 06:56:36 +0000 Received: from [4.65.25.155] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AymmP-000M7I-OI for v6ops@ops.ietf.org; Thu, 04 Mar 2004 06:56:25 +0000 Received: from eaglet (127.0.0.1:4590) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 3 Mar 2004 23:00:04 -0800 From: "Tony Hain" To: Subject: discussion about document publishing Date: Wed, 3 Mar 2004 22:56:25 -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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcQBjxGS7TXiaSwWSdSA+Mxggj4jxAAJd0Mg X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 The point I was trying to raise at the mic was that we don't need to publish in parallel with the working group if the working group will simply publish the documents on the table. There still appears to be a desire to kill these transition tools. The BS about allowing them to be Experimental is nothing more than trying to duck the issue. I can't get back to the mic... WE DON'T HAVE TO MEASURE DEPLOYMENT FOR PS !!!! The mechanisms that solve the identified scenarios all need to be on the standards track. There is no need for delay and long evaluation. Tony From owner-v6ops@ops.ietf.org Thu Mar 4 02:22: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 CAA21620 for ; Thu, 4 Mar 2004 02:22:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ayn9W-000PZE-VB for v6ops-data@psg.com; Thu, 04 Mar 2004 07:20:18 +0000 Received: from [192.11.226.163] (helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ayn9M-000PXD-Bv for v6ops@ops.ietf.org; Thu, 04 Mar 2004 07:20:08 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247K4c12487 for ; Thu, 4 Mar 2004 01:20:05 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699LYCX>; Thu, 4 Mar 2004 08:20:02 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B64661@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Tony Hain , v6ops@ops.ietf.org Subject: RE: discussion about document publishing Date: Thu, 4 Mar 2004 08:20:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Tony Hain writes: > > The point I was trying to raise at the mic was that we don't > need to publish in parallel with the working group if the > working group will simply publish the documents on the table. > There still appears to be a desire to kill these > transition tools. The BS about allowing them to be > Experimental is nothing more than trying to duck the issue. > I believe that allowing them to be published as experimental or informational allows you to publish them ASAP. This to document CURRENT IMPLEMENTATIONs, not document current implementation plus extra things that might be implemented. > I can't get back to the mic... > WE DON'T HAVE TO MEASURE DEPLOYMENT FOR PS !!!! > Correct. > The mechanisms that solve the identified scenarios all need > to be on the standards track. > There is no need for delay and long evaluation. > We do need standards track solutions indeed. BUT, to come to consensus on which one (or maybe few) solutions should be on the standards track will probably take a somewhat long(er) time. If you prefer that, then that may be an alternative. Bert > Tony > > From owner-v6ops@ops.ietf.org Thu Mar 4 02:37: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 CAA23593 for ; Thu, 4 Mar 2004 02:37:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AynNV-0001e1-Qi for v6ops-data@psg.com; Thu, 04 Mar 2004 07:34:45 +0000 Received: from [4.65.25.155] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AynND-0001cm-44 for v6ops@ops.ietf.org; Thu, 04 Mar 2004 07:34:27 +0000 Received: from eaglet (127.0.0.1:3640) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 3 Mar 2004 23:38:06 -0800 From: "Tony Hain" To: "'Wijnen, Bert \(Bert\)'" , Subject: RE: discussion about document publishing Date: Wed, 3 Mar 2004 23:34:27 -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 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503B64661@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcQBuaV5mqZ2RfnxTWiP0spJSYhWaQAAB8XQ X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Wijnen, Bert wrote: > ... > > The mechanisms that solve the identified scenarios all need > > to be on the standards track. > > There is no need for delay and long evaluation. > > > We do need standards track solutions indeed. BUT, to come to consensus > on which one (or maybe few) solutions should be on the standards track > will probably take a somewhat long(er) time. If you prefer that, then > that may be an alternative. There will not be a one-size-fits-all transition mechanism. As Jordi described at the mic on Monday, a single laptop (like mine) might need all of them over the period of a single multi-city trip. I have no problem dropping mechanisms that do not fit in our scenarios. My issue is the apparent attempt to thwart the working group from progressing as standards the mechanisms that their customers are in fact using. This 'publish them as Experimental' approach is not about getting them progressing along the standards track. The only reason to keep them off the standards track is to only allow a working group doc out when it is ready for DS. That is not how we develop standards track documents. Tony From owner-v6ops@ops.ietf.org Thu Mar 4 03:05:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26684 for ; Thu, 4 Mar 2004 03:05:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aynof-0007fx-VS for v6ops-data@psg.com; Thu, 04 Mar 2004 08:02:49 +0000 Received: from [4.65.25.155] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AynoV-0007f3-8O for v6ops@ops.ietf.org; Thu, 04 Mar 2004 08:02:39 +0000 Received: from eaglet (127.0.0.1:3173) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 4 Mar 2004 00:06:19 -0800 From: "Tony Hain" To: Subject: RE: discussion about document publishing Date: Thu, 4 Mar 2004 00:02:40 -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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcQBuaV5mqZ2RfnxTWiP0spJSYhWaQAAB8XQAAE0LPA= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 The consensus call was somewhat bogus. The lead in discussion from the chair said we either publish as experimental or publish nothing. Clearly people will pick any opportunity to publish something, because they are frustrated with lack of progress. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Tony Hain > Sent: Wednesday, March 03, 2004 11:34 PM > To: 'Wijnen, Bert (Bert)'; v6ops@ops.ietf.org > Subject: RE: discussion about document publishing > > Wijnen, Bert wrote: > > ... > > > The mechanisms that solve the identified scenarios all need > > > to be on the standards track. > > > There is no need for delay and long evaluation. > > > > > We do need standards track solutions indeed. BUT, to come to consensus > > on which one (or maybe few) solutions should be on the standards track > > will probably take a somewhat long(er) time. If you prefer that, then > > that may be an alternative. > > There will not be a one-size-fits-all transition mechanism. As Jordi > described at the mic on Monday, a single laptop (like mine) might need all > of them over the period of a single multi-city trip. > > I have no problem dropping mechanisms that do not fit in our scenarios. My > issue is the apparent attempt to thwart the working group from progressing > as standards the mechanisms that their customers are in fact using. This > 'publish them as Experimental' approach is not about getting them > progressing along the standards track. The only reason to keep them off > the > standards track is to only allow a working group doc out when it is ready > for DS. That is not how we develop standards track documents. > > Tony From owner-v6ops@ops.ietf.org Thu Mar 4 03:14: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 DAA27435 for ; Thu, 4 Mar 2004 03:14:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aynxx-00094k-Hk for v6ops-data@psg.com; Thu, 04 Mar 2004 08:12:25 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aynxn-00093Y-0s for v6ops@ops.ietf.org; Thu, 04 Mar 2004 08:12:15 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2004 00:16:20 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i248CCxU017043 for ; Thu, 4 Mar 2004 03:12:12 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM99140; Thu, 4 Mar 2004 03:12:10 -0500 (EST) Message-Id: <4.3.2.7.2.20040304031106.02a54210@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Mar 2004 03:12:07 -0500 To: From: Ralph Droms Subject: RE: discussion about document publishing 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.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 Will the issues that we are voting on here in the v6ops WG meeting be taken to the v6ops mailing list for final resolution? - Ralph From owner-v6ops@ops.ietf.org Thu Mar 4 03:32: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 DAA28897 for ; Thu, 4 Mar 2004 03:32:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyoF2-000BNL-Qw for v6ops-data@psg.com; Thu, 04 Mar 2004 08:30:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyoEr-000BJU-R5 for v6ops@ops.ietf.org; Thu, 04 Mar 2004 08:29:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i248ThJ04204; Thu, 4 Mar 2004 10:29:43 +0200 Date: Thu, 4 Mar 2004 10:29:43 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: v6ops@ops.ietf.org Subject: RE: discussion about document publishing In-Reply-To: <4.3.2.7.2.20040304031106.02a54210@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 4 Mar 2004, Ralph Droms wrote: > Will the issues that we are voting on here in the v6ops WG meeting be taken > to the v6ops mailing list for final resolution? Yes. Pekka & Jonne From owner-v6ops@ops.ietf.org Thu Mar 4 03:35: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 DAA29005 for ; Thu, 4 Mar 2004 03:35:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyoIb-000Bto-9z for v6ops-data@psg.com; Thu, 04 Mar 2004 08:33:45 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyoIQ-000Brp-7Z for v6ops@ops.ietf.org; Thu, 04 Mar 2004 08:33:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i248XUC04334; Thu, 4 Mar 2004 10:33:30 +0200 Date: Thu, 4 Mar 2004 10:33:30 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org Subject: RE: discussion about document publishing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 4 Mar 2004, Tony Hain wrote: > The consensus call was somewhat bogus. The lead in discussion from the chair > said we either publish as experimental or publish nothing. I said basically, "publish with informational/experimental (plus caveats) or do something else which may be publish as e.g. PS, or not publish at all. > Clearly people will pick any opportunity to publish something, > because they are frustrated with lack of progress. (personal opinion only) Well, the WG seemed to require more analysis before making a decision, so let's hope we'll improve over time... That may not help in trying to move forward. -- 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 Mar 4 03:38: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 DAA29085 for ; Thu, 4 Mar 2004 03:38:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyoKv-000COg-4X for v6ops-data@psg.com; Thu, 04 Mar 2004 08:36:09 +0000 Received: from [218.37.229.202] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyoKk-000CNS-5H for v6ops@ops.ietf.org; Thu, 04 Mar 2004 08:35:58 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i248ZL8G006597 for ; Thu, 4 Mar 2004 17:35:21 +0900 (KST) Date: Thu, 04 Mar 2004 17:35:20 +0900 From: Florent Parent To: v6ops@ops.ietf.org Subject: comparaison grids presented in meeting Message-ID: <636210000.1078389320@blues.hexago.com> 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.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, Jonne, I presume you will publish the grids you presented during the wg meeting so people on the list will be able to comment on them? The information in them is suggestive at best and needs input from the community. Specially since they are used to conclude as to which transition tool fit the scenario documents. Thanks Florent From owner-v6ops@ops.ietf.org Thu Mar 4 11:38: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 LAA00961 for ; Thu, 4 Mar 2004 11:38:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyvoS-0005i7-Jq for v6ops-data@psg.com; Thu, 04 Mar 2004 16:35:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyvoB-0005fH-AX for v6ops@ops.ietf.org; Thu, 04 Mar 2004 16:34:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i24GYjl12632; Thu, 4 Mar 2004 18:34:46 +0200 Date: Thu, 4 Mar 2004 18:34:45 +0200 (EET) From: Pekka Savola To: Florent Parent cc: v6ops@ops.ietf.org Subject: Re: comparaison grids presented in meeting In-Reply-To: <636210000.1078389320@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.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 On Thu, 4 Mar 2004, Florent Parent wrote: > I presume you will publish the grids you presented during the wg meeting so > people on the list will be able to comment on them? Certainly. Might take a couple of days... From owner-v6ops@ops.ietf.org Thu Mar 4 21:32: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 VAA28936 for ; Thu, 4 Mar 2004 21:32:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Az544-000F4g-1Z for v6ops-data@psg.com; Fri, 05 Mar 2004 02:27:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Az53s-000F18-11 for v6ops@ops.ietf.org; Fri, 05 Mar 2004 02:27:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i252Raa21466; Fri, 5 Mar 2004 04:27:36 +0200 Date: Fri, 5 Mar 2004 04:27:36 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: isatap-20 comments In-Reply-To: <20040304020431.85028.qmail@web80504.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A couple of responses inline.. On Wed, 3 Mar 2004, Fred Templin wrote: > > 2) the specification (sect 7.4) appears to default to forward between > > interfaces -- was this intentional ?? > > The text says: "ISATAP interfaces are configured as advertising > IPv6 interfaces". Not sure where you derive "default to forward > between interfaces"? Seems like a pretty obvious implication, following RFC2461: 6.2. Router Specification [...] 6.2.2. Becoming An Advertising Interface The term "advertising interface" refers to any functioning and enabled multicast interface that has at least one unicast IP address assigned to it and whose corresponding AdvSendAdvertisements flag is TRUE. A router MUST NOT send Router Advertisements out any interface that is not an advertising interface. > > 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?) > > The fragmentation/reassembly/MTU section provides considerations for avoiding > harmful network-based IPv4 fragmentation, whereas other mechanisms tend to > simply set LinkMTU to 1280 and congratulate themselves on a job well done. > IMO, these considerations need to be spelled out somwehere. But is this document the right place to do so? > About MANET derivative work, need some more context to understand this. I meant, looking at the system in general ("advertising interface") etc. this seemed like to geared to solve some unspecified problems in MANET-like networks .. which would be a bad idea, because that is nt the goal of the mechanism (at least in the scope of v6ops). > > 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 > > [...] > > Perhaps a forward reference to section 9 would fix this? The problem is that you don't specify how to create an *authenticated* RA message. Creating a regular RA is probably straightforward enough, I think :) > > 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. > > It seems there may be another document that already speaks to this; > perhaps a reference to the other document would suffice? I am not aware of the existence of such a document. Maybe you should clarify what you're referring to? > > 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. > > Suggestions? Nothing specific at the moment. This would require a lot of consideration. I would avoid assuming site-traversal completely. > > 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... > > Any suggestions on what to do with the figure? Try to make it "less intense", by reducing the number of links, sites, lines, etc. -- simplicity is easier to understand. > > 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. > > It seems that any assumption made today might be obsoleted tomorrow > through operatonal practices. Prefer to leave this as-is. That is true enough -- such considerations would probably need to be separate from the body of the specification, e.g., in an operational considerations section, introduction or whatever. If we had multicast on the sites, we could have gone the way of 6over4 long time ago, and ISATAP would never probably even gotten started. And that was over 5 years ago. I don't think the situation has changed significantly :). > > 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. > > The implication is similar to the "weak/strong" end system model as > defined by STD3 (referenced under "terminology"), i.e., it should be > permissible to accept a packet from a neighbor even if it arrives > on a different interface attached to the same site. You mean the case where the peer uses IPv6 address X on its packet, but the IPv4 packet was sent over another interface whose address didn't match X? This seems like a rather complicated procedure from the security check POV. IMHO, it would probably be much easier to specify that when encapsulating, pick v4 address which matches the v6 address -- and if you want more of them, just add more ISATAP addresses (for each v4 address you want to use for ISATAP). > > 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.. > > The meaning here is exactly the same as for RFC2827 IPv4 ingress filtering > as specified in ([MECH], section 3.6), which is referenced normatively. I mean, do you mean like: - unicast reverse path forwarding, - filter out your own addresses (or some other bogus addresses), or - filtering out private addresses or whatever This seems to vary from time to time. Typically it should mean at least the first. Maybe MECH needs to be looked at as well, just to make sure what is meant here. > > 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. > > As long as we also specify how RAs received on ISATAP interfaces > are processed it should be OK - right? I personally don't think it makes sense to add special casing in the ND code for ISATAP, because ND processing those is not interface-specific, for this. This also has the problem of trying to get around the IPv6 specified requirements.. > > FQDNs are established via manual configuration or an unspecified > > alternate method. > > > > ==> might be pretty important for interop purposes. > > Suggestions? Sorry, I think I misread this. You're specifying that FQDN to be looked up must be specified manually. There's obviously no need for interop requirements here (as long as the implementation processes all the addresses returned, not just the one which happens to come first in getaddrinfo). On the other hand, to make this really useful, there would have to be a specific name to be looked up by default, but there are some dragons there -- and these kind of "automatic discovery" mechanisms need a lot of thought. -- 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 Mar 4 21:55: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 VAA29687 for ; Thu, 4 Mar 2004 21:55:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Az5SW-000KH7-Vo for v6ops-data@psg.com; Fri, 05 Mar 2004 02:53:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Az5SL-000KFb-R7 for v6ops@ops.ietf.org; Fri, 05 Mar 2004 02:52:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i252qOO21700; Fri, 5 Mar 2004 04:52:24 +0200 Date: Fri, 5 Mar 2004 04:52:24 +0200 (EET) From: Pekka Savola To: tcpm@ietf.org cc: v6ops@ops.ietf.org, Subject: TCP, multiple addresses and soft errors when connecting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all (mainly the TCP guys!), v6ops WG is in the process of documenting issues which are caused or made more severe by the introduction of IPv6. The document is draft-ietf-v6ops-v6onbydefault-01.txt TCP timeouts when connecting to a destination, but when the destination is unreachable (e.g., because you don't have global IPv6 routes, your first-hop router is not operational, the packets are sent on-link by default, etc.), TCP does not abort the connectivity (and try the next address quicker -- instead of waiting for the TCP timeout). The critical observation to make here is as IPv6 addresses are tried first (I'm simplifying; it's more complex than that), one must cycle through all the addresses, before trying with IPv4. However, IPv4 connections might still work! With TCP timeouts, this takes a lot of time --- and should be made quicker. There is going to be a WG last call on the document soon, aimed for Informational -- just for documenting the issues. The actual fixes (or not) would have to be done elsewhere (e.g., in TCPM WG ;-). Please provide feedback especially on the language used for TCP. (Below.) draft-ietf-v6ops-v6onbydefault-01.txt: ========== 2.3.1 TCP Implications In the case of a socket application attempting a connection via TCP, it would be unreasonable for the application to block even after the system has received notification that the destination address is unreachable via an ICMPv6 Destination Unreachable message. Following are some ways of solving TCP related delays associated with destination unreachability when ICMPv6 errors are generated. 2.3.1.1 TCP Connection Termination One solution is for TCP to abort connections in SYN-SENT or SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable message. [HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT abort connections when receiving ICMP Destination Unreachable messages that indicate "soft errors", where soft errors are defined as ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 (source route failed), and SHOULD abort connections upon receiving the other codes (which are considered "hard errors"). ICMPv6 didn't exist when that document was written, but one could extrapolate the concept of soft errors to ICMPv6 Type 1 codes 0 (no route to destination) and 3 (address unreachable), and hard errors to the other codes. Thus, it could be argued that a TCP implementation that behaves as suggested in this section is in conflict with [HOSTREQS]. When [HOSTREQS] was written, most applications would mostly only try one address when establishing communication with a destination. Not aborting a connection was a sane thing to do if re-trying a single address was a better alternative over quitting the application altogether. With IPv6, and especially on dual stack systems, destinations are often assigned multiple addresses (at least one IPv4 and one IPv6 address), and applications iterate through destination addresses when attempting connections. Since soft errors conditions are those that would entice an application to continue iterating to another address, TCP shouldn't make the distinction between ICMPv6 soft errors and hard errors when in SYN-SENT or SYN-RECEIVED state. It should abort a connection in those states when receiving any ICMPv6 Destination Unreachable message. When in any other state, TCP would behave as described in [HOSTREQS]. Many TCP implementations already behave this way, but others do not. This should be noted as a best current practice in this case. A tangential method of handling the problem in this way would be for applications to somehow notify the TCP layer of their preference in the matter. An application could notify TCP that it should abort a connection upon receipt of particular ICMPv6 errors. Similarly, it could notify TCP that it should not abort a connection. This would allow existing TCP implementations to maintain their status quo at the expense of increased application complexity. 2.3.1.2 Asynchronous Application Notification In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism for reporting soft TCP error conditions to the application. Such a mechanism (assuming one is implemented) could be used by applications to cycle through destination addresses. =========== -- 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 Mar 5 21:53: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 VAA13464 for ; Fri, 5 Mar 2004 21:53:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzRqp-0002j6-Mp for v6ops-data@psg.com; Sat, 06 Mar 2004 02:47:43 +0000 Received: from [66.218.79.73] (helo=web80503.mail.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AzRqe-0002hc-D7 for v6ops@ops.ietf.org; Sat, 06 Mar 2004 02:47:32 +0000 Message-ID: <20040306024732.773.qmail@web80503.mail.yahoo.com> Received: from [63.197.18.101] by web80503.mail.yahoo.com via HTTP; Fri, 05 Mar 2004 18:47:32 PST Date: Fri, 5 Mar 2004 18:47:32 -0800 (PST) From: Fred Templin Subject: Re: isatap-20 comments To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1749336390-1078541252=:99929" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1749336390-1078541252=:99929 Content-Type: text/plain; charset=us-ascii Pekka, Thanks for the valuable input and will give it the appropriate consideration in determining the best way forward. Will respond in more detail as soon as possible. Fred osprey67@yahoo.com Pekka Savola wrote: A couple of responses inline.. On Wed, 3 Mar 2004, Fred Templin wrote: > > 2) the specification (sect 7.4) appears to default to forward between > > interfaces -- was this intentional ?? > > The text says: "ISATAP interfaces are configured as advertising > IPv6 interfaces". Not sure where you derive "default to forward > between interfaces"? Seems like a pretty obvious implication, following RFC2461: 6.2. Router Specification [...] 6.2.2. Becoming An Advertising Interface The term "advertising interface" refers to any functioning and enabled multicast interface that has at least one unicast IP address assigned to it and whose corresponding AdvSendAdvertisements flag is TRUE. A router MUST NOT send Router Advertisements out any interface that is not an advertising interface. > > 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?) > > The fragmentation/reassembly/MTU section provides considerations for avoiding > harmful network-based IPv4 fragmentation, whereas other mechanisms tend to > simply set LinkMTU to 1280 and congratulate themselves on a job well done. > IMO, these considerations need to be spelled out somwehere. But is this document the right place to do so? > About MANET derivative work, need some more context to understand this. I meant, looking at the system in general ("advertising interface") etc. this seemed like to geared to solve some unspecified problems in MANET-like networks .. which would be a bad idea, because that is nt the goal of the mechanism (at least in the scope of v6ops). > > 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 > > [...] > > Perhaps a forward reference to section 9 would fix this? The problem is that you don't specify how to create an *authenticated* RA message. Creating a regular RA is probably straightforward enough, I think :) > > 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. > > It seems there may be another document that already speaks to this; > perhaps a reference to the other document would suffice? I am not aware of the existence of such a document. Maybe you should clarify what you're referring to? > > 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. > > Suggestions? Nothing specific at the moment. This would require a lot of consideration. I would avoid assuming site-traversal completely. > > 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... > > Any suggestions on what to do with the figure? Try to make it "less intense", by reducing the number of links, sites, lines, etc. -- simplicity is easier to understand. > > 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. > > It seems that any assumption made today might be obsoleted tomorrow > through operatonal practices. Prefer to leave this as-is. That is true enough -- such considerations would probably need to be separate from the body of the specification, e.g., in an operational considerations section, introduction or whatever. If we had multicast on the sites, we could have gone the way of 6over4 long time ago, and ISATAP would never probably even gotten started. And that was over 5 years ago. I don't think the situation has changed significantly :). > > 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. > > The implication is similar to the "weak/strong" end system model as > defined by STD3 (referenced under "terminology"), i.e., it should be > permissible to accept a packet from a neighbor even if it arrives > on a different interface attached to the same site. You mean the case where the peer uses IPv6 address X on its packet, but the IPv4 packet was sent over another interface whose address didn't match X? This seems like a rather complicated procedure from the security check POV. IMHO, it would probably be much easier to specify that when encapsulating, pick v4 address which matches the v6 address -- and if you want more of them, just add more ISATAP addresses (for each v4 address you want to use for ISATAP). > > 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.. > > The meaning here is exactly the same as for RFC2827 IPv4 ingress filtering > as specified in ([MECH], section 3.6), which is referenced normatively. I mean, do you mean like: - unicast reverse path forwarding, - filter out your own addresses (or some other bogus addresses), or - filtering out private addresses or whatever This seems to vary from time to time. Typically it should mean at least the first. Maybe MECH needs to be looked at as well, just to make sure what is meant here. > > 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. > > As long as we also specify how RAs received on ISATAP interfaces > are processed it should be OK - right? I personally don't think it makes sense to add special casing in the ND code for ISATAP, because ND processing those is not interface-specific, for this. This also has the problem of trying to get around the IPv6 specified requirements.. > > FQDNs are established via manual configuration or an unspecified > > alternate method. > > > > ==> might be pretty important for interop purposes. > > Suggestions? Sorry, I think I misread this. You're specifying that FQDN to be looked up must be specified manually. There's obviously no need for interop requirements here (as long as the implementation processes all the addresses returned, not just the one which happens to come first in getaddrinfo). On the other hand, to make this really useful, there would have to be a specific name to be looked up by default, but there are some dragons there -- and these kind of "automatic discovery" mechanisms need a lot of thought. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --0-1749336390-1078541252=:99929 Content-Type: text/html; charset=us-ascii
Pekka,
 
Thanks for the valuable input and will give it the appropriate consideration
in determining the best way forward. Will respond in more detail as soon
as possible.
 
Fred
osprey67@yahoo.com

Pekka Savola <pekkas@netcore.fi> wrote:
A couple of responses inline..

On Wed, 3 Mar 2004, Fred Templin wrote:
> > 2) the specification (sect 7.4) appears to default to forward between
> > interfaces -- was this intentional ??
>
> The text says: "ISATAP interfaces are configured as advertising
> IPv6 interfaces". Not sure where you derive "default to forward
> between interfaces"?

Seems like a pretty obvious implication, following RFC2461:

6.2. Router Specification
[...]
6.2.2. Becoming An Advertising Interface

The term "advertising interface" refers to any functioning and
enabled multicast interface that has at least one unicast IP address
assigned to it and whose corresponding AdvSendAdvertisements flag is
TRUE. A router MUST NOT send Router Advertisements out any interface
that is not an advertising interface.

> > 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?)
>
> The fragmentation/reassembly/MTU section provides considerations for avoiding
> harmful network-based IPv4 fragmentation, whereas other mechanisms tend to
> simply set LinkMTU to 1280 and congratulate themselves on a job well done.
> IMO, these considerations need to be spelled out somwehere.

But is this document the right place to do so?

> About MANET derivative work, need some more context to understand this.

I meant, looking at the system in general ("advertising interface")
etc. this seemed like to geared to solve some unspecified problems in
MANET-like networks .. which would be a bad idea, because that is nt
the goal of the mechanism (at least in the scope of v6ops).

> > 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
> > [...]
>
> Perhaps a forward reference to section 9 would fix this?

The problem is that you don't specify how to create an *authenticated*
RA message. Creating a regular RA is probably straightforward enough,
I think :)

> > 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.
>
> It seems there may be another document that already speaks to this;
> perhaps a reference to the other document would suffice?

I am not aware of the existence of such a document. Maybe you should
clarify what you're referring to?

> > 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.
>
> Suggestions?

Nothing specific at the moment. This would require a lot of
consideration. I would avoid assuming site-traversal completely.

> > 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...
>
> Any suggestions on what to do with the figure?

Try to make it "less intense", by reducing the number of links, sites,
lines, etc. -- simplicity is easier to understand.

> > 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.
>
> It seems that any assumption made today might be obsoleted tomorrow
> through operatonal practices. Prefer to leave this as-is.

That is true enough -- such considerations would probably need to be
separate from the body of the specification, e.g., in an operational
considerations section, introduction or whatever.

If we had multicast on the sites, we could have gone the way of 6over4
long time ago, and ISATAP would never probably even gotten started.
And that was over 5 years ago. I don't think the situation has
changed significantly :).

> > 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.
>
> The implication is similar to the "weak/strong" end system model as
> defined by STD3 (referenced under "terminology"), i.e., it should be
> permissible to accept a packet from a neighbor even if it arrives
> on a different interface attached to the same site.

You mean the case where the peer uses IPv6 address X on its packet,
but the IPv4 packet was sent over another interface whose address
didn't match X? This seems like a rather complicated procedure from
the security check POV. IMHO, it would probably be much easier to
specify that when encapsulating, pick v4 address which matches the v6
address -- and if you want more of them, just add more ISATAP
addresses (for each v4 address you want to use for ISATAP).

> > 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..
>
> The meaning here is exactly the same as for RFC2827 IPv4 ingress filtering
> as specified in ([MECH], section 3.6), which is referenced normatively.

I mean, do you mean like:
- unicast reverse path forwarding,
- filter out your own addresses (or some other bogus addresses), or
- filtering out private addresses or whatever

This seems to vary from time to time. Typically it should mean at
least the first. Maybe MECH needs to be looked at as well, just to
make sure what is meant here.

> > 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.
>
> As long as we also specify how RAs received on ISATAP interfaces
> are processed it should be OK - right?

I personally don't think it makes sense to add special casing in the
ND code for ISATAP, because ND processing those is not
interface-specific, for this. This also has the problem of trying to
get around the IPv6 specified requirements..

> > FQDNs are established via manual configuration or an unspecified
> > alternate method.
> >
> > ==> might be pretty important for interop purposes.
>
> Suggestions?

Sorry, I think I misread this. You're specifying that FQDN to be
looked up must be specified manually. There's obviously no need for
interop requirements here (as long as the implementation processes all
the addresses returned, not just the one which happens to come first
in getaddrinfo). On the other hand, to make this really useful, there
would have to be a specific name to be looked up by default, but there
are some dragons there -- and these kind of "automatic discovery"
mechanisms need a lot of thought.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--0-1749336390-1078541252=:99929-- From owner-v6ops@ops.ietf.org Sat Mar 6 00:52: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 AAA19127 for ; Sat, 6 Mar 2004 00:52:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzUfQ-000D2Z-Rv for v6ops-data@psg.com; Sat, 06 Mar 2004 05:48:08 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzHgt-000JXz-EA for v6ops@ops.ietf.org; Fri, 05 Mar 2004 15:56:47 +0000 Received: from consulintel02 ([211.235.19.99]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 36-md50000000070.tmp for ; Fri, 05 Mar 2004 17:01:41 +0100 Message-ID: <38da01c402cb$1278cda0$c0e625da@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , , References: <0aa201c400b6$4eb2b900$ade325da@consulintel.es> Subject: Re: IPv6 Overall Status document Date: Sat, 6 Mar 2004 01:01:03 +0900 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, Fri, 05 Mar 2004 17:01:41 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 211.235.19.99 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, I forgot to mention something ... We try to keep posted the latest IPv6 news, every day, at = http://www.ist-ipv6.org. You can subscribe to the list with mailto:mdaemon@ist-ipv6.org?subject=3Dsubscribe&BODY=3Dsubscribe = ipv6cluster@ist-ipv6.org. So if you know about anything or have anything to announce, related to = IPv6, please let me know ! By the way, congratulations to our NTT/Verio friends ! (see = http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Dartic= le&sid=3D412). Regards, Jordi PS: Same disclaimer ... this is not an IETF activity, but I guess is = interesting for this group anyway. ----- Original Message -----=20 From: "JORDI PALET MARTINEZ" To: Sent: Wednesday, March 03, 2004 9:27 AM Subject: IPv6 Overall Status document Hi, We have published a new edition of a document that try to collect the = status of the different deployment activities in the world: http://www.ipv6tf-sc.org/html/public/ipv6tf-sc_pu_d3_4v1_3.pdf The document is being updated periodically (next review in 2 months), so = if you have any amendment, updated information, or proposal to add or = change something, please, let me know. Related web sites are http://www.ipv6tf.org, = http://www.ipv6tf.org/europe.php and http://www.eu.ipv6tf.org. Regards, Jordi PS: This is not an IETF activity, but I guess is interesting for this = group anyway. ********************************** 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. ********************************** 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. ********************************** 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 Mar 8 08:06: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 IAA29458 for ; Mon, 8 Mar 2004 08:06:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0KMx-0002k9-GZ for v6ops-data@psg.com; Mon, 08 Mar 2004 13:00:31 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0KMm-0002eq-Gg for v6ops@ops.ietf.org; Mon, 08 Mar 2004 13:00:20 +0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2004 05:08:38 +0000 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 i28Cx625006742; Mon, 8 Mar 2004 13:59:48 +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, 8 Mar 2004 13:00:11 +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: comparaison grids presented in meeting Date: Mon, 8 Mar 2004 13:00:10 -0000 Message-ID: Thread-Topic: comparaison grids presented in meeting Thread-Index: AcQCBzMpgsM3gR3GQV+WnWoYgMWlVADE85lw From: "Pascal Thubert (pthubert)" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 08 Mar 2004 13:00:11.0522 (UTC) FILETIME=[4A76A620:01C4050D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka: I was not too surprised after your reaction on the ML that you did not include Doors in that comparison grid. Not that I found that only fair, but I agree that IP is a pain when it comes to standards. In the other hand it's more and more the normal life of companies these days and we'll have to cope with this one way or another. Anyway I can try and see with the lawyers about the terms for that one, if there's at least a little chance to raise interest on standardizing Doors.=20 I understand that you think the same about Nemo since it's also encumbered. On the other hand, ISPs I met with were quite interested in the concept of using Nemo to deploy managed IPv6 networks such as Home and SOHO. The key is that when you have subscribers by the million(s), you'd prefer not renumber them when they move, be it every 10 years. Also, there's the concept of the preconfigured branch office network that can be tested by IT and deployed as is using Nemo. So Nemo could actually help a lot in making IPv6 networks pervasive, and a feature like doors in that context is quite compelling to make it deployable today. So yes, I get positive feedback from early experimentations on Japan, the US and Europe. And yes, we are pretty serious about that feature. Anything we could do to move forward or will you just drop it flat? Pascal > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: jeudi 4 mars 2004 17:35 > To: Florent Parent > Cc: v6ops@ops.ietf.org > Subject: Re: comparaison grids presented in meeting >=20 > On Thu, 4 Mar 2004, Florent Parent wrote: > > I presume you will publish the grids you presented during the wg meeting so > > people on the list will be able to comment on them? >=20 > Certainly. Might take a couple of days... >=20 >=20 From owner-v6ops@ops.ietf.org Mon Mar 8 08:20: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 IAA29889 for ; Mon, 8 Mar 2004 08:20:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0KdV-0007xn-FR for v6ops-data@psg.com; Mon, 08 Mar 2004 13:17:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Kd1-0007je-R8 for v6ops@ops.ietf.org; Mon, 08 Mar 2004 13:17:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i28DH6e22425; Mon, 8 Mar 2004 15:17:06 +0200 Date: Mon, 8 Mar 2004 15:17:06 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: huitema@microsoft.com Subject: huitema-v6ops-teredo-01 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.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I did a rather thorough reading of Teredo-01 on the plane. Comments below... substantial ----------- 1) sect 5.2.1, qualification procedure seems to yield either cone NAT, restricted cone NAT or symmetric NAT. What about port-restricted cone NATs? Are these implicitly covered in some terminology here? They don't seem to be explicitly mentioned anywhere! 2) security considerations should discuss that MD5 is not anymore considered "secure" due to better collision-resistance of SHA1. However, in this specific case, I don't think this is a huge problem. 3) I think this document seriously needs an "overview" section, around section 4, which could be e.g. 2-4 pages, trying to summarize the whole operation while leaving out the details with figures, etc. -- whatever appropriate. The spec is rather compact and requires careful reading to understand its implications. Having such a section (as there was before, but it was removed, I think) would be very useful for those who want to get a good overview of how the mechanism works. 4) what's the implementation status? to what degree do the implementation(s) reflect the current spec? I have a few thoughts for improvements if certain parts of the spec would not be implemented yet (e.g., the authentication encapsulation), but if they are, making such changes might not be feasible. 5) an interesting deployment model could be deploying a Teredo-cognizant tunnel broker at the teredo anycast address, basically "hijacking" all the teredo users as your tunnel broker customers -- requiring no tunnel broker implementations at the client side. This would be a rather interesting way to leverage the existing implementations to provide tunnel broker service :-). 6) this doc probably needs a bit more applicability etc. work but that's something that can be inserted a bit later on as well. semi-editorial/substatial ------------------------- Abstract We propose here a service that enables nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays"; the Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. ==> the last sentence is not accurate when you take also the "6to4 universe" into account -- needs rewording somehow? A possible way to solve the problem is to rely on a set of "tunnel brokers." There are however limits to any solution that is based on such brokers: the quality of service is not very good, since the traffic follows a "dog leg" route from the source to the broker and then the destination; the broker has to provide sufficient transmission capacity to relay all packets and thus suffers a high cost. For these two reasons, we tend to prefer solutions that allow for "automatic tunneling", i.e. let the packets follow a direct path to the destination. ==> I'd reword this to a bit softer, because tunnel brokers are actually useful in some contexts: ==> s/is not very good/may be limited/ ==> s/we tend to prefer/it may be desirable to have/ 2.8 Teredo service port The port through which the Teredo client sends Teredo packets. This port is attached to one of the client's IPv4 interfaces. The IPv4 address may or may not be globally routable, as the client may be located behind one or several NAT. ==> ports are not attached to interfaces. They may be attached to addresses only. So, maybe rename "Teredo service port" to "Teredo service address/port" or whatever, and reword the text a bit? Experience shows that the implementers of NAT devices can adopt widely different treatments of UDP mappings: ==> if this has been analyzed at more length elsewhere, I'd refer to that work for additional information. Later in the document, RFC3489 is cited as one source, at least. 3) Instead of keeping just a list of authorized hosts, some NAT implementations keep a list of authorized host and port pairs. UDP packets coming from remote addresses are rejected if the internal host has not yet sent traffic to the outside host and port pair. The NATs are often called "port-restricted cone NATs" ==> I've always had problems figuring out what this means. I suggest adding a new second-to-last sentence: That is, as long as the internal host has communicated with a (host, port) pair, the created NAT mapping (to some other host or port) can be used to inject incoming packets to the internal host. 3.2.1 When to use Teredo? Teredo is designed to robustly enable IPv6 traffic through NATs, and the price of robustness is a reasonable amount of overhead, due to UDP encapsulation and transmission of bubbles. Nodes that want to connect to the IPv6 Internet SHOULD only use the Teredo service as a "last resort" option: they SHOULD prefer using direct IPv6 connectivity if it is locally available or if it is provided by a 6to4 router co-located with the local NAT, and they SHOULD prefer using the less onerous "6to4" encapsulation if they can use a global IPv4 address. ==> this doesn't yet describe tunnel service (details TBD at the moment) at all -- it is also a preferable choice. 4 Teredo Addresses ==> I'd consider separating this to two subsection, global and link-local addresses -- as these seem to have slightly different characteristics. - The bits indicated with "z" must be set to zero. ==> s/set to zero/sent as zero and ignored on receipt/ ? The Teredo relay advertises reachability of the Teredo service prefix over IPv6. It forwards Teredo IPv6 packets to the appropriate IPv4 address and UDP port. ==> local relays don't do the first. This has been ignored in a few other places in the document as well. The following 16 bits contain the obfuscated value of the port number from which the packet was received, in network byte order. The next 32 bits contain the obfuscated IPv4 address from which the packet was received, in network byte order. In this format, both the original "IPv4 address" and "UDP port" of the client are obfuscated. Each bit in the address and port number is reversed; this can be done by an exclusive OR of the 16-bit port number with the hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF. For example, if the original UDP port number was 337 (hexadecimal 0151) and original IPv4 address was 1.2.3.4 (hexadecimal: 01020304), the origin indication would contain the value "0000FEAEFEFDFCFB". ==> this obfuscation code has been described in two places -- maybe it would make sense to put it in a subsection or something, so it could be referred to more easily when it's used later on in the draft? The third octet indicates the length of the client identifier; the fourth octet indicates the length of the authentication value. ==> is zero client ID OK as well? The same about authentication value? (these could be useful if you'd only want "return routability" like anonymous testing, where you'd only want to use nonces. ==> these octets give the length in the units of bytes, correct? (make explicit) In accordance with [RFC2461], the default time-out value is set to T=4 seconds, and the maximum number of repetitions is set to N=3. ==> this seems quite long, and I don't see how RFC2461 relates here. Maybe e.g. T=2, N=1 would be sufficient? option. This prefix should be a valid Teredo IPv6 server prefix: the first 32 bits should contain the global Teredo IPv6 service prefix, and the next 32 bits should contain the server's IPv4 address. If this is the case, the client learns the Teredo mapped address and ==> "global" --> remove that, could be local as well? If the client has received an RA with the "Cone" bit set to 1, it is behind a cone NAT and is fully qualified. If the RA is received with the Cone bit set to 0, the client does not know whether the local NAT is restricted or symmetric. The client selects a secondary IPv4 server address, and repeats the procedure, the cone bit remaining to the value zero. ==> there are multiple places where Cone bit can be set, so maybe reword like: If the client has received an RA with the "Cone" bit in the advertised prefix set to 1, it is behind a cone NAT and is fully qualified. If the RA is received with the Cone bit in the advertised prefix set to 0, the client does not know whether the local NAT is restricted or symmetric. The client selects a secondary IPv4 server address, and repeats the procedure, the cone bit in the link-local address remaining to the value zero. .... indication. The cone bit should be set to the value used to receive the RA, i.e. 1 if the client is behind a cone NAT, 0 otherwise. The ==> s/to receive the RA/in the RA/ ? Or am I confused about cone bit in the prefix vs. link-local address? When a UDP packet is received over the Teredo service port, the Teredo client checks that it is encoded according to the packet encoding rules defined in 5.1.1, and that it contains either a valid IPv6 packet as specified in [RFC2460], ==> you must spell out what exactly to check, as RFC2460 does not specify what is a "valid IPv6 packet". The same happens a lot later in the spec as well. if an origin indication is present, the client should perform the "direct IPv6 connectivity test" described in section 5.2.9. ==> should you use more uppercase keywords, e.g., in here, but in several other places as well? If the values match, the packet should be accepted; the date and time of the last reception from the peer should be updated. ==> s/should be/is/ ? 2) If there is an entry for the source IPv6 address in the list of peers whose status is not trusted, the client checks whether the packet is an ICMPv6 echo reply. If this is the case, and if the content of the reply matches the "nonce" stored in the peer entry, the packet should be accepted; ==> s/content/ICMPv6 data/ any packet queued for this IPv6 peer should be de-queued and forwarded to the newly learned IPv4 address and UDP port. ==> add a pointer to 5.2.4 around queuing? 4) If the source IPv6 address is a Teredo address, and the mapped IPv4 address and mapped port in the source address do not match the source IPv4 address and source port of the packet, the client checks whether the is an existing "local" entry for that IPv6 address. If there is such an entry, and if the local IPv4 address and local port indicated in that entry match the source IPv4 address and source port of the packet, the client updates the "local" entry, whose status should be set to "trusted". If the packet is a bubble, it should be discarded after this processing; otherwise, the packet should be accepted. In all cases, the client must de-queue and forward any packet queued for that destination. ==> and what if there is no such entry? do nothing? 5) If the IPv4 destination address through which the packet was received is the Teredo IPv4 Discovery Address, the source address is ==> add a note here stating that this procedure is optional. 2) If the destination is not a Teredo IPv6 address, the packet is queued, and the client performs the "direct IPv6 connectivity test" described in section 5.2.8. The packet will be de-queued and ==> s/5.2.8/5.2.9/ 5.2.6 Sending Teredo Bubbles ==> this section should also discuss "indirect bubbles" (as introduced in 5.2.4) and how they're sent. the client MUST create a new list entry for the address, setting the last reception date and the last transmission date to 30 seconds before the current date, and the number of bubbles to zero. ==> umm.. why exactly are you setting the dates to 30 seconds in the history?? The secondary port MUST NOT be used for any other purpose than the interval determination procedure. If a spurious packet is received on the secondary port, the client SHOULD repeat the maintenance procedure on this port and reset the date and time of the last interaction on the secondary port. ==> umm,, this would seem to hint at an implementation technique, where you'd be continously listening at the secondary port. I fail to see the need for that -- this is only done when you start up Teredo (if it's implemented that is). Rather, just specify that the port is closed when the procedure ends? A Teredo client who wishes to enable local discovery SHOULD wait for discovery bubbles to be received on the Teredo IPv4 Discovery Address, and should send local discovery bubbles to the Teredo IPv4 Discovery Address at random intervals ==> which -- wait _or_ send? Or both? Make it more explicit. Maybe just say that one should join the group. - IPv6 source: the Teredo IPv6 address of the sender ==> is this the global or link-local address? 5.3 Teredo Server specification ==> you should really add text here describing the forwarding of ICMPv6 probes, and bubbles between Teredo and non-Teredo nodes. ==> also, you should mention the requirement about the secondary address on the server. Upon reception of a packet on the Teredo port, the Teredo server will first check that the UDP payload contains a valid IPv6 packet; if this is not the case, the packet will be silently discarded. Before processing the packet, the Teredo server MUST check the validity of the encapsulated IPv6 source address, the IPv4 source address and the UDP source port: 1) If the UDP content is not a well formed IPv6 packet, the packet MUST be silently discarded. ==> isn't the first paragraph unnecessary, compared to 1)? ==> you don't define well-formed? 2) If the UDP packet is not a bubble or an ICMPv6 message, it should be discarded. ==> should probably add a pointer for the definition of a bubble. ==> should you use upper-case keywords in a place like this? 4) If the IPv6 source address is an IPv6 link-local address, the IPv6 destination address is the link-local scope all routers multicast address (FF02::2), and the packet contains an ICMPv6 Router Solicitation message, the packet SHOULD be accepted; it MUST be discarded if the server requires secure qualification and the authentication encapsulation is absent or cannot be verified. ==> SHOULD be accepted? What's the alternative -- discard them? Shouldn't this be a mandatory part? (Same later in 5) and 6) ==> s/cannot be verified/verification fails/ ? The Teredo server will then check the IPv6 destination address of the encapsulated IPv6 packet. ==> s/./:/ ==> maybe the following paragraphs should be similarly separated to 1), 2) and 3) for clarity? If the IPv6 destination address is a valid Teredo IPv6 address, the Teredo Server MUST check that the IPv4 address derived from this IPv6 address is in the format of a global unicast address ==> a link-local address is also a valid Teredo address, right? But not applicable here? Maybe needs spelling out which specific address type? If the destination IPv6 address is a Teredo client whose address is serviced by this specific server, the server should insert an origin indication in the first bytes of the UDP payload, as specified in section 5.1.1. ==> how can the server know which addresses it's supposed to be servicing? Or are you really saying, "if received through the Teredo interface.." ? The IPv6 source address should be set to a Teredo link-local server address associated to the local interface. ==> how exactly did you form the LL address on the server? What about the C-bit? However, Teredo relays do not have to perform the qualification procedure. [...] In cases 2 and 3, the Teredo relay should create a peer entry for the IPv6 address; the entry status is marked as trusted in case 2 (cone NAT), not trusted in case 3. In case 3, if the Teredo relay happens to be located behind a non-cone NAT, it should also send a bubble directly to the mapped IPv4 address and mapped port number of the Teredo destination; this will "open the path" for the return bubble from the Teredo client. ==> aren't these in conflict? The relay don't know which NAT it's behind unless it has run qualification procedure? 1) If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the mapped IPv4 address and mapped UDP port of the entry. The client updates the date of last transmission in the peer entry. ==> hmm.. could the list of peers information be stale, or is it purged often enough so that if the NAT mapping of a host changes, there won't be communication with it directly? Are there fallbacks? Then, the Teredo relay examines whether the IPv6 source address is a valid Teredo address, and if the mapped IPv4 address and mapped port match the IPv4 source address and port number from which the packet is received. If this is not the case, the packet is silently discarded. ==> I've trouble figuring out how this would work -- maybe I'm confused. I mean, when the Teredo client sends toward different IPv4 destination addresses, new mappings are created in the NAT for each -- and this is by definition different from the one which is learned by the Teredo client from the Teredo Server? Finally, the relay examines the destination IPv6 address. If the destination is the "all nodes multicast address", the packet should be processed locally. ==> why this rule? The dual-role of server and relays implies an additional complexity for the programming of servers: the processing of incoming packets should be a combination of the server processing rules defined in 5.3.1, and the relay processing rules defined in 5.4.2. ==> this text is not clear enough on whether section 5.3 on Teredo servers already includes all the functionalitty required of Teredo servers + relays, or whether you need to combine 5.3+5.4 to get server+relay? Most Teredo servers will not be expected to operate more than a few years, perhaps until at most 2006. ==> umm, isn't this awfully optimistic? :) The very purpose of the Teredo service is to make a machine reachable through IPv6. By definition, the machine using the service will give up whatever "firewall" service was available in the NAT box; all services declared locally will become potential target of attacks from the entire IPv6 Internet. This may sound scary, but there are three mitigating factors. ==> "all services declared locally" is a bit short, maybe spell it out? Maybe also missing a word or two? The first mitigating factor is the possibility to restrict some services to only accept traffic from one of the limited address scopes defined in IPv6, e.g. link-local or site-local. ==> using link-locals w/ apps is IMHO pretty bad practice, and site-locals are gone. please update :) There is no support for such scopes in Teredo, which implies that limited-scope services will not be accessed through Teredo, and will be restricted to whatever other IPv6 connectivity may be available, e.g. direct traffic with neighbors on the local link, behind the NAT. ==> these also have teredo addresses, which go through the teredo server, etc. -- not from the same namespace, unless you configure them manually or using some other process.. The third mitigating factor, already noted, is the availability of end-to-end connectivity, which allows for deployment of IP security services such as IKE, AH or ESP. Using these services in conjunction with Teredo is a good policy, as it will protect the client from possible attacks in intermediate servers such as the NAT, the Teredo server, or the Teredo relay. ==> when you use these magic keywords, one must always ask, "OK, how do you do key distribution?" Not practical in many cases, I guess. Meta-issue here: opportunistic IPsec might leverage DNS records for storing the keys; I think Teredo doesn't support setting reverse DNS records at the moment. (Which maybe for the best, considering how often the addresses would probably change..) The goal of the Teredo service is to provide hosts located behind a NAT with a globally reachable IPv6 address. There is a possible class of attacks against this service in which an attacker somehow intercepts the router solicitation, responds with a spoofed router advertisement, and provides a Teredo client with an incorrect address. ==> actually, a more typical attack would be the attacker guessing the server address (simple if there are only a few of those), and the IPv4 address/port of the destination. Then, by appropriate spoofing, a RA could be injected without getting hold of the RS's. Of course, this is practically impossible if the Authentication option (just using the nonces is enough) is included. The secure qualification procedure described in section 5.2.2 enables a good protection against attacks in which a third party tries to spoof the server. ==> how would that secret (if you don't use just nonces) is distributed? Especially if the server is hosted by someone you don't have a direct relationship with, you could be in trouble.. protect against this attack, the secret shared between client and server should be provisioned by an automatic procedure and contain sufficient entropy. ==> what are you referring to with "automatic procesdure"? 1) automatic distribution, or 2) automatic generation of secrets (trying ot ensure they have good enough entropy, e.g., are subject to e.g., disctionary attacks) ? ==> I'd again want to note, that using null ID and null authentication, could still give you the 64bit protection using nonces -- which is not bad for a use case like this. ==> the authentication encapsulation does not provide replay protection, at least as specified, but some of this could be fixed I guess? 1) Client prepares router solicitation, including authentication header. ==> s/header/encapsulation/ (or something, to make sure this is not IPsec AH) 7.3.2 Denial of service by exceeding the number of peers A Teredo client manages a cache of recently-used peers, which makes it stateful. ==> this is a problem of Teredo relay as well, right? The ICMP Traceback (ITRACE) working group is considering systems for "tracing" the source of DOS attacks. According to the proposal, when forwarding packets, routers can, with a low probability, generate a Traceback message that is sent along to the destination; with enough Traceback messages from enough routers along the path, the traffic source and path can be determined. This set up assumes that the source and destination are both using the same version of IP. In the Teredo case, the ICMP Traceback packets will be sent to the Teredo server, not the final destination. It is conceivable to "map" the IPv4 traceback to an IPv6 traceback sent by the Teredo server; the details of the solution should be specified by the ITRACE working group. ==> unfortunately, the ITRACE WG was closed, and the spec is pretty much dead.. so I don't think we can count on this anymore. (The same issue later in the spec again) The exit strategy is facilitated by the nature of Teredo, which provides an IP level solution. IPv6 aware applications do not have to be updated to use or not use Teredo. The absence of impact on the applications makes it easier to migrate out of Teredo: network connectivity suffices. ==> The clients migrate out of Teredo, that's correct, but the actual problem is how do you retire (host-side, "local") relays? As long as there are Teredo hosts out there (10 years from now on?) having such a feature on the box would be useful (with some definition of useful). What's the exit strategy for these? editorial --------- We propose here a service that enables nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity by tunneling packets ==> s/one or several/one or more/ (isn't this the more common usage) ? (this is in very many places) several NATs; it also supposes that we can find a way to bypass the various "per destination protections" that many NATs implement. In ==> add a reference here to section 3.1? The specification is organized as follow. Section 2 contains the ==> s/follow/follows/ 2.1 Teredo service ==> 16 subsections, none of which is longer than 1 paragraph, one for each term -- they explode the ToC. Maybe remove the subsections and put these in the body of section 2, otherwise identically? A node that has some access to the IPv4 Internet and that wants to gain access to the IPv6 Internet. ==> remove redundant "that" (the same in a few other examples as well) ? 2.10 Teredo mapped address and Teredo mapped port A global IPv4 address and a UDP port that results from the translation by one or several NATs of the IPv4 address and UDP port of a client's Teredo service port. ==> suggest rewording e.g. to be like: 2.10 Teredo mapped address and Teredo mapped port A global IPv4 address and a UDP port that result from the translation of the client's IPv4 address and Teredo service port by one or more NATs. ... of 30 seconds; a longer value may be determined by local tests, described in section 5. ==> s/described/as described/ Relaying packets over TCP would be possible, but would result in a very poor quality of service; relaying over UDP is a better choice. ==> s/relaying/encapsulation/ on the specified port for a "lifetime" period. The Teredo client that want to maintain a mapping open in the NAT will have to send ==> s/want/wants/ when no traffic is observed is observed on the connection for a ==> remove extra "is observed" transition schemes designed by the NGTRANS working group. This ==> v6ops now? - Client IPv4: the obfuscated "mapped IPv4 address" of a client ==> s/a client/the client/ There are thus two valid values of the Flags field: "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the cone bit is set to 1. ==> remove "valid" or even state like "two currently specified values" .. just to spell it out there might be more in the future. A third party sends IPv6 packets to a Teredo client by sending these packets over UDP to the mapped IPv4 address and port of the client if the cone bit is set, or if the third party has recently received direct traffic from the client. In the other cases, the third party will have to first synchronize with the client, by sending an initial bubble through the server. ==> this seems to be mostly outside the scope of Teredo address specification, so one should either remove it or add references to the fuller specification later on in the draft. 5.1.1 Teredo IPv6 packets encapsulation ==> s/packets/packet/ +--------+--------+--------+--------+ | 0x00 | 0x01 | ID-len | AU-len | +--------+--------+--------+--------+ | Client identifier (ID-len | +-----------------+-----------------+ | octets) | Authentication | +-----------------+--------+--------+ | value (AU-len octets) | Nonce | +--------------------------+--------+ | value (8 octets | +--------------------------+--------+ | | Conf. | +--------------------------+--------+ ==> I'd really try to aim for using the typical "nice" figures such as the the ones used in RFC2461, RFC2463, etc. the client may use the Teredo service port to transmit and receive IPv6 packets, according to the transmission and reception procedures; these procedures use the "list of recent peers". For each peer, the list contains: ==> s/; t/. T/ ? +----+----+ | Set C=1 | +----+----+ ==> make more explicit that C means Cone bit? /---------\ Timer | ^ |Starting |-------+ N attempts /----------\ Yes | \---------/------------------->| C == 1 ? |-----+ | Response \----------/ ==> does "N attempts" refer to moving from "Starting" to "Start", or to "C == 1?" state? Maybe reorganize the text a bit? /-----------------\ | Restricted NAT | \-----------------/ ==> restricted cone NAT you mean? When the interface is initialized, the system first performs the "start action" by sending a Router Solicitation message, as defined in [RFC2461]. The client picks a link-local address and uses it as the IPv6 source of the message; the "cone" bit in the address is set to 1; ==> maybe refer to sect 4? 3) If the source IPv6 address is a Teredo address, the client compares the mapped IPv4 address and mapped port in the source address with the source IPv4 address and source port of the packet. ==> s/source address/IPv6 source address/ ? and local peer port parameters to reflect the IPv4 source address and UDP source port of the bubble the last reception date to the ==> s/bubble/bubble,/ When it wants to send a packet to an IPv6 node on the IPv6 Internet, the client should check whether a valid peer entry already exists ==> swap "it" and "the client" here. destination. The ICMPv6 packet will then be sent encapsulated in a UDP packet bound to the local server IPv4 address, and to the Teredo port. The rules of section 5.2.3 specify how the reception of this packet will be processed. ==> s/bound/destined/ ? ==> s/local server IPv4/Teredo server/ ? ==> s/reception of/reply to/ ? It is in many cases possible to work around the limitations of these ==> s/It is in many cases/In many cases, it is/ ? - The source IPv4 address is the server's IPv4 address. ==> s/server's IPv4/Teredo server/ (same in a couple of other places) If the cone bit of the client's IPv6 address is set to 1, the RA must be sent from a different IPv4 source address than the server address over which the RS was received; if the cone bit is set to zero, the response must be sent back from the same address. ==> this has some operationa requirements (i.e., the server having more than one address), which should be spelled out (already commented for section 5.3) Teredo relays are IPv6 routers that advertise reachability of the Teredo service IPv6 prefix through the IPv6 routing protocols. ==> or not, in the case of local relays.. When a Teredo relay has to transmit a packet to a Teredo client, it examines the destination IPv6 address. By definition, the Teredo relays will only send over UDP IPv6 packets whose IPv6 destination address is a valid Teredo IPv6 address. Before processing these packets, the Teredo Server MUST check that the IPv4 destination ==> split a new paragraph before "Before" ? It may be desirable in some cases to deploy stateful tunnel servers instead of the stateless Teredo servers. Tunnels servers generally ==> s/Tunnels/Tunnel/ capacity. In summary, the attack is very hard to mount, and the gain for the attacker is minimal. ==> s/gain/additional gain/ ? its IPv6 traffic, using IPSEC. Even if the IPv4 and UDP headers are vulnerable, the use of IPSEC will effectively prevent spoofing and ==> s/IPSEC/IPsec/ (everywhere) 8.3.1 Denial of service by server spoofing In section 8.2, we discussed the use of spoofed router ==> s/8.3/7.3/, s/8.2/7.2/ ? non existing IPv4 address or to the IPv4 address of a third party. ==> s/non/non-/ 7.4.1 Laundering DOS attacks from IPv4 to IPv4 ==> s/DOS/DoS/ on their treatment of UDP; the mappings need to be continuously refreshed, while the ; and addressing structure may cause some hosts ==> something missing around ";" From owner-v6ops@ops.ietf.org Mon Mar 8 08:53: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 IAA00870 for ; Mon, 8 Mar 2004 08:53:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0L9x-000Iof-Oq for v6ops-data@psg.com; Mon, 08 Mar 2004 13:51:09 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0L9m-000IfX-BO for v6ops@ops.ietf.org; Mon, 08 Mar 2004 13:50:58 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i28DosS25203; Mon, 8 Mar 2004 15:50:54 +0200 (EET) X-Scanned: Mon, 8 Mar 2004 15:50:12 +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 i28DoCST009480; Mon, 8 Mar 2004 15:50:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00T66l0S; Mon, 08 Mar 2004 15:50:11 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 i28Do0715634; Mon, 8 Mar 2004 15:50:01 +0200 (EET) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Mar 2004 15:49:59 +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: comparaison grids presented in meeting Date: Mon, 8 Mar 2004 15:49:58 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195B1602F@esebe024.ntc.nokia.com> Thread-Topic: comparaison grids presented in meeting thread-index: AcQCBzMpgsM3gR3GQV+WnWoYgMWlVADE85lwAAG24BA= From: To: , Cc: X-OriginalArrivalTime: 08 Mar 2004 13:49:59.0259 (UTC) FILETIME=[3F4B22B0:01C40514] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, it seems that I have missed something. What is DOORS? Is there a draft = about it? Cheers, Jonne. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Pascal Thubert (pthubert) > Sent: 08 March, 2004 15:00 > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: RE: comparaison grids presented in meeting >=20 >=20 > Hi Pekka: >=20 > I was not too surprised after your reaction on the ML that you did not > include Doors in that comparison grid. Not that I found that=20 > only fair, > but I agree that IP is a pain when it comes to standards. In the other > hand it's more and more the normal life of companies these days and > we'll have to cope with this one way or another. >=20 > Anyway I can try and see with the lawyers about the terms for=20 > that one, > if there's at least a little chance to raise interest on standardizing > Doors.=20 >=20 > I understand that you think the same about Nemo since it's also > encumbered. On the other hand, ISPs I met with were quite=20 > interested in > the concept of using Nemo to deploy managed IPv6 networks such as Home > and SOHO. The key is that when you have subscribers by the million(s), > you'd prefer not renumber them when they move, be it every 10 years. > Also, there's the concept of the preconfigured branch office network > that can be tested by IT and deployed as is using Nemo. >=20 > So Nemo could actually help a lot in making IPv6 networks=20 > pervasive, and > a feature like doors in that context is quite compelling to make it > deployable today. So yes, I get positive feedback from early > experimentations on Japan, the US and Europe. And yes, we are pretty > serious about that feature. Anything we could do to move=20 > forward or will > you just drop it flat? >=20 > Pascal >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Pekka Savola > > Sent: jeudi 4 mars 2004 17:35 > > To: Florent Parent > > Cc: v6ops@ops.ietf.org > > Subject: Re: comparaison grids presented in meeting > >=20 > > On Thu, 4 Mar 2004, Florent Parent wrote: > > > I presume you will publish the grids you presented during the wg > meeting so > > > people on the list will be able to comment on them? > >=20 > > Certainly. Might take a couple of days... > >=20 > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Mar 8 13:14: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 NAA18001 for ; Mon, 8 Mar 2004 13:14:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0PDw-0001AV-QV for v6ops-data@psg.com; Mon, 08 Mar 2004 18:11:32 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0PDm-00015g-1n for v6ops@ops.ietf.org; Mon, 08 Mar 2004 18:11:22 +0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2004 10:19:44 +0000 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 i28IAp1v015698; Mon, 8 Mar 2004 19:10: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, 8 Mar 2004 18:11:19 +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: comparaison grids presented in meeting Date: Mon, 8 Mar 2004 18:11:18 -0000 Message-ID: Thread-Topic: comparaison grids presented in meeting Thread-Index: AcQCBzMpgsM3gR3GQV+WnWoYgMWlVADE85lwAAG24BAACW/s4A== From: "Pascal Thubert (pthubert)" To: , Cc: X-OriginalArrivalTime: 08 Mar 2004 18:11:19.0610 (UTC) FILETIME=[C182D1A0:01C40538] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jonne:=20 I proposed Doors to the WG last year, mid November (thread was RE: automatic tunneling and v6 interoperation). Doors builds on MIPv6 to build an automatic tunnel over IPv4, and uses addresses that are built after the 6to4 format though it could be otherwise. MIPv6 (or Nemo for that matter) does the bulk of the work, and Doors is just opportunistically using the states that MIPv6 installs at the HA to store the UDP encapsulation parameters. Doors goes through all forms of NATs, AFAIK. Actually, in the case of a nested Nemo, a single PAT state in the network covers the full nested cloud. I'm afraid that the draft has expired but it can still be found at the nemo site: http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ipv4-traver sal-01.txt=20 There's a lot more we could do like advertise a door gateway using DHCPv4 or IPv4CP, but I did not try and go that far since the base design is not a WG work item at this point. On the other hand, that left us some time to beta test Doors over a wide range of networks. This includes all forms of wireless phones on 3 continents and satellite (by NASA). Worked, as of now. Pascal > -----Original Message----- > From: Jonne.Soininen@nokia.com [mailto:Jonne.Soininen@nokia.com] > Sent: lundi 8 mars 2004 14:50 > To: Pascal Thubert (pthubert); pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: comparaison grids presented in meeting >=20 > Hello, >=20 > it seems that I have missed something. What is DOORS? Is there a draft about it? >=20 > Cheers, >=20 > Jonne. >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > > Behalf Of ext Pascal Thubert (pthubert) > > Sent: 08 March, 2004 15:00 > > To: Pekka Savola > > Cc: v6ops@ops.ietf.org > > Subject: RE: comparaison grids presented in meeting > > > > > > Hi Pekka: > > > > I was not too surprised after your reaction on the ML that you did not > > include Doors in that comparison grid. Not that I found that > > only fair, > > but I agree that IP is a pain when it comes to standards. In the other > > hand it's more and more the normal life of companies these days and > > we'll have to cope with this one way or another. > > > > Anyway I can try and see with the lawyers about the terms for > > that one, > > if there's at least a little chance to raise interest on standardizing > > Doors. > > > > I understand that you think the same about Nemo since it's also > > encumbered. On the other hand, ISPs I met with were quite > > interested in > > the concept of using Nemo to deploy managed IPv6 networks such as Home > > and SOHO. The key is that when you have subscribers by the million(s), > > you'd prefer not renumber them when they move, be it every 10 years. > > Also, there's the concept of the preconfigured branch office network > > that can be tested by IT and deployed as is using Nemo. > > > > So Nemo could actually help a lot in making IPv6 networks > > pervasive, and > > a feature like doors in that context is quite compelling to make it > > deployable today. So yes, I get positive feedback from early > > experimentations on Japan, the US and Europe. And yes, we are pretty > > serious about that feature. Anything we could do to move > > forward or will > > you just drop it flat? > > > > Pascal > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > > Behalf Of Pekka Savola > > > Sent: jeudi 4 mars 2004 17:35 > > > To: Florent Parent > > > Cc: v6ops@ops.ietf.org > > > Subject: Re: comparaison grids presented in meeting > > > > > > On Thu, 4 Mar 2004, Florent Parent wrote: > > > > I presume you will publish the grids you presented during the wg > > meeting so > > > > people on the list will be able to comment on them? > > > > > > Certainly. Might take a couple of days... > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Mon Mar 8 14:56:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24235 for ; Mon, 8 Mar 2004 14:56:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0Qnh-000KZq-5U for v6ops-data@psg.com; Mon, 08 Mar 2004 19:52:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0QnW-000KOe-4k for v6ops@ops.ietf.org; Mon, 08 Mar 2004 19:52:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i28JqFS28621; Mon, 8 Mar 2004 21:52:15 +0200 Date: Mon, 8 Mar 2004 21:52:15 +0200 (EET) From: Pekka Savola To: "Pascal Thubert (pthubert)" cc: Jonne.Soininen@nokia.com, Subject: Doors for IPv6 connectivity [RE: comparaison grids presented in meeting] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Mon, 8 Mar 2004, Pascal Thubert (pthubert) wrote: > MIPv6 (or Nemo for that matter) does the bulk of the work, and Doors is > just opportunistically using the states that MIPv6 installs at the HA to > store the UDP encapsulation parameters. Doors goes through all forms of > NATs, AFAIK. Actually, in the case of a nested Nemo, a single PAT state > in the network covers the full nested cloud. > > I'm afraid that the draft has expired but it can still be found at the > nemo site: > http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ipv4-traver > sal-01.txt Actually, I think this is conceptually similar to http://www.watersprings.org/pub/id/draft-soliman-v4v6-mipv4-00.txt -- just adding some IPv4 glue in the MIPv6 HA implementations to create a tunnel. My kneejerk reaction to that was, why not co-locate a tunnel server/broker implementation with the HA, and get around the issue without modifying MIPv6 (to include IPv4 specific components). After all, IPv6 connectivity in IPv4 networks (and NAT traversal) is a more generic problem than that. Actually, it's even better not to co-locate the v4 tunnel endpoint with IPv6 HA -- that way, if a tunnel endpoint close by, closer than the HA, there are some route optimization benefits. (This is the "mobility thoughts" topic which was discussed on Thursday session, and next a problem statement/scenario -like draft is probably going to be written.) Pascal, is there something obvious I missed when I glanced through your idea? -- 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 Mar 9 04:47: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 EAA17853 for ; Tue, 9 Mar 2004 04:47:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0dme-0002g0-8r for v6ops-data@psg.com; Tue, 09 Mar 2004 09:44:20 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0dmT-0002Yg-IC for v6ops@ops.ietf.org; Tue, 09 Mar 2004 09:44:09 +0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2004 01:52:43 +0000 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 i299hag8026542; Tue, 9 Mar 2004 10:43:36 +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); Tue, 9 Mar 2004 09:44:04 +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: Doors for IPv6 connectivity [RE: comparaison grids presented in meeting] Date: Tue, 9 Mar 2004 09:44:02 -0000 Message-ID: Thread-Topic: Doors for IPv6 connectivity [RE: comparaison grids presented in meeting] Thread-Index: AcQFRuNl5FRTi3CnSYiRXoqBFEDYywAgZMiw From: "Pascal Thubert (pthubert)" To: "Pekka Savola" Cc: , X-OriginalArrivalTime: 09 Mar 2004 09:44:04.0572 (UTC) FILETIME=[0F3A51C0:01C405BB] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka: I realize you already spent quite some time on this, on both the public and private sides. I do appreciate the quality and the consciousness of your work. =20 >=20 > On Mon, 8 Mar 2004, Pascal Thubert (pthubert) wrote: > > MIPv6 (or Nemo for that matter) does the bulk of the work, and Doors is > > just opportunistically using the states that MIPv6 installs at the HA to > > store the UDP encapsulation parameters. Doors goes through all forms of > > NATs, AFAIK. Actually, in the case of a nested Nemo, a single PAT state > > in the network covers the full nested cloud. > > > > I'm afraid that the draft has expired but it can still be found at the > > nemo site: > > http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ipv4-traver > > sal-01.txt >=20 > Actually, I think this is conceptually similar to > http://www.watersprings.org/pub/id/draft-soliman-v4v6-mipv4-00.txt -- > just adding some IPv4 glue in the MIPv6 HA implementations to create a > tunnel. >=20 Right. I pointed that to Hesham at the WG and he very well knows this. So does Ryuji (Wakikawa) who also works on something similar. Hesham's approach for MIP6 has 2 aspects, the careof can be v4 and the payload in the MIP6 tunnel can be v4. While I agree on the latter (for the time being because maybe one day the HA will not have IPv4 connectivity), I think (as you seem to do as well) that changing MIP6 to traverse IPv4 is unnecessary, and doors is an illustration of that. As opposed to using an IPv4 careof: - Doors builds an IPv6 careof and leaves MIP6 unchanged - Doors goes through NATs (which is just a MUST in my mind) > My kneejerk reaction to that was, why not co-locate a tunnel > server/broker implementation with the HA, and get around the issue > without modifying MIPv6 (to include IPv4 specific components). After > all, IPv6 connectivity in IPv4 networks (and NAT traversal) is a more > generic problem than that. >=20 :) > Actually, it's even better not to co-locate the v4 tunnel endpoint > with IPv6 HA -- that way, if a tunnel endpoint close by, closer than > the HA, there are some route optimization benefits. >=20 True, while harder to achieve than the NAT traversal. Maybe something to address in our Nemo RO taxonomy draft. > (This is the "mobility thoughts" topic which was discussed on Thursday > session, and next a problem statement/scenario -like draft is probably > going to be written.) >=20 > Pascal, is there something obvious I missed when I glanced through > your idea? >=20 I do not think so but I'd like to point out this: the cool thing with doors is that the security and state maintenance are inherited from MIP6; makes it a lightweight draft (and implementation) for quite a huge value. In other words, if your stack has MIP6 and you have a HA to register to, then Doors may be the easiest way to go through IPv4 and NATs. Thus it makes sense to me to include it in the grid, with the conscious dependency on MIP6 success.=20 What do you think? Pascal From owner-v6ops@ops.ietf.org Thu Mar 11 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 BAA00996 for ; Thu, 11 Mar 2004 01:27:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1Jbf-000E4Y-PA for v6ops-data@psg.com; Thu, 11 Mar 2004 06:23:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1JbT-000E0N-JY for v6ops@ops.ietf.org; Thu, 11 Mar 2004 06:23:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2B6NXu11398 for ; Thu, 11 Mar 2004 08:23:34 +0200 Date: Thu, 11 Mar 2004 08:23:33 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Tunneling scenarios and mechanisms evaluation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, The presentation on tunneling scenarios and mechanisms has now been converted to an Internet-Draft. Some additional text was also added; some other minor modifications were made. As it apparently didn't get announced on Wednesday, it's available here: http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-00.txt Abstract This memo analyses the v6ops scenarios/analysis work (Unmanaged, 3GPP, ISP and Enterprise) for their requirements for tunneling solutions, and analyses the proposed mechanisms on how they might fit in these requirements, and discusses possibilities for choosing solution(s). -- 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 Mar 11 03:18: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 DAA18473 for ; Thu, 11 Mar 2004 03:18:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1LKG-0003HT-Qv for v6ops-data@psg.com; Thu, 11 Mar 2004 08:13:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1LJx-0003CB-Oi for v6ops@ops.ietf.org; Thu, 11 Mar 2004 08:13:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2B8Da312910 for ; Thu, 11 Mar 2004 10:13:36 +0200 Date: Thu, 11 Mar 2004 10:13:36 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Tunneling scenarios and mechanisms evaluation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Whoops -- forgive my slip. The address below was where it WILL be available. For now, it's at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-tunneling-00.txt Sorry -- and thanks to Tim for pointing the obvious! :) On Thu, 11 Mar 2004, Pekka Savola wrote: [...] > http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-00.txt > > Abstract > This memo analyses the v6ops scenarios/analysis work (Unmanaged, > 3GPP, ISP and Enterprise) for their requirements for tunneling > solutions, and analyses the proposed mechanisms on how they might fit > in these requirements, and discusses possibilities for choosing > solution(s). > > > -- 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 Mar 11 18:34: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 SAA03706 for ; Thu, 11 Mar 2004 18:34:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1ZdV-0006f5-DG for v6ops-data@psg.com; Thu, 11 Mar 2004 23:30:45 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1ZdC-0006X8-3V for v6ops@ops.ietf.org; Thu, 11 Mar 2004 23:30:26 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2BNUPwr020795 for ; Thu, 11 Mar 2004 16:30:25 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUF00JEYQMOPV@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 11 Mar 2004 16:30:25 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUF002L2QMNV3@mail.sun.net> for v6ops@ops.ietf.org; Thu, 11 Mar 2004 16:30:24 -0700 (MST) Date: Thu, 11 Mar 2004 15:30:22 -0800 From: Alain Durand Subject: Re: Tunneling scenarios and mechanisms evaluation In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <114A0FC0-73B4-11D8-942F-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 10, 2004, at 10:23 PM, Pekka Savola wrote: > Hi, > > The presentation on tunneling scenarios and mechanisms has now been > converted to an Internet-Draft. Some additional text was also added; > some other minor modifications were made Couple questions/comments: 1) Section 4.3: Therefore we get that Teredo and STEP is the lowest common denominator, after having to take a few tough issues in the consideration, with Teredo and TSP coming somewhat behind. Is there a typo here? Teredo is listed twice. 2) This draft makes a big issue about direct connectivity and bases the some underlying recommendations on this. let me ask: is this really a requirement or yet another nice to have? What will break without direct connectivity? (in any of the scenarios) If nothing really breaks, but things are just sub-optimal, then I would say this is not that bad. remember that we are talking about transition mechanisms, they DO NOT NEED to be perfect, if not we will never deploy fully IPv6... So, in a certain sense, suboptimal transition mechanisms can be good in the long run ;-) 3) this document acknowledge the importance of things that have been implemented and deployed but treats TSP and STEP as equal. I think this comparison is biased. To be fair, one should compare Tunnel broker & STEP as TSP is a particular implementation of the tunnel broker model that has incorporated UDP tunneling. There are a huge number of users of the many variant of tunnel brokers, so it is a model that has been proven. On the other hand, the document recognize that STEP has never been implemented. 4) I was not at the last two IETF meetings for family reasons, so I might miss something. However, here is what I take from the analysis done in this document: 1- There is a clear need for some assisted IPv6/UDP/IPv4 tunnel management. The tunnel broker model seems to work fine as demonstrated by TSP, which I regard as an existence proof. This area need to be standardized, by advancing TSP or an evolution of it on the standard track. Note: With regard to TSP, we are not in a situation of take it or leave it. If the ban on developing tools is lifted, I'm convince that we could design something very quickly if the detail analysis of TSP shows improvement are necessary. 2- Teredo is only necessary when direct connection is mandatory and there is no help from the ISP. if the wg thinks that direct connectivity is absolutely necessary and this is a valid scenario, then we should advance Teredo on the standard track. If not, publication as experimental is always an option. 3- Isatap is really interesting in sparse deployment, which are early scenario. If this wg takes another 4 years to look at it, then its value would have long been depreciated... 5) what about the others, like 6to4? Do we still need this despite the issues with the relays? - Alain. From owner-v6ops@ops.ietf.org Thu Mar 11 20:26: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 UAA09499 for ; Thu, 11 Mar 2004 20:25:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1bNj-00062n-Hp for v6ops-data@psg.com; Fri, 12 Mar 2004 01:22:35 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1bNY-0005yo-DQ for v6ops@ops.ietf.org; Fri, 12 Mar 2004 01:22:24 +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 3E0278707; Fri, 12 Mar 2004 02:22:22 +0100 (CET) From: "Jeroen Massar" To: "'Alain Durand'" , "'Pekka Savola'" Cc: Subject: RE: Tunneling scenarios and mechanisms evaluation Date: Fri, 12 Mar 2004 02:22:09 +0100 Organization: Unfix MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <114A0FC0-73B4-11D8-942F-00039376A6AA@sun.com> Thread-Index: AcQHwYLulO/DyDBgSWON/B/TBnE9DAAC8XSw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040312012222.3E0278707@purgatory.unfix.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alain Durand wrote: > On Mar 10, 2004, at 10:23 PM, Pekka Savola wrote: > > > Hi, > > > > The presentation on tunneling scenarios and mechanisms has now been > > converted to an Internet-Draft. Some additional text was also added; > > some other minor modifications were made > > > Couple questions/comments: > 1- There is a clear need for some assisted IPv6/UDP/IPv4 tunnel > management. > The tunnel broker model seems to work fine as demonstrated by TSP, > which I regard as an existence proof. > This area need to be standardized, by advancing TSP or an > evolution of it on the standard track. I'd rather see the IPv6 in UDP protocol be defined as that is not included in a draft as it is not documented in any of the old nor in the new draft (draft-blanchet-v6ops-tunnelbroker-tsp-00) and I think that it is an interesting thing to have as many of those so called "NAT-routers" don't support proto-41 forwarding but do allow forwarding of udp packets on a certain port. This is basically one of the things that Teredo addresses but that uses a completely different model and also has signalling included. The TSPC 1.0 sources provided through the Freenet6 site don't mention anything about these UDP tunnels either. Having a standard for these would be a good thing as then the OS's could be made to support it also and afaik there is no such support yet. Maybe the above is going to be addressed for -01? PS: Marc, use 2001:db8::/32 and 192.0.2.0/24 in examples. Currently I am using tinc in cases where proto-41 doesn't penetrate the NAT or the firewall, btw think of IPv6 over tinc over httptunnel's and have IPv6 everywhere you want ;) As for automatic 'repointing' of tunnels I have written and implemented draft-massar-v6ops-heartbeat-00 for those cases. These types of tunnels are proto-41 mind you but the protocol defined in that draft could easily be made to reconfigure udp tunnels and the likes as the protocol itself only handles either a src+dst pair or inner src+dst & outer src+dst pairs, thus it is not tunneling-protocol bound. > Note: With regard to TSP, we are not in a situation of take > it or leave it. If the ban on developing tools is lifted, > I'm convince that we could design something very quickly if > the detail analysis of TSP shows improvement are necessary. Is there a ban on developing tools based on TSP? Please elaborate. I do have another, somewhat more of my own 'problem' with TSP and that is that I can't seem to make it fit the model of the SixXS tunnelbroker we are running, which is why we described our own protocol + tools for configuring clients. Draft not ready yet though. For configuration only the serverside of TSP could be implemented, but I guess it would be more reading the older drafts and the sources of tspc to make that work. > what about the others, like 6to4? Do we still need this despite the > issues with the relays? There seem to be a huge amount of traffic here in the Netherlands going over 6to4, this because there is the newszilla6.xs4all.nl box that has an open IPv6 NNTP (binary) service. People only need to type 'ipv6 install' on their XP boxes and they can connect. Thus I think one should not forget it even though it isn't totally abuse proof and not easily traceable/debuggable, which is one of the things I see as a big negative. It also doesn't cross NAT's but proto-41 doesn't do that either unless the NAT-router is configured correctly where possible. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFEQwQAAJc4AnA/piNZwV1hZP2FIl6q6fHlg 1m0eAJ9lfZ25UUFYqAc5opI/fmRLzWFJ2A== =T59V -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Thu Mar 11 21:04: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 VAA10947 for ; Thu, 11 Mar 2004 21:04:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1c09-000PY7-Go for v6ops-data@psg.com; Fri, 12 Mar 2004 02:02:17 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1bzy-000PTp-IH for v6ops@ops.ietf.org; Fri, 12 Mar 2004 02:02:06 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2C226wr009445 for ; Thu, 11 Mar 2004 19:02:06 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUF00HY8XNH2L@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 11 Mar 2004 19:02:06 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUF00DOAXNG8V@mail.sun.net> for v6ops@ops.ietf.org; Thu, 11 Mar 2004 19:02:05 -0700 (MST) Date: Thu, 11 Mar 2004 18:02:02 -0800 From: Alain Durand Subject: Re: Tunneling scenarios and mechanisms evaluation In-reply-to: <20040312012222.3E0278707@purgatory.unfix.org> To: Jeroen Massar Cc: "'Pekka Savola'" , v6ops@ops.ietf.org Message-id: <40DE51E0-73C9-11D8-85CB-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040312012222.3E0278707@purgatory.unfix.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 11, 2004, at 5:22 PM, Jeroen Massar wrote: >> 1- There is a clear need for some assisted IPv6/UDP/IPv4 tunnel >> management. >> The tunnel broker model seems to work fine as demonstrated by TSP, >> which I regard as an existence proof. >> This area need to be standardized, by advancing TSP or an >> evolution of it on the standard track. > > I'd rather see the IPv6 in UDP protocol be defined This too needs to happen. The point I'm trying to make is that I see a clear need to work in the general area of assisted IPv6/UDP/IPv4 tunneling. A number of things need to be specified, defining IPv6 in UDP is clearly one of them. > As for automatic 'repointing' of tunnels I have written and > implemented draft-massar-v6ops-heartbeat-00 for those cases. This also need to be studied further. > Is there a ban on developing tools based on TSP? There is a ban that was institute in the last days of NGtrans and that was carried on in v6ops that forbid to work on transition mechanism as wg items until the scenario document were finished. I think we are due to lift this ban and restart wg activities in the general area of assisted tunneling mechanism as it is clear now that such work is needed to address the scenarios in scope for v6ops. Delaying this further would be irresponsible. > I do have another, somewhat more of my own 'problem' with TSP > and that is that I can't seem to make it fit the model of the > SixXS tunnelbroker we are running, which is why we described > our own protocol + tools for configuring clients. Draft not > ready yet though. For configuration only the serverside of > TSP could be implemented, but I guess it would be more reading > the older drafts and the sources of tspc to make that work. As I said earlier, I view TSP as an existence proof, not necessarily as the final solution. it may be, but it is not proven. - Alain. From owner-v6ops@ops.ietf.org Thu Mar 11 21:26: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 VAA11786 for ; Thu, 11 Mar 2004 21:26:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1cKr-0009RO-U1 for v6ops-data@psg.com; Fri, 12 Mar 2004 02:23:41 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1cKh-0009Ij-8S for v6ops@ops.ietf.org; Fri, 12 Mar 2004 02:23:31 +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 i2C2NHng001294; Thu, 11 Mar 2004 18:23:18 -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 i2C2NFQ11381; Fri, 12 Mar 2004 03:23:15 +0100 (MET) Date: Thu, 11 Mar 2004 18:23:20 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt To: Pekka Savola Cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com, huitema@microsoft.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Sorry for not catching this earlier. Section 4.1 says An ND proxy can also be used to extend a /64 prefix to multiple physical links of different properties (e.g, an Ethernet and a PPP link). But isn't this solving a non-problem? Today in IPv4 (where a prefix is delegated to e.g. a SOHO customer) this doesn't seem to be an issue; either separate addresses are assigned to the PPP link, or the PPP link ends up being unnumbered. Why don't those approaches apply to IPv6? Section 4.1.1 talks of a larger unmanaged network. But why do we think we need IPv6 specific solutions to this problem? If IEEE 802 bridges are not ideal maybe either we should tell this to the IEEE, or pursue the various ideas that where discussed in the ZEROUTER BoF a while back. Locking us into ndproxy as a solution to a problem that no IETF WG has carefully looked at seems unwise. Based on these concerns of mine, I disagree with recommendation #2. Erik From owner-v6ops@ops.ietf.org Thu Mar 11 22:47: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 WAA15190 for ; Thu, 11 Mar 2004 22:47:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1dbc-000KPx-Hu for v6ops-data@psg.com; Fri, 12 Mar 2004 03:45:04 +0000 Received: from [24.203.190.116] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1dbR-000KKr-CL for v6ops@ops.ietf.org; Fri, 12 Mar 2004 03:44:53 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i2C3inRn017327; Thu, 11 Mar 2004 22:44:49 -0500 (EST) Date: Thu, 11 Mar 2004 22:44:49 -0500 From: Florent Parent To: Jeroen Massar cc: v6ops@ops.ietf.org Subject: RE: Tunneling scenarios and mechanisms evaluation Message-ID: <426440000.1079063089@blues.hexago.com> In-Reply-To: <20040312012222.3E0278707@purgatory.unfix.org> References: <20040312012222.3E0278707@purgatory.unfix.org> 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.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, March 12, 2004 02:22:09 +0100 Jeroen Massar wrote: > I'd rather see the IPv6 in UDP protocol be defined as that is not > included in a draft as it is not documented in any of the old nor > in the new draft (draft-blanchet-v6ops-tunnelbroker-tsp-00) and > I think that it is an interesting thing to have as many of those > so called "NAT-routers" don't support proto-41 forwarding but > do allow forwarding of udp packets on a certain port. This is > basically one of the things that Teredo addresses but that uses > a completely different model and also has signalling included. > The TSPC 1.0 sources provided through the Freenet6 site don't > mention anything about these UDP tunnels either. Having a > standard for these would be a good thing as then the OS's could > be made to support it also and afaik there is no such support yet. > Maybe the above is going to be addressed for -01? > PS: Marc, use 2001:db8::/32 and 192.0.2.0/24 in examples. Jeroen, As I stated in a previous email on the list, I'm working on the -01 rev. of this draft which will include details on the UDP stuff. Wait a few more days. As for the client source code, the web site client is outdated. Client source for NAT traversal is available (GPL) and will appear there at some point. Send me an email if you'd like a copy sooner. Florent From owner-v6ops@ops.ietf.org Thu Mar 11 23:49: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 XAA17486 for ; Thu, 11 Mar 2004 23:49:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1eXr-000K6k-BL for v6ops-data@psg.com; Fri, 12 Mar 2004 04:45:15 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1eXg-000K36-HE for v6ops@ops.ietf.org; Fri, 12 Mar 2004 04:45:04 +0000 content-class: urn:content-classes:message Subject: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation Date: Thu, 11 Mar 2004 23:45:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Tunneling scenarios and mechanisms evaluation X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQH1xP7MZs9OxKCT9qM92dAgCjorQAFFqrg From: "Soliman Hesham" To: "Alain Durand" , "Jeroen Massar" Cc: "Pekka Savola" , X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > I do have another, somewhat more of my own 'problem' with TSP > > and that is that I can't seem to make it fit the model of the > > SixXS tunnelbroker we are running, which is why we described > > our own protocol + tools for configuring clients. Draft not > > ready yet though. For configuration only the serverside of > > TSP could be implemented, but I guess it would be more reading > > the older drafts and the sources of tspc to make that work. >=20 > As I said earlier, I view TSP as an existence proof, not=20 > necessarily as=20 > the final solution. > it may be, but it is not proven. =3D> I have a question that is somewhat related to this=20 thread. Why isn't L2TP a credible, secure, tunnelling=20 mechanism to be used? Do we really need a brand new protocol? L2TP is widely implemented and deployed. If this question was raised before I'd appreciate a pointer to the discussion. Hesham >=20 > - Alain. >=20 >=20 From owner-v6ops@ops.ietf.org Fri Mar 12 02:43: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 CAA06626 for ; Fri, 12 Mar 2004 02:43:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1hFy-000Ekd-UY for v6ops-data@psg.com; Fri, 12 Mar 2004 07:38:58 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1hFn-000Edl-Ap for v6ops@ops.ietf.org; Fri, 12 Mar 2004 07:38:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C7cTa01023; Fri, 12 Mar 2004 09:38:29 +0200 Date: Fri, 12 Mar 2004 09:38:29 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: Alain Durand , Jeroen Massar , Subject: Re: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 11 Mar 2004, Soliman Hesham wrote: > => I have a question that is somewhat related to this thread. Why > isn't L2TP a credible, secure, tunnelling mechanism to be used? Do > we really need a brand new protocol? L2TP is widely implemented and > deployed. > > If this question was raised before I'd appreciate a pointer to the > discussion. Hesham It was raised before, when I first sent a pointer to STEP. I'm not 100% sure of the conclusion. It seems like L2TP architecture is relatively heavy-weight (UDP tunneling, PPP, L2TP service architecture, etc.), except when the ISP and the client is already using it for some other purpose. I think it's a scenario worth recommending, to those who have already deployed the requisite architecture, but I have a feeling that for ISPs that just want to set up something quickly and simply, with as little overhead as possible, it may be a bit too heavy. Now -- if I (personally) had to choose between the current TSP and the current L2TP architecture, I think the set-up etc. is in the same order of magnitude. But (personally) I'd like to have a more zero-config solution for the tunnel service.. -- 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 Mar 12 02:48: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 CAA06837 for ; Fri, 12 Mar 2004 02:48:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1hNT-000IfW-OR for v6ops-data@psg.com; Fri, 12 Mar 2004 07:46:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1hNI-000Ia4-HF for v6ops@ops.ietf.org; Fri, 12 Mar 2004 07:46:32 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C7kTH01135; Fri, 12 Mar 2004 09:46:29 +0200 Date: Fri, 12 Mar 2004 09:46:29 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org, , Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 11 Mar 2004, Erik Nordmark wrote: > Section 4.1 says > An ND proxy can also be used to extend a /64 prefix to multiple > physical links of different properties (e.g, an Ethernet and a PPP > link). > > But isn't this solving a non-problem? > Today in IPv4 (where a prefix is delegated to e.g. a SOHO customer) > this doesn't seem to be an issue; either separate addresses are assigned > to the PPP link, or the PPP link ends up being unnumbered. > > Why don't those approaches apply to IPv6? PPP doesn't support v6 prefix delegation, and there is no will to make it so. Does v4 either? (I'm not sure -- but maybe that's some vendor extension.) This approach works in the case where the ISP is advertising you an IPv6 prefix using RA, and you want to extend it to another subnet. On the other hand, in IPv4, there are no such advertisements. Either the prefix is delegated somehow, or you use NAT. > Section 4.1.1 talks of a larger unmanaged network. > But why do we think we need IPv6 specific solutions to this problem? Because with IPv4 we have NAT.. which is sad but true -- it's used precisely in a scenario like this... (Of course, v4 also has proxy-arp, but that's used less and less now that there are easier solutions such as NAT available..) > If IEEE 802 bridges are not ideal maybe either we should tell this > to the IEEE, or pursue the various ideas that where discussed in the > ZEROUTER BoF a while back. Locking us into ndproxy as a solution to > a problem that no IETF WG has carefully looked at seems unwise. I don't think we're locking into a solution -- but giving flexibility to pick either explicit prefix delegation or ND proxying, whichever seems suitable. > Based on these concerns of mine, I disagree with recommendation #2. What would you suggest as an (easy) replacement for v4 NATs? ND proxying seems like an obvious solution in a scenario like this (that is, when pure bridging does not work). So, I'd appreciate if you could elaborate on this .. and if possible, provide text/clarification you'd like to see in the document to bring out the concerns better. -- 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 Mar 12 02:53: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 CAA06995 for ; Fri, 12 Mar 2004 02:53:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1hSA-000LFy-Fs for v6ops-data@psg.com; Fri, 12 Mar 2004 07:51:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1hRz-000L7V-Il for v6ops@ops.ietf.org; Fri, 12 Mar 2004 07:51:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C7pIP01261; Fri, 12 Mar 2004 09:51:18 +0200 Date: Fri, 12 Mar 2004 09:51:18 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Jeroen Massar , Subject: "ban" against mechanisms [Re: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <40DE51E0-73C9-11D8-85CB-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 11 Mar 2004, Alain Durand wrote: > > Is there a ban on developing tools based on TSP? > > There is a ban that was institute in the last days of NGtrans and > that was carried on in v6ops that forbid to work on transition > mechanism as wg items until the scenario document were finished. > > I think we are due to lift this ban and restart wg activities in the > general area of assisted tunneling mechanism as it is clear now > that such work is needed to address the scenarios in scope for v6ops. > Delaying this further would be irresponsible. There has never been a "ban" on working on something. Only, v6ops and at the later days, ngtrans, would not take these items as WG work items. I don't think discussing such work on either list has ever been explicitly forbidden (as long as it wouldn't interfere with the rest of the work). It has always been OK to continue working on the proposed mechanisms as individual drafts. -- 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 Mar 12 02:56: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 CAA07079 for ; Fri, 12 Mar 2004 02:56:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1hVJ-000Mvt-OR for v6ops-data@psg.com; Fri, 12 Mar 2004 07:54:49 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1hV9-000MrG-8e for v6ops@ops.ietf.org; Fri, 12 Mar 2004 07:54:39 +0000 content-class: urn:content-classes:message Subject: RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation Date: Fri, 12 Mar 2004 02:54:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQIBQQ4UqWEUeaBQ5+i2Q+AelitVAAAMqKQ From: "Soliman Hesham" To: "Pekka Savola" Cc: "Alain Durand" , "Jeroen Massar" , X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > It was raised before, when I first sent a pointer to STEP. >=20 > I'm not 100% sure of the conclusion. It seems like L2TP architecture > is relatively heavy-weight (UDP tunneling, PPP, L2TP service > architecture, etc.), except when the ISP and the client is already > using it for some other purpose. =3D> That was one of my main reasons for asking. It's much faster to use something that already exists, deployed, and in fact used a lot today by ISPs and enterprise networks.=20 Hesham From owner-v6ops@ops.ietf.org Fri Mar 12 03:16: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 DAA07639 for ; Fri, 12 Mar 2004 03:16:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1hnF-0005Qs-Mo for v6ops-data@psg.com; Fri, 12 Mar 2004 08:13:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1hn4-0005Jp-HZ for v6ops@ops.ietf.org; Fri, 12 Mar 2004 08:13:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C8D7f01700; Fri, 12 Mar 2004 10:13:07 +0200 Date: Fri, 12 Mar 2004 10:13:07 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: Tunneling scenarios and mechanisms evaluation In-Reply-To: <114A0FC0-73B4-11D8-942F-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for the feedback, Alain. Responses inline.. On Thu, 11 Mar 2004, Alain Durand wrote: > On Mar 10, 2004, at 10:23 PM, Pekka Savola wrote: > Couple questions/comments: > > 1) > Section 4.3: > Therefore we get that Teredo and STEP is the lowest common > denominator, after having to take a few tough issues in the > consideration, with Teredo and TSP coming somewhat behind. > > Is there a typo here? Teredo is listed twice. This is intended. Based on the analysis, the requirement for Teredo exists no matter what else we choose. The most preferable solutions in addition to Teredo, however, seemed to be STEP and TSP. > 2) > This draft makes a big issue about direct connectivity and bases > the some underlying recommendations on this. > > let me ask: is this really a requirement or yet another nice to have? > What will break without direct connectivity? (in any of the scenarios) When your ISP doesn't offer IPv6 connectivity, but you would have to take a "long leg" to get it, it seems that to be able to achieve anything useful (e.g., peer to peer connectivity), direct connectivity is a real requirement. On the other hand, when your ISP/operator is offering IPv6 connectivity, in my eyes it is *not* a strict requirement (and not reflected as such in the analysis), because the extra leg that needs to be taken is probably in the order of 1-10 ms, not 30-300 ms. The former is still usable, the latter not. > If nothing really breaks, but things are just sub-optimal, then I > would say this is not that bad. remember that we are talking about > transition mechanisms, they DO NOT NEED to be perfect, if not we > will never deploy fully IPv6... So, in a certain sense, suboptimal > transition mechanisms can be good in the long run ;-) I agree that I don't (personally) think direct connectivity is a requirement, for reasons you state, when your ISP/operator is offering the tunnel service. I'm not sure which context you're discussing, but if you're saying that direct connectivity is not a requirement in the cases where your ISP is not offering a service, then I would have to disagree due to concerns of scalability for large-scale deployment. > 3) this document acknowledge the importance of things that have been > implemented and deployed but treats TSP and STEP as equal. I think > this comparison is biased. Implemented & deployed are tradeoffs among others. There may of course be some bias here :). > To be fair, one should compare Tunnel broker & STEP as TSP is a > particular implementation of the tunnel broker model that has > incorporated UDP tunneling. There are a huge number of users of the > many variant of tunnel brokers, so it is a model that has been > proven. On the other hand, the document recognize that STEP has > never been implemented. I have to disagree here. The tunnel broker is just a concept. It doesn't fly on its own. It's not even interoperable, which is causing a lot of problems. STEP, as a matter of fact, is also a tunnel broker of a kind. My personal preference would be to create a combination of TSP, STEP (and ISATAP, to a lesser degree) as a single tunnel server solution: providing simplicity of STEP when more complex setups aren't needed, yet providing (additional, optional?) flexibility of TSP in the cases where e.g., static prefix is desirable. IMHO, TSP is unnecessarily heavyweight when all you need is just a simple IPv6 address. You don't really need to do all of that signalling for the basic usage case.. > 4) > > I was not at the last two IETF meetings for family reasons, so I > might miss something. However, here is what I take from the analysis > done in this document: > > 1- There is a clear need for some assisted IPv6/UDP/IPv4 tunnel > management. Totally agree here. > The tunnel broker model seems to work fine as demonstrated by TSP, > which I regard as an existence proof. This area need to be > standardized, by advancing TSP or an evolution of it on the standard > track. > > Note: With regard to TSP, we are not in a situation of take it or > leave it. If the ban on developing tools is lifted, I'm convince > that we could design something very quickly if the detail analysis > of TSP shows improvement are necessary. Such ban does not exist, and IMHO it is clear that TSP (or the model in general) requires a lot of improvement -- I reviewed it some time ago, and sent feedback on the list. So far that I'd rather start from scratch, while keeping the model intact.. But this is something that would be very quickly doable, if we want to do it. > 2- Teredo is only necessary when direct connection is mandatory and > there is no help from the ISP. if the wg thinks that direct > connectivity is absolutely necessary and this is a valid scenario, > then we should advance Teredo on the standard track. If not, > publication as experimental is always an option. Yep. Though there was some resistance to moving it along for now in the meeting, calling for analysis. (It's interesting, as people were previously shouting for moving forward.) > 3- Isatap is really interesting in sparse deployment, which are > early scenario. If this wg takes another 4 years to look at it, then > its value would have long been depreciated... Did you mean s/really interesting/really only interesting/? The benefit of ISATAP is providing direct tunneling between the nodes. This may be interesting in sparse deployment (compared to going dual-stack; but in sparse deployment, tunnel server is also fine), and some have even expressed interest in dense deployment (compared to dual-stack: not wanting to go there; compared to tunnel server: not overloading the server). IMHO, the dense deployment scenario calls for dual-stack, and we should not be hacking to work around that.. and sparse deployment can be facilitated by a tunnel server. So, personally, I'm not sure if I see much applicability in direct connectivity in this specific "ISP-assisted" context. > 5) > what about the others, like 6to4? Do we still need this despite the > issues with the relays? Unfortunately, I think yes -- in the unmanaged case where there is no ISP support ... -- 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 Mar 12 03:27:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07954 for ; Fri, 12 Mar 2004 03:27:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1hyo-000BH9-CJ for v6ops-data@psg.com; Fri, 12 Mar 2004 08:25:18 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1hyc-000BBx-F2 for v6ops@ops.ietf.org; Fri, 12 Mar 2004 08:25:06 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B1hyb-0002cv-00 for v6ops@ops.ietf.org; Fri, 12 Mar 2004 08:25:05 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B1hyb-0002cq-00 for v6ops@ops.ietf.org; Fri, 12 Mar 2004 08:25:05 +0000 Received: from zurich.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id i2C8P4F69994 for ; Fri, 12 Mar 2004 08:25:05 GMT Message-ID: <405173FD.9AD0CA42@zurich.ibm.com> Date: Fri, 12 Mar 2004 09:25:33 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: 6to4 sub-topic [Re: Tunneling scenarios and mechanisms evaluation] References: <20040312012222.3E0278707@purgatory.unfix.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jeroen Massar wrote: ... > > > what about the others, like 6to4? Do we still need this despite the > > issues with the relays? > > There seem to be a huge amount of traffic here in the Netherlands > going over 6to4, this because there is the newszilla6.xs4all.nl > box that has an open IPv6 NNTP (binary) service. People only need > to type 'ipv6 install' on their XP boxes and they can connect. > Thus I think one should not forget it even though it isn't totally > abuse proof and not easily traceable/debuggable, which is one of > the things I see as a big negative. It also doesn't cross NAT's > but proto-41 doesn't do that either unless the NAT-router is > configured correctly where possible. I think this is about right. I confess that 6to4 was invented as a provocative technology that would allow some relatively easy IPv6 deployment without too much "official" support, and it has succeeded... with some disadvantages as noted. But whether "we" (v6ops) need it or not, it is there. Personally, I'm happy to see it sit at PS for a while longer, and publish Pekka's security addendum as Informational. It really doesn't matter whether 6to4 is on some approved list or not. Brian From owner-v6ops@ops.ietf.org Fri Mar 12 04:20: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 EAA09833 for ; Fri, 12 Mar 2004 04:20:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1inN-0009Gc-4H for v6ops-data@psg.com; Fri, 12 Mar 2004 09:17:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1in4-00097Z-3I for v6ops@ops.ietf.org; Fri, 12 Mar 2004 09:17:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C9HCb02705; Fri, 12 Mar 2004 11:17:12 +0200 Date: Fri, 12 Mar 2004 11:17:12 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: IETF59 minutes and presentations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 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) The minutes and presentations have been made available at: http://www.6bone.net/v6ops/minutes/index.htm Please send corrections, omissions, etc., to the chairs within a week (by Mar 19). Thanks! From owner-v6ops@ops.ietf.org Fri Mar 12 04:21:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09851 for ; Fri, 12 Mar 2004 04:21:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1iow-0009xa-Gx for v6ops-data@psg.com; Fri, 12 Mar 2004 09:19:10 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1iol-0009tQ-Ms for v6ops@ops.ietf.org; Fri, 12 Mar 2004 09:18:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C9Iwr02724 for ; Fri, 12 Mar 2004 11:18:58 +0200 Date: Fri, 12 Mar 2004 11:18:58 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: WG Last Call: draft-ietf-v6ops-application-transition-01.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.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 (co-chair hat on) Just a reminder -- the WGLC for the application transition document was issued just prior to the IETF, and still runs for about a week or so. Please provide feedback. Thanks! ---------- Forwarded message ---------- 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 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 Mar 12 10:31: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 KAA28052 for ; Fri, 12 Mar 2004 10:31:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1oZH-0008ov-UE for v6ops-data@psg.com; Fri, 12 Mar 2004 15:27:23 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1oMi-0002x9-Tw for v6ops@ops.ietf.org; Fri, 12 Mar 2004 15:14:25 +0000 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Mar 2004 16:14:21 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : Tunneling scenarios and mechanisms evaluation Date: Fri, 12 Mar 2004 16:14:21 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC236D5C8@ftrdmel3.rd.francetelecom.fr> Thread-Topic: Tunneling scenarios and mechanisms evaluation Thread-Index: AcQHQdZ3cPnmdpsTT4ihsSQXs2kmJAA9whog From: "BAUDOT Alain FTRD/DMI/CAE" To: "Pekka Savola" , X-OriginalArrivalTime: 12 Mar 2004 15:14:21.0682 (UTC) FILETIME=[B2629520:01C40844] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Here are my few comments on the document: 1. Introduction I think Tunnel Broker (TB) should part of the analysis, as well. 3.2 Unmanaged Networks Case 2 seems to match ISP case 2a (where the connection network cannot = be upgraded), unless it is a compilation of unman case C and ISP case = 2a. Anyway, in one case the ISP cannot cooperate with unman network, = while it can do so in the other case. The appropriate solution may then = meet different requirements, e.g. oportunistic mechanism may or may be = not suitable.=20 I guess this need some clarification. "NAT traversal must be supported." This is not true if the tunnel ends = in the gateway where the NAT function is usually located. I think this = is important, since the solution to deploy does not need to deal with = complexity of NAT traversal. 3.4 ISP Scenarios "ISPs do not have specific scenarios which need to be addresses which haven't been already mentioned" ISP scenario case 2b, where the ISP backbone is not IPv6 capable, is not = discussed here. Anyway, I think that there is a large difference between "obtaining" = connectivity, as discussed in the previous section 3.3, and "providing" = a connectivity as an ISP. ISPs have strong requirements, at least, on = user identification, in order to make sure the connectivity is provided = to its customers with some reasonable load (and without unpredictable = overload), and on addressing since the duly identified customer may = benefit from some address/prefix delagation from the ISP' TLA. 4.1 Scenarios Evaluation I think the matrix should match here all the identfied scenarios from = 3GPP, UNMAN, ISP and ENT, and not a subset of them. Two columns maybe added: one dealing with "user identification" and = another one dealing with some prefix delagation means, in order to = actually complement the ISP column. 4.2 Mechanisms Evaluation I wonder here what is the real meaning of ISP support in terms of = features or functions. Anyway, to get a more compltete picture, I would add columns for:=20 -terminal/gateway: if the macnism applies to a terminal only, a gateway = only or both with the idea of complement ISP column:=20 -user identification -address/prefix delegation means. Regards, Alain.=20 -----Message d'origine----- De : owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] De la = part de Pekka Savola Envoy=E9 : jeudi 11 mars 2004 09:14 =C0 : v6ops@ops.ietf.org Objet : Re: Tunneling scenarios and mechanisms evaluation Whoops -- forgive my slip. The address below was where it WILL be=20 available. For now, it's at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-tunneling-00.txt Sorry -- and thanks to Tim for pointing the obvious! :) On Thu, 11 Mar 2004, Pekka Savola wrote: [...] > http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-00.tx > t >=20 > Abstract > This memo analyses the v6ops scenarios/analysis work (Unmanaged, > 3GPP, ISP and Enterprise) for their requirements for tunneling > solutions, and analyses the proposed mechanisms on how they might = fit > in these requirements, and discusses possibilities for choosing > solution(s). >=20 >=20 >=20 --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Mar 12 11:15: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 LAA00683 for ; Fri, 12 Mar 2004 11:15:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1pHZ-0004oe-3j for v6ops-data@psg.com; Fri, 12 Mar 2004 16:13:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1pHN-0004j5-K7 for v6ops@ops.ietf.org; Fri, 12 Mar 2004 16:12:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2CGCeB09202; Fri, 12 Mar 2004 18:12:40 +0200 Date: Fri, 12 Mar 2004 18:12:39 +0200 (EET) From: Pekka Savola To: BAUDOT Alain FTRD/DMI/CAE cc: v6ops@ops.ietf.org Subject: Re: RE : Tunneling scenarios and mechanisms evaluation In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC236D5C8@ftrdmel3.rd.francetelecom.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for your comments. You raise tough issues, and I'm not sure if I see the point in some of them. Maybe you can elaborate a bit.. On Fri, 12 Mar 2004, BAUDOT Alain FTRD/DMI/CAE wrote: > 1. Introduction > > I think Tunnel Broker (TB) should part of the analysis, as well. I have to disagree -- AFAICS, TB (RFC 3053) is just a concept, TSP being an instantiation of that concept. I'm not sure how to even compare that if it was included.. > 3.2 Unmanaged Networks > > Case 2 seems to match ISP case 2a (where the connection network > cannot be upgraded), unless it is a compilation of unman case C and > ISP case 2a. Yes. > Anyway, in one case the ISP cannot cooperate with unman > network, while it can do so in the other case. The appropriate > solution may then meet different requirements, e.g. oportunistic > mechanism may or may be not suitable. I guess this need some > clarification. I'm not sure if I understand what you meant with "cannot cooperate with unman network" ? Do you mean that the unmanaged user does not use (or cannot use) the mechanism that the ISP is using? The user should get that support then, or if not, the case would equal the unman case 1.1 -- when ISP does not provide any support. > "NAT traversal must be supported." This is not true if the tunnel > ends in the gateway where the NAT function is usually located. I > think this is important, since the solution to deploy does not need > to deal with complexity of NAT traversal. True. On the other hand, practically, it seems clear that we cannot expect *all* of these gateways to support IPv6 -- so we'll have to cope with every scenario. However, this does not say that NAT traversal must be _used_ -- it just has to be supported in the case that it's needed. One could certainly break the unmanaged cases into smaller pieces, depending on whether IPv6 is supported in the gateway device or not, but I think the result in the end is just the same, and we would not gain anything by splitting a larger scenario to a few smaller pieces (as we would still have to wrap it up -- to use the same mechanism as it would not make sense to specify two for the slightly different cases). Or, did you mean that the "IPv6 in the gateway via a tunnel" is a significant case, and it might be useful to try to analyze it separately? > 3.4 ISP Scenarios > > "ISPs do not have specific scenarios which need to be addresses which > haven't been already mentioned" > > ISP scenario case 2b, where the ISP backbone is not IPv6 capable, is > not discussed here. It isn't, because the answer is obvious, especially after the Monday meeting: configured tunneling or something like BGP tunneling. I guess this could be spelled out.. > Anyway, I think that there is a large difference between "obtaining" > connectivity, as discussed in the previous section 3.3, and > "providing" a connectivity as an ISP. ISPs have strong requirements, > at least, on user identification, in order to make sure the > connectivity is provided to its customers with some reasonable load > (and without unpredictable overload), and on addressing since the > duly identified customer may benefit from some address/prefix > delagation from the ISP' TLA. I'm not sure if I see fundamental issues here. All the mechanisms which are meant to be used in the "ISP-assisted" method already provide pretty good means for identifying the user as the ISPs own customer -- either through the identification of IP address, or through other means. I didn't quite understand your comment on the load. That's of course certainly a factor, especially with tunnel-server -like models. Could you elaborate? All the mechanisms on the table for "ISP-assisted" case are already offering an address or prefix from the ISP's address block (in contrast to someone else's) so I'm not sure if I see your point. Or were you saying that we should spell out whether the user gets an address, a subnet /64 prefix or a site /48 prefix through the use of the mechanism? There are certainly differences there, but as the mechanisms are not meant to be permanent, I'm not sure how important that would be from the _ISP's_ perspective at least. > 4.1 Scenarios Evaluation > > I think the matrix should match here all the identfied scenarios > from 3GPP, UNMAN, ISP and ENT, and not a subset of them. The matrix is intended to include the specific scenarios from all the documents which have been identified, while avoiding duplication. Can you identify some scenarios which are missing? > Two columns maybe added: one dealing with "user identification" and > another one dealing with some prefix delagation means, in order to > actually complement the ISP column. I think we'd have to have a bit more precise idea what these would imply. Could you for example describe the requirements for user identification in each case (and rate the requirements)? What would be sufficinet user identification? And similar about prefix delegation. I guess what you're saying is that different scenarios require different amounts of addresses? And similarly, different mechanisms provide a different amount of addresses. Note that in many cases, there's no stopping from each host in the network running the mechanism on its own, getting an address from each tunnel. How would that get rated in the "amount of addresses" field? > 4.2 Mechanisms Evaluation > > I wonder here what is the real meaning of ISP support in terms of > features or functions. It just simply tries to imply whether support from the ISP is required or not. Of course, this is difficult to judge -- is e.g., a 6to4 relay somewhere in the network, by some other ISP considered "ISP support"? I don't count it as such. > Anyway, to get a more compltete picture, I would add columns for: > > -terminal/gateway: if the macnism applies to a terminal only, a gateway only or both > with the idea of complement ISP column: > -user identification > -address/prefix delegation means. Similarly, I would like to understand the terminal/gateway distinction better, i.e., how it would be useful for this comparison? When it comes to mechanisms proposed, Teredo is terminal-only, as well as is ISATAP (to a degree anyway -- some releases have provided support for prefix delegation etc. but I don't think this exists at the moment -- and would be terribly insecure if it did). TSP and STEP work in both. But with the current requirements, it's fine to just run the mechanism on the hosts themselves, not on the gateway, thus making this point a bit of moot. -- 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 Mar 12 11:54: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 LAA02742 for ; Fri, 12 Mar 2004 11:54:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1ptW-000O8D-Bh for v6ops-data@psg.com; Fri, 12 Mar 2004 16:52:22 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1ptL-000O41-CQ for v6ops@ops.ietf.org; Fri, 12 Mar 2004 16:52:11 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2CGqBwr010457 for ; Fri, 12 Mar 2004 09:52:11 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUH00HEP2UYLE@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 12 Mar 2004 09:52:11 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUH00L4J2UXW4@mail.sun.net> for v6ops@ops.ietf.org; Fri, 12 Mar 2004 09:52:10 -0700 (MST) Date: Fri, 12 Mar 2004 08:52:07 -0800 From: Alain Durand Subject: Re: Tunneling scenarios and mechanisms evaluation In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <991CC9E6-7445-11D8-85CB-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 12, 2004, at 12:13 AM, Pekka Savola wrote: >> Section 4.3: >> Therefore we get that Teredo and STEP is the lowest common >> denominator, after having to take a few tough issues in the >> consideration, with Teredo and TSP coming somewhat behind. >> >> Is there a typo here? Teredo is listed twice. > > This is intended. Based on the analysis, the requirement for Teredo > exists no matter what else we choose. The most preferable solutions > in addition to Teredo, however, seemed to be STEP and TSP. Ok, then it just that the sentence is a bit confusing, as you were looking at 4 tools, I thought that 2 of them were 'preferable' and the other 2 were 'not so preferable' > >> 2) >> This draft makes a big issue about direct connectivity and bases >> the some underlying recommendations on this. >> >> let me ask: is this really a requirement or yet another nice to have? >> What will break without direct connectivity? (in any of the scenarios) > > When your ISP doesn't offer IPv6 connectivity, but you would have to > take a "long leg" to get it, it seems that to be able to achieve > anything useful (e.g., peer to peer connectivity), direct connectivity > is a real requirement. > > On the other hand, when your ISP/operator is offering IPv6 > connectivity, in my eyes it is *not* a strict requirement (and not > reflected as such in the analysis), because the extra leg that needs > to be taken is probably in the order of 1-10 ms, not 30-300 ms. The > former is still usable, the latter not. The length of the 'long leg' may vary. Even if your ISP does not provide you with a tunnel server, this does not mean that you have to go to Canada to get one! If this model is successful, there will be a good chance that somebody near you could offer tunnel service. I can even see that as a commercial argument to incite people to switch ISP! This is an economic/deployment issue, not a protocol issue. >> If nothing really breaks, but things are just sub-optimal, then I >> would say this is not that bad. remember that we are talking about >> transition mechanisms, they DO NOT NEED to be perfect, if not we >> will never deploy fully IPv6... So, in a certain sense, suboptimal >> transition mechanisms can be good in the long run ;-) > > I agree that I don't (personally) think direct connectivity is a > requirement, for reasons you state, when your ISP/operator is offering > the tunnel service. I'm not sure which context you're discussing, but > if you're saying that direct connectivity is not a requirement in the > cases where your ISP is not offering a service, then I would have to > disagree due to concerns of scalability for large-scale deployment. Please elaborate on this point. If your ISP does not help but a neighboring ISP offer v6 tunnels, what is the problem? >> Note: With regard to TSP, we are not in a situation of take it or >> leave it. If the ban on developing tools is lifted, I'm convince >> that we could design something very quickly if the detail analysis >> of TSP shows improvement are necessary. > > Such ban does not exist, In practice it does exist. TSP, for example, did not have the same amount of review, collaborative work as a individual submission as if it would have been a wg item. > and IMHO it is clear that TSP (or the model > in general) requires a lot of improvement -- I reviewed it some time > ago, and sent feedback on the list. So far that I'd rather start from > scratch, while keeping the model intact.. But this is something that > would be very quickly doable, if we want to do it. Agree. Let's do it. >> 3- Isatap is really interesting in sparse deployment, which are >> early scenario. If this wg takes another 4 years to look at it, then >> its value would have long been depreciated... > > Did you mean s/really interesting/really only interesting/? Yes, typo. > The benefit of ISATAP is providing direct tunneling between the nodes. > This may be interesting in sparse deployment (compared to > going dual-stack; but in sparse deployment, tunnel server is also > fine), and some have even expressed interest in dense deployment > (compared to dual-stack: not wanting to go there; compared to tunnel > server: not overloading the server). IMHO, the dense deployment > scenario calls for dual-stack, and we should not be hacking to work > around that.. and sparse deployment can be facilitated by a tunnel > server. So, personally, I'm not sure if I see much applicability in > direct connectivity in this specific "ISP-assisted" context. Agreed, I have said for about 4 years now that one could use an internal TB to do this. > >> 5) >> what about the others, like 6to4? Do we still need this despite the >> issues with the relays? > > Unfortunately, I think yes -- in the unmanaged case where there is no > ISP support ... Well, if there were deployed 'neighborhood' TB that works well, the need for 6to4 will be somehow lower. - Alain. From owner-v6ops@ops.ietf.org Fri Mar 12 12:59: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 MAA08008 for ; Fri, 12 Mar 2004 12:59:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1qu2-000464-H3 for v6ops-data@psg.com; Fri, 12 Mar 2004 17:56:58 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1qtr-00041X-SV for v6ops@ops.ietf.org; Fri, 12 Mar 2004 17:56:47 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2CHueex026725; Fri, 12 Mar 2004 10:56:41 -0700 (MST) 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 i2CHucQ16524; Fri, 12 Mar 2004 18:56:38 +0100 (MET) Date: Fri, 12 Mar 2004 09:56:43 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt To: Pekka Savola Cc: Erik Nordmark , v6ops@ops.ietf.org, jonne.soininen@nokia.com, huitema@microsoft.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.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 > PPP doesn't support v6 prefix delegation, and there is no will to make > it so. Does v4 either? (I'm not sure -- but maybe that's some vendor > extension.) > > This approach works in the case where the ISP is advertising you an > IPv6 prefix using RA, and you want to extend it to another subnet. > On the other hand, in IPv4, there are no such advertisements. Either > the prefix is delegated somehow, or you use NAT. Ignoring the protocol aspects, I have an IPv4 (public) /29 prefix at home and it seems to work just fine. Why does IPv6 need to be different in this respect? What is broken or missing in IPv4 that needs to be fixed or added in IPv6? Before we can answer those questions we shouldn't do anything in this space IMHO. > What would you suggest as an (easy) replacement for v4 NATs? ND > proxying seems like an obvious solution in a scenario like this (that > is, when pure bridging does not work). DHCPv6 prefix delegation takes care of things at the CPE router. ndproxy also claims to solve the ZEROUTER problem - allowing multiple links in a small site without any explicit configuration of routers and without having to bridge everything together. Firstly this is utterly out of scope for this draft and this v6. Secondly, it doesn't really solve anything in this space. Basically the choice is between building ndproxy boxes which can't prevent loops, or build boxes which implement IEEE 802.1D spanning tree protocol. In the first case you have ndproxy boxes that, when you plug them together at home you can cause the equivalent of persistent L2 loops where packets circle forever and never die. In the second case you end up doing exactly what IEEE 802 bridges do; bridge the whole network together by defining how to do IEEE 802 over non-802 media. But as I said, that part is out of scope for this draft. Erik From owner-v6ops@ops.ietf.org Fri Mar 12 14:15:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11817 for ; Fri, 12 Mar 2004 14:15:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1s4t-000IuD-Oj for v6ops-data@psg.com; Fri, 12 Mar 2004 19:12:15 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1s4b-000IkL-01 for v6ops@ops.ietf.org; Fri, 12 Mar 2004 19:11:57 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CJBmH05615; Fri, 12 Mar 2004 11:11:48 -0800 X-mProtect: <200403121911> 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 smtpdriRQB2; Fri, 12 Mar 2004 11:11:46 PST Message-ID: <40520B7E.7020800@iprg.nokia.com> Date: Fri, 12 Mar 2004 11:11:58 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: IETF59 minutes and presentations References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, I just wanted to clarify one remark that was (correctly) attributed to me during the Thursday session: > Fred: If the question is must we have one solution, then I am cautious. but > can we find one solution, I would say yes. By "one solution", I was referring to the possibility of a _unified_ solution which might include aspects of several mechanisms, i.e., not necessarily just a single mechanism. (Perhaps this is the same as what Pekka referred to as a "hybrid" solution?) While I believe such a unified solution is possible, I have no way of predicting a timeframe and believe it is important that we continue to gain experience with mechanisms at-hand. Fred L. Templin ftemplin@iprg.nokia.com Pekka Savola wrote: >Hi, > >(co-chair hat on) > >The minutes and presentations have been made available at: > >http://www.6bone.net/v6ops/minutes/index.htm > >Please send corrections, omissions, etc., to the chairs within a week >(by Mar 19). > >Thanks! > > > > From owner-v6ops@ops.ietf.org Fri Mar 12 14:43: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 OAA14196 for ; Fri, 12 Mar 2004 14:43:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1sX0-0007B0-TS for v6ops-data@psg.com; Fri, 12 Mar 2004 19:41:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1sWZ-0006xY-Gt for v6ops@ops.ietf.org; Fri, 12 Mar 2004 19:40:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2CJemn13051; Fri, 12 Mar 2004 21:40:48 +0200 Date: Fri, 12 Mar 2004 21:40:48 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org, , Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Mar 2004, Erik Nordmark wrote: > > PPP doesn't support v6 prefix delegation, and there is no will to make > > it so. Does v4 either? (I'm not sure -- but maybe that's some vendor > > extension.) > > > > This approach works in the case where the ISP is advertising you an > > IPv6 prefix using RA, and you want to extend it to another subnet. > > On the other hand, in IPv4, there are no such advertisements. Either > > the prefix is delegated somehow, or you use NAT. > > Ignoring the protocol aspects, I have an IPv4 (public) /29 prefix at home and > it seems to work just fine. > > Why does IPv6 need to be different > in this respect? What is broken or missing in IPv4 that needs to be > fixed or added in IPv6? I think this seems rather obvious. IPv4 has NAT, IPv6 doesn't (and we hope it won't). Longer answer: assume that you have a gateway and a host behind it (or, think of it as two chained hosts, the first of which acts as a gateway). A very common home set-up. Now, let's assume IPv6 ISP would not want to do prefix delegation (for any of a number of reasons), or the home user wouldn't want to deal with the mess, or pay for the premium service to get it. Now, we have a few choices: a) ignore this case, b) develop IPv6 NAT, c) use ND proxying to give v6 access, to share the subnet, d) something else, what? > > What would you suggest as an (easy) replacement for v4 NATs? ND > > proxying seems like an obvious solution in a scenario like this (that > > is, when pure bridging does not work). > > DHCPv6 prefix delegation takes care of things at the CPE router. Yes -- but still NATs are being used in internal networks. Prefix delegation / routing is applicable to an extent, but doesn't carry you far enough (IMHO). > ndproxy also claims to solve the ZEROUTER problem - allowing multiple > links in a small site without any explicit configuration of routers > and without having to bridge everything together. > Firstly this is utterly out of scope for this draft and this v6. > Secondly, it doesn't really solve anything in this space. > Basically the choice is between building ndproxy boxes which can't prevent > loops, or build boxes which implement IEEE 802.1D spanning tree protocol. > In the first case you have ndproxy boxes that, when you plug them together > at home you can cause the equivalent of persistent L2 loops where packets > circle forever and never die. > In the second case you end up doing exactly what IEEE 802 bridges do; bridge > the whole network together by defining how to do IEEE 802 over non-802 media. > But as I said, that part is out of scope for this draft. Well, this is a nice rant about ND-proxy, but a bit out of scope from here. People have no doubt proposed something like ND-proxy in the ZEROUTER problem space, but if there is overlap, it doesn't really concern us that much. The current spec states that spanning tree in ND-proxy is optional. I would personally want to get rid of it altogether, to discourage its use in the more complex setups where it shouldn't be used in the first place. But that's beside the point here. What folks want is bridge two media together; the work is already in progress and nearing completion -- it will be pushed out in IPv6 WG whether we will it or not. So, the only choice in this document we have is whether we mention its usefulness in the specific problem space. I personally think it may be useful when the ISP (or you) for some reason doesn't want to do full prefix delegation. -- 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 Mar 12 14:56: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 OAA14732 for ; Fri, 12 Mar 2004 14:56:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1sjl-000DHz-1P for v6ops-data@psg.com; Fri, 12 Mar 2004 19:54:29 +0000 Received: from [206.123.31.135] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1sjK-000D5g-38 for v6ops@ops.ietf.org; Fri, 12 Mar 2004 19:54:02 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i2CJrvYo021326; Fri, 12 Mar 2004 14:53:57 -0500 (EST) Date: Fri, 12 Mar 2004 14:53:57 -0500 From: Florent Parent To: Soliman Hesham cc: v6ops@ops.ietf.org Subject: RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation Message-ID: <572180000.1079121237@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.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 Friday, March 12, 2004 02:54:41 -0500 Soliman Hesham wrote > > > It was raised before, when I first sent a pointer to STEP. > > > > I'm not 100% sure of the conclusion. It seems like L2TP architecture > > is relatively heavy-weight (UDP tunneling, PPP, L2TP service > > architecture, etc.), except when the ISP and the client is already > > using it for some other purpose. > > => That was one of my main reasons for asking. It's much faster > to use something that already exists, deployed, and in fact > used a lot today by ISPs and enterprise networks. Hesham, As you are saying, if its already there (L2TP infrastructure), then this route can certainly make sense. But if an ISP doesn't have an L2TP infrastructure, deploying a tunnel broker solution is simpler. To me, this is analogous to the BGP tunneling (6PE) stuff: if you already have MPLS-IPv4 backbone, BGP tunneling is attractive for IPv6 deployment to CE. Otherwise, doesn't make sense to deploy MPLS to get IPv6 to your customers. Florent From owner-v6ops@ops.ietf.org Fri Mar 12 15:32: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 PAA17245 for ; Fri, 12 Mar 2004 15:32:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1tI6-0005qQ-7D for v6ops-data@psg.com; Fri, 12 Mar 2004 20:29:58 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1tHv-0005kl-DJ for v6ops@ops.ietf.org; Fri, 12 Mar 2004 20:29:47 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17135; Fri, 12 Mar 2004 15:29:44 -0500 (EST) Message-Id: <200403122029.PAA17135@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-02.txt Date: Fri, 12 Mar 2004 15:29:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Security Considerations for 6to4 Author(s) : P. Savola Filename : draft-ietf-v6ops-6to4-security-02.txt Pages : 39 Date : 2004-3-12 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-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-6to4-security-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-6to4-security-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-3-12152657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-6to4-security-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-security-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152657.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Mar 12 18:04: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 SAA25136 for ; Fri, 12 Mar 2004 18:04:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1vf0-000ACK-2D for v6ops-data@psg.com; Fri, 12 Mar 2004 23:01:46 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1veh-0009u1-Be for v6ops@ops.ietf.org; Fri, 12 Mar 2004 23:01:27 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2CN1Nex011546; Fri, 12 Mar 2004 16:01:24 -0700 (MST) 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 i2CN1KQ14969; Sat, 13 Mar 2004 00:01:21 +0100 (MET) Date: Fri, 12 Mar 2004 15:01:25 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Tunneling scenarios and mechanisms evaluation To: Pekka Savola Cc: Alain Durand , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > 5) > > what about the others, like 6to4? Do we still need this despite the > > issues with the relays? > > Unfortunately, I think yes -- in the unmanaged case where there is no > ISP support ... ...and there is no IPv4 NAT. I wonder if we can simplify things by using Teredo in the case when there is no ISP support whether or not there is a NAT. If that makes sense we would have to worry as much about how 6to4 and Teredo boxes talk to each other, but only about Teredo and native talk to each other. Erik From owner-v6ops@ops.ietf.org Fri Mar 12 18:11: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 SAA26191 for ; Fri, 12 Mar 2004 18:11:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1vmy-000EoH-QR for v6ops-data@psg.com; Fri, 12 Mar 2004 23:10:00 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1vmf-000EdJ-UQ for v6ops@ops.ietf.org; Fri, 12 Mar 2004 23:09:41 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2CN9fwr021348 for ; Fri, 12 Mar 2004 16:09:41 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUH003DCKC47L@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 12 Mar 2004 16:09:41 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUH004RQKC3EC@mail.sun.net> for v6ops@ops.ietf.org; Fri, 12 Mar 2004 16:09:40 -0700 (MST) Date: Fri, 12 Mar 2004 15:09:37 -0800 From: Alain Durand Subject: Re: IETF59 minutes and presentations In-reply-to: To: Pekka Savola Cc: jonne.soininen@nokia.com, v6ops@ops.ietf.org Message-id: <5520920A-747A-11D8-99C4-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: multipart/alternative; boundary="Boundary_(ID_gnnL04WRcylGtaIFCt7wPw)" References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Boundary_(ID_gnnL04WRcylGtaIFCt7wPw) Content-type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7BIT From the minutes: - Unmanaged user wants to do p2p with another Direct "short-cut" connectivity very important If no support from the direct ISP Automatic tunneling works automatically: Teredo requires "Server" with low b/w reqs Tunnel broker would help, if the users could find a free broker nearby If there would be incentive for broker deployment, a "nearest broker discovery" process would also help Unless the user is really determined, the user is lost without automatic tunneling ==> I do not see how this scenario is fundamentally different from the road warrior using IPv4 on a dial-up modem. In many cases, he can call a well known centralized 1-800 number that will create a suboptimal long path or he will have a phone number for a local PoP, that will hopefully provide shorter RTT. There is no 'find me the nearest PoP' protocol here. If we look at a tunnel broker as a virtual IPv6 ISP, can someone point me how things are different? - Alain. --Boundary_(ID_gnnL04WRcylGtaIFCt7wPw) Content-type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7BIT CourierFrom the minutes: - Unmanaged user wants to do p2p with another Direct "short-cut" connectivity very important If no support from the direct ISP Automatic tunneling works automatically: Teredo requires "Server" with low b/w reqs Tunnel broker would help, if the users could find a free broker nearby If there would be incentive for broker deployment, a "nearest broker discovery" process would also help Unless the user is really determined, the user is lost without automatic tunneling ==> I do not see how this scenario is fundamentally different from the road warrior using IPv4 on a dial-up modem. In many cases, he can call a well known centralized 1-800 number that will create a suboptimal long path or he will have a phone number for a local PoP, that will hopefully provide shorter RTT. There is no 'find me the nearest PoP' protocol here. If we look at a tunnel broker as a virtual IPv6 ISP, can someone point me how things are different? - Alain. --Boundary_(ID_gnnL04WRcylGtaIFCt7wPw)-- From owner-v6ops@ops.ietf.org Fri Mar 12 18:46: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 SAA28950 for ; Fri, 12 Mar 2004 18:46:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1wKh-0008bi-5Y for v6ops-data@psg.com; Fri, 12 Mar 2004 23:44:51 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1wKW-0008Ue-5I for v6ops@ops.ietf.org; Fri, 12 Mar 2004 23:44:40 +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 i2CNiSng020350; Fri, 12 Mar 2004 15:44:28 -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 i2CNiPQ20285; Sat, 13 Mar 2004 00:44:25 +0100 (MET) Date: Fri, 12 Mar 2004 15:44:30 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt To: Pekka Savola Cc: Erik Nordmark , v6ops@ops.ietf.org, jonne.soininen@nokia.com, huitema@microsoft.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.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 this seems rather obvious. IPv4 has NAT, IPv6 doesn't (and we > hope it won't). I think things are a bit more subtle than that. My house has neither an IPv4 NAT or an IPv6 NAT. There are products that do IPv4 NAT and (I'm pretty sure) IPv6 NAT. The issue is under what circumstances one is required hence how prevalent they become. In IPv4 NATs are required due to issues related to the size of the address space, which we've removed as a reason in IPv6. Unfortunately that doesn't mean that other motivations for NAT go away in IPv6 :-( > Longer answer: assume that you have a gateway and a host behind it > (or, think of it as two chained hosts, the first of which acts as a > gateway). A very common home set-up. > > Now, let's assume IPv6 ISP would not want to do prefix delegation (for > any of a number of reasons), or the home user wouldn't want to deal > with the mess, or pay for the premium service to get it. If an IPv6 ISP wants to get customers to pay per device/IP address, why would they hand out a /64 to begin with? They'd just hand out a /128. Unfortunately the only technical solution which can handle that is an IPv6 NAT. I question the benefit of having a solution for the /64 case that doesn't handle the /128 case. > Now, we have a few choices: a) ignore this case, b) develop IPv6 NAT, > c) use ND proxying to give v6 access, to share the subnet, d) > something else, what? If you believe we need to handle the /64 and /128 case, does that mean that we also should develop workarounds for ISPs that filter port 25 in this WG? As a standards organization can't prevent ISPs from filtering in whatever bizarre way that think solves their business needs. What we can do is specifying standards that make it easy for ISPs and customers to do things in a way that preserves the transparency of the network. DHCP prefix delegation is part of that picture. http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html is useful reading in this space. > Yes -- but still NATs are being used in internal networks. Prefix > delegation / routing is applicable to an extent, but doesn't carry you > far enough (IMHO). The recommendation in RFC 3177 is one way to handle this. That doesn't solve the ease of having routers autoconfigure inside the home site. IEEE 802 bridging solves this, and so do some of the things discussed in the ZEROUTER context. But as I said this is out of scope of this WG as far as I know. (Please correct me if I am wrong.) > Well, this is a nice rant about ND-proxy, but a bit out of scope from > here. I already stated that it was out of scope in my note. I take it you then agree that we should remove all mention of ndproxy from the draft in question since you agree with me that it is out of scope :-) FWIW I take exception to you calling my explanation a "rant" - that is pretty close to an ad-hominum attack IMHO. Perhaps I should complain about your behavior to the WG co-chairs :-( > People have no doubt proposed something like ND-proxy in the > ZEROUTER problem space, but if there is overlap, it doesn't really > concern us that much. The current spec states that spanning tree in > ND-proxy is optional. I would personally want to get rid of it > altogether, to discourage its use in the more complex setups where it > shouldn't be used in the first place. But that's beside the point > here. What folks want is bridge two media together; the work is > already in progress and nearing completion -- it will be pushed out in > IPv6 WG whether we will it or not. Odd - when I was in the IPv6 WG last week there was some discussion about the fact that ndproxy and SEND can not be made to work together. (Conclusion seems to be that proxy NA can be secured using SEND in the case where there is a trust relationship between the host and the proxy, but there is no such relationship in ndproxy hence it can not be secured.) The odd thing is that there wasn't a groundswell reaction in the IPv6 WG saying "we really need ndproxy - how do we get SEND fixed" - there seemed to be almost complete disinterest in ndproxy as far as I could tell. > So, the only choice in this document we have is whether we mention its > usefulness in the specific problem space. I personally think it may > be useful when the ISP (or you) for some reason doesn't want to do > full prefix delegation. I though you said it was out of scope for the v6ops WG above, so it shouldn't be in the document. We already have DHCP prefix delegation as a solution to the problem at the connection to the ISP. How many solutions do we need in this space? I feel the need to share this quote as this point in time: It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. -- Jon Postel Erik From owner-v6ops@ops.ietf.org Fri Mar 12 19:03: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 TAA00291 for ; Fri, 12 Mar 2004 19:03:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1wb7-000Ipq-GN for v6ops-data@psg.com; Sat, 13 Mar 2004 00:01:49 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1waY-000IXn-SH for v6ops@ops.ietf.org; Sat, 13 Mar 2004 00:01:14 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2D01Ewr008739 for ; Fri, 12 Mar 2004 17:01:14 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUH00M4CMQ1K1@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 12 Mar 2004 17:01:14 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUH00K72MQ03K@mail.sun.net> for v6ops@ops.ietf.org; Fri, 12 Mar 2004 17:01:13 -0700 (MST) Date: Fri, 12 Mar 2004 16:01:09 -0800 From: Alain Durand Subject: Re: IETF59 minutes and presentations In-reply-to: To: Pekka Savola , jonne.soininen@nokia.com Cc: v6ops@ops.ietf.org Message-id: <88887880-7481-11D8-99C4-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 12, 2004, at 1:17 AM, Pekka Savola wrote: > Hi, > > (co-chair hat on) > > The minutes and presentations have been made available at: > > http://www.6bone.net/v6ops/minutes/index.htm Dear wg chairs, I just read those minutes on the hesitations for one vs many transition solutions. Have we made much progress since Minneapolis march 2002? (ban on Ngtrans work on tools) Have we made much progress since Grenoble interim meeting (Feb. 1999) were we tried to go down to one transition mechanism and failed... Yes, we now have some scenarios, but they are far form being all completed. And at the end of this exercise, we are still trying to answer the same questions, do we need automatic vs assisted mechanisms and how much should we rely on the infrastructure put in place by ISPs. But still no simple recommendation on how to do transition. - Alain. From owner-v6ops@ops.ietf.org Fri Mar 12 21:04:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06436 for ; Fri, 12 Mar 2004 21:04:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1ySF-000861-94 for v6ops-data@psg.com; Sat, 13 Mar 2004 02:00:47 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1yS2-0007sT-Cj for v6ops@ops.ietf.org; Sat, 13 Mar 2004 02:00:34 +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-md50000000353.tmp for ; Sat, 13 Mar 2004 03:05:43 +0100 Message-ID: <08b501c4089f$8bf1fa10$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: IETF59 minutes and presentations Date: Sat, 13 Mar 2004 03:04:39 +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, Sat, 13 Mar 2004 03:05:43 +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.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, Regarding the minutes: - Actually I said something like "... every client has IPv6 = connectivity available even when moving thru different networks. I'm = having this problem when traveling and I can sort it out most of the = time because have the expertise, but this is not the case for regular = users. We need a kind of auto-transition feature that choose the right = protocol from a set, no needed user intervention, but ensure = connectivity even if this is bad (worst case, for example, IPv6 over = HTTP, of course I will not suggest it, only in very extreme cases)." - After "Not so sure how many mechanisms must be specified.", I = indicated "There are many possible networks, many possible scenarios, I = insist that we must ensure that the client can have IPv6 connectivity in = any case, automatically, a kind of auto-transition, of course, trying to = use the best possible solution". - In my presentation, I used "nomadic" instead of mobile. I believe is = important the distinction, to avoid mixing the concept with IP mobility. = Also "visited networks". I didn't said should deal with IDS, it was more = a could (to learn about possible attacks and protect against them, even = requiring a security policy update). Regarding my last point on the IPv6 distributed security issue, the = design team, we have already started to work, and have decided a set of = milestones, expecting to have them documented for the next meeting. If = someone is interested, please let me know directly, or use the list = (ipv6ds@v6ops.euro6ix.net). Last but not least, if possible use Jordi instead Palet (I hate this one = !, worst case Jordi Palet), if possible (in any case, we should uniform = the minutes in this sense). Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: Cc: Sent: Friday, March 12, 2004 10:17 AM Subject: IETF59 minutes and presentations > Hi, >=20 > (co-chair hat on) >=20 > The minutes and presentations have been made available at: >=20 > http://www.6bone.net/v6ops/minutes/index.htm >=20 > Please send corrections, omissions, etc., to the chairs within a week > (by Mar 19). >=20 > Thanks! > ********************************** 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 Mar 12 21:05: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 VAA06508 for ; Fri, 12 Mar 2004 21:05:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1yV3-0009nq-Kj for v6ops-data@psg.com; Sat, 13 Mar 2004 02:03:41 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1yUs-0009h3-Jt for v6ops@ops.ietf.org; Sat, 13 Mar 2004 02:03:30 +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 47-md50000000353.tmp for ; Sat, 13 Mar 2004 03:08:39 +0100 Message-ID: <08cd01c4089f$f4de7b20$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <941BA0BF46DB8F4983FF7C8AFE800BC236D5C8@ftrdmel3.rd.francetelecom.fr> Subject: Re: Tunneling scenarios and mechanisms evaluation Date: Sat, 13 Mar 2004 03:07:35 +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, Sat, 13 Mar 2004 03:08:39 +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.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, I agree with Alain, that the way proto-41 fits. I'm not sure if we can = call this NAT traversal, so may be rewording to NAT traversal or = proto-41-forwarding ? Regards, Jordi ----- Original Message -----=20 From: "BAUDOT Alain FTRD/DMI/CAE" To: "Pekka Savola" ; Sent: Friday, March 12, 2004 4:14 PM Subject: RE : Tunneling scenarios and mechanisms evaluation Hi, Here are my few comments on the document: 1. Introduction I think Tunnel Broker (TB) should part of the analysis, as well. 3.2 Unmanaged Networks Case 2 seems to match ISP case 2a (where the connection network cannot = be upgraded), unless it is a compilation of unman case C and ISP case = 2a. Anyway, in one case the ISP cannot cooperate with unman network, = while it can do so in the other case. The appropriate solution may then = meet different requirements, e.g. oportunistic mechanism may or may be = not suitable.=20 I guess this need some clarification. "NAT traversal must be supported." This is not true if the tunnel ends = in the gateway where the NAT function is usually located. I think this = is important, since the solution to deploy does not need to deal with = complexity of NAT traversal. 3.4 ISP Scenarios "ISPs do not have specific scenarios which need to be addresses which haven't been already mentioned" ISP scenario case 2b, where the ISP backbone is not IPv6 capable, is not = discussed here. Anyway, I think that there is a large difference between "obtaining" = connectivity, as discussed in the previous section 3.3, and "providing" = a connectivity as an ISP. ISPs have strong requirements, at least, on = user identification, in order to make sure the connectivity is provided = to its customers with some reasonable load (and without unpredictable = overload), and on addressing since the duly identified customer may = benefit from some address/prefix delagation from the ISP' TLA. 4.1 Scenarios Evaluation I think the matrix should match here all the identfied scenarios from = 3GPP, UNMAN, ISP and ENT, and not a subset of them. Two columns maybe added: one dealing with "user identification" and = another one dealing with some prefix delagation means, in order to = actually complement the ISP column. 4.2 Mechanisms Evaluation I wonder here what is the real meaning of ISP support in terms of = features or functions. Anyway, to get a more compltete picture, I would add columns for:=20 -terminal/gateway: if the macnism applies to a terminal only, a gateway = only or both with the idea of complement ISP column:=20 -user identification -address/prefix delegation means. Regards, Alain.=20 -----Message d'origine----- De : owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] De la = part de Pekka Savola Envoy=E9 : jeudi 11 mars 2004 09:14 =C0 : v6ops@ops.ietf.org Objet : Re: Tunneling scenarios and mechanisms evaluation Whoops -- forgive my slip. The address below was where it WILL be=20 available. For now, it's at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-tunneling-00.txt Sorry -- and thanks to Tim for pointing the obvious! :) On Thu, 11 Mar 2004, Pekka Savola wrote: [...] > http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-00.tx > t >=20 > Abstract > This memo analyses the v6ops scenarios/analysis work (Unmanaged, > 3GPP, ISP and Enterprise) for their requirements for tunneling > solutions, and analyses the proposed mechanisms on how they might = fit > in these requirements, and discusses possibilities for choosing > solution(s). >=20 >=20 >=20 --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ********************************** 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 Mar 12 23:10:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11495 for ; Fri, 12 Mar 2004 23:10:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B20R6-000NrC-F3 for v6ops-data@psg.com; Sat, 13 Mar 2004 04:07:44 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B20Qv-000NkW-M4 for v6ops@ops.ietf.org; Sat, 13 Mar 2004 04:07:33 +0000 content-class: urn:content-classes:message Subject: RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation Date: Fri, 12 Mar 2004 23:07:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQIa8Q0qdlB0yI6ReePyqrbYAYKkwAQ05JQ From: "Soliman Hesham" To: "Florent Parent" Cc: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Hesham, > As you are saying, if its already there (L2TP=20 > infrastructure), then this=20 > route can certainly make sense. But if an ISP doesn't have an L2TP=20 > infrastructure, deploying a tunnel broker solution is simpler. =3D> Respectfully disagree. Many hosts already have L2TP,=20 you're asking them to implement another protocol.=20 If the operator doesn't have then he can have it, it's=20 already available in products. An existing protocol that=20 is already implemented is better than standardising=20 a new protocol because it might be simpler to implement. >=20 > To me, this is analogous to the BGP tunneling (6PE) stuff:=20 > if you already=20 > have MPLS-IPv4 backbone, BGP tunneling is attractive for=20 > IPv6 deployment to=20 > CE. Otherwise, doesn't make sense to deploy MPLS to get IPv6 to your=20 > customers. =3D> I'd like BGP tunnelling mechanisms to be independent=20 of MPLS as much as possible. We can also do the same thing for OSPF, IS-IS ...etc. IMHO these are the best auto tunnelling mechanisms for the core. Hesham >=20 > Florent >=20 From owner-v6ops@ops.ietf.org Sat Mar 13 00:45: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 AAA14645 for ; Sat, 13 Mar 2004 00:45:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B21us-000JY1-Oa for v6ops-data@psg.com; Sat, 13 Mar 2004 05:42:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B21uh-000JT4-Cc for v6ops@ops.ietf.org; Sat, 13 Mar 2004 05:42:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D5fWv20212; Sat, 13 Mar 2004 07:41:44 +0200 Date: Sat, 13 Mar 2004 07:41:32 +0200 (EET) From: Pekka Savola To: Alain Durand cc: jonne.soininen@nokia.com, Subject: Re: IETF59 minutes and presentations In-Reply-To: <88887880-7481-11D8-99C4-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Mar 2004, Alain Durand wrote: > I just read those minutes on the hesitations for one vs many transition > solutions. > > Have we made much progress since Minneapolis march 2002? (ban on > Ngtrans work on tools) > Have we made much progress since Grenoble interim meeting (Feb. 1999) > were we tried to go down to one transition mechanism and failed... Actually, the point about one vs many was completely misunderstood by the WG (or completely misrepresented by me). Stay tuned for a clarification. The point was basically -- could we cut down the number of mechanisms to configured tunneling, 6to4, Teredo, and XXX.. where XXX would have to be picked or defined somehow... or would we need MORE than these four. > Yes, we now have some scenarios, but they are far form being all > completed. And at the end of this exercise, we are still trying to > answer the same questions, do we need automatic vs assisted > mechanisms and how much should we rely on the infrastructure put in > place by ISPs. But still no simple recommendation on how to do > transition. I think the scenarios themselves, except for enterprise, are quite near to completion. The difficult part, always, has been trying to cut down the number of transition mechanisms, or to find a a very low number of common mechanisms. The scenarios could have completed a year or two ago if we accepted that the total number of transition mechanisms was something like 5-6... -- 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 Sat Mar 13 00:53: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 AAA15107 for ; Sat, 13 Mar 2004 00:53:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B224U-000Oez-Jy for v6ops-data@psg.com; Sat, 13 Mar 2004 05:52:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B224J-000OZg-Kd for v6ops@ops.ietf.org; Sat, 13 Mar 2004 05:52:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D5qGk20349; Sat, 13 Mar 2004 07:52:16 +0200 Date: Sat, 13 Mar 2004 07:52:16 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <08cd01c4089f$f4de7b20$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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > I agree with Alain, that the way proto-41 fits. I'm not sure if we > can call this NAT traversal, so may be rewording to NAT traversal or > proto-41-forwarding ? Alain did not mention proto 41 forwarding at all.. so I'm not sure where you got that. NAT traversal must work in a reasonably high number of different NAT boxes. Proto-41 forwarding does not. Of course, it can still be used as an optimization in the case it's being supported, but the case where it matters is basically the tunnel-server like approaches (TSP and STEP) which already support or will support NAT traversal. -- 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 Sat Mar 13 01:01: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 BAA15561 for ; Sat, 13 Mar 2004 01:01:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B22Bf-0002rw-P1 for v6ops-data@psg.com; Sat, 13 Mar 2004 05:59:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B22BU-0002hf-Nb for v6ops@ops.ietf.org; Sat, 13 Mar 2004 05:59:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D5xdg20403; Sat, 13 Mar 2004 07:59:39 +0200 Date: Sat, 13 Mar 2004 07:59:39 +0200 (EET) From: Pekka Savola To: Alain Durand cc: jonne.soininen@nokia.com, Subject: Re: IETF59 minutes and presentations In-Reply-To: <5520920A-747A-11D8-99C4-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Mar 2004, Alain Durand wrote: > ==> I do not see how this scenario is fundamentally different > from the road warrior using IPv4 on a dial-up modem. > In many cases, he can call a well known centralized 1-800 number > that will create a suboptimal long path or he will have a phone number > for a local PoP, that will hopefully provide shorter RTT. > There is no 'find me the nearest PoP' protocol here. > > If we look at a tunnel broker as a virtual IPv6 ISP, > can someone point me how things are different? Road warrior has made a contract with an ISP, which is his back-up long-distance number. If we assume that all the users would have to make a contract/signup/whatever with a long-distance virtual IPv6 ISP, then this would probably be the case. What I'd like to get is when the local ISP is offering the tunnel service, the user would get directed there automatically, and would become aware of it so that he could start using that service instead (instead of using long-distance service). That is, I think we want to avoid these "long-distance calls", and we want to make it easier for the user to notice whether there is support in the local ISP. Additionally, the configuration of tunneling IMHO should be close to zero-config. (Looking up tunnel server addresses, signup forms, or whatever in the web is unacceptable -- and that's one reason why the tunnel broker model hasn't seemed to fly so well so far..) If we want to make this easy for the users, that seems like something that would have to be done. Especially if we insisted that we wouldn't need Teredo. Hopefully I answered your question.. -- 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 Sat Mar 13 01:10: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 BAA15857 for ; Sat, 13 Mar 2004 01:10:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B22KX-0007xN-Ds for v6ops-data@psg.com; Sat, 13 Mar 2004 06:09:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B22KM-0007ra-9I for v6ops@ops.ietf.org; Sat, 13 Mar 2004 06:08:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D68pG20539; Sat, 13 Mar 2004 08:08:51 +0200 Date: Sat, 13 Mar 2004 08:08:51 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Alain Durand , Subject: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Mar 2004, Erik Nordmark wrote: > > > 5) > > > what about the others, like 6to4? Do we still need this despite the > > > issues with the relays? > > > > Unfortunately, I think yes -- in the unmanaged case where there is no > > ISP support ... > > ...and there is no IPv4 NAT. > > I wonder if we can simplify things by using Teredo in the case when there is > no ISP support whether or not there is a NAT. > > If that makes sense we would have to worry as much about how 6to4 > and Teredo boxes talk to each other, but only about Teredo and > native talk to each other. Yes -- I think 6to4 is an optimization for the unmanaged case when there happens to be no NAT. The chief advantage of 6to4 is its simplicity (a minimal -- but insecure -- implementation can be about 5-10 lines of code!), and the ability to provide a /48 prefix, instead of being run individually on each system. This could be useful especially in the cases where the (NAT) gateways would implement some form of IPv6 support. As Teredo cannot support more than one address, it would not be applicable in this scope. The disadvantage is that it's an additional mechanism, and not applicable except in the space where NAT is often being used; also, the security properties are worse with 6to4 than Teredo (due to its simplicity). Depending on how strongly people feel about the necessity of this optimization and providing an easy means for (NAT) gateway vendors to add basic IPv6 support, 6to4 could be retained, or we could try to figure out whether Teredo spec needs to be re-evaluated for the case when there is no NAT traversal at all. Thoughts? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat Mar 13 02:13:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00846 for ; Sat, 13 Mar 2004 02:13:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B23Hu-000B7C-OF for v6ops-data@psg.com; Sat, 13 Mar 2004 07:10:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B23Hi-000B0k-P2 for v6ops@ops.ietf.org; Sat, 13 Mar 2004 07:10:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D7ABb21202; Sat, 13 Mar 2004 09:10:11 +0200 Date: Sat, 13 Mar 2004 09:10:11 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org, , Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Mar 2004, Erik Nordmark wrote: > > I think this seems rather obvious. IPv4 has NAT, IPv6 doesn't (and we > > hope it won't). > > I think things are a bit more subtle than that. > My house has neither an IPv4 NAT or an IPv6 NAT. > There are products that do IPv4 NAT and (I'm pretty sure) IPv6 NAT. > The issue is under what circumstances one is required hence how > prevalent they become. > In IPv4 NATs are required due to issues related to the size of the > address space, which we've removed as a reason in IPv6. > Unfortunately that doesn't mean that other motivations for NAT go > away in IPv6 :-( NAT is used for a lot more than just due to a lack of address space. They're also used as security devices (out of scope here), *AND* as an easy means to extend a subnet. A common example is a WLAN-capable router, which is doing NAT.. just because it's a simple thing it can do. Similarly, if a host would want to connect to an another host, and share the prefix (compared to manually delegating another subprefix to the router?!!), NAT would be the simplest thing to deploy. We need to kill that conception. Bridging is a nice way in many cases, and when it doesn't work, ND-proxying appears to work just as well. > > Longer answer: assume that you have a gateway and a host behind it > > (or, think of it as two chained hosts, the first of which acts as a > > gateway). A very common home set-up. > > > > Now, let's assume IPv6 ISP would not want to do prefix delegation (for > > any of a number of reasons), or the home user wouldn't want to deal > > with the mess, or pay for the premium service to get it. > > If an IPv6 ISP wants to get customers to pay per device/IP address, > why would they hand out a /64 to begin with? They'd just hand out a > /128. > Unfortunately the only technical solution which can handle > that is an IPv6 NAT. > I question the benefit of having a solution for the /64 case that doesn't > handle the /128 case. There is no stopping them if they want to get paid by the /128, of course. I'm thinking this from the perspective of the ISP: what's the simplest thing for them to deploy. It certainly doesn't seem to be prefix delegation. RA-based advertisement on a point-to-point link seems like an obvious means. I'm not even sure how one would go about giving the user a /128 in the first place. So, what I'm trying to see is the easiest way an ISP could deal with "basic IPv6 usage case" (seems to be a /64 advertisement), which would still encourage for the better service (/48 prefix delegation). The case where the ISP absolutely wants just support one IP address is out of scope here. Another angle here is how are you going to deal with the case where you have to have stacked gateways. E.g., the home gateway is doing prefix delegation, and advertising /64's on its links. One of the nodes at home is also a router, and behind it is a host. How do you get v6 to that host behind the node? That's a very common scenario today. I think it in most cases you could probably move that node to the same link, but in some cases (e.g., mismatching media) it might not be possible. > > Yes -- but still NATs are being used in internal networks. Prefix > > delegation / routing is applicable to an extent, but doesn't carry you > > far enough (IMHO). > > The recommendation in RFC 3177 is one way to handle this. > That doesn't solve the ease of having routers autoconfigure inside > the home site. IEEE 802 bridging solves this, and so do some of > the things discussed in the ZEROUTER context. > But as I said this is out of scope of this WG as far as I know. > (Please correct me if I am wrong.) Autoconfiguring router networks inside the home site is IMHO out of scope here. But I think the point of ND proxying was precisely the fact that IEEE 802 bridging does not work in all the cases. (And if it did, we wouldn't be needing ND-proxy in the first place.) > > Well, this is a nice rant about ND-proxy, but a bit out of scope from > > here. > > I already stated that it was out of scope in my note. > I take it you then agree that we should remove all mention of ndproxy > from the draft in question since you agree with me that it is out of > scope :-) I meant that discussing how ND-proxying is applicable in ZEROUTER etc. environments appears to be out of scope. The scenario has identified one specific case where it is useful. That is an entirely different scenario than plugging 5 ND-proxies in the network in any way one sees fit and assuming they should work just fine (which seemed to be what you were implying, but I could have read it wrong). > FWIW I take exception to you calling my explanation a "rant" - that > is pretty close to an ad-hominum attack IMHO. Perhaps I should complain > about your behavior to the WG co-chairs :-( Discussing the applicability of ND-proxy in ZEROUTER environments appeared to be rather out of scope here.. because we're not discussing applying it in those environments. So, the point of your anti- ND-proxying note was IMHO well written, but not something that belonged here -- rather maybe IPv6 WG which is working on ND-proxy. Sorry if I called that "ranting"; I don't see that as a too negative term myself -- perhaps because I feel I'm ranting a lot myself on some occasions ;-) > > People have no doubt proposed something like ND-proxy in the > > ZEROUTER problem space, but if there is overlap, it doesn't really > > concern us that much. The current spec states that spanning tree in > > ND-proxy is optional. I would personally want to get rid of it > > altogether, to discourage its use in the more complex setups where it > > shouldn't be used in the first place. But that's beside the point > > here. What folks want is bridge two media together; the work is > > already in progress and nearing completion -- it will be pushed out in > > IPv6 WG whether we will it or not. > > Odd - when I was in the IPv6 WG last week there was some discussion > about the fact that ndproxy and SEND can not be made to work together. > (Conclusion seems to be that proxy NA can be secured using SEND in the case > where there is a trust relationship between the host and the proxy, but > there is no such relationship in ndproxy hence it can not be secured.) > The odd thing is that there wasn't a groundswell reaction in the IPv6 WG saying > "we really need ndproxy - how do we get SEND fixed" - there seemed to be > almost complete disinterest in ndproxy as far as I could tell. Well, I guess I interpreted the silence differently -- I thought "do we need SEND in the scenarios we're going to use ND-proxy?" When you consider the applicability of SEND, it's probably highly useful in environments like enterprise networks, server farms, etc. (in case someone breaks in there and would start hijacking etc.), in public WLAN (and other) environments where you deal with untrusted users, and similar cases. It is probably not so necessary in a home network, or in the point-to-point link between the ISP and a home network (where the ISP can DoS/MitM/etc. you in any case). So, my gut feeling is that people think -- ok, it's fine that ND-proxy doesn't work with SEND. Let's not try to fix either SEND or ND-proxy. The critical issue here, IMHO, is whether the hosts which are unaware of whether ND-proxy is used or not can enable SEND or not. That is, we wouldn't want the vendors to turn SEND off by default if that meant the hosts would not work with ND-proxy. I don't think this is the case, but I could be wrong. I think this depends on what kind of "triggers" SEND-capable nodes get from the network before generating CGA addresses etc. -- do the e.g., wait for the first SEND-enabled RA/NA, or whatever -- or do they always start immediately (which might be a bit redundant until SEND is commonly deployed). (But this is something that should probably go to either SEND or IPv6 WG...) > > So, the only choice in this document we have is whether we mention its > > usefulness in the specific problem space. I personally think it may > > be useful when the ISP (or you) for some reason doesn't want to do > > full prefix delegation. > > I though you said it was out of scope for the v6ops WG above, so it shouldn't > be in the document. Discussing its applicability in ZEROUTER etc. enviroments is out of scope, but ND-proxy, in simpler setups, could be in scope here. > We already have DHCP prefix delegation as a solution to the problem at > the connection to the ISP. How many solutions do we need in this space? I believe this is a separate problem. (FWIW, I'd like to have something simpler than DHCP prefix delegation in any case, maybe along the lines of draft-bykim-ipv6-hpd-01.txt, but DHCPv6 probably has already gained too much momentum to make it worth the effort..) -- 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 Sat Mar 13 02:25: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 CAA02006 for ; Sat, 13 Mar 2004 02:25:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B23Ug-000Hlt-GR for v6ops-data@psg.com; Sat, 13 Mar 2004 07:23:38 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B23UV-000HgV-AC for v6ops@ops.ietf.org; Sat, 13 Mar 2004 07:23:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D7NOP21382; Sat, 13 Mar 2004 09:23:24 +0200 Date: Sat, 13 Mar 2004 09:23:24 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: Tunneling scenarios and mechanisms evaluation In-Reply-To: <991CC9E6-7445-11D8-85CB-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'm only responding on direct connectivity / far-away tunnel brokers, as I think rest of the points are either trivial or already addressed in other mails.. On Fri, 12 Mar 2004, Alain Durand wrote: > > When your ISP doesn't offer IPv6 connectivity, but you would have to > > take a "long leg" to get it, it seems that to be able to achieve > > anything useful (e.g., peer to peer connectivity), direct connectivity > > is a real requirement. > > > > On the other hand, when your ISP/operator is offering IPv6 > > connectivity, in my eyes it is *not* a strict requirement (and not > > reflected as such in the analysis), because the extra leg that needs > > to be taken is probably in the order of 1-10 ms, not 30-300 ms. The > > former is still usable, the latter not. > > The length of the 'long leg' may vary. Even if your ISP does not > provide you with a tunnel server, this does not mean that you have > to go to Canada to get one! If this model is successful, there will > be a good chance that somebody near you could offer tunnel service. > I can even see that as a commercial argument to incite people to > switch ISP! This is an economic/deployment issue, not a protocol > issue. AFAICS, the commercial argument is the other way around. That is, if another ISP close by is offering free service, there is no incentive to switch to that ISP in the first place. On the other hand, if an ISP is offering the service to only its own customers, the others don't get it anyway, causing the long leg to a first "free" server. The economics and deployment issues are unfortunately very much against the 3rd party tunnel server model... even more so than deploying e.g. 6to4 relays. And deployment issues seem to be the fundamental part of the business of this WG. There is no use depending on a specific model, if it seems like that that model would have trouble in getting deployed. > > I agree that I don't (personally) think direct connectivity is a > > requirement, for reasons you state, when your ISP/operator is offering > > the tunnel service. I'm not sure which context you're discussing, but > > if you're saying that direct connectivity is not a requirement in the > > cases where your ISP is not offering a service, then I would have to > > disagree due to concerns of scalability for large-scale deployment. > > Please elaborate on this point. If your ISP does not help but > a neighboring ISP offer v6 tunnels, what is the problem? The problem is that the neighboring ISP won't offer v6 tunnel to you because you're not his customer. There has been very little 6to4 relay deployment. And that's even better for the ISPs to deploy, because the abuse etc. that happens doesn't come from you 2001:f00::/32 address space. The ISPs in general *don't* want to offer their production space address space to every John Doe that comes knocking on their door. Having followed this relay / tunnel deployment for a while, it seems like that offering these kind of services to outsiders is not seen as very interesting thing to do. Sure, there are some who do it in any case, but more often than not, they're rather far away (and to optimize that, a "broker discovery" mechanism would not hurt) because they're so scarce. If Internet was still this co-operative, non-profit environment, this kind of "open for all" tunnel broker model would be very efficient.. but this is not the case, unfortunately.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat Mar 13 02:43: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 CAA02852 for ; Sat, 13 Mar 2004 02:43:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B23lV-0000Xr-NJ for v6ops-data@psg.com; Sat, 13 Mar 2004 07:41:01 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B23kI-000PoV-TV for v6ops@ops.ietf.org; Sat, 13 Mar 2004 07:39:47 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4F79E18E0 for ; Sat, 13 Mar 2004 02:39:45 -0500 (EST) Date: Sat, 13 Mar 2004 02:39:45 -0500 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040313073945.4F79E18E0@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Sat, 13 Mar 2004 08:08:51 +0200 (EET), Pekka Savola wrote: > > The chief advantage of 6to4 is its simplicity (a minimal -- but > insecure -- implementation can be about 5-10 lines of code!), and the > ability to provide a /48 prefix, instead of being run individually on > each system. This could be useful especially in the cases where the > (NAT) gateways would implement some form of IPv6 support. As Teredo > cannot support more than one address, it would not be applicable in > this scope. The 6to4 edge routers I've been using for the last two or three years do this. I for one would be unhappy to lose this capability. > The disadvantage is that it's an additional mechanism, and not > applicable except in the space where NAT is often being used; also, > the security properties are worse with 6to4 than Teredo (due to its > simplicity). With all due respect, the second clause of that sentence is a cheap shot. 6to4 can be implemented well or poorly and can be used well or poorly. Packet filtering works just fine on an edge router if one bothers to turn it on. I do not believe that giving 6to4's job to Terado would really solve any security problems; at best it would transform them, and in some cases it would probably make them worse by replacing a simple solution with a more complex one. > Depending on how strongly people feel about the necessity of this > optimization and providing an easy means for (NAT) gateway vendors to > add basic IPv6 support, 6to4 could be retained, or we could try to > figure out whether Teredo spec needs to be re-evaluated for the case > when there is no NAT traversal at all. Terado is excessively complex for the case of a user who wants IPv6 capability from an IPv4-only ISP and has the ability to replace the NAT box. Yes, Terado could probably be used in this case instead of 6to4; pigs also fly just fine, given sufficient thrust [RFC1925], but that doesn't make either of these a good idea. Please retain 6to4. From owner-v6ops@ops.ietf.org Sat Mar 13 06:36: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 GAA10319 for ; Sat, 13 Mar 2004 06:36:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B27OV-000GaH-Je for v6ops-data@psg.com; Sat, 13 Mar 2004 11:33:31 +0000 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B27OJ-000GTQ-9G for v6ops@ops.ietf.org; Sat, 13 Mar 2004 11:33:19 +0000 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 13 Mar 2004 11:33:18 +0000 (GMT) Date: Sat, 13 Mar 2004 11:33:16 +0000 From: David Malone To: Pekka Savola Cc: Alain Durand , v6ops@ops.ietf.org Subject: Re: Tunneling scenarios and mechanisms evaluation Message-ID: <20040313113316.GA11526@walton.maths.tcd.ie> References: <991CC9E6-7445-11D8-85CB-00039376A6AA@sun.com> 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.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 Sat, Mar 13, 2004 at 09:23:24AM +0200, Pekka Savola wrote: > There has been very little 6to4 relay deployment. Hating to bang on about it, but I've written up my count of 6to4 relay routers. I'd written it in a style that might suit the Cisco IPJ, but I'm not sure how well suited it is. I guess it might be of interest to the working group, if it were in a different format? Any comments welcome. David. Counting 6to4 Relay Routers David Malone, CNRI, Dublin Institute of Technology. Introduction ------------ In the IPv6 world, significant effort has been spent devising ways for people to use IPv6 in the absence of a complete IPv6 infrastructure. Maybe the best known example of this involves forming a virtual point-to-point link by encapsulating IPv6 packets in IPv4 packets and sending them from one point in the existing Internet to another. This is technology that we can all relate to: it looks just like any other point-to-point link. Some issues have become apparent with the use of point-to-point tunnels. First, they have properties like the traditional links on which they are based: they need the agreement of parties at either end regarding configuration details and arrangements must be come to over addressing and routing. The second issue is that, unlike real point-to-point links, a tunnel can stretch between arbitrary points in the Internet resulting in highly unpredictable link properties. This can lead to packets taking a scenic route, and so people now prefer to only use tunnels between topologically close sites. 6to4 is another way of routing IPv6 packets over the IPv4 Internet. 6to4 has been described elsewhere[1], so we will just give a flavour of it here. Much like point-to-point tunnelling, sites using 6to4 have a router responsible for decapsulating and encapsulating packets. However, 6to4 assigns IPv6 addresses based on a public IPv4 address of this 6to4 router. Thus, when a 6to4 aware node gets an IPv6 packet destined to any 6to4 address, it immediately knows which IPv4 address the packet should be tunnelled to. 6to4 aware nodes that are willing to perform this tunnelling advertise a route to 2002::/16, the IPv6 prefix containing all 6to4 addresses. These nodes are known as 'relay routers' and form a bridge between the IPv6 and IPv4 Internet. This explains how packets make their way from the IPv6 Internet to 6to4 networks, and also how packets are routed between 6to4 networks associated with different IPv4 addresses. The remaining part of the puzzle is how packets from 6to4 networks get back to the IPv6 Internet. Originally, you had to know the IPv4 address of a relay router[2] and you would configure your 6to4 router to encapsulate any traffic to the IPv6 Internet and send it to a specific 6to4 router. Naturally it would be better if this could be done automatically, without having to choose a relay. In a similar way to how relay routers advertise themselves in the IPv6 network, a relay router can now advertise itself in an IPv4 network by advertising the address 192.88.99.1[3]. This is an IPv4 anycast address that could be thought of as representing the IPv6 Internet in the IPv4 network. 6to4's design does work around some of the problems that have come up with point-to-point tunnels. First, it can be automatically configured once you have a public IPv4 address without any configuration to be performed "at the other end". Second, it uses the existing IPv4 and IPv6 routing infrastructure to find the nearest 6to4 relay router, providing some automatic adaptation to the state of the network. Note that this may not completely eliminate scenic routing as the relay router may be some distance from the packet's eventual destination. From this picture of 6to4, it should be clear that the relay routers are essential to the operation of 6to4, in a similar way that the DNS root servers are essential to the operation of DNS. The more relay routers that are available throughout the network, the smoother and more reliable the operation of 6to4 will be. Consequently, the the number of 6to4 relay routers available is something that impacts on the ability of 6to4 to provide IPv6 connectivity. How to count relay routers -------------------------- There are a small number of 6to4 relay routers that make themselves very obvious by advertising themselves in the IPv4 BGP routing tables using the anycast address 192.88.99.1. Perhaps the best known of these is the one at SWITCH, the Swiss Education and Research Network, but on any day there are a number of networks offering 6to4 relay services. One snapshot from the Route Views project[4] shows the following autonomous systems (ASs) advertising 192.88.99.0/24: AS559 SWITCH AS1741 FUNET AS3246 SONGNETWORKS AS8379 CYBERNET-AG AS9033 ECIX-AS AS12859 NL-BIT AS17832 SIXNGIX-AS-KR AS30155 KLU However, this is not the whole story. To begin with, the list of visible relay routers in IPv6 BGP may not be the same, for example, by looking at several IPv6 looking-glasses we see the following ASs advertising routes to the 6to4 prefix, 2002::/16: AS109 CISCOSYSTEMS AS559 SWITCH AS786 JANET AS9264 ASNET AS12859 NL-BIT AS17715 CHTTL-TW AS24895 FUBAR More interesting is that some network providers may choose to provide a 6to4 relay that is only available internally, by advertising the 192.88.99.0/24 and/or 2002::/16 within their own AS (or possibly only to selected BGP peers). In these cases it is less likely that these routes will ever be visible in a project like Route Views. However, if 6to4 turns out to be a popular method for the connection of IPv6 end sites, it seems a significant number of 6to4 users could be supported by such private relays. So, how can we estimate the number of 6to4 relays that are actually in service? The ideal way would be to traceroute to 192.88.99.1 from various points in the Internet and see where those traceroutes lead. Similarly, tracerouting from points in the IPv6 Internet to some address in the 2002::/16 range would reveal the IPv6 side of 6to4 routers. This could be undertaken using a facility like PlanetLab[5]. However, a practical way presents itself that does not require any special facilities. Consider what happens if we traceroute in with a source address that is a 6to4 address. As packets (ICMP TTL exceed) are sent from each hop, they will make their way to the nearest relay router accepting packets for 2002::/16. This router will encapsulate the packet and send it to the appropriate IPv4 address. By collecting these IPv4 packets at their destination and examining the source address used for encapsulation, we will get the addresses of the 6to4 relays along the path we are tracerouting. Targets for such a traceroute are relatively easy to find. In the IPv6 world a network provider is generally represented by a single prefix in the global IPv6 BGP tables. This routing table is still relatively compact, containing less than 1000 prefixes. By tracerouting to the first address in each range, it seems likely that a packet will make its way into the organisation's network and the ICMP message will make its way to the nearest relay to that organisation. Doing the count --------------- Performing the count described above is relatively straight forward. A list of prefixes can be obtained from your nearest friendly IPv6 BGP speaker. Packets can be collected on a target 6to4 host using tcpdump, and traceroute can be run with appropriate options. The IPv4 addresses can then easily be extracted. The whole process can be completed in a few hours without stressing a modest DSL connection. In practice, most of the returned packets are accounted for by a rather small number of encapsulating IPv4 addresses. Among these is 192.88.99.1, which obviously may account for a number of relays. As an anycast address, 192.88.99.1 should probably not appear as a source address, however for reasons related to both operational and software it does. Trying to resolve the relays replying using 192.88.99.1 seems important, as it may account for a significant number of relays. This can also be done with traceroute. Consider a node that traceroutes to a 6to4 address - the last hop before the decapsulating router will be the relay router. Just as with IPv4 loose source routing, IPv6 provides a way to traceroute via a particular node (using routing headers). So, by tracerouting via nodes whose relay router replied using the the anycast address, we can find IPv6 addresses associated with that relay router. Note that a single relay router may have many IPv4 and IPv6 addresses. Manual inspection suggested that IPv4 addresses (other than 192.88.99.1) represented distinct single relays. This is probably due to source address selection being applied consistently for a fixed IPv4 destination when encapsulation takes place on a particular router. For the relay routers that replied using the anycast IPv4 address, we also determined their IPv6 addresses. This list contained groups of addresses that obviously belonged to the same router. This is due to the traceroute replies being generated by a particular interface, probably the one on which the expiring packet arrived. To account for these duplicates, only the first 32 bits of the IPv6 address was considered, and then these were checked in the whois database to eliminate duplicates caused by relays that use both 6bone (3ffe::) and production (2001::) prefixes. Results of the count -------------------- The first count was performed in July 2003 and produced a list of 26 different IPv4 addresses, including 192.88.99.1. Trying to resolve 192.88.99.1, using the technique we described above, produced a list of 12 /32s. Of these 12, two were SWITCH. This gives a total of 37 different relay routers identified by the count. One relay router was systematically missed because it was within two hops of the node performing the count. The count was repeated in January 2004 and again produced a list of 26 different IPv4 addresses. However, this time a 18 different /32s were found behind the anycast address (without the duplication of SWITCH). Interestingly, a number of distinct relays were found in the same /32, in space assigned by RIPE to IXPs. This suggests a figure around 44 relay routers. In this second count, two relay routers were missed because they were within two hops of the node performing the count. The following breakdown was produced by attempting to assign relay routers to countries using whois. The breakdown includes the relays that were systematically missed. July '03 January '04 AU 1 1 CA 0 1 CH 1 2 CZ 1 0 DE 4 9 EE 1 1 ES 0 1 EU 0 2 FI 2 2 GR 0 1 IE 3 3 IT 0 1 JP 2 1 KR 3 2 LT 2 2 LU 0 1 NL 4 1 NO 1 1 PT 1 2 SE 2 2 TH 1 3 TW 2 1 UK 3 4 US 4 2 Total 38 46 Conclusions and Remaining Issues -------------------------------- It seems that, in addition to the handful of publicly advertised 6to4 relays that are available, there are also quite a number of additional private relays in operation. This is good news for people using 6to4, meaning they are more likely to get a router close to them. The list of countries does seem to be biased towards Europe. At least part of this is likely to be systematic bias - the count was performed from a European IPv6 network, and packets are more likely to take transit through European networks, and so find European relays. It is also possible that the deployment of native IPv6 is further ahead in other parts of the world, and consequently 6to4 relays are consequently less common. What isn't clear from this count is how wide the domain of attraction for each of these relays is, how many clients each serves and how the traffic load is distributed between them. As commented earlier, a large number of packets are being returned through a small number of relays, particularly one relay in Japan. Perhaps the biggest weakness of this count is that it is possible (though unlikely) that the relays that take packets from the IPv6 Internet to the IPv4 Internet are completely unrelated to the relays that send packets in the opposite direction. Some asymmetry has already been noticed in this area, where publicly advertised relays often see much more traffic going from IPv4->IPv6 than IPv6->IPv4. A reasonable explanation for this is that many sites with native IPv6 connectivity also have some IPv4 connectivity, and so can run a private relay. Consequently, it would certainly be interesting to know how many hops the average user has to go to find a machine listening on 192.88.99.1. References ---------- [1] Connecting IPv6 Routing Domains Over the IPv4 Internet Carpenter, Moore and Fink, Cisco Internet Protocol Journal Volume 3, Number 1, March 2000 [2] Public 6to4 Relay Routers Sayer, http://www.kfu.com/~nsayer/6to4/ [3] An Anycast Prefix for 6to4 Relay Routers Huitema, RFC 3068, June 2001. [4] University of Oregon Route Views Project, Advanced Network Technology Center, http://www.routeviews.org/ [5] PlanetLab, http://www.planet-lab.org/ From owner-v6ops@ops.ietf.org Sat Mar 13 06:41: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 GAA10466 for ; Sat, 13 Mar 2004 06:41:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B27Ui-000KB3-9Y for v6ops-data@psg.com; Sat, 13 Mar 2004 11:39:56 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B27UW-000K5H-PK for v6ops@ops.ietf.org; Sat, 13 Mar 2004 11:39:44 +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 i2DBdhOr025716 for ; Sat, 13 Mar 2004 11:39:43 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 LAA17681 for ; Sat, 13 Mar 2004 11:39:39 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2DBdck32709 for v6ops@ops.ietf.org; Sat, 13 Mar 2004 11:39:38 GMT Date: Sat, 13 Mar 2004 11:39:38 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Tunneling scenarios and mechanisms evaluation Message-ID: <20040313113938.GC32481@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <991CC9E6-7445-11D8-85CB-00039376A6AA@sun.com> <20040313113316.GA11526@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040313113316.GA11526@walton.maths.tcd.ie> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk How do you know how many relay routers exist? All you can count are ones that ISPs/NRENs choose to advertise beyond their borders? Tim On Sat, Mar 13, 2004 at 11:33:16AM +0000, David Malone wrote: > On Sat, Mar 13, 2004 at 09:23:24AM +0200, Pekka Savola wrote: > > There has been very little 6to4 relay deployment. > > Hating to bang on about it, but I've written up my count of 6to4 > relay routers. I'd written it in a style that might suit the Cisco > IPJ, but I'm not sure how well suited it is. I guess it might be > of interest to the working group, if it were in a different format? > > Any comments welcome. > > David. > > > Counting 6to4 Relay Routers > David Malone, CNRI, Dublin Institute of Technology. > > Introduction > ------------ > > In the IPv6 world, significant effort has been spent devising ways > for people to use IPv6 in the absence of a complete IPv6 infrastructure. > Maybe the best known example of this involves forming a virtual > point-to-point link by encapsulating IPv6 packets in IPv4 packets > and sending them from one point in the existing Internet to another. > This is technology that we can all relate to: it looks just like > any other point-to-point link. > > > Some issues have become apparent with the use of point-to-point > tunnels. First, they have properties like the traditional links on > which they are based: they need the agreement of parties at either > end regarding configuration details and arrangements must be come > to over addressing and routing. The second issue is that, unlike > real point-to-point links, a tunnel can stretch between arbitrary > points in the Internet resulting in highly unpredictable link > properties. This can lead to packets taking a scenic route, and > so people now prefer to only use tunnels between topologically > close sites. > > > 6to4 is another way of routing IPv6 packets over the IPv4 Internet. > 6to4 has been described elsewhere[1], so we will just give a flavour > of it here. Much like point-to-point tunnelling, sites using 6to4 > have a router responsible for decapsulating and encapsulating > packets. However, 6to4 assigns IPv6 addresses based on a public > IPv4 address of this 6to4 router. Thus, when a 6to4 aware node gets > an IPv6 packet destined to any 6to4 address, it immediately knows > which IPv4 address the packet should be tunnelled to. 6to4 aware > nodes that are willing to perform this tunnelling advertise a route > to 2002::/16, the IPv6 prefix containing all 6to4 addresses. These > nodes are known as 'relay routers' and form a bridge between the > IPv6 and IPv4 Internet. > > > This explains how packets make their way from the IPv6 Internet to > 6to4 networks, and also how packets are routed between 6to4 networks > associated with different IPv4 addresses. The remaining part of the > puzzle is how packets from 6to4 networks get back to the IPv6 > Internet. Originally, you had to know the IPv4 address of a relay > router[2] and you would configure your 6to4 router to encapsulate > any traffic to the IPv6 Internet and send it to a specific 6to4 > router. Naturally it would be better if this could be done > automatically, without having to choose a relay. In a similar way > to how relay routers advertise themselves in the IPv6 network, a relay > router can now advertise itself in an IPv4 network by advertising > the address 192.88.99.1[3]. This is an IPv4 anycast address that > could be thought of as representing the IPv6 Internet in the IPv4 > network. > > > 6to4's design does work around some of the problems that have come > up with point-to-point tunnels. First, it can be automatically > configured once you have a public IPv4 address without any configuration > to be performed "at the other end". Second, it uses the existing > IPv4 and IPv6 routing infrastructure to find the nearest 6to4 relay > router, providing some automatic adaptation to the state of the > network. Note that this may not completely eliminate scenic routing > as the relay router may be some distance from the packet's eventual > destination. > > > >From this picture of 6to4, it should be clear that the relay routers > are essential to the operation of 6to4, in a similar way that the > DNS root servers are essential to the operation of DNS. The more > relay routers that are available throughout the network, the smoother > and more reliable the operation of 6to4 will be. Consequently, the > the number of 6to4 relay routers available is something that impacts > on the ability of 6to4 to provide IPv6 connectivity. > > > How to count relay routers > -------------------------- > > There are a small number of 6to4 relay routers that make themselves > very obvious by advertising themselves in the IPv4 BGP routing > tables using the anycast address 192.88.99.1. Perhaps the best known > of these is the one at SWITCH, the Swiss Education and Research > Network, but on any day there are a number of networks offering > 6to4 relay services. One snapshot from the Route Views project[4] > shows the following autonomous systems (ASs) advertising 192.88.99.0/24: > > AS559 SWITCH > AS1741 FUNET > AS3246 SONGNETWORKS > AS8379 CYBERNET-AG > AS9033 ECIX-AS > AS12859 NL-BIT > AS17832 SIXNGIX-AS-KR > AS30155 KLU > > > However, this is not the whole story. To begin with, the list of visible > relay routers in IPv6 BGP may not be the same, for example, by looking at > several IPv6 looking-glasses we see the following ASs advertising routes > to the 6to4 prefix, 2002::/16: > > AS109 CISCOSYSTEMS > AS559 SWITCH > AS786 JANET > AS9264 ASNET > AS12859 NL-BIT > AS17715 CHTTL-TW > AS24895 FUBAR > > > More interesting is that some network providers may choose to provide > a 6to4 relay that is only available internally, by advertising the > 192.88.99.0/24 and/or 2002::/16 within their own AS (or possibly > only to selected BGP peers). In these cases it is less likely that > these routes will ever be visible in a project like Route Views. > However, if 6to4 turns out to be a popular method for the connection > of IPv6 end sites, it seems a significant number of 6to4 users could > be supported by such private relays. > > > So, how can we estimate the number of 6to4 relays that are actually > in service? The ideal way would be to traceroute to 192.88.99.1 > from various points in the Internet and see where those traceroutes > lead. Similarly, tracerouting from points in the IPv6 Internet to > some address in the 2002::/16 range would reveal the IPv6 side of > 6to4 routers. This could be undertaken using a facility like > PlanetLab[5]. > > > However, a practical way presents itself that does not require any > special facilities. Consider what happens if we traceroute in with > a source address that is a 6to4 address. As packets (ICMP TTL > exceed) are sent from each hop, they will make their way to the > nearest relay router accepting packets for 2002::/16. This router > will encapsulate the packet and send it to the appropriate IPv4 > address. By collecting these IPv4 packets at their destination and > examining the source address used for encapsulation, we will get > the addresses of the 6to4 relays along the path we are tracerouting. > > > Targets for such a traceroute are relatively easy to find. In the > IPv6 world a network provider is generally represented by a single > prefix in the global IPv6 BGP tables. This routing table is still > relatively compact, containing less than 1000 prefixes. By > tracerouting to the first address in each range, it seems likely > that a packet will make its way into the organisation's network and > the ICMP message will make its way to the nearest relay to that > organisation. > > > Doing the count > --------------- > > Performing the count described above is relatively straight forward. > A list of prefixes can be obtained from your nearest friendly IPv6 > BGP speaker. Packets can be collected on a target 6to4 host using > tcpdump, and traceroute can be run with appropriate options. The > IPv4 addresses can then easily be extracted. The whole process can > be completed in a few hours without stressing a modest DSL connection. > > > In practice, most of the returned packets are accounted for by a > rather small number of encapsulating IPv4 addresses. Among these > is 192.88.99.1, which obviously may account for a number of relays. > As an anycast address, 192.88.99.1 should probably not appear as a > source address, however for reasons related to both operational and > software it does. > > > Trying to resolve the relays replying using 192.88.99.1 seems > important, as it may account for a significant number of relays. > This can also be done with traceroute. Consider a node that traceroutes > to a 6to4 address - the last hop before the decapsulating router > will be the relay router. Just as with IPv4 loose source routing, > IPv6 provides a way to traceroute via a particular node (using > routing headers). So, by tracerouting via nodes whose relay router > replied using the the anycast address, we can find IPv6 addresses > associated with that relay router. > > > Note that a single relay router may have many IPv4 and IPv6 addresses. > Manual inspection suggested that IPv4 addresses (other than > 192.88.99.1) represented distinct single relays. This is probably > due to source address selection being applied consistently for a > fixed IPv4 destination when encapsulation takes place on a particular > router. > > > For the relay routers that replied using the anycast IPv4 address, > we also determined their IPv6 addresses. This list contained groups > of addresses that obviously belonged to the same router. This is > due to the traceroute replies being generated by a particular > interface, probably the one on which the expiring packet arrived. > To account for these duplicates, only the first 32 bits of the IPv6 > address was considered, and then these were checked in the whois > database to eliminate duplicates caused by relays that use both > 6bone (3ffe::) and production (2001::) prefixes. > > > Results of the count > -------------------- > > The first count was performed in July 2003 and produced a list of > 26 different IPv4 addresses, including 192.88.99.1. Trying to > resolve 192.88.99.1, using the technique we described above, produced > a list of 12 /32s. Of these 12, two were SWITCH. This gives a total > of 37 different relay routers identified by the count. One relay > router was systematically missed because it was within two hops of > the node performing the count. > > > The count was repeated in January 2004 and again produced a list > of 26 different IPv4 addresses. However, this time a 18 different > /32s were found behind the anycast address (without the duplication > of SWITCH). Interestingly, a number of distinct relays were found > in the same /32, in space assigned by RIPE to IXPs. This suggests > a figure around 44 relay routers. In this second count, two relay > routers were missed because they were within two hops of the node > performing the count. > > > The following breakdown was produced by attempting to assign relay > routers to countries using whois. The breakdown includes the relays > that were systematically missed. > > > July '03 January '04 > AU 1 1 > CA 0 1 > CH 1 2 > CZ 1 0 > DE 4 9 > EE 1 1 > ES 0 1 > EU 0 2 > FI 2 2 > GR 0 1 > IE 3 3 > IT 0 1 > JP 2 1 > KR 3 2 > LT 2 2 > LU 0 1 > NL 4 1 > NO 1 1 > PT 1 2 > SE 2 2 > TH 1 3 > TW 2 1 > UK 3 4 > US 4 2 > Total 38 46 > > > Conclusions and Remaining Issues > -------------------------------- > > It seems that, in addition to the handful of publicly advertised > 6to4 relays that are available, there are also quite a number of > additional private relays in operation. This is good news for > people using 6to4, meaning they are more likely to get a router > close to them. > > > The list of countries does seem to be biased towards Europe. At > least part of this is likely to be systematic bias - the count was > performed from a European IPv6 network, and packets are more likely > to take transit through European networks, and so find European > relays. It is also possible that the deployment of native IPv6 is > further ahead in other parts of the world, and consequently 6to4 > relays are consequently less common. > > > What isn't clear from this count is how wide the domain of attraction > for each of these relays is, how many clients each serves and how > the traffic load is distributed between them. As commented earlier, > a large number of packets are being returned through a small number > of relays, particularly one relay in Japan. > > > Perhaps the biggest weakness of this count is that it is possible > (though unlikely) that the relays that take packets from the IPv6 > Internet to the IPv4 Internet are completely unrelated to the relays > that send packets in the opposite direction. Some asymmetry has > already been noticed in this area, where publicly advertised > relays often see much more traffic going from IPv4->IPv6 than > IPv6->IPv4. A reasonable explanation for this is that many sites > with native IPv6 connectivity also have some IPv4 connectivity, and > so can run a private relay. Consequently, it would certainly be > interesting to know how many hops the average user has to go to > find a machine listening on 192.88.99.1. > > > References > ---------- > > [1] Connecting IPv6 Routing Domains Over the IPv4 Internet > Carpenter, Moore and Fink, > Cisco Internet Protocol Journal Volume 3, Number 1, March 2000 > > [2] Public 6to4 Relay Routers > Sayer, > http://www.kfu.com/~nsayer/6to4/ > > [3] An Anycast Prefix for 6to4 Relay Routers > Huitema, > RFC 3068, June 2001. > > [4] University of Oregon Route Views Project, > Advanced Network Technology Center, > http://www.routeviews.org/ > > [5] PlanetLab, > http://www.planet-lab.org/ From owner-v6ops@ops.ietf.org Sat Mar 13 06:52:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11059 for ; Sat, 13 Mar 2004 06:52:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B27ep-0000If-FP for v6ops-data@psg.com; Sat, 13 Mar 2004 11:50:23 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B27ee-0000CB-S2 for v6ops@ops.ietf.org; Sat, 13 Mar 2004 11:50:12 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i2DBo7G29183; Sat, 13 Mar 2004 03:50:07 -0800 From: bill Message-Id: <200403131150.i2DBo7G29183@karoshi.com> Subject: Re: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and To: pekkas@netcore.fi (Pekka Savola) Date: Sat, 13 Mar 2004 03:50:07 -0800 (PST) Cc: Erik.Nordmark@sun.com (Erik Nordmark), Alain.Durand@sun.com (Alain Durand), v6ops@ops.ietf.org In-Reply-To: from "Pekka Savola" at Mar 13, 2004 08:08:51 AM 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.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > the security properties are worse with 6to4 than Teredo (due to its > simplicity). > > Pekka Savola reading the above sentence... its the most humourous thing i've read all week. perhaps what Pekka intended to say was that the security properties of 6to4 are more knowable than Teredo due to its simplicity. Most folks believe that if you can know the properties of some bit of code, its more secure than code that is too large/complex to understand well. Or perhaps Pekka ment something else... --bill From owner-v6ops@ops.ietf.org Sat Mar 13 08:18: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 IAA13987 for ; Sat, 13 Mar 2004 08:18:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B28yh-000Jma-DJ for v6ops-data@psg.com; Sat, 13 Mar 2004 13:14:59 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B28yV-000JgZ-KM for v6ops@ops.ietf.org; Sat, 13 Mar 2004 13:14:47 +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 8D8E8871C; Sat, 13 Mar 2004 14:14:44 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Alain Durand'" Cc: Subject: RE: Tunneling scenarios and mechanisms evaluation Date: Sat, 13 Mar 2004 14:14:02 +0100 Organization: Unfix MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQIzGckvCEg1un/QIS/N+rPwm+hAAAJ7Ssw Message-Id: <20040313131444.8D8E8871C@purgatory.unfix.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Savola wrote: Giving some insight on this as seen from the SixXS project... If you think this is marketing hype thing alike skip this message there is no commercial thing in the project and it is all on a free/goodwill basis with the main target of providing IPv6 deployment. > > Please elaborate on this point. If your ISP does not help but > > a neighboring ISP offer v6 tunnels, what is the problem? > > The problem is that the neighboring ISP won't offer v6 tunnel to you > because you're not his customer. In general this is actually what we are doing. The red line though is that people should provide full contact address information and that their endpoint has a latency of less than 100ms. > There has been very little 6to4 relay deployment. And that's even > better for the ISPs to deploy, because the abuse etc. that happens > doesn't come from you 2001:f00::/32 address space. The ISPs in > general *don't* want to offer their production space address space to > every John Doe that comes knocking on their door. I personally think that that is actually one of the things *against* 6to4, it is totally untraceable/debuggable as one never knows where packets are going to flow to/from as there just might be one or even more hidden 6to4 relays along the route. Next to that apparently many users *demand* RIR space, they think it is cooler or works better. There are even people who are proud to have inet6num's ;) As for abuse, in case of SixXS, it has been at an all time low fortunatly and we haven't heared a complaint for quite some while (*knock on wood*) but that could be because of the quite strictness with which users are accepted and the fact that they know that they are out and are kept out of the system when they have commited it. > Having followed this relay / tunnel deployment for a while, it seems > like that offering these kind of services to outsiders is not seen as > very interesting thing to do. Sure, there are some who do it in any > case, but more often than not, they're rather far away (and to > optimize that, a "broker discovery" mechanism would not hurt) because > they're so scarce. The 'discovery' mechanism we use for the SixXS project is quite simple though absolutely not automated: users signs up through the website and gives it's details, thus we know his address+country + IP, then after being approved they can request a tunnel, again we get an IP. Then the system 'asks' the POPs who is willing to serve that IP. The POPs that want to serve the user then display them selves and the user can select it, again a manual approval based on lowest latency/least hops and some other criteria. The approvals are web or cli based thus admins only select from some default answers. > If Internet was still this co-operative, non-profit environment, this > kind of "open for all" tunnel broker model would be very efficient.. > but this is not the case, unfortunately.. SixXS currently has 11 POPs across europe and for the exception of two of those they are all open and providing IPv6 to quite a number of users who seem to be very happy about the service, you only hear them complain when it breaks, which happens only about once a year when there is some odd hardware failure. Generally a POP only serves the users of that country, unless it is the closest POP for a user where there are no POPs in the country. Or in numbers: (http://www.sixxs.net/misc/usage/) The 1747 users span 44 countries. The 1649 tunnels span 35 countries. Currently there are 923 subnet delegations over the tunnels. In the these numbers deleted and disabled tunnels are not counted. I do have to add that we are apparently in quite a unique situation as as far as I know of there are not that many public Tunnel Brokers in the US/Asian parts of the world. First 27 pages of a google on "tunnel broker", sorted on region and order of appearance in google: US: 1 Hurricane (http://ipv6.he.net) 2 Freenet6 (http://www.freenet6.net) Europe: - - BT Exact (http://tb.ipv6.btexact.com) - - Dolphins (http://tunnelbroker.as8758.net) - - XS26 (http://www.xs26.net) - - ngNet.it (http://tb.ngnet.it) - - Estpak (http://www.ipv6.estpak.ee) - - Euro6ix (http://www.euro6ix.org:8080/tb/) - - FCCN/IPv6-TF.pt (http://ipv6-tf.com.pt/tunnel/) - - SixXS (http://www.sixxs.net) - - Berkom (http://fix.ipv6.berkom.de/cgi-bin/tb.pl) - - Netgroup.dk (http://noodle.ngdc.net/~hroi/tb/) - - Coredumps (http://tb.coredumps.org/) Asia/Australia: - - Manis (Beta; http://tbroker.manis.net.my) - - SingNet (http://tunnel-broker.singnet.com.sg) - - AARNet (http://broker.aarnet.edu.au) - - SJTU.edu.cn (http://tb.sjtu.edu.cn/) - - ASCC (http://tb.ipv6.ascc.net/) - - NGIX (http://tb.ngix.ne.kr/cgi-bin/tb.pl) 19 and there are probably a couple of others, as to how and if they work and how stable they are that is up to their respective users. It might be interresting to know how many active/used tunnels are being used around the globe though as that might indicate a bit if there is a demand and how it could be fulfilled. Statistics on how these TB's are used could also prove interresting. Policies of these brokers might differ btw to be open or closed or they only might serve to a certain region and have other regulations in hand. Next to that there are bound to be private TB's which are not to be found in google. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFMJGgAAlwcAnisbsI75IPYnbnVTs1SqwxkV USPPAJ9MwuxWg52PZTeaxtuixjrbGzZAqA== =h9IU -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sat Mar 13 11:28: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 LAA20431 for ; Sat, 13 Mar 2004 11:28:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2Bwd-000Ed0-1B for v6ops-data@psg.com; Sat, 13 Mar 2004 16:25:03 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2BwQ-000EUE-O3 for v6ops@ops.ietf.org; Sat, 13 Mar 2004 16:24:51 +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 45-md50000000358.tmp for ; Sat, 13 Mar 2004 17:30:01 +0100 Message-ID: <0b9901c40918$48ec3040$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20040313131444.8D8E8871C@purgatory.unfix.org> Subject: Re: Tunneling scenarios and mechanisms evaluation Date: Sat, 13 Mar 2004 17:28:56 +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, Sat, 13 Mar 2004 17:30:01 +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.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 There is one more TB at=20 http://tb.consulintel.euro6ix.org and http://www.6sos.org Regards, Jordi ----- Original Message -----=20 From: "Jeroen Massar" To: "'Pekka Savola'" ; "'Alain Durand'" = Cc: Sent: Saturday, March 13, 2004 2:14 PM Subject: RE: Tunneling scenarios and mechanisms evaluation > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Pekka Savola wrote: >=20 > >=20 > Giving some insight on this as seen from the SixXS project... > If you think this is marketing hype thing alike skip this message > there is no commercial thing in the project and it is all on a > free/goodwill basis with the main target of providing IPv6 deployment. >=20 > > > Please elaborate on this point. If your ISP does not help but > > > a neighboring ISP offer v6 tunnels, what is the problem? > >=20 > > The problem is that the neighboring ISP won't offer v6 tunnel to you = > > because you're not his customer. >=20 > In general this is actually what we are doing. The red line though > is that people should provide full contact address information and > that their endpoint has a latency of less than 100ms. >=20 > > There has been very little 6to4 relay deployment. And that's even > > better for the ISPs to deploy, because the abuse etc. that happens > > doesn't come from you 2001:f00::/32 address space. The ISPs in > > general *don't* want to offer their production space address space = to > > every John Doe that comes knocking on their door. =20 >=20 > I personally think that that is actually one of the things *against* > 6to4, it is totally untraceable/debuggable as one never knows where > packets are going to flow to/from as there just might be one or even > more hidden 6to4 relays along the route. >=20 > Next to that apparently many users *demand* RIR space, they think > it is cooler or works better. There are even people who are proud > to have inet6num's ;) >=20 > As for abuse, in case of SixXS, it has been at an all time low > fortunatly and we haven't heared a complaint for quite some while > (*knock on wood*) but that could be because of the quite strictness > with which users are accepted and the fact that they know that they > are out and are kept out of the system when they have commited it. >=20 > > Having followed this relay / tunnel deployment for a while, it seems > > like that offering these kind of services to outsiders is not seen = as > > very interesting thing to do. Sure, there are some who do it in any > > case, but more often than not, they're rather far away (and to > > optimize that, a "broker discovery" mechanism would not hurt) = because > > they're so scarce. >=20 > The 'discovery' mechanism we use for the SixXS project is quite simple > though absolutely not automated: users signs up through the website > and gives it's details, thus we know his address+country + IP, then > after being approved they can request a tunnel, again we get an IP. > Then the system 'asks' the POPs who is willing to serve that IP. > The POPs that want to serve the user then display them selves and > the user can select it, again a manual approval based on lowest > latency/least hops and some other criteria. The approvals are > web or cli based thus admins only select from some default answers. >=20 > > If Internet was still this co-operative, non-profit environment, = this > > kind of "open for all" tunnel broker model would be very efficient.. = =20 > > but this is not the case, unfortunately.. >=20 > SixXS currently has 11 POPs across europe and for the exception of > two of those they are all open and providing IPv6 to quite a number > of users who seem to be very happy about the service, you only > hear them complain when it breaks, which happens only about once > a year when there is some odd hardware failure. Generally a POP > only serves the users of that country, unless it is the closest > POP for a user where there are no POPs in the country. >=20 > Or in numbers: (http://www.sixxs.net/misc/usage/) > The 1747 users span 44 countries. > The 1649 tunnels span 35 countries. > Currently there are 923 subnet delegations over the tunnels. > In the these numbers deleted and disabled tunnels are not counted. >=20 > I do have to add that we are apparently in quite a unique > situation as as far as I know of there are not that many > public Tunnel Brokers in the US/Asian parts of the world. >=20 > First 27 pages of a google on "tunnel broker", sorted on > region and order of appearance in google: >=20 > US: > 1 Hurricane (http://ipv6.he.net) > 2 Freenet6 (http://www.freenet6.net) >=20 > Europe: > - - BT Exact (http://tb.ipv6.btexact.com) > - - Dolphins (http://tunnelbroker.as8758.net) > - - XS26 (http://www.xs26.net) > - - ngNet.it (http://tb.ngnet.it) > - - Estpak (http://www.ipv6.estpak.ee) > - - Euro6ix (http://www.euro6ix.org:8080/tb/) > - - FCCN/IPv6-TF.pt (http://ipv6-tf.com.pt/tunnel/) > - - SixXS (http://www.sixxs.net) > - - Berkom (http://fix.ipv6.berkom.de/cgi-bin/tb.pl) > - - Netgroup.dk (http://noodle.ngdc.net/~hroi/tb/) > - - Coredumps (http://tb.coredumps.org/) >=20 > Asia/Australia: > - - Manis (Beta; http://tbroker.manis.net.my) > - - SingNet (http://tunnel-broker.singnet.com.sg) > - - AARNet (http://broker.aarnet.edu.au) > - - SJTU.edu.cn (http://tb.sjtu.edu.cn/) > - - ASCC (http://tb.ipv6.ascc.net/) > - - NGIX (http://tb.ngix.ne.kr/cgi-bin/tb.pl) >=20 > 19 and there are probably a couple of others, as to > how and if they work and how stable they are that is > up to their respective users. It might be interresting > to know how many active/used tunnels are being used > around the globe though as that might indicate a bit > if there is a demand and how it could be fulfilled. > Statistics on how these TB's are used could also prove > interresting. Policies of these brokers might differ > btw to be open or closed or they only might serve to > a certain region and have other regulations in hand. > Next to that there are bound to be private TB's which > are not to be found in google. >=20 > Greets, > Jeroen >=20 > -----BEGIN PGP SIGNATURE----- > Version: Unfix PGP for Outlook > Comment: Jeroen Massar / http://unfix.org/~jeroen/ >=20 > iQBGBAERAgAQCRApqihSMz58IwUCQFMJGgAAlwcAnisbsI75IPYnbnVTs1SqwxkV > USPPAJ9MwuxWg52PZTeaxtuixjrbGzZAqA=3D=3D > =3Dh9IU > -----END PGP SIGNATURE----- > ********************************** 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 Sat Mar 13 11:31:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20789 for ; Sat, 13 Mar 2004 11:31:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2C1U-000HLW-8g for v6ops-data@psg.com; Sat, 13 Mar 2004 16:30:04 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2C1J-000HBg-53 for v6ops@ops.ietf.org; Sat, 13 Mar 2004 16:29:53 +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 49-md50000000358.tmp for ; Sat, 13 Mar 2004 17:35:06 +0100 Message-ID: <0bac01c40918$ff03a2f0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: IETF59 minutes and presentations Date: Sat, 13 Mar 2004 17:34:01 +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, Sat, 13 Mar 2004 17:35:06 +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.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 agree with your point of view, indeed we are working on this approach = (more TBs, more "local") and for the "auto-location" of the TB, we are = already working on several ideas, and will try to present something at = the next meeting. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "Alain Durand" Cc: ; Sent: Saturday, March 13, 2004 6:59 AM Subject: Re: IETF59 minutes and presentations > On Fri, 12 Mar 2004, Alain Durand wrote: > > =3D=3D> I do not see how this scenario is fundamentally different > > from the road warrior using IPv4 on a dial-up modem. > > In many cases, he can call a well known centralized 1-800 number > > that will create a suboptimal long path or he will have a phone = number > > for a local PoP, that will hopefully provide shorter RTT. > > There is no 'find me the nearest PoP' protocol here. > >=20 > > If we look at a tunnel broker as a virtual IPv6 ISP, > > can someone point me how things are different? >=20 > Road warrior has made a contract with an ISP, which is his back-up > long-distance number. If we assume that all the users would have to > make a contract/signup/whatever with a long-distance virtual IPv6 ISP, > then this would probably be the case. >=20 > What I'd like to get is when the local ISP is offering the tunnel > service, the user would get directed there automatically, and would > become aware of it so that he could start using that service instead > (instead of using long-distance service). >=20 > That is, I think we want to avoid these "long-distance calls", and we > want to make it easier for the user to notice whether there is support > in the local ISP. Additionally, the configuration of tunneling IMHO > should be close to zero-config. (Looking up tunnel server addresses, > signup forms, or whatever in the web is unacceptable -- and that's one > reason why the tunnel broker model hasn't seemed to fly so well so > far..) >=20 > If we want to make this easy for the users, that seems like something=20 > that would have to be done. Especially if we insisted that we=20 > wouldn't need Teredo. >=20 > Hopefully I answered your question.. >=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 Sat Mar 13 11:39:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21431 for ; Sat, 13 Mar 2004 11:39:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2C98-000Lxi-Md for v6ops-data@psg.com; Sat, 13 Mar 2004 16:37:58 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2C8x-000Lqt-S2 for v6ops@ops.ietf.org; Sat, 13 Mar 2004 16:37:48 +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 58-md50000000358.tmp for ; Sat, 13 Mar 2004 17:42:56 +0100 Message-ID: <0bef01c4091a$16ffa970$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation] Date: Sat, 13 Mar 2004 17:41: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, Sat, 13 Mar 2004 17:42: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.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, Alain's comment was: "NAT traversal must be supported." This is not true if the tunnel ends = in the gateway where the NAT function is usually located. I think this = is important, since the solution to deploy does not need to deal with = complexity of NAT traversal. What I understood then is 2 options: 1) The NAT box is already the IPv6 end point for the tunnel ? Correct if = we prefer this instead of 6to4 (because probably the cost of = implementing 6to4 is the same as a TB client in the NAT) 2) We don't need NAT traversal IF proto-41-forwarding is working in that = NAT By understanding is that the number of NATs that support proto-41 is = comparable to the number of NATs that support Teredo (not sure other NAT = traversal mechanism). Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Saturday, March 13, 2004 6:52 AM Subject: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios = and mechanisms evaluation] > On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > > I agree with Alain, that the way proto-41 fits. I'm not sure if we > > can call this NAT traversal, so may be rewording to NAT traversal or > > proto-41-forwarding ? >=20 > Alain did not mention proto 41 forwarding at all.. so I'm not sure=20 > where you got that. >=20 > NAT traversal must work in a reasonably high number of different NAT > boxes. Proto-41 forwarding does not. Of course, it can still be used > as an optimization in the case it's being supported, but the case > where it matters is basically the tunnel-server like approaches (TSP > and STEP) which already support or will support NAT traversal. >=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 Sat Mar 13 14:35: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 OAA27399 for ; Sat, 13 Mar 2004 14:35:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2Erc-000GFC-Cn for v6ops-data@psg.com; Sat, 13 Mar 2004 19:32:04 +0000 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B2ErQ-000G8I-Q2 for v6ops@ops.ietf.org; Sat, 13 Mar 2004 19:31:52 +0000 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 13 Mar 2004 19:31:51 +0000 (GMT) Date: Sat, 13 Mar 2004 19:31:51 +0000 From: David Malone To: v6ops@ops.ietf.org Subject: Re: Tunneling scenarios and mechanisms evaluation Message-ID: <20040313193151.GA38725@walton.maths.tcd.ie> References: <991CC9E6-7445-11D8-85CB-00039376A6AA@sun.com> <20040313113316.GA11526@walton.maths.tcd.ie> <20040313113938.GC32481@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040313113938.GC32481@login.ecs.soton.ac.uk> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Mar 13, 2004 at 11:39:38AM +0000, Tim Chown wrote: > How do you know how many relay routers exist? All you can count are ones > that ISPs/NRENs choose to advertise beyond their borders? It is explained in the writeup - you look for people who are willing to encapsulate packets destined to 6to4 addresses by tracerouting to various parts of the 6to4 network and seeing who encapsulates the ICMP TTL unreachables. David. From owner-v6ops@ops.ietf.org Sat Mar 13 14:37: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 OAA27457 for ; Sat, 13 Mar 2004 14:37:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2EvC-000IT8-1N for v6ops-data@psg.com; Sat, 13 Mar 2004 19:35:46 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2Ev1-000ILt-EY for v6ops@ops.ietf.org; Sat, 13 Mar 2004 19:35:35 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 13 Mar 2004 11:35:37 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 13 Mar 2004 11:35:34 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 13 Mar 2004 11:35:33 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 13 Mar 2004 11:35:24 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 13 Mar 2004 11:35:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and Date: Sat, 13 Mar 2004 11:35:32 -0800 Message-ID: Thread-Topic: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and thread-index: AcQI8nRKT1utiAk8Q5m4qBOsTPS7wQAPm/Sw From: "Christian Huitema" To: "bill" , "Pekka Savola" Cc: "Erik Nordmark" , "Alain Durand" , X-OriginalArrivalTime: 13 Mar 2004 19:35:29.0991 (UTC) FILETIME=[57D68D70:01C40932] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > the security properties are worse with 6to4 than Teredo (due to its > > simplicity). > > > > Pekka Savola >=20 > reading the above sentence... its the most humourous thing > i've read all week. perhaps what Pekka intended to say was > that the security properties of 6to4 are more knowable than > Teredo due to its simplicity. Most folks believe that if > you can know the properties of some bit of code, its more > secure than code that is too large/complex to understand well. > Or perhaps Pekka ment something else... Pekka's point can be summarized as follow: the bubble mechanism of Teredo performs a 3-ways handshake, which effectively mitigates some potential misuse of the relays for anonymous DOS attacks; there is no such mechanism in 6to4. Rob and Bill retort with the general "complexity is bad" argument: it is much easier to have a bug in 100,000 lines of code than in 100; simper code is easier to debug. However, Teredo's code is not all that large, maybe a few hundred lines, and it can effectively be debugged. After all, we do have two independent implementations of Teredo that interoperate without apparent issues. That being said, I would not want to replace all usage of 6to4 by Teredo. 6to4 is a natural solution for upgrading the existing home routers. -- Christian Huitema From owner-v6ops@ops.ietf.org Sat Mar 13 14:47: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 OAA27716 for ; Sat, 13 Mar 2004 14:47:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2F5C-000Oim-27 for v6ops-data@psg.com; Sat, 13 Mar 2004 19:46:06 +0000 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B2F51-000OcQ-7I for v6ops@ops.ietf.org; Sat, 13 Mar 2004 19:45:55 +0000 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 13 Mar 2004 19:45:54 +0000 (GMT) Date: Sat, 13 Mar 2004 19:45:54 +0000 From: David Malone To: v6ops@ops.ietf.org Subject: Re: Tunneling scenarios and mechanisms evaluation Message-ID: <20040313194554.GA39502@walton.maths.tcd.ie> References: <991CC9E6-7445-11D8-85CB-00039376A6AA@sun.com> <20040313113316.GA11526@walton.maths.tcd.ie> <20040313113938.GC32481@login.ecs.soton.ac.uk> <20040313193151.GA38725@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040313193151.GA38725@walton.maths.tcd.ie> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Mar 13, 2004 at 07:31:51PM +0000, David Malone wrote: > On Sat, Mar 13, 2004 at 11:39:38AM +0000, Tim Chown wrote: > > How do you know how many relay routers exist? All you can count are ones > > that ISPs/NRENs choose to advertise beyond their borders? > > It is explained in the writeup - you look for people who are willing > to encapsulate packets destined to 6to4 addresses by tracerouting to > various parts of the 6to4 network and seeing who encapsulates the ^^^^^ IPv6 From owner-v6ops@ops.ietf.org Sat Mar 13 15:16: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 PAA29222 for ; Sat, 13 Mar 2004 15:16:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2FWK-000FE1-CA for v6ops-data@psg.com; Sat, 13 Mar 2004 20:14:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2FW8-000F6n-Tx for v6ops@ops.ietf.org; Sat, 13 Mar 2004 20:13:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2DKDrO30551; Sat, 13 Mar 2004 22:13:53 +0200 Date: Sat, 13 Mar 2004 22:13:52 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <0bef01c4091a$16ffa970$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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > Alain's comment was: > > "NAT traversal must be supported." This is not true if the tunnel > ends in the gateway where the NAT function is usually located. I > think this is important, since the solution to deploy does not need > to deal with complexity of NAT traversal. True enough. However, I have doubts on how useful this case is in practice, as a large number of gateways cannot be expected to be upgraded -- that is, we will have to support host-centric deployment in any case. However, I guess it might be useful to try to tease these two subcases apart to see if there are significant differences, like: unmanaged w/o ISP support, IPv4 gateway not upgraded - NAT traversal or proto-41 forw. required - only host addressing OK, site addressing "nice to have" unmanaged w/o ISP support, IPv4 gateway upgraded - host(s) require nothing - the gateway requires NAT traversal capability - must support getting at least /64 unmanaged with ISP support, IPv4 gateway not upgraded - NAT traversal or proto-41 forw. required - only host addressing OK, site addressing "nice to have" unmanaged with ISP support, IPv4 gateway upgraded - host(s) require nothing - the gateway does not require NAT traversal - must support getting at least /64 So, it seems what we get here is one case where NAT traversal is not required, and a rather obvious conclusion that when the gateway is implementing a transition function, it must implement a mechanism which can be used to obtain at least a /64 prefix; e.g., Teredo is not sufficient. This should go into the draft somehow, but as listing these would complicate the matrices a lot, I'm not sure whether the matrix is the right place to add this result. Something obvious I missed? > What I understood then is 2 options: >> > 1) The NAT box is already the IPv6 end point for the tunnel ? > Correct if we prefer this instead of 6to4 (because probably the cost > of implementing 6to4 is the same as a TB client in the NAT) Tunnel broker is generally much more complex than 6to4, but if you buy the concept of ND proxying, it could be a lot simpler as well. If not, you'll need something like DHCPv6 prefix delegation or custom mechanisms. > 2) We don't need NAT traversal IF proto-41-forwarding is working in > that NAT Yet, that is an optimization (or at least, cannot be the only solution) unless we can be assured that sufficiently large percentage of boxes do that (e.g., over 95% of the market or whatever). > By understanding is that the number of NATs that support proto-41 is > comparable to the number of NATs that support Teredo (not sure other > NAT traversal mechanism). Do you have more precise data than that? Maybe it would be useful to write it down -- like draft-jennings-midcom-stun-results-00.txt has done about some NAT types. I have a gut feeling that NAT proto-41 forwarding is not as common as non-symmetric NATs. -- 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 Sat Mar 13 15:40: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 PAA00109 for ; Sat, 13 Mar 2004 15:40:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2Fsz-0003Ck-Ez for v6ops-data@psg.com; Sat, 13 Mar 2004 20:37:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2Fso-00036b-GD for v6ops@ops.ietf.org; Sat, 13 Mar 2004 20:37:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2DKbF030764; Sat, 13 Mar 2004 22:37:15 +0200 Date: Sat, 13 Mar 2004 22:37:15 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: "'Alain Durand'" , Subject: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <20040313131444.8D8E8871C@purgatory.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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I think this message was useful; let me try to respond to some comments inline.. On Sat, 13 Mar 2004, Jeroen Massar wrote: > > > Please elaborate on this point. If your ISP does not help but > > > a neighboring ISP offer v6 tunnels, what is the problem? > > > > The problem is that the neighboring ISP won't offer v6 tunnel to you > > because you're not his customer. > > In general this is actually what we are doing. Sure; I didn't want to say that such nice folks don't exist. I just was arguing that they aren't that commonplace, may be difficult to find (especially to those not familiar with IPv6!), may not use the same mechanisms at the tunnel broker (making client software deployment a mess), etc. Remember, our goal is not get IPv6 deployed to those guys who are reading this mailing-list and can do a lot of technical stuff to set things up. The target audience (which I have in mind at least) is much more "dumber" than that. I'd like to aim for the case where the most the user would have to do is click an "activate IPv6" icon on the desktop or network settings -- and not necessarily even that. That function should try to send route solicitation on your link, find a free tunnel broker provided by your own ISP, or set up 6to4/Teredo all else failing. > > There has been very little 6to4 relay deployment. And that's even > > better for the ISPs to deploy, because the abuse etc. that happens > > doesn't come from you 2001:f00::/32 address space. The ISPs in > > general *don't* want to offer their production space address space to > > every John Doe that comes knocking on their door. > > I personally think that that is actually one of the things *against* > 6to4, it is totally untraceable/debuggable as one never knows where > packets are going to flow to/from as there just might be one or even > more hidden 6to4 relays along the route. From one perspective, yes. From the ISP perspective, maybe not. That is, 6to4 is rather an anonymous mechanism: you can provide it to third parties without them getting your IP addresses, without you getting complaints about abuse, etc. -- it's much simpler to set up for outsiders in many ways than a tunnel broker. > Next to that apparently many users *demand* RIR space, they think > it is cooler or works better. There are even people who are proud > to have inet6num's ;) Certainly, the users want RIR space. But the question was what the ISPs want to *GIVE* to folks that are not their customers. We, as an ISP, certainly don't want to give 3rd party users *our* address space. Many tunnel brokers today that exist operate with 6bone address space, or are some kind of "pilot service", which may be less of a problem in some sense. > The 'discovery' mechanism we use for the SixXS project is quite simple > though absolutely not automated: users signs up through the website > and gives it's details, thus we know his address+country + IP, then > after being approved they can request a tunnel, again we get an IP. Yep -- but that assumes the users must first know that such tunnel brokers exist, can find them in the web, install the software, fill in the forms, etc. I.e., it's OK for techies, but looking at wider deployment, it's unacceptable. But I guess it depends on who are you aiming the mechanism for; if we standardized a solution in this space, I think it would certainly have to be much simpler than that administratively. -- 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 Sat Mar 13 15:45: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 PAA00270 for ; Sat, 13 Mar 2004 15:45:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2FzI-0006fa-Lq for v6ops-data@psg.com; Sat, 13 Mar 2004 20:44:04 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2Fz7-0006YB-0P for v6ops@ops.ietf.org; Sat, 13 Mar 2004 20:43:53 +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 49-md50000000360.tmp for ; Sat, 13 Mar 2004 21:49:04 +0100 Message-ID: <0d6901c4093c$78e81560$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation] Date: Sat, 13 Mar 2004 21:47:55 +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, Sat, 13 Mar 2004 21:49: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.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, See below, in-line. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Saturday, March 13, 2004 9:13 PM Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling = scenarios and mechanisms evaluation] > On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > > Alain's comment was: > > > > "NAT traversal must be supported." This is not true if the tunnel > > ends in the gateway where the NAT function is usually located. I > > think this is important, since the solution to deploy does not need > > to deal with complexity of NAT traversal. >=20 > True enough. However, I have doubts on how useful this case is in=20 > practice, as a large number of gateways cannot be expected to be=20 > upgraded -- that is, we will have to support host-centric deployment=20 > in any case. I don't agree. In general is in the other way around. Is more and more = often that the routers, gateways, etc., are updated from time to time, = with new firmware or software. >=20 > However, I guess it might be useful to try to tease these two subcases = > apart to see if there are significant differences, like: >=20 > unmanaged w/o ISP support, IPv4 gateway not upgraded > - NAT traversal or proto-41 forw. required > - only host addressing OK, site addressing "nice to have" >=20 > unmanaged w/o ISP support, IPv4 gateway upgraded > - host(s) require nothing > - the gateway requires NAT traversal capability > - must support getting at least /64 >=20 > unmanaged with ISP support, IPv4 gateway not upgraded > - NAT traversal or proto-41 forw. required > - only host addressing OK, site addressing "nice to have" >=20 > unmanaged with ISP support, IPv4 gateway upgraded > - host(s) require nothing > - the gateway does not require NAT traversal > - must support getting at least /64 >=20 > So, it seems what we get here is one case where NAT traversal is not=20 > required, and a rather obvious conclusion that when the gateway is=20 > implementing a transition function, it must implement a mechanism=20 > which can be used to obtain at least a /64 prefix; e.g., Teredo is not = > sufficient. >=20 Agree. > This should go into the draft somehow, but as listing these would=20 > complicate the matrices a lot, I'm not sure whether the matrix is the=20 > right place to add this result. I think if we are trying to approach to a more complete solution, we = need to include these options in the draft/matrix. As I indicated in the = meeting, I'm sure there are 100% perfect solutions, but they will take = long time to be ready; but at the same time, completing the matrix, even = when complicating it a little bit, is mandatory, to cover as much as = possible the real market situation, and consequently provide the needed = transition tools, to facilitate how the deployment can happen (in the = real market). >=20 > Something obvious I missed? > =20 > > What I understood then is 2 options: > >> > > 1) The NAT box is already the IPv6 end point for the tunnel ? > > Correct if we prefer this instead of 6to4 (because probably the cost > > of implementing 6to4 is the same as a TB client in the NAT) >=20 > Tunnel broker is generally much more complex than 6to4, but if you buy > the concept of ND proxying, it could be a lot simpler as well. If > not, you'll need something like DHCPv6 prefix delegation or custom > mechanisms. I meant that the NAT can be the end-tunnel point (for a TB, and if = possible automatically configured, but we don't have this right now), OR = the NAT box is upgraded to support 6to4. Note that this is already = happening. I read a couple of weeks ago about an upgrade for an existing = router (IPv4 only previously) to support 6to4. >=20 > > 2) We don't need NAT traversal IF proto-41-forwarding is working in > > that NAT >=20 > Yet, that is an optimization (or at least, cannot be the only > solution) unless we can be assured that sufficiently large percentage > of boxes do that (e.g., over 95% of the market or whatever). Our testing, considering not just the number of models and manufacturers = in the market, but also how many units there are in the market from each = manufacturer, shows about 85% supporting proto-41, but I guess this will = improve. I'm not sure if is good to mention here specific brands and = models, but in any case is simple to understand. We can have a market = with 100 models (just an example), but one of the models has 60% of the = market sharing and supports it. That means that we have already 60% of = the market supporting this feature, just add the others from the pool of = 100, and you have the 85%. > =20 > > By understanding is that the number of NATs that support proto-41 is > > comparable to the number of NATs that support Teredo (not sure other > > NAT traversal mechanism). >=20 > Do you have more precise data than that? Maybe it would be useful to > write it down -- like draft-jennings-midcom-stun-results-00.txt has > done about some NAT types. I have a gut feeling that NAT proto-41 > forwarding is not as common as non-symmetric NATs. You feeling is wrong ;-), see my previous reply. We have gathered this = information from different sources for months. Just an example, only one = of the products being sold/installed in Spain by the xDSL provides, = didn't supported proto-41-forw., and by the way, is not the one that has = the bigger market sharing. >=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 Sat Mar 13 16:01:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00824 for ; Sat, 13 Mar 2004 16:01:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2GFN-000GQc-6h for v6ops-data@psg.com; Sat, 13 Mar 2004 21:00:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2GFC-000GG9-1R for v6ops@ops.ietf.org; Sat, 13 Mar 2004 21:00:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2DL0Ob31062; Sat, 13 Mar 2004 23:00:24 +0200 Date: Sat, 13 Mar 2004 23:00:24 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <0d6901c4093c$78e81560$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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > > True enough. However, I have doubts on how useful this case is in > > practice, as a large number of gateways cannot be expected to be > > upgraded -- that is, we will have to support host-centric deployment > > in any case. > > I don't agree. In general is in the other way around. Is more and > more often that the routers, gateways, etc., are updated from time > to time, with new firmware or software. For technical users, yes; for non-techies, I have serious doubts about that. DSL products bought or provided by the ISP stay there for 3-5 years at least, and they don't have a software upgrade; even if they had, the average user wouldn't know or dare to install it. If an IPv6 product (e.g., Microsoft's some new shiny new patch kit to use v6 in peer-to-peer) was being deployed, saying "upgrade your NAT box" is not an option. The case where we can't do anything about the deployed base is the minimal target: it must be supported as well as it can be. If we can, we might also want to create optimization(s) for the cases where some box has been upgraded (or not). > > This should go into the draft somehow, but as listing these would > > complicate the matrices a lot, I'm not sure whether the matrix is the > > right place to add this result. > > I think if we are trying to approach to a more complete solution, we > need to include these options in the draft/matrix. As I indicated in > the meeting, I'm sure there are 100% perfect solutions, but they > will take long time to be ready; but at the same time, completing > the matrix, even when complicating it a little bit, is mandatory, to > cover as much as possible the real market situation, and > consequently provide the needed transition tools, to facilitate how > the deployment can happen (in the real market). The real market situation can be handled if we design solutions that work with the lowest common denominator (e.g., no NAT/gateway support), right? > > > 2) We don't need NAT traversal IF proto-41-forwarding is working in > > > that NAT > > > > Yet, that is an optimization (or at least, cannot be the only > > solution) unless we can be assured that sufficiently large percentage > > of boxes do that (e.g., over 95% of the market or whatever). > > Our testing, considering not just the number of models and > manufacturers in the market, but also how many units there are in > the market from each manufacturer, shows about 85% supporting > proto-41, but I guess this will improve. I'm not sure if is good to > mention here specific brands and models, but in any case is simple > to understand. We can have a market with 100 models (just an > example), but one of the models has 60% of the market sharing and > supports it. That means that we have already 60% of the market > supporting this feature, just add the others from the pool of 100, > and you have the 85%. I think it's OK to mention brands and models -- there's precedent in draft-jennings-midcom-stun-results-00.txt and a lot of other documents. We might not want to publish those results as an RFC, but I think it would be useful to make that list public so folks could see if they something to add to the list, see whether they have different experiences, see if their product would be supported or not, etc. -- 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 Sat Mar 13 16:02:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00842 for ; Sat, 13 Mar 2004 16:02:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2GEq-000G4o-S0 for v6ops-data@psg.com; Sat, 13 Mar 2004 21:00:08 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2GEf-000Fx8-Ri for v6ops@ops.ietf.org; Sat, 13 Mar 2004 20:59:58 +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 57-md50000000360.tmp for ; Sat, 13 Mar 2004 22:05:11 +0100 Message-ID: <0d7501c4093e$b923f3e0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] Date: Sat, 13 Mar 2004 22:03:58 +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, Sat, 13 Mar 2004 22:05:11 +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.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, See in-line. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "Jeroen Massar" Cc: "'Alain Durand'" ; Sent: Saturday, March 13, 2004 9:37 PM Subject: tunnel broker deployment [RE: Tunneling scenarios and = mechanisms evaluation] > Hi, >=20 > I think this message was useful; let me try to respond to some=20 > comments inline.. >=20 > On Sat, 13 Mar 2004, Jeroen Massar wrote: > > > > Please elaborate on this point. If your ISP does not help but > > > > a neighboring ISP offer v6 tunnels, what is the problem? > > >=20 > > > The problem is that the neighboring ISP won't offer v6 tunnel to = you=20 > > > because you're not his customer. > >=20 > > In general this is actually what we are doing. >=20 > Sure; I didn't want to say that such nice folks don't exist. I just > was arguing that they aren't that commonplace, may be difficult to > find (especially to those not familiar with IPv6!), may not use the > same mechanisms at the tunnel broker (making client software > deployment a mess), etc. >=20 > Remember, our goal is not get IPv6 deployed to those guys who are > reading this mailing-list and can do a lot of technical stuff to set > things up. The target audience (which I have in mind at least) is > much more "dumber" than that. I'd like to aim for the case where the > most the user would have to do is click an "activate IPv6" icon on the > desktop or network settings -- and not necessarily even that. That > function should try to send route solicitation on your link, find a > free tunnel broker provided by your own ISP, or set up 6to4/Teredo all = > else failing. Agree, as said in a previous message, this is more or less what we are = doing, and hopefully could present in San Diego (we call it = auto-transition): - Native - 6to4 - TB with 6in4 if a public IPv4 address is available - TB with proto-41-forwarding if NAT supports it - TB with UDP encapsulation - Teredo - others (even IPv6 over HTTP in the worst case !) The order not necessarily is what I wrote down, as it may depend on the = "best performance" solution for every client, and even change if the = client or network change. The "activate IPv6" should not be needed if we can manage to have the = process automatically, and alternatively we should offer the "deactivate = IPv6", hopefully, if for whatever reason, the user choose to ;-) The auto-transition might propose the user, if the IPv6 performance in a = given situation is very bad, to use IPv4 (hopefully with the time less = and less often). The discovery process might be not simple, specially because we want to = ensure the best possible performance at any time. >=20 > > > There has been very little 6to4 relay deployment. And that's even > > > better for the ISPs to deploy, because the abuse etc. that happens > > > doesn't come from you 2001:f00::/32 address space. The ISPs in > > > general *don't* want to offer their production space address space = to > > > every John Doe that comes knocking on their door. =20 > >=20 > > I personally think that that is actually one of the things *against* > > 6to4, it is totally untraceable/debuggable as one never knows where > > packets are going to flow to/from as there just might be one or even > > more hidden 6to4 relays along the route. >=20 > From one perspective, yes. From the ISP perspective, maybe not. =20 > That is, 6to4 is rather an anonymous mechanism: you can provide it to > third parties without them getting your IP addresses, without you > getting complaints about abuse, etc. -- it's much simpler to set up > for outsiders in many ways than a tunnel broker. >=20 > > Next to that apparently many users *demand* RIR space, they think > > it is cooler or works better. There are even people who are proud > > to have inet6num's ;) >=20 > Certainly, the users want RIR space. But the question was what the > ISPs want to *GIVE* to folks that are not their customers. We, as an > ISP, certainly don't want to give 3rd party users *our* address space. = =20 > Many tunnel brokers today that exist operate with 6bone address space, > or are some kind of "pilot service", which may be less of a problem in > some sense. >=20 My feeling is that this is no longer true, and more and more TBs offer = RIR space, and even the change to have it statically even when the user = is moving. > > The 'discovery' mechanism we use for the SixXS project is quite = simple > > though absolutely not automated: users signs up through the website > > and gives it's details, thus we know his address+country + IP, then > > after being approved they can request a tunnel, again we get an IP. >=20 > Yep -- but that assumes the users must first know that such tunnel=20 > brokers exist, can find them in the web, install the software, fill in = > the forms, etc. >=20 > I.e., it's OK for techies, but looking at wider deployment, it's=20 > unacceptable. But I guess it depends on who are you aiming the=20 > mechanism for; if we standardized a solution in this space, I think it = > would certainly have to be much simpler than that administratively. That's why we are looking for automatic discovery as part of the = auto-transition "toolset". >=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 Sat Mar 13 16:23: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 QAA01533 for ; Sat, 13 Mar 2004 16:23:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2GZq-0003IV-4H for v6ops-data@psg.com; Sat, 13 Mar 2004 21:21:50 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2GZf-0003Bs-3l for v6ops@ops.ietf.org; Sat, 13 Mar 2004 21:21:39 +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 10-md50000000361.tmp for ; Sat, 13 Mar 2004 22:26:51 +0100 Message-ID: <0db001c40941$bd243f10$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation] Date: Sat, 13 Mar 2004 22:25:03 +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, Sat, 13 Mar 2004 22:26: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.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 See in-line. ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Saturday, March 13, 2004 10:00 PM Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling = scenarios and mechanisms evaluation] > On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > > > True enough. However, I have doubts on how useful this case is in = > > > practice, as a large number of gateways cannot be expected to be=20 > > > upgraded -- that is, we will have to support host-centric = deployment=20 > > > in any case. > >=20 > > I don't agree. In general is in the other way around. Is more and > > more often that the routers, gateways, etc., are updated from time > > to time, with new firmware or software. >=20 > For technical users, yes; for non-techies, I have serious doubts about > that. DSL products bought or provided by the ISP stay there for 3-5 > years at least, and they don't have a software upgrade; even if they > had, the average user wouldn't know or dare to install it. No, I don't think so. More and more users keep updating their equipment, = even when non-techies. But definitively, no longer the equipment is = there for so long time, I will say less than 2 years, actually. >=20 > If an IPv6 product (e.g., Microsoft's some new shiny new patch kit to > use v6 in peer-to-peer) was being deployed, saying "upgrade your NAT > box" is not an option. The case where we can't do anything about the > deployed base is the minimal target: it must be supported as well as > it can be. If we can, we might also want to create optimization(s) =20 > for the cases where some box has been upgraded (or not). If a wide spread game or product is in the market and requires the user = to upgrade their box, even purchase a new one to play that game, you can = make sure that they will do so ;-) The only problem right now is the = price for IPv6 enabled routers. Hopefully low cost models will come soon = from Taiwan and China. >=20 > > > This should go into the draft somehow, but as listing these would=20 > > > complicate the matrices a lot, I'm not sure whether the matrix is = the=20 > > > right place to add this result. > >=20 > > I think if we are trying to approach to a more complete solution, we > > need to include these options in the draft/matrix. As I indicated in > > the meeting, I'm sure there are 100% perfect solutions, but they > > will take long time to be ready; but at the same time, completing > > the matrix, even when complicating it a little bit, is mandatory, to > > cover as much as possible the real market situation, and > > consequently provide the needed transition tools, to facilitate how > > the deployment can happen (in the real market). >=20 > The real market situation can be handled if we design solutions that > work with the lowest common denominator (e.g., no NAT/gateway > support), right? Yes, but choosing only 1 or 2 options (is just an example, I'm not = counting the real situation right now) may be not optimal, specially if = we have a 3rd one that could be more optimal in, let's say more than = 30-40% (may be even less percentage is acceptable) of the cases. If = that's the case, then we should include that option in our matrix. >=20 > > > > 2) We don't need NAT traversal IF proto-41-forwarding is working = in > > > > that NAT > > >=20 > > > Yet, that is an optimization (or at least, cannot be the only > > > solution) unless we can be assured that sufficiently large = percentage > > > of boxes do that (e.g., over 95% of the market or whatever). > >=20 > > Our testing, considering not just the number of models and > > manufacturers in the market, but also how many units there are in > > the market from each manufacturer, shows about 85% supporting > > proto-41, but I guess this will improve. I'm not sure if is good to > > mention here specific brands and models, but in any case is simple > > to understand. We can have a market with 100 models (just an > > example), but one of the models has 60% of the market sharing and > > supports it. That means that we have already 60% of the market > > supporting this feature, just add the others from the pool of 100, > > and you have the 85%. >=20 > I think it's OK to mention brands and models -- there's precedent in=20 > draft-jennings-midcom-stun-results-00.txt and a lot of other=20 > documents. We might not want to publish those results as an RFC, but=20 > I think it would be useful to make that list public so folks could see = > if they something to add to the list, see whether they have different=20 > experiences, see if their product would be supported or not, etc. Ok, then as I can remember, we have all the Cisco, 3Com, Linksys, Nokia, = D-Link, NetGear, Draytek, SMC, Conceptronic, Allied-Telesyn, Develcon, = Perle, Trinexus, Yamaha, Zyxel, NEC and Buffalo. In addition, looking into the "firmware" of these products, I found as a = common denominator that they work if they have IOS, VxWorks, QnX, Linux, = USSoftware, and BSD. Some times the OS is hidden, but I've been able to = discover it or checking with the manufacturer or some document around. Note that I've not tried all those (may be about 40% of them only), but = we asked in this list and several others, the people to try out and this = is the result of the feedback received. The only one that I've found myself that failed to support = proto-41-forwarding was Efficient Networks (I believe now belongs to = Siemens). If you look into the market sharing, I'm very convinced that this is = even higher than 85%, but just to be conservative ... >=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 Sat Mar 13 21:32: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 VAA12344 for ; Sat, 13 Mar 2004 21:32:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2LMw-000I8y-1o for v6ops-data@psg.com; Sun, 14 Mar 2004 02:28:50 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2LMk-000HzL-F4 for v6ops@ops.ietf.org; Sun, 14 Mar 2004 02:28:38 +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 617328722; Sun, 14 Mar 2004 03:28:34 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" Cc: "'Alain Durand'" , Subject: RE: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] Date: Sun, 14 Mar 2004 03:28:08 +0100 Organization: Unfix MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQJOvlj98gk6Cc/R/mt6Mrg995gFwAChISg Message-Id: <20040314022834.617328722@purgatory.unfix.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Savola [mailto:pekkas@netcore.fi] wrote: > Remember, our goal is not get IPv6 deployed to those guys who are > reading this mailing-list and can do a lot of technical stuff to set > things up. The target audience (which I have in mind at least) is > much more "dumber" than that. I'd like to aim for the case where the > most the user would have to do is click an "activate IPv6" icon on the > desktop or network settings -- and not necessarily even that. If they can use MSN, which requires one to sign up with MS Passport and then fill in quite an amount of data, then most people, anyone age 13 and up, should be able to sign up with a number of tunnelbroker systems. The average 13 year old uses KaZaA and a number of other odd systems to download all the things they want which usually come into multiple pieces, zip inside rars inside other weird package formats etc. And apparently those users all seem to have a lot of fun playing the newest games, listening to the newest music and watching movies. How hard can it be for them be to click a couple of times and fill in their info's? Many of the users on the dutch POPs have IPv6 solely for one simple purpose: access to IPv6 news servers. Apparantly it is easy for the people wanting to use it. For Freenet it only requires installation of their client. For SixXS it even has nice clickety click stuff thing which should be simple enough. It would be nice if those things would be standardized though, if there is one we will adapt to it. > That function should try to send route solicitation on your link, find a > free tunnel broker provided by your own ISP, or set up > 6to4/Teredo all else failing. As you are mentioning a 'discovery' type of service, I don't think that is really possible as TB's are more like virtual ISP's and like real ISP's it's the clients who want it. The only thing that can be auto-discovered+configured is currently 6to4. If we (ietf) would want to have a autodiscovery feature for TB'sit would have to rely on a anycast address which the ISP announces the same way as the 6to4 address and basically one would get 6to4. - user enabled the IPv6 knob in $os - host builds tunnel to anycast address - normal ND/Ra procedures delegate the addresses. This won't work with non-static IP's and getting the same prefix back though, thus we require another thus another option would be: - user enables the IPv6 knob in $os - host contacts the anycast address port over TCP* - sends it's user login/password - retrieves it's configuration data. On error (eg user doesn't exist, not configured) it could return a URL of the closest POP for that TB service. The anycast service could also be used to redirect people to the closest TB or a list of TB's of course. * = yes I wrote anycast, but for the short lived communication of a config protocol it should work even using TCP, retries can always be re-tried if the communication fails but I guess that won't happen that often and quick to even consider. > > > There has been very little 6to4 relay deployment. And that's even > > > better for the ISPs to deploy, because the abuse etc. that happens > > > doesn't come from you 2001:f00::/32 address space. The ISPs in > > > general *don't* want to offer their production space address space to > > > every John Doe that comes knocking on their door. > > > > I personally think that that is actually one of the things *against* > > 6to4, it is totally untraceable/debuggable as one never knows where > > packets are going to flow to/from as there just might be one or even > > more hidden 6to4 relays along the route. > > From one perspective, yes. From the ISP perspective, maybe not. > That is, 6to4 is rather an anonymous mechanism: you can provide it to > third parties without them getting your IP addresses, without you > getting complaints about abuse, etc. -- it's much simpler to set up > for outsiders in many ways than a tunnel broker. As far as I heard the Hexago Migration broker box is just a 'buy' 'enter config data' 'start' procedure, but I haven't seen it yet. As for SixXS it is just 'contact info@sixxs.net, install a unix box, enter config data, upload the software, enable the POP, done' All depends wether you want to reinvent the wheel or not ;) > > Next to that apparently many users *demand* RIR space, they think > > it is cooler or works better. There are even people who are proud > > to have inet6num's ;) > > Certainly, the users want RIR space. But the question was what the > ISPs want to *GIVE* to folks that are not their customers. We, as an > ISP, certainly don't want to give 3rd party users *our* address space. In case of the SixXS model that would simply be feeding it the prefixes that you would want to serve, as what happens with the Data Telecom and the M"Net POPs. This would disallow them from using those boxes. In case of the above anycast service only your customers would get service from you as those would get the anycast address response due to it being in their routing system. Other users would possibly get a public TB. > Many tunnel brokers today that exist operate with 6bone address space, > or are some kind of "pilot service", which may be less of a problem in > some sense. Au contraire, Hurricane gives out RIR space, Freenet does 6bone, AARNet does RIR space and for SixXS 2 do 6bone and 9 RIR space. Notez bien, that the problem of 6bone will be resolved in about 2 years time, no more need for ip6.arpa/int discussions either ;) But I understand your point. > > The 'discovery' mechanism we use for the SixXS project is quite simple > > though absolutely not automated: users signs up through the website > > and gives it's details, thus we know his address+country + IP, then > > after being approved they can request a tunnel, again we get an IP. > > Yep -- but that assumes the users must first know that such tunnel > brokers exist, can find them in the web, install the software, fill in > the forms, etc. They found MSN, Yahoo, Google, KaZaA etc. Friends tell that is the trick to it, if there is interresting enough content even 13 year olds can configure it. Again my example of newszilla6.xs4all.nl for which a number of 'how do I configure my box to do IPv6 FAQ's' exist on the net and people are using it for specifically that purpose. The same goes for KaZaA for which I today read an article in a printed magazine explaining in the most extremely childish way how to download the newest movies and that as long as you don't offer (upload) the !copyrighted! material yourself it was totally legal in .nl, offering/downloading copyrighted software was different though. Odd world we live in. But to get to the point: if users see a need for it they will get it and the standard way of telling people things will make it happen. It would be better though if we, ietf, have produced a standard way of doing the above, maybe it is time to do so? See below. > I.e., it's OK for techies, but looking at wider deployment, it's > unacceptable. But I guess it depends on who are you aiming the > mechanism for; if we standardized a solution in this space, I > think it > would certainly have to be much simpler than that administratively. Indeed, I guess it would be a good idea to pursue the anycast configuration service or a similar technique. ISP's that don't want to allow other ISP's users on their service can always not announce the prefix to other ISP's and can always announce the prefix to other users. Having a single hostname, eg "ipv6.tunnelbroker.arpa" or something would not work as ISP's would then have to depend on the instance running that service to distribute the clients. Unfair competition and other blabla comes to mind. To sum up the features I would like to have in such a protocol: - anycast address or similar to choose the closest TB and this could quite well be the service the ISP operates or a friendly ISP announcing this prefix. One problem though there is no way of having multiple TB's this way. But if a user knows which TB she wants she can always go directly to that TB. - Restricting users to only certain prefixes using the anycast announcement, just don't announce and/or redirect the users to another service, never say NO... - user authentication (optional) this is mainly to track users, know who is using what etc it also allows giving the same prefix to the same user even when the user changes IP addresses. This could also be done using a cookie mechanism. - static prefix delegation could be done using normal RA techniques. - DNS server configuration for that prefix. - Protocol 41 at first but optionally over UDP eg after detecting that proto-41 doesn't work. - UDP mode to be able to cross a NAT. Every single NAT I know of can be configured to forward UDP packets, thus that should work. There is one but, the first packet must come from the client and there should be some packet flow to not zero the NAT's counter. The above service could also announce a list of TB's to the client and let the user pick, they seem to be quite good at that. This feature should then be released for all major OS's as otherwise it still wouldn't deploy... and it will just be the same as 6to4, a very good idea but little usage. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFPDNwAAaCIAn1KRFZkPrxOnK94RlUgnVe5b NZwZAJ9Ryelx6My3/cnB9VEzLXKT+ggZEw== =wC0I -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sun Mar 14 01:26: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 BAA21163 for ; Sun, 14 Mar 2004 01:26:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2P24-000JC2-HU for v6ops-data@psg.com; Sun, 14 Mar 2004 06:23:32 +0000 Received: from [140.109.4.194] (helo=dormnet.sinica.edu.tw) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2Kil-000Nb4-Px for v6ops@ops.ietf.org; Sun, 14 Mar 2004 01:47:19 +0000 Received: from [127.0.0.1] (mclin1.sinica.edu.tw [140.109.1.184]) (authenticated bits=0) by dormnet.sinica.edu.tw (8.12.8/8.12.8) with ESMTP id i2E1l8YU021576; Sun, 14 Mar 2004 09:47:11 +0800 Date: Sun, 14 Mar 2004 09:47:09 +0800 From: "Ethern M.C. Lin" To: "JORDI PALET MARTINEZ" Subject: Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] Cc: In-Reply-To: <0d7501c4093e$b923f3e0$8700000a@consulintel.es> References: <0d7501c4093e$b923f3e0$8700000a@consulintel.es> Message-Id: <20040314091346.1457.ETHERN@ascc.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.08 [en] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to give some comment about the Tunnel Broker and 6to4 relay service in the IPv6/IPv4 transition mechanism. We provide TB and 6to4 relay since 2001, and we use the TB from CSELT TILAB(http://www.cselt.it/) and I think almost free TBs are coming from there.;) And now we only have 30 tunnels in active. We have almost 2300 registered users in our TB database, but almost are data faked or incompleted. We are opened for the wohle world users, and we only assign /127 to the tunnel. Why we only open 30 active tunnels for use? Because we are afraid of ABUSE of the users. It is quite amazing. An open service but has its limited. The registered users are from all over the world, and some are even untracable and uncommunicated. So if the user has something happened, we are the one which will be complained. So that's why we open so less usable tunnel. We will continue to improve the TB to make it more reliable and secure. Although our purpose is to promote the IPv6 and make the connectivity to the whole IPv6 world, but the most importance thing we care is the *security* in our service. IMHO, to provide and service and care the consequence of service is the provider's responsibility. We get two IPv6 prefix block, one is 3FFE:4001::/32, the other is 2001:C08::/32. We provide the tunnel with 3FFE:4001::/32 to use, since we define the TB as the "pilot service" as right now. Even the 6to4 relay is the same. We use FreeBSD w/ KAME to provide 6to4 connectivity, but only accessable to the ASNet. We don't open to peers nor customers. We only take the TB and 6to4 relay are the temporarily services for the moment. In the future, we will focus the dual-stack connectivity. Best Regards, Ethern ASCC -- ============================= Ethern M. C. Lin, Network Division Computing Centre, Academia Sinica Phone: +886-2-2789-9953 Fax : +886-2-2783-6444 ============================= -- On Sat, 13 Mar 2004 22:03:58 +0100 "JORDI PALET MARTINEZ" wrote: >Pekka, > >See in-line. > >Regards, >Jordi > >----- Original Message ----- >From: "Pekka Savola" >To: "Jeroen Massar" >Cc: "'Alain Durand'" ; >Sent: Saturday, March 13, 2004 9:37 PM >Subject: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] > > >> Hi, >> >> I think this message was useful; let me try to respond to some >> comments inline.. >> >> On Sat, 13 Mar 2004, Jeroen Massar wrote: >> > > > Please elaborate on this point. If your ISP does not help but >> > > > a neighboring ISP offer v6 tunnels, what is the problem? >> > > >> > > The problem is that the neighboring ISP won't offer v6 tunnel to you >> > > because you're not his customer. >> > >> > In general this is actually what we are doing. >> >> Sure; I didn't want to say that such nice folks don't exist. I just >> was arguing that they aren't that commonplace, may be difficult to >> find (especially to those not familiar with IPv6!), may not use the >> same mechanisms at the tunnel broker (making client software >> deployment a mess), etc. >> >> Remember, our goal is not get IPv6 deployed to those guys who are >> reading this mailing-list and can do a lot of technical stuff to set >> things up. The target audience (which I have in mind at least) is >> much more "dumber" than that. I'd like to aim for the case where the >> most the user would have to do is click an "activate IPv6" icon on the >> desktop or network settings -- and not necessarily even that. That >> function should try to send route solicitation on your link, find a >> free tunnel broker provided by your own ISP, or set up 6to4/Teredo all >> else failing. > >Agree, as said in a previous message, this is more or less what we are doing, and hopefully could present in San Diego (we call it auto-transition): >- Native >- 6to4 >- TB with 6in4 if a public IPv4 address is available >- TB with proto-41-forwarding if NAT supports it >- TB with UDP encapsulation >- Teredo >- others (even IPv6 over HTTP in the worst case !) > >The order not necessarily is what I wrote down, as it may depend on the "best performance" solution for every client, and even change if the client or network change. > >The "activate IPv6" should not be needed if we can manage to have the process automatically, and alternatively we should offer the "deactivate IPv6", hopefully, if for whatever reason, the user choose to ;-) > >The auto-transition might propose the user, if the IPv6 performance in a given situation is very bad, to use IPv4 (hopefully with the time less and less often). > >The discovery process might be not simple, specially because we want to ensure the best possible performance at any time. > >> >> > > There has been very little 6to4 relay deployment. And that's even >> > > better for the ISPs to deploy, because the abuse etc. that happens >> > > doesn't come from you 2001:f00::/32 address space. The ISPs in >> > > general *don't* want to offer their production space address space to >> > > every John Doe that comes knocking on their door. >> > >> > I personally think that that is actually one of the things *against* >> > 6to4, it is totally untraceable/debuggable as one never knows where >> > packets are going to flow to/from as there just might be one or even >> > more hidden 6to4 relays along the route. >> >> From one perspective, yes. From the ISP perspective, maybe not. >> That is, 6to4 is rather an anonymous mechanism: you can provide it to >> third parties without them getting your IP addresses, without you >> getting complaints about abuse, etc. -- it's much simpler to set up >> for outsiders in many ways than a tunnel broker. >> >> > Next to that apparently many users *demand* RIR space, they think >> > it is cooler or works better. There are even people who are proud >> > to have inet6num's ;) >> >> Certainly, the users want RIR space. But the question was what the >> ISPs want to *GIVE* to folks that are not their customers. We, as an >> ISP, certainly don't want to give 3rd party users *our* address space. >> Many tunnel brokers today that exist operate with 6bone address space, >> or are some kind of "pilot service", which may be less of a problem in >> some sense. >> > >My feeling is that this is no longer true, and more and more TBs offer RIR space, and even the change to have it statically even when the user is moving. > >> > The 'discovery' mechanism we use for the SixXS project is quite simple >> > though absolutely not automated: users signs up through the website >> > and gives it's details, thus we know his address+country + IP, then >> > after being approved they can request a tunnel, again we get an IP. >> >> Yep -- but that assumes the users must first know that such tunnel >> brokers exist, can find them in the web, install the software, fill in >> the forms, etc. >> >> I.e., it's OK for techies, but looking at wider deployment, it's >> unacceptable. But I guess it depends on who are you aiming the >> mechanism for; if we standardized a solution in this space, I think it >> would certainly have to be much simpler than that administratively. > >That's why we are looking for automatic discovery as part of the auto-transition "toolset". > >> >> -- >> 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. > > ============================= Ethern M. C. Lin, Network Division Computing Centre, Academia Sinica Phone: +886-2-2789-9953 Fax : +886-2-2783-6444 ============================= From owner-v6ops@ops.ietf.org Sun Mar 14 11:17:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25266 for ; Sun, 14 Mar 2004 11:17:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2YEv-000EbR-5y for v6ops-data@psg.com; Sun, 14 Mar 2004 16:13:25 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2YEU-000ERI-BG for v6ops@ops.ietf.org; Sun, 14 Mar 2004 16:12:58 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2YET-0001su-00; Sun, 14 Mar 2004 16:12:57 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2YET-0001sp-00; Sun, 14 Mar 2004 16:12:57 +0000 Received: from zurich.ibm.com (sig-9-145-168-107.de.ibm.com [9.145.168.107]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2EGCuF09148; Sun, 14 Mar 2004 16:12:56 GMT Message-ID: <405484A6.2AE378D7@zurich.ibm.com> Date: Sun, 14 Mar 2004 17:13:26 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Rob Austein CC: v6ops@ops.ietf.org Subject: Re: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] References: <20040313073945.4F79E18E0@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.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 Rob Austein wrote: > > At Sat, 13 Mar 2004 08:08:51 +0200 (EET), Pekka Savola wrote: > > > > The chief advantage of 6to4 is its simplicity (a minimal -- but > > insecure -- implementation can be about 5-10 lines of code!), and the > > ability to provide a /48 prefix, instead of being run individually on > > each system. This could be useful especially in the cases where the > > (NAT) gateways would implement some form of IPv6 support. As Teredo > > cannot support more than one address, it would not be applicable in > > this scope. > > The 6to4 edge routers I've been using for the last two or three years > do this. I for one would be unhappy to lose this capability. > > > The disadvantage is that it's an additional mechanism, and not > > applicable except in the space where NAT is often being used; also, > > the security properties are worse with 6to4 than Teredo (due to its > > simplicity). > > With all due respect, the second clause of that sentence is a cheap > shot. 6to4 can be implemented well or poorly and can be used well or > poorly. Packet filtering works just fine on an edge router if one > bothers to turn it on. I do not believe that giving 6to4's job to > Terado would really solve any security problems; at best it would > transform them, and in some cases it would probably make them worse by > replacing a simple solution with a more complex one. > > > Depending on how strongly people feel about the necessity of this > > optimization and providing an easy means for (NAT) gateway vendors to > > add basic IPv6 support, 6to4 could be retained, or we could try to > > figure out whether Teredo spec needs to be re-evaluated for the case > > when there is no NAT traversal at all. > > Terado is excessively complex for the case of a user who wants IPv6 > capability from an IPv4-only ISP and has the ability to replace the > NAT box. Yes, Terado could probably be used in this case instead of > 6to4; pigs also fly just fine, given sufficient thrust [RFC1925], but > that doesn't make either of these a good idea. > > Please retain 6to4. Not surprisingly, I agree :-) But in any case, I think it is out of the IETF's hands at this point. 6to4 will die when it no longer serves any purpose. Brian From owner-v6ops@ops.ietf.org Mon Mar 15 02:08: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 CAA04316 for ; Mon, 15 Mar 2004 02:08:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2m8T-000Fr1-In for v6ops-data@psg.com; Mon, 15 Mar 2004 07:03:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2m8I-000Foj-5j for v6ops@ops.ietf.org; Mon, 15 Mar 2004 07:03:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2F73EX27732; Mon, 15 Mar 2004 09:03:15 +0200 Date: Mon, 15 Mar 2004 09:03:14 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Rob Austein , Subject: Re: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <405484A6.2AE378D7@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 14 Mar 2004, Brian E Carpenter wrote: > Rob Austein wrote: > > Please retain 6to4. > > Not surprisingly, I agree :-) > > But in any case, I think it is out of the IETF's hands at this point. > 6to4 will die when it no longer serves any purpose. Of course, we cannot take away what's deployed, or what will be deployed :-). The relevant point, however, is a) what we should recommend that folks do, and b) how strongly we should aim for good interoperability between different sets of {6to4, Teredo, Native} If there was concensus that we shouldn't need to do 6to4, we might be able to simplify those interoperability concerns. At the moment, however, there doesn't seem to be strong push for that. -- 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 Mar 15 02:25:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12493 for ; Mon, 15 Mar 2004 02:25:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2mS1-000KM2-Co for v6ops-data@psg.com; Mon, 15 Mar 2004 07:23:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2mRq-000KJK-8U for v6ops@ops.ietf.org; Mon, 15 Mar 2004 07:23:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2F7NXe28017; Mon, 15 Mar 2004 09:23:34 +0200 Date: Mon, 15 Mar 2004 09:23:33 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: "'Alain Durand'" , Subject: RE: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <20040314022834.617328722@purgatory.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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 14 Mar 2004, Jeroen Massar wrote: > If they can use MSN, which requires one to sign up with > MS Passport and then fill in quite an amount of data, then most > people, anyone age 13 and up, should be able to sign up with a > number of tunnelbroker systems. MSN is, as far as I know, rather integrated with the system, so setting it up is easier. The critical point here is locating the tunnel broker. If you just have one or two to pick from, they may be more well-known. Locating MSN is much easier than locating a tunnel broker (or even knowing that such brokers would exist). Further, it's a bit different to sign up for MSN and tunnel broker (IMHO): the requirements for the tunnel broker owner in terms of bandwidth, etc. are probably much higher. > > That function should try to send route solicitation on your link, find a > > free tunnel broker provided by your own ISP, or set up > > 6to4/Teredo all else failing. > > As you are mentioning a 'discovery' type of service, I don't > think that is really possible as TB's are more like virtual > ISP's and like real ISP's it's the clients who want it. > > The only thing that can be auto-discovered+configured is > currently 6to4. And Teredo, and ISATAP, if you count on them being here yet. > If we (ietf) would want to have a > autodiscovery feature for TB'sit would have to rely on a > anycast address which the ISP announces the same way as > the 6to4 address and basically one would get 6to4. Anycast for interdomain discovery; DNS, or DHCP would work if the goal is to auto-discover when your local ISP is offering service. > - user enabled the IPv6 knob in $os > - host builds tunnel to anycast address > - normal ND/Ra procedures delegate the addresses. > > This won't work with non-static IP's and getting the same prefix > back though, Sure; but this would probably be sufficient for the average John Doe, right? > thus we require another thus another option would be: > > - user enables the IPv6 knob in $os > - host contacts the anycast address port over TCP* > - sends it's user login/password > - retrieves it's configuration data. Anycast w/ user authentication would probably be out of scope, due to the problems you describe. The only thing that _could_ be done is to create a discovery process which would indicate where the closest broker w/ authentication is available. > On error (eg user doesn't exist, not configured) it could > return a URL of the closest POP for that TB service. > > The anycast service could also be used to redirect people > to the closest TB or a list of TB's of course. That would require that there is some form of agreement/knowledge of all the other TB's in the responding service. > > From one perspective, yes. From the ISP perspective, maybe not. > > That is, 6to4 is rather an anonymous mechanism: you can provide it to > > third parties without them getting your IP addresses, without you > > getting complaints about abuse, etc. -- it's much simpler to set up > > for outsiders in many ways than a tunnel broker. > > As far as I heard the Hexago Migration broker box is just a > 'buy' 'enter config data' 'start' procedure, but I haven't seen it yet. > As for SixXS it is just 'contact info@sixxs.net, install a unix box, > enter config data, upload the software, enable the POP, done' > > All depends wether you want to reinvent the wheel or not ;) Yet, this misses the point. I don't think the problem is the complexity of setting up the mechanism (especially for 6to4 relay, might be for the tunnel broker at the moment), but rather whether the ISP would want to offer such service in the first place. Many don't. See the next point. > > Certainly, the users want RIR space. But the question was what the > > ISPs want to *GIVE* to folks that are not their customers. We, as an > > ISP, certainly don't want to give 3rd party users *our* address space. > > In case of the SixXS model that would simply be feeding it the > prefixes that you would want to serve, as what happens with > the Data Telecom and the M"Net POPs. This would disallow them > from using those boxes. In case of the above anycast service > only your customers would get service from you as those would > get the anycast address response due to it being in their > routing system. Other users would possibly get a public TB. Such internal tunnel brokers only have sense to participate in the "SixXS" model to gain publicity (i.e., their own customers know they're offering the service) or to give better service to their unaware customers (i.e., if the tunnel broker at SixXS redirects them to the private broker based on some shared information, like "we know this one is best for you, use that!"). But the real problem here is that we can't really create (or at least, I'm having trouble visualizing such a system..) a global tunnel-broker network, like SixXS, which could be used by anyone in the world to learn the closest and "best" tunnel server available to them. And all the tunnel servers, public ones at least, but also private ones if they aren't discovered using a different process, would be connected to that... > > Yep -- but that assumes the users must first know that such tunnel > > brokers exist, can find them in the web, install the software, fill in > > the forms, etc. > > They found MSN, Yahoo, Google, KaZaA etc. Friends tell that is the > trick to it, if there is interresting enough content even 13 year > olds can configure it. Right. If we assume IPv6 would have killer applications which would make the users really eager to get it, sure -- everything would probably be simpler. But in the absence of such, we need to forward without them :-). [ I've snipped the parts about a tunnel broker discovery mechanism to another thread ] -- 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 Mar 15 02:54:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13547 for ; Mon, 15 Mar 2004 02:54:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2msx-000360-1J for v6ops-data@psg.com; Mon, 15 Mar 2004 07:51:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2msl-00032V-Bo for v6ops@ops.ietf.org; Mon, 15 Mar 2004 07:51:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2F7pQd28289; Mon, 15 Mar 2004 09:51:26 +0200 Date: Mon, 15 Mar 2004 09:51:26 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: "'Alain Durand'" , Subject: tunnel broker auto-discovery [RE: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <20040314022834.617328722@purgatory.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.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 Taking the "auto-discovery" part of the thread apart from the rest... I think one should soon try to write a draft about different tradeoffs of tunnel service discovery procedures (inter-domain anycast, intra-domain anycast, DNS (at least two methods), DHCP, manual config ec.). This might help us a lot in trying to figure out what we actually want in this space. Maybe someone(s) in the WG would be interested in drafting such a document in a fast-track fashion (e.g., within a week or two at most).. On Sun, 14 Mar 2004, Jeroen Massar wrote: > Pekka Savola [mailto:pekkas@netcore.fi] wrote: > > I.e., it's OK for techies, but looking at wider deployment, it's > > unacceptable. But I guess it depends on who are you aiming the > > mechanism for; if we standardized a solution in this space, I > > think it > > would certainly have to be much simpler than that administratively. > > Indeed, I guess it would be a good idea to pursue the anycast > configuration service or a similar technique. ISP's that don't > want to allow other ISP's users on their service can always > not announce the prefix to other ISP's and can always announce > the prefix to other users. > > Having a single hostname, eg "ipv6.tunnelbroker.arpa" or something > would not work as ISP's would then have to depend on the instance > running that service to distribute the clients. Unfair competition > and other blabla comes to mind. Yes, single hostname wouldn't work, I think. However, one could say that you could check for the local tunnel broker by looking up e.g. 'ipv6-tunnel-server.' appended with your DNS search path, right? That would work just fine in certain scenarios: if the broker doesn't exist, you get negative reply and use a different mechanism (e.g., anycast or manual config); if positive, you use that. This has drawbacks in the cases when you're mobile/nomadic (i.e., have to re-do the DNS lookup, not just re-route by anycast, but as the prefix when moving would change as well, this might not be a significant drawback). One item I'd like to know more is how large ISPs which offer e.g., DSL service, in different geographical areas, configure the DNS search paths. That is, whether the DNS search path trick would be sufficient in finding the closest broker, or whether anycast would have to be used on the side (note: nothing of course prevents you from anycasting the IPv4 tunnel broker address that gets returned from the DNS). The main question here is, I think, whether there would be pushback in the DNS community for standardizing such "special-case local names". I recall there is precedent for doing something like this, but I'm not fully certain. This would have to be investigated in advance.. > To sum up the features I would like to have in such a protocol: > - anycast address or similar to choose the closest TB and > this could quite well be the service the ISP operates or > a friendly ISP announcing this prefix. One problem though > there is no way of having multiple TB's this way. > But if a user knows which TB she wants she can always go > directly to that TB. Precisely. > - Restricting users to only certain prefixes > using the anycast announcement, just don't announce and/or > redirect the users to another service, never say NO... Yep. > - user authentication (optional) > this is mainly to track users, know who is using what etc > it also allows giving the same prefix to the same user even > when the user changes IP addresses. > This could also be done using a cookie mechanism. I think this should probably be out of scope for anycast mechanism, at least in some sense. That is, - the anycast service must not lead to a tunnel server, which requires user authentication; that is, "zero-configuration" must always be possible. - the user might try to perform user authentication with the tunnel server, but if the tunnel server does not know the user, the user would not have other fallbacks than manually selecting the tunnel server. I think it might even be better that the anycasted services would not offer any kind of user auth -- because if the closest server changes, the authentication won't work anyway (or you'd have to redo it), and it's just wasted effort. > - static prefix delegation > could be done using normal RA techniques. This would probably depend on user authentication or some kind of identification being there. If it isn't, the prefix can be only as stable as it is (i.e., until the IPv4 address or IPv4 address + port changes). So, in my book, "static" is not a requirement. I'd rather tie the requirement to the staticity of the v4 address and or UDP port (if coming through a NAT). Are you referring to advertising a /64 and doing something like ND-proxying, something like draft-bykim-ipv6-hpd-01.txt or what? Without ND-proxy I don't think prefix delegation would work with currently specified mechanisms except for DHCPv6. > - DNS server configuration for that prefix. You mean reverse DNS. Delegation and/or full configuration (e.g., a wildcard record for the whole prefix)? > - Protocol 41 at first but optionally over UDP eg > after detecting that proto-41 doesn't work. Yep. > - UDP mode to be able to cross a NAT. > Every single NAT I know of can be configured to > forward UDP packets, thus that should work. > There is one but, the first packet must come > from the client and there should be some packet > flow to not zero the NAT's counter. Yep. > The above service could also announce a list of TB's > to the client and let the user pick, they seem to be > quite good at that. Clarification: are you referring to TB's controlled by the anycast-replying entity (e.g., a large ISP having a dozen geographically distributed tunnel servers), or referring to other TB's as well? The former doesn't make sense with anycast, as there is no need for that. The latter doesn't seem to be feasible, as it would require sharing information with about all the tunnel brokers in the world. How would one do that? Not manually I hope. So, this seems equally problematic as well. > This feature should then be released for all major OS's > as otherwise it still wouldn't deploy... and it will > just be the same as 6to4, a very good idea but little usage. You never know.. it could be little usage, but if implemented and used by e.g. Microsoft, you would immediately have 5+ million IPv6 users through a tunnel broker.. for the good or bad :) -- 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 Mar 15 06:08:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20877 for ; Mon, 15 Mar 2004 06:08:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2puZ-000Eci-Ad for v6ops-data@psg.com; Mon, 15 Mar 2004 11:05:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2puO-000EZN-58 for v6ops@ops.ietf.org; Mon, 15 Mar 2004 11:05:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2FB5Ik30552; Mon, 15 Mar 2004 13:05:19 +0200 Date: Mon, 15 Mar 2004 13:05:18 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <0d7501c4093e$b923f3e0$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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'm replying to only one issue, under a new subject line, because I think the others have been sufficiently addressed.. I think this mechanism selection work is also important, and it would be nice to have something written out very soon so that we wouldn't get stalled too soon. If folks are interested in writing up something quickly, please do line up.. :) On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > > Remember, our goal is > > not get IPv6 deployed to those guys who are reading this > > mailing-list and can do a lot of technical stuff to set things up. > > The target audience (which I have in mind at least) is much more > > "dumber" than that. I'd like to aim for the case where the most > > the user would have to do is click an "activate IPv6" icon on the > > desktop or network settings -- and not necessarily even that. > > That function should try to send route solicitation on your link, > > find a free tunnel broker provided by your own ISP, or set up > > 6to4/Teredo all else failing. > > Agree, as said in a previous message, this is more or less what we > are doing, and hopefully could present in San Diego (we call it > auto-transition): Yes, this is very useful work, but something that should be done much sooner than San Diego (IMHO). Draft out within a week or two would be a good goal :-). Actually I think this has already been discussed quite a bit (e.g., the "unmanaged bar gathering" at Minneapolis at IETF58), but not written out and fleshed out entirely. It would be very useful to get that at least started and something written out soon. Another related subject which needs to be worked at also is the coexistance of all of these mechanisms. It's not just what you're using yourself, but what you should do to enable the others to use v6 to talk to you (e.g., local 6to4 or Teredo relays). This may be out of scope for this idea, but something to keep in mind in any case. > - Native > - 6to4 > - TB with 6in4 if a public IPv4 address is available > - TB with proto-41-forwarding if NAT supports it > - TB with UDP encapsulation It may be worth noting that discovery of TB's is a rather delicate process (see the other thread), and a subject which may be very difficult to do properly. But we can try... > - Teredo > - others (even IPv6 over HTTP in the worst case !) Well, I'd leave that "even" out from here.. :-) > The order not necessarily is what I wrote down, as it may depend on > the "best performance" solution for every client, and even change if > the client or network change. True, though "perfomance" is hardly an easily measurable unit, so difficult to use in practice algorithmically. > The "activate IPv6" should not be needed if we can manage to have > the process automatically, and alternatively we should offer the > "deactivate IPv6", hopefully, if for whatever reason, the user > choose to ;-) Sure. > The auto-transition might propose the user, if the IPv6 performance > in a given situation is very bad, to use IPv4 (hopefully with the > time less and less often). That's possible, yes. In most cases, the performance is actually worse, but there are different ways to count it (e.g., v4 connectivity through for P-2-P through a server vs. direct v6 connectivity; and good v4 latency vs bad v6 latency). This is probably something that would be impossible to measure properly. So I have doubts about this being all that useful -- but one could certainly use this to say "hey, the tunnel broker is 200 ms off on the other side of the globe -- maybe it's not a good idea to use it?" -- 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 Mar 15 06:25: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 GAA21295 for ; Mon, 15 Mar 2004 06:25:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2qBx-000J8p-PX for v6ops-data@psg.com; Mon, 15 Mar 2004 11:23:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2qBm-000J5r-B4 for v6ops@ops.ietf.org; Mon, 15 Mar 2004 11:23:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2FBNIk30749; Mon, 15 Mar 2004 13:23:18 +0200 Date: Mon, 15 Mar 2004 13:23:18 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation] In-Reply-To: <0db001c40941$bd243f10$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.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 To summarize the inline discussion: - counting on NAT boxes implementing v6 and getting those boxes in the field would probably require an IPv6 killer application, and IMHO we shouldn't be counting on it - I don't yet know how to integrate "v6 support in the gateway" in the document (somehow in the matrix, vs elsewhere). If you have specific suggestions, fire away. - I think it'd be very useful to publish as much info on proto-41 capable (or incapable) boxes as possible; I think that would help us a lot. (The same applies to different NAT types wrt. Teredo, but that's already being done in a separate draft.) More detail inline.. On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > > On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > > > > True enough. However, I have doubts on how useful this case is in > > > > practice, as a large number of gateways cannot be expected to be > > > > upgraded -- that is, we will have to support host-centric deployment > > > > in any case. > > > > > > I don't agree. In general is in the other way around. Is more and > > > more often that the routers, gateways, etc., are updated from time > > > to time, with new firmware or software. > > > > For technical users, yes; for non-techies, I have serious doubts about > > that. DSL products bought or provided by the ISP stay there for 3-5 > > years at least, and they don't have a software upgrade; even if they > > had, the average user wouldn't know or dare to install it. > > No, I don't think so. More and more users keep updating their > equipment, even when non-techies. But definitively, no longer the > equipment is there for so long time, I will say less than 2 years, > actually. Let's just say that we disagree on this. > > If an IPv6 product (e.g., Microsoft's some new shiny new patch kit to > > use v6 in peer-to-peer) was being deployed, saying "upgrade your NAT > > box" is not an option. The case where we can't do anything about the > > deployed base is the minimal target: it must be supported as well as > > it can be. If we can, we might also want to create optimization(s) > > for the cases where some box has been upgraded (or not). > > If a wide spread game or product is in the market and requires the > user to upgrade their box, even purchase a new one to play that > game, you can make sure that they will do so ;-) The only problem > right now is the price for IPv6 enabled routers. Hopefully low cost > models will come soon from Taiwan and China. Certainly. But you're counting on a killer application to appear, which would make the user to justify investing into a new NAT box, as well as spending time on working on a solution. None have appeared yet, so I do not want us to base IPv6 connectivity mechanisms on that premise. These should work (or at least a subset of them), even if the killer app doesn't turn up which would make the users want IPv6 so bad that they would be willing to buy new hardware, require IPv6 from their ISP, etc. Then we would be where we want to be, of course, but we shouldn't count on that. > > The real market situation can be handled if we design solutions that > > work with the lowest common denominator (e.g., no NAT/gateway > > support), right? > > Yes, but choosing only 1 or 2 options (is just an example, I'm not > counting the real situation right now) may be not optimal, specially > if we have a 3rd one that could be more optimal in, let's say more > than 30-40% (may be even less percentage is acceptable) of the > cases. If that's the case, then we should include that option in our > matrix. I think this depends on the complexity of the solution and how big an optimization it would actually offer. Currently, the case where NAT gateway implements v6 (like 6to4) does not seem useful enough, but might become so in the future (and it might not hurt to consider how the transition landscape could change if that happens). So, I certainly think it should be mentioned in the document, but I'm not yet sure how. Being included in the matrix could be an overkill and difficult, but leaving it out might cause us to omit some mechansims (or requirements) which would would be useful in the scenario. So, I'm open to more specific suggestions (than just "include it in the matrix"). Include it how? Reword the scenarios how? I'll probably try to think of some means myself, but if folks feel this is an important issue, feel free to help... :-) > > I think it's OK to mention brands and models -- there's precedent in > > draft-jennings-midcom-stun-results-00.txt and a lot of other > > documents. We might not want to publish those results as an RFC, but > > I think it would be useful to make that list public so folks could see > > if they something to add to the list, see whether they have different > > experiences, see if their product would be supported or not, etc. > > Ok, then as I can remember, we have all the Cisco, 3Com, Linksys, > Nokia, D-Link, NetGear, Draytek, SMC, Conceptronic, Allied-Telesyn, > Develcon, Perle, Trinexus, Yamaha, Zyxel, NEC and Buffalo. > > In addition, looking into the "firmware" of these products, I found > as a common denominator that they work if they have IOS, VxWorks, > QnX, Linux, USSoftware, and BSD. Some times the OS is hidden, but > I've been able to discover it or checking with the manufacturer or > some document around. > > Note that I've not tried all those (may be about 40% of them only), > but we asked in this list and several others, the people to try out > and this is the result of the feedback received. > > The only one that I've found myself that failed to support > proto-41-forwarding was Efficient Networks (I believe now belongs to > Siemens). > > If you look into the market sharing, I'm very convinced that this is > even higher than 85%, but just to be conservative ... Market share is probably an important consideration, but not the only one. Could you get this written up in some form (e.g., a web page, internet-draft, etc.) with as much detail as possible (and when in doubt about the information, with contact info etc.). This would probably make it much easier for folks to see how the support SHOULD be and state if there are inaccuracies, start to use this if they didn't know their own NAT even supported this, etc. It may also be worth noting which features are supported. I recall there was some confusion wrt. being able to configure an internal host to receive proto-41 packets (or requiring any other configuration) vs. the NAT box working automatically out of the box, or whether it requires some configuration [what kind of config?] (the out of the box operation is a very important consideration here). -- 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 Mar 15 09:05:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28167 for ; Mon, 15 Mar 2004 09:05:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2sf2-000FPy-JR for v6ops-data@psg.com; Mon, 15 Mar 2004 14:01:44 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2rzQ-0002Tv-Ru for v6ops@ops.ietf.org; Mon, 15 Mar 2004 13:18:45 +0000 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Mar 2004 14:03:46 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : RE : Tunneling scenarios and mechanisms evaluation Date: Mon, 15 Mar 2004 14:03:45 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC23B702A@ftrdmel3.rd.francetelecom.fr> Thread-Topic: RE : Tunneling scenarios and mechanisms evaluation Thread-Index: AcQITZr7MnX78ccwTaqyfbCuTqadewCJkyHQ From: "BAUDOT Alain FTRD/DMI/CAE" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 15 Mar 2004 13:03:46.0802 (UTC) FILETIME=[F3AC0520:01C40A8D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks for your comments. You raise tough issues, and I'm not sure if=20 I see the point in some of them. Maybe you can elaborate a bit.. On Fri, 12 Mar 2004, BAUDOT Alain FTRD/DMI/CAE wrote: > 1. Introduction >=20 > I think Tunnel Broker (TB) should part of the analysis, as well. I have to disagree -- AFAICS, TB (RFC 3053) is just a concept, TSP=20 being an instantiation of that concept. I'm not sure how to even=20 compare that if it was included.. AB> TB is part of the analysis, then, not by its own, but through TSP ;) Basically, if TB is not directly part of the analysis, it should be explained. > 3.2 Unmanaged Networks >=20 > Case 2 seems to match ISP case 2a (where the connection network cannot > be upgraded), unless it is a compilation of unman case C and ISP case=20 > 2a. Yes. > Anyway, in one case the ISP cannot cooperate with unman network, while > it can do so in the other case. The appropriate solution may then meet > different requirements, e.g. oportunistic mechanism may or may be not=20 > suitable. I guess this need some clarification. I'm not sure if I understand what you meant with "cannot cooperate=20 with unman network" ? Do you mean that the unmanaged user does not use (or cannot use) the mechanism that the ISP is using? The user should get that support=20 then, or if not, the case would equal the unman case 1.1 -- when ISP=20 does not provide any support. AB> Well, I mean that "ISP support" meaning is unclear... It seems that the ISP, either is passive, or is providing direct IPv6 connectivity. ISP case 2a is actually in the between. =20 > "NAT traversal must be supported." This is not true if the tunnel ends > in the gateway where the NAT function is usually located. I think this > is important, since the solution to deploy does not need to deal with=20 > complexity of NAT traversal. True. On the other hand, practically, it seems clear that we cannot=20 expect *all* of these gateways to support IPv6 -- so we'll have to=20 cope with every scenario. However, this does not say that NAT=20 traversal must be _used_ -- it just has to be supported in the case=20 that it's needed. AB> Right. And an ISP may not support every scenario.=20 One could certainly break the unmanaged cases into smaller pieces, depending on whether IPv6 is supported in the gateway device or not, but I think the result in the end is just the same, and we would not gain anything by splitting a larger scenario to a few smaller pieces (as we would still have to wrap it up -- to use the same mechanism as it would not make sense to specify two for the slightly different cases). Or, did you mean that the "IPv6 in the gateway via a tunnel" is a=20 significant case, and it might be useful to try to analyze it=20 separately? AB> IPv6 in a gateway via a tunnel is very close to "IPv6 in the gateway", i.e. natively. Everything behind the gate should be exactly the same in both cases. It sounds like a significant case indeed. =20 > 3.4 ISP Scenarios >=20 > "ISPs do not have specific scenarios which need to be addresses which=20 > haven't been already mentioned" >=20 > ISP scenario case 2b, where the ISP backbone is not IPv6 capable, is=20 > not discussed here. It isn't, because the answer is obvious, especially after the Monday meeting: configured tunneling or something like BGP tunneling. I guess this could be spelled out.. > Anyway, I think that there is a large difference between "obtaining"=20 > connectivity, as discussed in the previous section 3.3, and=20 > "providing" a connectivity as an ISP. ISPs have strong requirements,=20 > at least, on user identification, in order to make sure the=20 > connectivity is provided to its customers with some reasonable load=20 > (and without unpredictable overload), and on addressing since the duly > identified customer may benefit from some address/prefix delagation=20 > from the ISP' TLA. I'm not sure if I see fundamental issues here. All the mechanisms which are meant to be used in the "ISP-assisted" method already provide pretty good means for identifying the user as the ISPs own customer -- either through the identification of IP address, or through other means. AB> I mean here that, in order to be really manageable, identification/delegation has to be explicite, as well as it is with IPv4, with a clear connection between the user and prefix. =20 I didn't quite understand your comment on the load. That's of course=20 certainly a factor, especially with tunnel-server -like models. Could=20 you elaborate? AB> I mean here that some "open" or "opportunistic" mechanism are actually available for all, and one just neeed to pick up connectivity. In this case, and without any user control mechanism, the number of users and the trafic load come unpredictable. All the mechanisms on the table for "ISP-assisted" case are already=20 offering an address or prefix from the ISP's address block (in=20 contrast to someone else's) so I'm not sure if I see your point. Or=20 were you saying that we should spell out whether the user gets an=20 address, a subnet /64 prefix or a site /48 prefix through the use of=20 the mechanism? =20 There are certainly differences there, but as the mechanisms are not meant to be permanent, I'm not sure how important that would be from=20 the _ISP's_ perspective at least. AB> The point is that, once the mechanism is removed, the others means or behavior (from the user and the ISP point of view) should remain, as much as possible, unchanged. =20 > 4.1 Scenarios Evaluation >=20 > I think the matrix should match here all the identfied scenarios from=20 > 3GPP, UNMAN, ISP and ENT, and not a subset of them. The matrix is intended to include the specific scenarios from all the=20 documents which have been identified, while avoiding duplication. Can=20 you identify some scenarios which are missing? AB> My point is that we simply should find in the matrix exactly the cases identified into scenario documents (unman csae, A,B,C,D, ISP, case 2a, 2b, etc...) > Two columns maybe added: one dealing with "user identification" and=20 > another one dealing with some prefix delagation means, in order to=20 > actually complement the ISP column. I think we'd have to have a bit more precise idea what these would=20 imply. Could you for example describe the requirements for user=20 identification in each case (and rate the requirements)? What would=20 be sufficinet user identification? And similar about prefix delegation. I guess what you're saying is that different scenarios require different amounts of addresses? And similarly, different mechanisms provide a different amount of addresses. AB> Explicite mechanism maybe enough here. For instance, embedding an IPv4 addresse into IPv6 one, is an implicite mechanism. Note that in many cases, there's no stopping from each host in the=20 network running the mechanism on its own, getting an address from each=20 tunnel. How would that get rated in the "amount of addresses" field? > 4.2 Mechanisms Evaluation >=20 > I wonder here what is the real meaning of ISP support in terms of=20 > features or functions. It just simply tries to imply whether support from the ISP is required=20 or not. Of course, this is difficult to judge -- is e.g., a 6to4=20 relay somewhere in the network, by some other ISP considered "ISP=20 support"? I don't count it as such. > Anyway, to get a more compltete picture, I would add columns for: > > -terminal/gateway: if the macnism applies to a terminal only, a=20 > gateway only or both with the idea of complement ISP column: -user=20 > identification -address/prefix delegation means. Similarly, I would like to understand the terminal/gateway distinction better, i.e., how it would be useful for this comparison? AB> The distinction here is that a mechanism that applies to a gateway, applies for the whole network behind the gateway, while a mechanism that applies to a terminal has to be duplicate. When it comes to mechanisms proposed, Teredo is terminal-only, as well as is ISATAP (to a degree anyway -- some releases have provided support for prefix delegation etc. but I don't think this exists at the moment -- and would be terribly insecure if it did). TSP and STEP work in both. But with the current requirements, it's fine to just run the mechanism on the hosts themselves, not on the gateway, thus making this point a bit of moot. Alain. From owner-v6ops@ops.ietf.org Mon Mar 15 12:05: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 MAA10248 for ; Mon, 15 Mar 2004 12:05:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2vTK-000Kyk-ET for v6ops-data@psg.com; Mon, 15 Mar 2004 17:01:50 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2vSU-000KhJ-En for v6ops@ops.ietf.org; Mon, 15 Mar 2004 17:00:58 +0000 Received: from consulintel02 ([213.214.32.41]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 1-md50000000401.tmp for ; Mon, 15 Mar 2004 18:06:12 +0100 Message-ID: <175801c40aaf$a7426f40$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] Date: Mon, 15 Mar 2004 17:56:29 +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, 15 Mar 2004 18:06:12 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 213.214.32.41 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.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 Ok. We will work hard to have it lets say in 3-4 weeks at maximum (with = the goal in mind to have it in only two weeks, even if is preliminary). Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Monday, March 15, 2004 12:05 PM Subject: automatic tunnel mechanism selection [Re: tunnel broker = deployment [RE: Tunneling scenarios and mechanisms evaluation] > I'm replying to only one issue, under a new subject line, because I > think the others have been sufficiently addressed.. >=20 > I think this mechanism selection work is also important, and it would > be nice to have something written out very soon so that we wouldn't > get stalled too soon. If folks are interested in writing up something > quickly, please do line up.. :) >=20 > On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote: > > > Remember, our goal is > > > not get IPv6 deployed to those guys who are reading this > > > mailing-list and can do a lot of technical stuff to set things up. = =20 > > > The target audience (which I have in mind at least) is much more > > > "dumber" than that. I'd like to aim for the case where the most > > > the user would have to do is click an "activate IPv6" icon on the > > > desktop or network settings -- and not necessarily even that. =20 > > > That function should try to send route solicitation on your link, > > > find a free tunnel broker provided by your own ISP, or set up > > > 6to4/Teredo all else failing. > >=20 > > Agree, as said in a previous message, this is more or less what we > > are doing, and hopefully could present in San Diego (we call it > > auto-transition): >=20 > Yes, this is very useful work, but something that should be done much=20 > sooner than San Diego (IMHO). Draft out within a week or two would be = > a good goal :-). Actually I think this has already been discussed=20 > quite a bit (e.g., the "unmanaged bar gathering" at Minneapolis at=20 > IETF58), but not written out and fleshed out entirely. It would be=20 > very useful to get that at least started and something written out=20 > soon. >=20 > Another related subject which needs to be worked at also is the=20 > coexistance of all of these mechanisms. It's not just what you're=20 > using yourself, but what you should do to enable the others to use v6=20 > to talk to you (e.g., local 6to4 or Teredo relays). This may be out=20 > of scope for this idea, but something to keep in mind in any case. >=20 > > - Native > > - 6to4 > > - TB with 6in4 if a public IPv4 address is available > > - TB with proto-41-forwarding if NAT supports it > > - TB with UDP encapsulation >=20 > It may be worth noting that discovery of TB's is a rather delicate=20 > process (see the other thread), and a subject which may be very=20 > difficult to do properly. But we can try... >=20 > > - Teredo > > - others (even IPv6 over HTTP in the worst case !) >=20 > Well, I'd leave that "even" out from here.. :-) >=20 > > The order not necessarily is what I wrote down, as it may depend on > > the "best performance" solution for every client, and even change if > > the client or network change. >=20 > True, though "perfomance" is hardly an easily measurable unit, so > difficult to use in practice algorithmically. > =20 > > The "activate IPv6" should not be needed if we can manage to have > > the process automatically, and alternatively we should offer the > > "deactivate IPv6", hopefully, if for whatever reason, the user > > choose to ;-) >=20 > Sure. >=20 > > The auto-transition might propose the user, if the IPv6 performance > > in a given situation is very bad, to use IPv4 (hopefully with the > > time less and less often). >=20 > That's possible, yes. In most cases, the performance is actually > worse, but there are different ways to count it (e.g., v4 connectivity > through for P-2-P through a server vs. direct v6 connectivity; and=20 > good v4 latency vs bad v6 latency). This is probably something that=20 > would be impossible to measure properly. So I have doubts about this=20 > being all that useful -- but one could certainly use this to say "hey, = > the tunnel broker is 200 ms off on the other side of the globe --=20 > maybe it's not a good idea to use it?" >=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 Mon Mar 15 12:05:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10267 for ; Mon, 15 Mar 2004 12:05:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2vTW-000L7r-3D for v6ops-data@psg.com; Mon, 15 Mar 2004 17:02:02 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2vSQ-000Kfi-Kt for v6ops@ops.ietf.org; Mon, 15 Mar 2004 17:00:54 +0000 Received: from consulintel02 ([213.214.32.41]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 64-md50000000400.tmp for ; Mon, 15 Mar 2004 18:06:07 +0100 Message-ID: <175601c40aaf$a3b6d780$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: tunnel broker auto-discovery [RE: Tunneling scenarios and mechanisms evaluation] Date: Mon, 15 Mar 2004 17:49:46 +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, 15 Mar 2004 18:06:07 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 213.214.32.41 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.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 Pekka, The "auto-discovery" feature is part of the work that we are doing as = "auto-transition", and we will an I-D on this in a few weeks, hopefully. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "Jeroen Massar" Cc: "'Alain Durand'" ; Sent: Monday, March 15, 2004 8:51 AM Subject: tunnel broker auto-discovery [RE: Tunneling scenarios and = mechanisms evaluation] > Taking the "auto-discovery" part of the thread apart from the rest... >=20 > I think one should soon try to write a draft about different tradeoffs > of tunnel service discovery procedures (inter-domain anycast, > intra-domain anycast, DNS (at least two methods), DHCP, manual config > ec.). This might help us a lot in trying to figure out what we > actually want in this space. >=20 > Maybe someone(s) in the WG would be interested in drafting such a > document in a fast-track fashion (e.g., within a week or two at > most).. >=20 > On Sun, 14 Mar 2004, Jeroen Massar wrote: > > Pekka Savola [mailto:pekkas@netcore.fi] wrote: > > > I.e., it's OK for techies, but looking at wider deployment, it's=20 > > > unacceptable. But I guess it depends on who are you aiming the=20 > > > mechanism for; if we standardized a solution in this space, I=20 > > > think it=20 > > > would certainly have to be much simpler than that = administratively. > >=20 > > Indeed, I guess it would be a good idea to pursue the anycast > > configuration service or a similar technique. ISP's that don't > > want to allow other ISP's users on their service can always=20 > > not announce the prefix to other ISP's and can always announce > > the prefix to other users. > >=20 > > Having a single hostname, eg "ipv6.tunnelbroker.arpa" or something > > would not work as ISP's would then have to depend on the instance > > running that service to distribute the clients. Unfair competition > > and other blabla comes to mind. >=20 > Yes, single hostname wouldn't work, I think. However, one could say > that you could check for the local tunnel broker by looking up e.g. =20 > 'ipv6-tunnel-server.' appended with your DNS search path, right? >=20 > That would work just fine in certain scenarios: if the broker doesn't > exist, you get negative reply and use a different mechanism (e.g., > anycast or manual config); if positive, you use that. This has > drawbacks in the cases when you're mobile/nomadic (i.e., have to re-do > the DNS lookup, not just re-route by anycast, but as the prefix when > moving would change as well, this might not be a significant > drawback). >=20 > One item I'd like to know more is how large ISPs which offer e.g., DSL > service, in different geographical areas, configure the DNS search > paths. That is, whether the DNS search path trick would be sufficient > in finding the closest broker, or whether anycast would have to be > used on the side (note: nothing of course prevents you from anycasting > the IPv4 tunnel broker address that gets returned from the DNS). > =20 > The main question here is, I think, whether there would be pushback in > the DNS community for standardizing such "special-case local names". =20 > I recall there is precedent for doing something like this, but I'm not > fully certain. This would have to be investigated in advance.. >=20 > > To sum up the features I would like to have in such a protocol: > > - anycast address or similar to choose the closest TB and > > this could quite well be the service the ISP operates or > > a friendly ISP announcing this prefix. One problem though > > there is no way of having multiple TB's this way. > > But if a user knows which TB she wants she can always go > > directly to that TB. >=20 > Precisely. >=20 > > - Restricting users to only certain prefixes > > using the anycast announcement, just don't announce and/or > > redirect the users to another service, never say NO... >=20 > Yep. >=20 > > - user authentication (optional) > > this is mainly to track users, know who is using what etc > > it also allows giving the same prefix to the same user even > > when the user changes IP addresses. > > This could also be done using a cookie mechanism. >=20 > I think this should probably be out of scope for anycast mechanism, at = > least in some sense. >=20 > That is,=20 > - the anycast service must not lead to a tunnel server, which=20 > requires user authentication; that is, "zero-configuration" must=20 > always be possible. >=20 > - the user might try to perform user authentication with the tunnel=20 > server, but if the tunnel server does not know the user, the user=20 > would not have other fallbacks than manually selecting the tunnel=20 > server. >=20 > I think it might even be better that the anycasted services would not > offer any kind of user auth -- because if the closest server changes, > the authentication won't work anyway (or you'd have to redo it), and > it's just wasted effort. >=20 > > - static prefix delegation > > could be done using normal RA techniques. >=20 > This would probably depend on user authentication or some kind of > identification being there. If it isn't, the prefix can be only as > stable as it is (i.e., until the IPv4 address or IPv4 address + port > changes). So, in my book, "static" is not a requirement. I'd rather > tie the requirement to the staticity of the v4 address and or UDP port > (if coming through a NAT). >=20 > Are you referring to advertising a /64 and doing something like=20 > ND-proxying, something like draft-bykim-ipv6-hpd-01.txt or what? >=20 > Without ND-proxy I don't think prefix delegation would work with=20 > currently specified mechanisms except for DHCPv6. >=20 > > - DNS server configuration for that prefix. >=20 > You mean reverse DNS. Delegation and/or full configuration (e.g., a > wildcard record for the whole prefix)? >=20 > > - Protocol 41 at first but optionally over UDP eg > > after detecting that proto-41 doesn't work. >=20 > Yep. >=20 > > - UDP mode to be able to cross a NAT. > > Every single NAT I know of can be configured to > > forward UDP packets, thus that should work. > > There is one but, the first packet must come > > from the client and there should be some packet > > flow to not zero the NAT's counter. >=20 > Yep. >=20 > > The above service could also announce a list of TB's > > to the client and let the user pick, they seem to be > > quite good at that. >=20 > Clarification: are you referring to TB's controlled by the=20 > anycast-replying entity (e.g., a large ISP having a dozen=20 > geographically distributed tunnel servers), or referring to other TB's = > as well? >=20 > The former doesn't make sense with anycast, as there is no need for=20 > that. >=20 > The latter doesn't seem to be feasible, as it would require sharing=20 > information with about all the tunnel brokers in the world. How would = > one do that? Not manually I hope. So, this seems equally problematic = > as well. >=20 > > This feature should then be released for all major OS's > > as otherwise it still wouldn't deploy... and it will > > just be the same as 6to4, a very good idea but little usage. >=20 > You never know.. it could be little usage, but if implemented and used > by e.g. Microsoft, you would immediately have 5+ million IPv6 users > through a tunnel broker.. for the good or bad :) >=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 Mon Mar 15 12:11: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 MAA10592 for ; Mon, 15 Mar 2004 12:11:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2vbB-000O8J-EF for v6ops-data@psg.com; Mon, 15 Mar 2004 17:09:57 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2vb0-000O3Q-H1 for v6ops@ops.ietf.org; Mon, 15 Mar 2004 17:09:46 +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 i2FH9gp13785; Mon, 15 Mar 2004 19:09:42 +0200 (EET) X-Scanned: Mon, 15 Mar 2004 19:07:32 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2FH7WMI015836; Mon, 15 Mar 2004 19:07:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00u9sWck; Mon, 15 Mar 2004 19:07:31 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 i2FH7U122515; Mon, 15 Mar 2004 19:07:30 +0200 (EET) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Mar 2004 19:07:29 +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: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and Date: Mon, 15 Mar 2004 19:07:28 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195B1608E@esebe024.ntc.nokia.com> Thread-Topic: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and thread-index: AcQI8nRKT1utiAk8Q5m4qBOsTPS7wQAPm/SwAF+hVOA= From: To: , , Cc: , , X-OriginalArrivalTime: 15 Mar 2004 17:07:29.0494 (UTC) FILETIME=[FF79BF60:01C40AAF] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, my opinion as an individual would be similar than what Brian et al. have = expressed. 6to4 is there, it is a fact if we like it or not.=20 I do not believe that after the WG being in a virtual stand still for = quite some time and now getting some progress done again we should use = our new found energy to try to stop people from using the one of the = very few mechanisms that we have actually specified and deprecating = existing transition mechanisms. Let's focus our energy on delivering what is needed to make the = transition to IPv6 as smooth as possible and not discuss if we should or = should not deprecate 6to4. Cheers, Jonne. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Christian Huitema > Sent: 13 March, 2004 21:36 > To: bill; Pekka Savola > Cc: Erik Nordmark; Alain Durand; v6ops@ops.ietf.org > Subject: RE: 6to4 being replaced by Teredo only? [Re: Tunneling > scenarios and >=20 >=20 > > > the security properties are worse with 6to4 than Teredo=20 > (due to its > > > simplicity). > > > > > > Pekka Savola > >=20 > > reading the above sentence... its the most humourous thing > > i've read all week. perhaps what Pekka intended to say was > > that the security properties of 6to4 are more knowable than > > Teredo due to its simplicity. Most folks believe that if > > you can know the properties of some bit of code, its more > > secure than code that is too large/complex to understand well. > > Or perhaps Pekka ment something else... >=20 > Pekka's point can be summarized as follow: the bubble mechanism of > Teredo performs a 3-ways handshake, which effectively mitigates some > potential misuse of the relays for anonymous DOS attacks; there is no > such mechanism in 6to4. >=20 > Rob and Bill retort with the general "complexity is bad"=20 > argument: it is > much easier to have a bug in 100,000 lines of code than in 100; simper > code is easier to debug. However, Teredo's code is not all that large, > maybe a few hundred lines, and it can effectively be debugged. After > all, we do have two independent implementations of Teredo that > interoperate without apparent issues. >=20 > That being said, I would not want to replace all usage of 6to4 by > Teredo. 6to4 is a natural solution for upgrading the existing home > routers. >=20 > -- Christian Huitema >=20 >=20 From owner-v6ops@ops.ietf.org Mon Mar 15 12:31: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 MAA11711 for ; Mon, 15 Mar 2004 12:31:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2vtr-0004rP-C3 for v6ops-data@psg.com; Mon, 15 Mar 2004 17:29:15 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2vtg-0004o5-LI for v6ops@ops.ietf.org; Mon, 15 Mar 2004 17:29:04 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2FHT4wr003435 for ; Mon, 15 Mar 2004 10:29:04 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUM00MWBOKFLX@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 15 Mar 2004 10:29:04 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUM00CD2OKEE4@mail.sun.net> for v6ops@ops.ietf.org; Mon, 15 Mar 2004 10:29:03 -0700 (MST) Date: Mon, 15 Mar 2004 09:29:00 -0800 From: Alain Durand Subject: Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] In-reply-to: To: Pekka Savola Cc: Jeroen Massar , v6ops@ops.ietf.org Message-id: <3F2DAF71-76A6-11D8-9F71-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 14, 2004, at 11:23 PM, Pekka Savola wrote: >> This won't work with non-static IP's and getting the same prefix >> back though, > > Sure; but this would probably be sufficient for the average John Doe, > right? What John Doe wants is irrelevant. What the IPv6 applications require is. Now, are you telling us that the potential IPv6 'killer apps' will not need stable addresses? Making this assumption is very dangerous, IMHO. >> They found MSN, Yahoo, Google, KaZaA etc. Friends tell that is the >> trick to it, if there is interresting enough content even 13 year >> olds can configure it. > > Right. If we assume IPv6 would have killer applications which would > make the users really eager to get it, sure -- everything would > probably be simpler. But in the absence of such, we need to forward > without them :-). In the absence of such, what is the justification of IPv6? - Alain. From owner-v6ops@ops.ietf.org Mon Mar 15 12:46: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 MAA12556 for ; Mon, 15 Mar 2004 12:46:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2w8R-0009mE-0s for v6ops-data@psg.com; Mon, 15 Mar 2004 17:44:19 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2w8G-0009ji-DT for v6ops@ops.ietf.org; Mon, 15 Mar 2004 17:44:08 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2FHi7wr029056 for ; Mon, 15 Mar 2004 10:44:07 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUM005AAP9JA6@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 15 Mar 2004 10:44:07 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUM00F89P9I46@mail.sun.net> for v6ops@ops.ietf.org; Mon, 15 Mar 2004 10:44:07 -0700 (MST) Date: Mon, 15 Mar 2004 09:44:04 -0800 From: Alain Durand Subject: focussing energies To: v6ops@ops.ietf.org Message-id: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT So, what to get from these latest discussion? My 0.02$: a) the best model is to get ISPs to deploy IPv6 to their customer. No transition mechanism is better than anything else. Most ISPs won't do it unless there is strong motivation: - political mandate to do so - political incentive (like tax break) - customer asking for it The first two are outside the realm of IETF. The last one will only be driven by the new applications requiring/working better with IPv6. Nothing here that this wg can do about. b) assisted tunneling works best in the scenario of an ISP willing to offer IPv6 service but not ready yet to pay to deploy native service. Those mechanisms, like tunnel broker, not only provide IPv6 connectivity to the user, but also to help the ISP to jump start IPv6 service to its customers at low cost. This is an area where standardization from this wg could help a lot. c) when ISPs are not cooperating, there is the choice between two evils: - fully automatic solutions, with their share of complexity, security issues,... - tunnel brokers operated by third parties, with possible sub-optimal paths and complex set-up. The point I'm trying to make is that, IMHO, this wg should not spend to much effort on c) [i.e. there are implemented solution, let's document them and move on] because: 1) either IPv6 will take off and ISPs will start to cooperate, thus we're back to case b) 2) ISP still don't cooperate in the near future, meaning that they see IPv6 as going nowhere, so why should this wg and software vendors invest in complex transition mechanisms? and focus its energies on standardizing a solution for b) - Alain. From owner-v6ops@ops.ietf.org Mon Mar 15 13:08: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 NAA13778 for ; Mon, 15 Mar 2004 13:08:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2wT2-000HIz-1f for v6ops-data@psg.com; Mon, 15 Mar 2004 18:05:36 +0000 Received: from [205.167.76.9] (helo=m106.maoz.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2wSr-000HFl-HB for v6ops@ops.ietf.org; Mon, 15 Mar 2004 18:05:25 +0000 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2FI5Pib030476; Mon, 15 Mar 2004 10:05:25 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2FI5Ps3030475; Mon, 15 Mar 2004 10:05:25 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 15 Mar 2004 10:05:25 -0800 From: David Meyer To: Alain Durand Cc: v6ops@ops.ietf.org Subject: Re: focussing energies Message-ID: <20040315180525.GA30382@1-4-5.net> References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Mar 15, 2004 at 09:44:04AM -0800, Alain Durand wrote: >> So, what to get from these latest discussion? >> My 0.02$: >> >> a) the best model is to get ISPs to deploy IPv6 to their customer. No >> transition mechanism is better >> than anything else. Most ISPs won't do it unless there is strong >> motivation: >> - political mandate to do so >> - political incentive (like tax break) >> - customer asking for it >> The first two are outside the realm of IETF. The last one will only be >> driven by the new applications >> requiring/working better with IPv6. Nothing here that this wg can do >> about. Agree, although I would say something more like "IPv6 will reach wide-scale deployment if and when there is a revenue stream with margin supporting that deployment" (however that comes about). >> b) assisted tunneling works best in the scenario of an ISP willing to >> offer IPv6 service >> but not ready yet to pay to deploy native service. Those mechanisms, >> like tunnel broker, >> not only provide IPv6 connectivity to the user, but also to help the >> ISP to jump start >> IPv6 service to its customers at low cost. This is an area where >> standardization from >> this wg could help a lot. So here's a question: Who is deploying "auto-tunneling" (of any kind, really) at any scale? For the moment assume that the "auto-tunneling" technique requires resources in the SP's network. Dave From owner-v6ops@ops.ietf.org Mon Mar 15 13:09: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 NAA13856 for ; Mon, 15 Mar 2004 13:09:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2wVO-000ISB-ND for v6ops-data@psg.com; Mon, 15 Mar 2004 18:08:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2wUx-000IFY-D5 for v6ops@ops.ietf.org; Mon, 15 Mar 2004 18:07:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2FI7W203985; Mon, 15 Mar 2004 20:07:32 +0200 Date: Mon, 15 Mar 2004 20:07:32 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] In-Reply-To: <3F2DAF71-76A6-11D8-9F71-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 15 Mar 2004, Alain Durand wrote: > On Mar 14, 2004, at 11:23 PM, Pekka Savola wrote: > >> This won't work with non-static IP's and getting the same prefix > >> back though, > > > > Sure; but this would probably be sufficient for the average John Doe, > > right? > > What John Doe wants is irrelevant. What the IPv6 applications require > is. Also, on the other hand, IPv6 is rather irrelevant unless we can make the assumption that it will be used by John Doe. I.e., if we want to change the Internet, we need mass. Guys like John Doe are the key to obtaining that critical mass. > Now, are you telling us that the potential IPv6 'killer apps' will > not need stable addresses? Making this assumption is very dangerous, > IMHO. I'm not saying that at all. I'm just saying that there are limits to the requirements for the duration of such addresses. For example, must John Doe's address stay stable if he shuts down his home PC, and leavs for 1-week trip to Tahiti, and then returns? It might not hurt, but the applications and the systems must IMHO be designed to deal with the situation that when they (re)start, the address might be different. I.e., the lifetime of the address does not *necessarily* have to be longer than the lifetime of the application process. On the other hand, as long as John Doe's home PC stays powered on and connected to the Internet, his address should stay stable. > >> They found MSN, Yahoo, Google, KaZaA etc. Friends tell that is the > >> trick to it, if there is interresting enough content even 13 year > >> olds can configure it. > > > > Right. If we assume IPv6 would have killer applications which would > > make the users really eager to get it, sure -- everything would > > probably be simpler. But in the absence of such, we need to forward > > without them :-). > > In the absence of such, what is the justification of IPv6? I'd rather not open this can of worms, but leave it as an exercise of the reader. As some have pointed out, we wouldn't have needed anything other than dual-stack (or the like) if we assumed that there will be strong killer app. When such app would appear, everyone would just upgrade, end of story, happy end. Unfortunately, IMHO, we need to move forward without making an assumption that such an app would miraculously appear; there will probably be ones (e.g., some p2p apps) which will help to drive the transition along, but again, this is something we should be counting on. -- 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 Mar 15 13:32:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15034 for ; Mon, 15 Mar 2004 13:32:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2wr9-0000FE-HZ for v6ops-data@psg.com; Mon, 15 Mar 2004 18:30:31 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2wqy-0000Cb-PQ for v6ops@ops.ietf.org; Mon, 15 Mar 2004 18:30:20 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2FIUKwr020632 for ; Mon, 15 Mar 2004 11:30:20 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUM005IXREJA6@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 15 Mar 2004 11:30:20 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUM00CSRREBE1@mail.sun.net> for v6ops@ops.ietf.org; Mon, 15 Mar 2004 11:30:12 -0700 (MST) Date: Mon, 15 Mar 2004 10:30:10 -0800 From: Alain Durand Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 15, 2004, at 10:07 AM, Pekka Savola wrote: > It might not hurt, but the applications and the systems must IMHO be > designed to deal with the situation that when they (re)start, the > address might be different. I.e., the lifetime of the address does not > *necessarily* have to be longer than the lifetime of the application > process. The "application" may be more complex than just one process. Stable addresses across reboot may be necessary. I want to be able to build apps that take advantage of the large IPv6 address space and consider that addresses are stable. > On the other hand, as long as John Doe's home PC stays powered on and > connected to the Internet, his address should stay stable. I suppose that you are aware of ISPs that change DHCPv4 allocated addresses every 24 hours... If John Doe's computer build its v6 address form those volatile v4 addresses, its v6 address will also change very 24 hours, and this even though John Doe has not rebooted his PC. Not good. - Alain. From owner-v6ops@ops.ietf.org Mon Mar 15 13:38: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 NAA15303 for ; Mon, 15 Mar 2004 13:38:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2wwi-0001on-Fn for v6ops-data@psg.com; Mon, 15 Mar 2004 18:36:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2wwX-0001lm-Fe for v6ops@ops.ietf.org; Mon, 15 Mar 2004 18:36:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2FIa4P04425 for ; Mon, 15 Mar 2004 20:36:04 +0200 Date: Mon, 15 Mar 2004 20:36:04 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Approaches to use IPsec to secure v6-over-v4 tunnels Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, This issue has never been fully discussed before, so I thought about it a bit. How do we set up secure v6-over-v4 tunnels (in the control & data plane security sense) for client <-> tunnel-server communication? How feasible is this? I'm mostly interested in investigating whether IPsec could be used as a "transport mechanism" for traversing NATs or managing the "configured tunnel end-point setup" when the address is dynamic. IPsec may not be feasible in all the scenarios, but if IPsec could be used to simplify a number of different cases, and security would come in as bonus, I guess it wouldn't hurt.. :) Basically, if you need data plane security (i.e., transport security), we go down to IPsec. Some control plane security might be manageable with ad-hoc mechanisms, such as hashing/keying methods or return routability. Now, as for IPsec, there seem to be two ways to deal with this: 1) IPv4 IPsec tunnel mode with IPv6 payload transform, resulting to: (In both, I'm excluding the authentication part, or ESP padding.) IPv4 header - 20 bytes ESP header - 8 bytes IPv6 header - 40 bytes [IPv6 payload] 2) IPv4 IPsec in transport mode with IPv4 transform, resulting to: IPv4 header - 20 bytes [next-header set to 41: implicit v6-over-v4] ESP header - 8 bytes IPv6 header - 40 bytes [IPv6 payload] So, both the approaches seem to be equivalent. Only, the mixed-IP version transforms, 1), is only supported by a couple of implementations, while I think 2) is more commonplace. 2) would additionally require a co-located configured tunnel management to the IPsec endpoints. If the method was used with dynamic addresses, this could be quite problematic, unless IPsec provides some triggers to "reconfigure" the configured tunnel to accommodate new tunnel-endpoint. A different approach is having some kind of pseudo-interface which would not have these issues, but I think we already got out of those... :) So, the overhead of about 28 bytes compared to 20 of v6-over-v4 tunnel in IP. If you encapsulate IPsec in UDP for NAT traversal, that's 8 additional bytes. That part is commonly implemented. Note that NAT traversal obviously only works when the other end-point has a public address. It seems a simple deployment for client <-> tunnel-server communication could be obtained using either mechanism, with 2) requiring zero implementation, only (rather complex) management for the tunnel-end point (if dynamic/NAT-traversed) in configured tunneling. So, in a sense 1) gives you simplicity when ÍPsec has to deal with that particular dynamicity complexity. Are there any flaws or missing points in this analysis? Thoughts? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Mar 15 14:06: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 OAA16533 for ; Mon, 15 Mar 2004 14:06:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2xNl-0007NL-3z for v6ops-data@psg.com; Mon, 15 Mar 2004 19:04:13 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B2xNS-0007JB-4n for v6ops@ops.ietf.org; Mon, 15 Mar 2004 19:03:54 +0000 Received: (qmail 20341 invoked by uid 417); 15 Mar 2004 19:03:53 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 15 Mar 2004 19:03:53 -0000 Received: from XPNERICK ([132.70.218.169]) by softhome.net with esmtp; Mon, 15 Mar 2004 12:03:52 -0700 Message-ID: <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> Subject: Re: focussing energies Date: Mon, 15 Mar 2004 21:03:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Alain Durand" > > a) the best model is to get ISPs to deploy IPv6 to their customer. No > transition mechanism is better > than anything else. Most ISPs won't do it unless there is strong > motivation: > - political mandate to do so > - political incentive (like tax break) > - customer asking for it > The first two are outside the realm of IETF. The last one will only be > driven by the new applications > requiring/working better with IPv6. Nothing here that this wg can do > about. > Just keep in mind that some governments have mandated that all services be transitioned to IPv6 by fixed dates (off the top of my head I know that Japan and the EU have mandated dates) but I am not sure what the penalties are for failing to meet these mandates. From owner-v6ops@ops.ietf.org Mon Mar 15 14:19: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 OAA17668 for ; Mon, 15 Mar 2004 14:19:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2xaJ-0009Nc-Re for v6ops-data@psg.com; Mon, 15 Mar 2004 19:17:11 +0000 Received: from [205.167.76.9] (helo=m106.maoz.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2xa9-0009Mt-Ar for v6ops@ops.ietf.org; Mon, 15 Mar 2004 19:17:01 +0000 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2FJH1vn001618; Mon, 15 Mar 2004 11:17:01 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2FJH1OY001617; Mon, 15 Mar 2004 11:17:01 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 15 Mar 2004 11:17:01 -0800 From: David Meyer To: EricLKlein Cc: v6ops@ops.ietf.org Subject: Re: focussing energies Message-ID: <20040315191701.GA1603@1-4-5.net> References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Mar 15, 2004 at 09:03:02PM +0200, EricLKlein wrote: >> From: "Alain Durand" >> > >> > a) the best model is to get ISPs to deploy IPv6 to their customer. No >> > transition mechanism is better >> > than anything else. Most ISPs won't do it unless there is strong >> > motivation: >> > - political mandate to do so >> > - political incentive (like tax break) >> > - customer asking for it >> > The first two are outside the realm of IETF. The last one will only be >> > driven by the new applications >> > requiring/working better with IPv6. Nothing here that this wg can do >> > about. >> > >> Just keep in mind that some governments have mandated that all services be >> transitioned to IPv6 by fixed dates (off the top of my head I know that >> Japan and the EU have mandated dates) but I am not sure what the penalties >> are for failing to meet these mandates. Good point: So make that revenue stream or governmental mandate. Dave From owner-v6ops@ops.ietf.org Mon Mar 15 14: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 OAA17978 for ; Mon, 15 Mar 2004 14:25:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2xgC-000ASh-Mu for v6ops-data@psg.com; Mon, 15 Mar 2004 19:23:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2xg1-000AR2-Pu for v6ops@ops.ietf.org; Mon, 15 Mar 2004 19:23:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2FJN4P05210 for ; Mon, 15 Mar 2004 21:23:04 +0200 Date: Mon, 15 Mar 2004 21:23:04 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: dynamic v6ops document status web page created Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, (co-chair hat on) Henrik Levkowetz has kindly set up a "draft status page" for v6ops documents. This shows the status of the documents, and gives the pointer to ID tracker for respective documents. This could in future also link to the issue tracker. By clicking the draft name, you can also get the previous versions of the documents, and HTML diffs between the different versions of the documents. (The format of the HTML diffs might improve in the future.) It is available at: http://ietf.levkowetz.com/drafts/v6ops/ We'll add reference to this on the www.6bone.net/v6ops/ page. Hopefully you'll find this useful! If you have suggestions for improvements etc., please send them to me. -- 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 Mar 15 15:14: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 PAA20876 for ; Mon, 15 Mar 2004 15:14:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2yS7-000KdJ-2F for v6ops-data@psg.com; Mon, 15 Mar 2004 20:12:47 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2yRv-000KYt-7a for v6ops@ops.ietf.org; Mon, 15 Mar 2004 20:12:35 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00D01W4XXX@mailout3.samsung.com> for v6ops@ops.ietf.org; Tue, 16 Mar 2004 05:12:33 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM00CDYW4X2L@mailout3.samsung.com> for v6ops@ops.ietf.org; Tue, 16 Mar 2004 05:12:33 +0900 (KST) Received: from ep_spt04 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM008MXW4WWR@ms3.samsung.com> for v6ops@ops.ietf.org; Tue, 16 Mar 2004 05:12:32 +0900 (KST) Content-return: prohibited Date: Mon, 15 Mar 2004 20:12:52 +0000 (GMT) From: PARK SOO HONG Subject: Re :automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2JpbA==?= =?windows-1252?B?ZSBQbGF0Zm9ybSBMYWI/UmVzZWFyY2hlcg==?= To: Pekka Savola , soohong.park@samsung.com Cc: JORDI PALET MARTINEZ , "v6ops@ops.ietf.org " Reply-to: soohong.park@samsung.com Message-id: <0HUM008MYW4WWR@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040315201229533@soohong.park X-MTR: 20040315201229533@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

not sure these draft are related to this thread since I didn't follow up this issue.

 

http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ctep-opt-00.txt

 

 

These draft only addresses configured tunnel end point so far, but it can be

expanded to include others easily IMHO.

 

Hope this help






------- Original Message -------
Sender : Pekka Savola<pekkas@netcore.fi>
Date : Mar 15, 2004 20:05
Title : automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]
I'm replying to only one issue, under a new subject line, because I
think the others have been sufficiently addressed..

I think this mechanism selection work is also important, and it would
be nice to have something written out very soon so that we wouldn't
get stalled too soon.  If folks are interested in writing up something
quickly, please do line up.. :)

On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:
> > Remember, our goal is
> > not get IPv6 deployed to those guys who are reading this
> > mailing-list and can do a lot of technical stuff to set things up.  
> > The target audience (which I have in mind at least) is much more
> > "dumber" than that.  I'd like to aim for the case where the most
> > the user would have to do is click an "activate IPv6" icon on the
> > desktop or network settings -- and not necessarily even that.  
> > That function should try to send route solicitation on your link,
> > find a free tunnel broker provided by your own ISP, or set up
> > 6to4/Teredo all else failing.
> 
> Agree, as said in a previous message, this is more or less what we
> are doing, and hopefully could present in San Diego (we call it
> auto-transition):

Yes, this is very useful work, but something that should be done much 
sooner than San Diego (IMHO).  Draft out within a week or two would be 
a good goal :-).  Actually I think this has already been discussed 
quite a bit (e.g., the "unmanaged bar gathering" at Minneapolis at 
IETF58), but not written out and fleshed out entirely.  It would be 
very useful to get that at least started and something written out 
soon.

Another related subject which needs to be worked at also is the 
coexistance of all of these mechanisms.  It's not just what you're 
using yourself, but what you should do to enable the others to use v6 
to talk to you (e.g., local 6to4 or Teredo relays).  This may be out 
of scope for this idea, but something to keep in mind in any case.

> - Native
> - 6to4
> - TB with 6in4 if a public IPv4 address is available
> - TB with proto-41-forwarding if NAT supports it
> - TB with UDP encapsulation

It may be worth noting that discovery of TB's is a rather delicate 
process (see the other thread), and a subject which may be very 
difficult to do properly.  But we can try...

> - Teredo
> - others (even IPv6 over HTTP in the worst case !)

Well, I'd leave that "even" out from here.. :-)

> The order not necessarily is what I wrote down, as it may depend on
> the "best performance" solution for every client, and even change if
> the client or network change.

True, though "perfomance" is hardly an easily measurable unit, so
difficult to use in practice algorithmically.
 
> The "activate IPv6" should not be needed if we can manage to have
> the process automatically, and alternatively we should offer the
> "deactivate IPv6", hopefully, if for whatever reason, the user
> choose to ;-)

Sure.

> The auto-transition might propose the user, if the IPv6 performance
> in a given situation is very bad, to use IPv4 (hopefully with the
> time less and less often).

That's possible, yes.  In most cases, the performance is actually
worse, but there are different ways to count it (e.g., v4 connectivity
through for P-2-P through a server vs. direct v6 connectivity; and 
good v4 latency vs bad v6 latency).  This is probably something that 
would be impossible to measure properly.  So I have doubts about this 
being all that useful -- but one could certainly use this to say "hey, 
the tunnel broker is 200 ms off on the other side of the globe -- 
maybe it's not a good idea to use it?"

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings





Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


From owner-v6ops@ops.ietf.org Mon Mar 15 16:14:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26355 for ; Mon, 15 Mar 2004 16:14:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2zNG-00063S-Fa for v6ops-data@psg.com; Mon, 15 Mar 2004 21:11:50 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2zN5-00060u-DJ for v6ops@ops.ietf.org; Mon, 15 Mar 2004 21:11:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2FLBZT07123; Mon, 15 Mar 2004 23:11:36 +0200 Date: Mon, 15 Mar 2004 23:11:35 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 15 Mar 2004, Alain Durand wrote: > On Mar 15, 2004, at 10:07 AM, Pekka Savola wrote: > > It might not hurt, but the applications and the systems must IMHO be > > designed to deal with the situation that when they (re)start, the > > address might be different. I.e., the lifetime of the address does not > > *necessarily* have to be longer than the lifetime of the application > > process. > > The "application" may be more complex than just one process. Agree. > Stable addresses across reboot may be necessary. > I want to be able to build apps that take advantage of the large IPv6 > address space and consider that addresses are stable. So, you want to build a simple application. Don't we all.. :) But I don't think this is something we can guarantee even with native access. ISPs just aren't offering static v4 addresses today even when they'd have technical means to do so. So, counting on static v6 prefixes would IMHO be cutting corners too much. The problem is worse with transition mechanisms, especially the ones which traverse NATs, but the situation may improve as soon as we can get rid of them. In any case, such mechanisms can provide a stable as long as they can keep the NAT/IP mappings stable -- which is, for a properly designed application, maybe sufficient. > > On the other hand, as long as John Doe's home PC stays powered on and > > connected to the Internet, his address should stay stable. > > I suppose that you are aware of ISPs that change DHCPv4 allocated > addresses every 24 hours... If John Doe's computer build its v6 > address form those volatile v4 addresses, its v6 address will also > change very 24 hours, and this even though John Doe has not rebooted > his PC. Not good. Yep, I know this -- unfortunately. But there is little that can be done to fix ISPs which want to enforce the users not to do Foo (whatever Foo may be). We can hardly fix the misbehaving ISP problem at the IETF.. as you're probably well aware :) -- 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 Mar 15 17:22: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 RAA02197 for ; Mon, 15 Mar 2004 17:22:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B30Qx-000Hl0-DZ for v6ops-data@psg.com; Mon, 15 Mar 2004 22:19:43 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B30Ql-000HjX-09 for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:19:31 +0000 Received: from consulintel02 ([212.76.240.58]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 33-md50000000409.tmp for ; Mon, 15 Mar 2004 23:24:44 +0100 Message-ID: <1b4c01c40adc$257b7fb0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <0HUM008MYW4WWR@ms3.samsung.com> Subject: Re: Re :automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] Date: Mon, 15 Mar 2004 23:23:28 +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, 15 Mar 2004 23:24:44 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.76.240.58 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Daniel, We are considering referring to your documents and providing inputs to = them, as part of our work. Keep in sycn ;-) Regards, Jordi ----- Original Message -----=20 From: "PARK SOO HONG" To: "Pekka Savola" ; Cc: "JORDI PALET MARTINEZ" ; = Sent: Monday, March 15, 2004 9:12 PM Subject: Re :automatic tunnel mechanism selection [Re: tunnel broker = deployment [RE: Tunneling scenarios and mechanisms evaluation] > Samsung Enterprise Portal mySinglenot sure these draft are related to = this thread since I didn't follow up this issue. >=20 > =20 >=20 > = http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt=20 >=20 > = http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ctep-opt-00.txt= =20 >=20 > =20 >=20 > =20 >=20 > These draft only addresses configured tunnel end point so far, but it = can be >=20 > expanded to include others easily IMHO. >=20 > =20 >=20 > Hope this help >=20 >=20 >=20 >=20 >=20 >=20 > ------- Original Message ------- > Sender : Pekka Savola > Date : Mar 15, 2004 20:05 > Title : automatic tunnel mechanism selection [Re: tunnel broker = deployment [RE: Tunneling scenarios and mechanisms evaluation] > I'm replying to only one issue, under a new subject line, because I=20 > think the others have been sufficiently addressed..=20 >=20 > I think this mechanism selection work is also important, and it would=20 > be nice to have something written out very soon so that we wouldn't=20 > get stalled too soon. If folks are interested in writing up something = > quickly, please do line up.. :)=20 >=20 > On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:=20 > > > Remember, our goal is=20 > > > not get IPv6 deployed to those guys who are reading this=20 > > > mailing-list and can do a lot of technical stuff to set things up. = =20 > > > The target audience (which I have in mind at least) is much more=20 > > > "dumber" than that. I'd like to aim for the case where the most=20 > > > the user would have to do is click an "activate IPv6" icon on the=20 > > > desktop or network settings -- and not necessarily even that. =20 > > > That function should try to send route solicitation on your link,=20 > > > find a free tunnel broker provided by your own ISP, or set up=20 > > > 6to4/Teredo all else failing.=20 > > =20 > > Agree, as said in a previous message, this is more or less what we=20 > > are doing, and hopefully could present in San Diego (we call it=20 > > auto-transition):=20 >=20 > Yes, this is very useful work, but something that should be done much = > sooner than San Diego (IMHO). Draft out within a week or two would be = =20 > a good goal :-). Actually I think this has already been discussed =20 > quite a bit (e.g., the "unmanaged bar gathering" at Minneapolis at =20 > IETF58), but not written out and fleshed out entirely. It would be =20 > very useful to get that at least started and something written out =20 > soon.=20 >=20 > Another related subject which needs to be worked at also is the =20 > coexistance of all of these mechanisms. It's not just what you're =20 > using yourself, but what you should do to enable the others to use v6 = > to talk to you (e.g., local 6to4 or Teredo relays). This may be out =20 > of scope for this idea, but something to keep in mind in any case.=20 >=20 > > - Native=20 > > - 6to4=20 > > - TB with 6in4 if a public IPv4 address is available=20 > > - TB with proto-41-forwarding if NAT supports it=20 > > - TB with UDP encapsulation=20 >=20 > It may be worth noting that discovery of TB's is a rather delicate =20 > process (see the other thread), and a subject which may be very =20 > difficult to do properly. But we can try...=20 >=20 > > - Teredo=20 > > - others (even IPv6 over HTTP in the worst case !)=20 >=20 > Well, I'd leave that "even" out from here.. :-)=20 >=20 > > The order not necessarily is what I wrote down, as it may depend on=20 > > the "best performance" solution for every client, and even change if = > > the client or network change.=20 >=20 > True, though "perfomance" is hardly an easily measurable unit, so=20 > difficult to use in practice algorithmically.=20 > =20 > > The "activate IPv6" should not be needed if we can manage to have=20 > > the process automatically, and alternatively we should offer the=20 > > "deactivate IPv6", hopefully, if for whatever reason, the user=20 > > choose to ;-)=20 >=20 > Sure.=20 >=20 > > The auto-transition might propose the user, if the IPv6 performance=20 > > in a given situation is very bad, to use IPv4 (hopefully with the=20 > > time less and less often).=20 >=20 > That's possible, yes. In most cases, the performance is actually=20 > worse, but there are different ways to count it (e.g., v4 connectivity = > through for P-2-P through a server vs. direct v6 connectivity; and =20 > good v4 latency vs bad v6 latency). This is probably something that =20 > would be impossible to measure properly. So I have doubts about this = > being all that useful -- but one could certainly use this to say "hey, = =20 > the tunnel broker is 200 ms off on the other side of the globe -- =20 > maybe it's not a good idea to use it?"=20 >=20 > -- =20 > Pekka Savola "You each name yourselves king, yet the=20 > Netcore Oy kingdom bleeds."=20 > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings=20 >=20 >=20 >=20 >=20 >=20 > Regards=20 >=20 > =20 >=20 > Daniel (Soohong Daniel Park)=20 >=20 > Mobile Platform Laboratory. SAMSUNG Electronics >=20 > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Mar 15 17:23:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02239 for ; Mon, 15 Mar 2004 17:23:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B30S3-000HxI-30 for v6ops-data@psg.com; Mon, 15 Mar 2004 22:20:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B30Rs-000HvE-CN for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:20:40 +0000 Received: from consulintel02 ([212.76.240.58]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 35-md50000000409.tmp for ; Mon, 15 Mar 2004 23:25:56 +0100 Message-ID: <1b5801c40adc$50ae2750$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> Subject: Re: focussing energies Date: Mon, 15 Mar 2004 23:24:41 +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, 15 Mar 2004 23:25:56 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.76.240.58 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, and more may be coming from EU in the comming months ... ----- Original Message -----=20 From: "EricLKlein" To: Sent: Monday, March 15, 2004 8:03 PM Subject: Re: focussing energies > From: "Alain Durand" > > > > a) the best model is to get ISPs to deploy IPv6 to their customer. = No > > transition mechanism is better > > than anything else. Most ISPs won't do it unless there is strong > > motivation: > > - political mandate to do so > > - political incentive (like tax break) > > - customer asking for it > > The first two are outside the realm of IETF. The last one will only = be > > driven by the new applications > > requiring/working better with IPv6. Nothing here that this wg can do > > about. > > > Just keep in mind that some governments have mandated that all = services be > transitioned to IPv6 by fixed dates (off the top of my head I know = that > Japan and the EU have mandated dates) but I am not sure what the = penalties > are for failing to meet these mandates. > ********************************** 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 Mar 15 17:29:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02655 for ; Mon, 15 Mar 2004 17:29:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B30Z6-000J3r-2Z for v6ops-data@psg.com; Mon, 15 Mar 2004 22:28:08 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B30Yu-000J37-Vt for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:27:57 +0000 Received: from consulintel02 ([212.76.240.58]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 52-md50000000409.tmp for ; Mon, 15 Mar 2004 23:33:10 +0100 Message-ID: <1b7e01c40add$5334b5b0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Mon, 15 Mar 2004 23:31:55 +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, 15 Mar 2004 23:33:10 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.76.240.58 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable To be honest, unfortunately, even if we have a "killer" application, I = don't think, at least not initially and quickly, we will have access = networks with native IPv6 support. The backbones, yes no problem for most of them, but access will take = some more time. One of the problems is that we don't have cheap xDSL or = cable CPEs with native IPv6 support (but are on the way). So I expect that initially even actual applications, that don't get wide = usage with IPv4 because the limitations, NAT and so on, will come to = live with IPv6. I actually use one of these, as I've all the devices, = lights, windows, alarm, ... accessible with IPv6, so I can even provide = water to my dogs, and look at them with IPv6 cameras. In San Diego I can = show it in the v6ops session or the coffee break if someone is = interested ;-) That was impossible with IPv4, but easy with IPv6. Regarding the ISPs that keep changing the address, this can be easily = solved with our "auto-trans" idea.. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "Alain Durand" Cc: Sent: Monday, March 15, 2004 10:11 PM Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: = Tunneling scenarios and mechanisms evaluation]] > On Mon, 15 Mar 2004, Alain Durand wrote: > > On Mar 15, 2004, at 10:07 AM, Pekka Savola wrote: > > > It might not hurt, but the applications and the systems must IMHO = be > > > designed to deal with the situation that when they (re)start, the > > > address might be different. I.e., the lifetime of the address does = not > > > *necessarily* have to be longer than the lifetime of the = application > > > process. > >=20 > > The "application" may be more complex than just one process. >=20 > Agree. >=20 > > Stable addresses across reboot may be necessary. > > I want to be able to build apps that take advantage of the large = IPv6 > > address space and consider that addresses are stable. >=20 > So, you want to build a simple application. Don't we all.. :) But I > don't think this is something we can guarantee even with native > access. ISPs just aren't offering static v4 addresses today even when > they'd have technical means to do so. So, counting on static v6 > prefixes would IMHO be cutting corners too much. >=20 > The problem is worse with transition mechanisms, especially the ones=20 > which traverse NATs, but the situation may improve as soon as we can=20 > get rid of them. In any case, such mechanisms can provide a stable=20 > as long as they can keep the NAT/IP mappings stable -- which is, for a = > properly designed application, maybe sufficient. >=20 > > > On the other hand, as long as John Doe's home PC stays powered on = and > > > connected to the Internet, his address should stay stable. > >=20 > > I suppose that you are aware of ISPs that change DHCPv4 allocated > > addresses every 24 hours... If John Doe's computer build its v6 > > address form those volatile v4 addresses, its v6 address will also > > change very 24 hours, and this even though John Doe has not rebooted > > his PC. Not good. >=20 > Yep, I know this -- unfortunately. But there is little that can be > done to fix ISPs which want to enforce the users not to do Foo > (whatever Foo may be). We can hardly fix the misbehaving ISP problem > at the IETF.. as you're probably well aware :) >=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 Mon Mar 15 17:33: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 RAA02878 for ; Mon, 15 Mar 2004 17:33:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B30dI-000JxJ-1u for v6ops-data@psg.com; Mon, 15 Mar 2004 22:32:28 +0000 Received: from [66.163.170.84] (helo=smtp814.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B30cr-000JtL-5G for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:32:01 +0000 Received: from unknown (HELO VALUED847D7605) (carl?e?williams@sbcglobal.net@209.137.156.6 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 15 Mar 2004 22:10:41 -0000 Reply-To: From: "Carl Williams" To: Subject: RE: focussing energies Date: Mon, 15 Mar 2004 14:12:38 -0800 Organization: KDDI Labs Message-ID: <000001c40ada$a1ccfa50$7e01a8c0@VALUED847D7605> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Good points. There is also the case whereby the ISP or carrier will deploy a native IPv6 service but the customer's environment (or network) is unable to become native IPv6 initially or the entire access network (or components of) may not be upgraded all at once. So the service provider may also need to be proactive in helping the customer in transition by providing offering transition services. We are looking at transition methods for moving our network - both fixed line service and 3G services - to native IPv6. We are also looking at helping the end customer transition (be it home networking, services to the enterprise, or other service deployments). Here we are looking at automatic tunneling methods to aid in those deployment services. The service provider must have a total plan - and not just build a native IPv6 network and hope that the IPv6 traffic will come. Carl Original Message: ----------------- From: Alain Durand Alain.Durand@Sun.COM Date: Mon, 15 Mar 2004 09:44:04 -0800 To: v6ops@ops.ietf.org Subject: focussing energies So, what to get from these latest discussion? My 0.02$: a) the best model is to get ISPs to deploy IPv6 to their customer. No transition mechanism is better than anything else. Most ISPs won't do it unless there is strong motivation: - political mandate to do so - political incentive (like tax break) - customer asking for it The first two are outside the realm of IETF. The last one will only be driven by the new applications requiring/working better with IPv6. Nothing here that this wg can do about. b) assisted tunneling works best in the scenario of an ISP willing to offer IPv6 service but not ready yet to pay to deploy native service. Those mechanisms, like tunnel broker, not only provide IPv6 connectivity to the user, but also to help the ISP to jump start IPv6 service to its customers at low cost. This is an area where standardization from this wg could help a lot. c) when ISPs are not cooperating, there is the choice between two evils: - fully automatic solutions, with their share of complexity, security issues,... - tunnel brokers operated by third parties, with possible sub-optimal paths and complex set-up. The point I'm trying to make is that, IMHO, this wg should not spend to much effort on c) [i.e. there are implemented solution, let's document them and move on] because: 1) either IPv6 will take off and ISPs will start to cooperate, thus we're back to case b) 2) ISP still don't cooperate in the near future, meaning that they see IPv6 as going nowhere, so why should this wg and software vendors invest in complex transition mechanisms? and focus its energies on standardizing a solution for b) - Alain. From owner-v6ops@ops.ietf.org Mon Mar 15 20:58: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 UAA13963 for ; Mon, 15 Mar 2004 20:58:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B33n5-0005QF-E6 for v6ops-data@psg.com; Tue, 16 Mar 2004 01:54:47 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B33mu-0005P6-Mu for v6ops@ops.ietf.org; Tue, 16 Mar 2004 01:54:36 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2G1sO710079; Mon, 15 Mar 2004 17:54:24 -0800 X-mProtect: <200403160154> 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 smtpdO7iOtU; Mon, 15 Mar 2004 17:54:22 PST Message-ID: <40565E4D.7000807@iprg.nokia.com> Date: Mon, 15 Mar 2004 17:54:21 -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: Erik Nordmark CC: Pekka Savola , v6ops@ops.ietf.org, jonne.soininen@nokia.com, huitema@microsoft.com, dthaler@microsoft.com, chirayu@chirayu.org Subject: Bridging dissimilar media with NDproxy (was Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik et al, Erik Nordmark wrote: >Odd - when I was in the IPv6 WG last week there was some discussion >about the fact that ndproxy and SEND can not be made to work together. >(Conclusion seems to be that proxy NA can be secured using SEND in the case >where there is a trust relationship between the host and the proxy, but >there is no such relationship in ndproxy hence it can not be secured.) >The odd thing is that there wasn't a groundswell reaction in the IPv6 WG saying >"we really need ndproxy - how do we get SEND fixed" - there seemed to be >almost complete disinterest in ndproxy as far as I could tell. > Diverting just a bit from the main focus of discussion, another feature introduced by ND proxying is that the NDproxies can support the path MTU discovery process when bridging between dissimilar media - this is something you don't get with simple L2 bridging. The question I raised at the microphone is whether the currently-specified ICMPv6 "packet too big" message approach could be trusted, and this morphed into the wider "NDproxy/SEND interactions" discussion referred to in this thread. But, the more specific question I didn't get the chance to ask was whether the ICMPv6 "packet too big" message approach is the best way to go in the first place? As has always been the case, the choices for L2 bridges are: 1) silently drop too-big packets (i.e., simple L2 bridging), 2) look into the L3 header and send PMTU feedback (e.g., ICMPv6 "packet too bigs") as necessary, 3) look into the L3 header and perform L3 fragmentation as necessary, or 4) perform link-specific fragmentation and reassembly. Option 1) has the disadvantage of no PMTU feedback and thus cannot be used for bridging dissimilar media due to PMTU black holes. Option 2) has the disadvantage of unreliable delivery of untrusted ICMPs, but even worse is the fact that the L3 header may not be available for inspection in all cases yielding the same broken PMTU behavior as for simple L2 bridging. Option 3) does not even work for IPv6, since middleboxes are not allowed to perform IPv6 fragmentation. Option 4) on the other hand has precedence in existing technologies (e.g. IEEE 802.11), is recommended by analytical works such as "Fragmentation Considered Harmful", and would seem like a reasonable alternative as long as it is well implemented and does not impart excessive delay/delay variance. It is only practical when reassembly takes place at the egress node at the edge of the bridged network (and not an L2 middlebox), but this is exactly the case when IPv4 is used as the L2 for IPv6. In other words, when IPv4 fragmentation is used as the link-specific fragmentation/reassembly mechanism the fragments not lost in the network will arrive at the same IPv6/IPv4 tunnel decapsulator. Essentially, I see advantages for NDproxy over simple L2 bridging *if* the NDproxies are specified to use link-specific fragmentation (i.e., IPv4 fragmentation) whenever possible rather than always trying to send ICMPv6 "packet too bigs". Since the NDproxy has no way of knowing the size of the reassembly buffer in the decapsulator, IPv4 fragmenation could only apply up to the minimum MRU required for all decapsulators, which I believe [MECH] currently sets at 1500bytes. For too-big packets larger than 1500bytes, the NDproxy could still send the ICMPv6 "packet too bigs" and hope for the best - but IPv6/IPv4 encapsulators would be well-advised to limit the size of the IPv6 packets/fragments they send to 1500bytes (or even smaller - down to 1280 bytes - if L2 encapsulatons might occur along the path) due to the PMTU black hole issues described above. Fred ftemplin@iprg.nokia.com P.S. Adding Dave and Chirayu to the Cc: list to get this on the NDproxy issue tracker. (Issue is "NDproxy should use IPv4 fragmentation for IPv6/IPv4 encapsulated packets no larger than 1500 bytes"). From owner-v6ops@ops.ietf.org Tue Mar 16 00: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 AAA26838 for ; Tue, 16 Mar 2004 00:37:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37DK-000AGA-Ef for v6ops-data@psg.com; Tue, 16 Mar 2004 05:34:06 +0000 Received: from [68.76.113.50] (helo=guns.icir.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B36Eq-0001rh-DW for v6ops@ops.ietf.org; Tue, 16 Mar 2004 04:31:36 +0000 Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id A30CB77AA55; Mon, 15 Mar 2004 23:31:33 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0C23C111E24; Mon, 15 Mar 2004 23:31:24 -0500 (EST) To: Pekka Savola From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Jailhouse Rock MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2004 23:31:23 -0500 Message-Id: <20040316043124.0C23C111E24@lawyers.icir.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-=-= (catching up) > The critical observation to make here is as IPv6 addresses are tried > first (I'm simplifying; it's more complex than that), one must cycle > through all the addresses, before trying with IPv4. However, IPv4 > connections might still work! With TCP timeouts, this takes a lot of > time --- and should be made quicker. Speaking personally, I think what you have written is fine and would not block the document on it. > There is going to be a WG last call on the document soon, aimed for > Informational -- just for documenting the issues. The actual fixes > (or not) would have to be done elsewhere (e.g., in TCPM WG ;-). Speaking as tcpm co-chair, yeah - we'd certainly be game to help out here. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAVoMbWyrrWs4yIs4RAmZ5AKCF3gmY1wWW3sbeFwcnBH35hIOrlACeKi6y H7MCcmIkLI9ENQtdHdDw8C4= =dBDy -----END PGP SIGNATURE----- --=-=-=-- From owner-v6ops@ops.ietf.org Tue Mar 16 00:40: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 AAA26933 for ; Tue, 16 Mar 2004 00:40:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37Hv-000AyR-Me for v6ops-data@psg.com; Tue, 16 Mar 2004 05:38:51 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B37Hl-000AxQ-0a for v6ops@ops.ietf.org; Tue, 16 Mar 2004 05:38:41 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2G5cewr022980 for ; Mon, 15 Mar 2004 22:38:40 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUN00BL4MCFGH@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:38:40 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUN0071SMCE5A@mail.sun.net> for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:38:39 -0700 (MST) Date: Mon, 15 Mar 2004 21:38:37 -0800 From: Alain Durand Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <2C96A4F5-770C-11D8-9F71-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote: > >> Stable addresses across reboot may be necessary. >> I want to be able to build apps that take advantage of the large IPv6 >> address space and consider that addresses are stable. > > So, you want to build a simple application. Don't we all.. :) But I > don't think this is something we can guarantee even with native > access. ISPs just aren't offering static v4 addresses today even when > they'd have technical means to do so. So, counting on static v6 > prefixes would IMHO be cutting corners too much. > > The problem is worse with transition mechanisms, especially the ones > which traverse NATs, but the situation may improve as soon as we can > get rid of them. In any case, such mechanisms can provide a stable > as long as they can keep the NAT/IP mappings stable -- which is, for a > properly designed application, maybe sufficient. I'm not sure I want to follow you here. If an application needs to be written to handle interface renumbering to benefit from IPv6 end to end connectivity, this is putting the bar fairly high. > >>> On the other hand, as long as John Doe's home PC stays powered on and >>> connected to the Internet, his address should stay stable. >> >> I suppose that you are aware of ISPs that change DHCPv4 allocated >> addresses every 24 hours... If John Doe's computer build its v6 >> address form those volatile v4 addresses, its v6 address will also >> change very 24 hours, and this even though John Doe has not rebooted >> his PC. Not good. > > Yep, I know this -- unfortunately. But there is little that can be > done to fix ISPs which want to enforce the users not to do Foo > (whatever Foo may be). We can hardly fix the misbehaving ISP problem > at the IETF.. as you're probably well aware :) In this scenario, we are already trying to fix the issue of ISP not cooperating to deploy IPv6... so I do not think it is unreasonable to seek to fix the address volatility problem at the same time if it is possible. - Alain. From owner-v6ops@ops.ietf.org Tue Mar 16 01:13: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 BAA28060 for ; Tue, 16 Mar 2004 01:13:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37nf-000GQt-5h for v6ops-data@psg.com; Tue, 16 Mar 2004 06:11:39 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B37nU-000GOR-8L for v6ops@ops.ietf.org; Tue, 16 Mar 2004 06:11:28 +0000 content-class: urn:content-classes:message Subject: RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Tue, 16 Mar 2004 01:11:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLGl7xw/0R0ldnR8y7kD7AZA5pGAAAc25g From: "Soliman Hesham" To: "Alain Durand" Cc: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Alain Durand > Sent: Tuesday, March 16, 2004 12:39 AM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: v6 deployment in general [Re: tunnel broker=20 > deployment [RE: > Tunneling scenarios and mechanisms evaluation]] >=20 >=20 >=20 > On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote: > > > >> Stable addresses across reboot may be necessary. > >> I want to be able to build apps that take advantage of=20 > the large IPv6 > >> address space and consider that addresses are stable. > > > > So, you want to build a simple application. Don't we=20 > all.. :) But I > > don't think this is something we can guarantee even with native > > access. =20 =3D> Yes we can ! Why not?=20 ISPs just aren't offering static v4 addresses=20 > today=20 =3D> Yes they are ! You just pay more for them. Hesham From owner-v6ops@ops.ietf.org Tue Mar 16 01:32:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28886 for ; Tue, 16 Mar 2004 01:32:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B386e-000ItG-Jl for v6ops-data@psg.com; Tue, 16 Mar 2004 06:31:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B386T-000IsR-F8 for v6ops@ops.ietf.org; Tue, 16 Mar 2004 06:31:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G6Uvx14496; Tue, 16 Mar 2004 08:30:57 +0200 Date: Tue, 16 Mar 2004 08:30:57 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: Alain Durand , Subject: static vs dynamic addresses for apps [RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'm responding to both Alain and Hesham in the same message, hoping to reduce overload on the list.. [Alain:] > I'm not sure I want to follow you here. If an application needs to > be written to handle interface renumbering to benefit from IPv6 end > to end connectivity, this is putting the bar fairly high. Apps certainly shouldn't need to handle renumbering on the fly .. or so I would hope. But they should not store information like "this is my static prefix, the next time I start, I will use it" either -- in each case, they should determine it independently. I don't think that sounds like too high a bar. [Alain quoting me:] > > Yep, I know this -- unfortunately. But there is little that can be > > done to fix ISPs which want to enforce the users not to do Foo > > (whatever Foo may be). We can hardly fix the misbehaving ISP problem > > at the IETF.. as you're probably well aware :) > > In this scenario, we are already trying to fix the issue of ISP not > cooperating to deploy IPv6... so I do not think it is unreasonable > to seek to fix the address volatility problem at the same time if it > is possible. It is entirely different when the ISP does not *care* about IPv6, and when the ISP is trying to *force* the user into a usage model (e.g., by renumbering the addresses used on the fly). We're addressing the first problem. There isn't much we can do if the ISP e.g., filters protocol-41 or the tunnel server UDP port at it's edge, for example. Having to deal with the case where the ISP is harassing the user, e.g., by the on-the-fly address changes is a complex problem. If we get a workaround for that for free -- that's fine. If not, I don't think we should try too hard. In the end, the IETF is inevitably going to lose to the ISPs who want to "encourage" their users to buy their premium service.. On Tue, 16 Mar 2004, Soliman Hesham wrote: > > On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote: > > > So, you want to build a simple application. Don't we > > > all.. :) But I > > > don't think this is something we can guarantee even with native > > > access. > > => Yes we can ! Why not? I think you're missing the context here. Would you build an application which would only work if the user's IPv6 address is static, and not for the others? At least when I have coded apps, I have to design them to work with everyone :). > > ISPs just aren't offering static v4 addresses > > today > > => Yes they are ! You just pay more for them. That's true of course .. but what do you think the user will choose, if given a dynamic (or reasonably static) prefix for free, or having to pay 5$/mo extra for a prefix which is guaranteed to be static? I want the prefixes to be static as much as you do -- but I have difficult time visualizing static prefixes to be so widely used that applications, which could be run on all kinds of networks, could be able to make an assumption that *all* the prefixes are static. Robust apps, especially if aimed at home users, just simply can't do that AFAICS (I'd hope I was wrong..). -- 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 Mar 16 02:03: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 CAA02284 for ; Tue, 16 Mar 2004 02:03:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B38ZU-000Nub-Oq for v6ops-data@psg.com; Tue, 16 Mar 2004 07:01:04 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B38ZJ-000NnA-Q6 for v6ops@ops.ietf.org; Tue, 16 Mar 2004 07:00:53 +0000 content-class: urn:content-classes:message Subject: RE: static vs dynamic addresses for apps [RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] Date: Tue, 16 Mar 2004 02:00:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: static vs dynamic addresses for apps [RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLIEBbwLzpfI9/Rsiih32eWpaJIgAAO2jg From: "Soliman Hesham" To: "Pekka Savola" Cc: "Alain Durand" , X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On Tue, 16 Mar 2004, Soliman Hesham wrote: > > > On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote: > > > > So, you want to build a simple application. Don't we > > > > all.. :) But I > > > > don't think this is something we can guarantee even=20 > with native > > > > access. =20 > >=20 > > =3D> Yes we can ! Why not?=20 >=20 > I think you're missing the context here. Would you build an=20 > application which would only work if the user's IPv6 address is=20 > static, and not for the others? =3D> That's a different question, ideally no, but I haven't surveyed all apps to see what best meets their requirements. My point is, if such app is needed we can certainly satisfy that need. There are several examples for apps that need a static address for reachability.=20 But I'm not an app designer and wouldn't want to make general statements about what applications need. > > > ISPs just aren't offering static v4 addresses=20 > > > today=20 > >=20 > > =3D> Yes they are ! You just pay more for them. >=20 > That's true of course .. but what do you think the user will choose, > if given a dynamic (or reasonably static) prefix for free, or having > to pay 5$/mo extra for a prefix which is guaranteed to be static? =3D> I don't think (hope) that the user will need to make that choice with IPv6. There is certainly no technical reason for operators to continue doing that, but hey, when did that ever count! On the other hand, I know that some users pay for=20 static addresses today and I don't see why they wouldn't do the same for IPv6. So independently of the choice I think the same user who wants a static address today will want=20 it tomorrow and there is no reason why the user will not=20 want to pay for it.=20 >=20 > I want the prefixes to be static as much as you do -- but I have > difficult time visualizing static prefixes to be so widely used that > applications, which could be run on all kinds of networks, could be > able to make an assumption that *all* the prefixes are static. =20 =3D> Ok, but you seem to be generalising here. First of all, some applications are not needed on all types of networks. Some apps will only run on certain networks. I don't think all app designers target all networks. So I wouldn't be surprised if other assumptions are made by app designers, just like=20 they make assumptions on the use scenario. Hesham From owner-v6ops@ops.ietf.org Tue Mar 16 02:06: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 CAA04187 for ; Tue, 16 Mar 2004 02:06:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B38cn-000OVO-QM for v6ops-data@psg.com; Tue, 16 Mar 2004 07:04:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B38cU-000OTA-IQ for v6ops@ops.ietf.org; Tue, 16 Mar 2004 07:04:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G747r14966; Tue, 16 Mar 2004 09:04:07 +0200 Date: Tue, 16 Mar 2004 09:04:07 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: focussing energies In-Reply-To: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a very important topic, but as it mostly goes to issues beyond our control, let's hope the thread does not get out of hand... On Mon, 15 Mar 2004, Alain Durand wrote: [...] > b) assisted tunneling works best in the scenario of an ISP willing > to offer IPv6 service but not ready yet to pay to deploy native > service. Those mechanisms, like tunnel broker, not only provide IPv6 > connectivity to the user, but also to help the ISP to jump start > IPv6 service to its customers at low cost. This is an area where > standardization from this wg could help a lot. > > c) when ISPs are not cooperating, there is the choice between two evils: > - fully automatic solutions, with their share of complexity, security > issues,... > - tunnel brokers operated by third parties, with possible sub-optimal > paths and complex set-up. [...] > The point I'm trying to make is that, IMHO, this wg should not spend to > much effort on c) > [i.e. there are implemented solution, let's document them and move on] > because: > 1) either IPv6 will take off and ISPs will start to cooperate, thus > we're back to case b) > 2) ISP still don't cooperate in the near future, meaning that they see > IPv6 as going nowhere, > so why should this wg and software vendors invest in complex > transition mechanisms? There is a middle ground here: ISPs not knowing when is the right take to start taking IPv6 seriously, and actually deploying it in a fast-track fashion. Most, especially those who look the red/black bottom line, have been just biding their time. They wait for the user demand or some push from any direction. This push could be achieved either through a) [which is outside of our scope] or through some v6 application getting popular. Barring outside agencies, we seem to need to work on enabling that "application landslide". More of that below. > and focus its energies on standardizing a > solution for b) My take on this is that being able to crack the chicken-and-egg problem is likely to take a while -- measured in years. We have to provide means for app developers to deploy v6 applications which might make IPv6 fly. In the general case, deploying v6 applications is only possible if there is sufficient IPv6 penetration, e.g., through the use of automatic transition mechanisms. (Otherwise the app developers just keep using IPv4 band-aids, and we never get to IPv6 in the first place -- and similarly, if an app is v4-capable, the users/vendors don't see the push to move to v6!) So, my personal gut feeling is that we need to tackle the first subcase of c), while the second is not useful for the mass deployment. If all goes well, this stage would be only short-term. b) is equally interesting; if coupled with a) in particular, the local ISPs might be keen to offer some IPv6 service. This is probably something that could be applicable for a slighly longer term than c) subcase 1). -- 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 Mar 16 02:14: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 CAA10519 for ; Tue, 16 Mar 2004 02:14:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B38kl-000PgD-AD for v6ops-data@psg.com; Tue, 16 Mar 2004 07:12:43 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B38ka-000Pf2-RD for v6ops@ops.ietf.org; Tue, 16 Mar 2004 07:12:32 +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); Mon, 15 Mar 2004 23:09:17 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Mar 2004 23:12:32 -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); Mon, 15 Mar 2004 23:14:12 -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); Mon, 15 Mar 2004 23:12:34 -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); Mon, 15 Mar 2004 23:12:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: static vs dynamic addresses for apps [RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] Date: Mon, 15 Mar 2004 23:12:34 -0800 Message-ID: Thread-Topic: static vs dynamic addresses for apps [RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] thread-index: AcQLIT0F2KyunDulQX+9CxwZYQ9WMAABI/Ow From: "Christian Huitema" To: "Pekka Savola" , "Soliman Hesham" Cc: "Alain Durand" , X-OriginalArrivalTime: 16 Mar 2004 07:12:41.0648 (UTC) FILETIME=[12465B00:01C40B26] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I think you're missing the context here. Would you build an > application which would only work if the user's IPv6 address is > static, and not for the others? >=20 > At least when I have coded apps, I have to design them to work with > everyone :). Yup. In particular, applications must work on laptops. When a laptop roams to a new WiFi hot spot, it gets a new address. Applications are expected to go on working... -- Christian Huitema=20 From owner-v6ops@ops.ietf.org Tue Mar 16 03:14: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 DAA17193 for ; Tue, 16 Mar 2004 03:14:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B39fQ-0007D4-1k for v6ops-data@psg.com; Tue, 16 Mar 2004 08:11:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39fF-0007CP-6z for v6ops@ops.ietf.org; Tue, 16 Mar 2004 08:11:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G8Aok15868; Tue, 16 Mar 2004 10:10:50 +0200 Date: Tue, 16 Mar 2004 10:10:50 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: Florent Parent , Subject: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Mar 2004, Soliman Hesham wrote: > > Hesham, > > As you are saying, if its already there (L2TP > > infrastructure), then this > > route can certainly make sense. But if an ISP doesn't have an L2TP > > infrastructure, deploying a tunnel broker solution is simpler. > > => Respectfully disagree. Many hosts already have L2TP, > you're asking them to implement another protocol. > If the operator doesn't have then he can have it, it's > already available in products. An existing protocol that > is already implemented is better than standardising > a new protocol because it might be simpler to implement. I looked at different L2TP approaches a bit. An important thing to note is that L2TP only offers control plane security, no data plane security. For the latter, you need IPsec as well. L2TP appears very heavyweight (even the spec is over 100 pages) for this specific purpose, especially for some scenarios -- e.g., 3GPP network for UE tunneling. So, my personal gut feeling at this point is that L2TP is probably applicable in the environments which already have the machinery in place, but is a pain to set-up, and has significant complexity and overhead which are probably drawbacks in a few scenarios at least. We could actually achieve more than L2TP with simply IPsec with NAT traversal (as outlined in a separate thread previously) -- but there are some issues here to be investigated -- the biggest problem AFAICS is the implementation status. But I'm not certain this is a feasible approach in all the scenarios either... -- 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 Mar 16 03:28: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 DAA17716 for ; Tue, 16 Mar 2004 03:28:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B39uG-0009Cj-Tu for v6ops-data@psg.com; Tue, 16 Mar 2004 08:26:36 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39ty-00099a-As for v6ops@ops.ietf.org; Tue, 16 Mar 2004 08:26:18 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B39tt-0003Uv-00; Tue, 16 Mar 2004 08:26:13 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B39tt-0003Uq-00; Tue, 16 Mar 2004 08:26:13 +0000 Received: from zurich.ibm.com (sig-9-145-169-66.de.ibm.com [9.145.169.66]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2G8QDF133742; Tue, 16 Mar 2004 08:26:14 GMT Message-ID: <4056BA42.84D81796@zurich.ibm.com> Date: Tue, 16 Mar 2004 09:26:42 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: EricLKlein CC: v6ops@ops.ietf.org Subject: Re: focussing energies References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The EU has certainly not mandated any such thing. They burnt their fingers badly with OSI mandates 15 years ago, and are unlikely to repeat that mistake. There is substantial EU support for IPv6 deployment, but that is far from being a mandate. Brian EricLKlein wrote: > > From: "Alain Durand" > > > > a) the best model is to get ISPs to deploy IPv6 to their customer. No > > transition mechanism is better > > than anything else. Most ISPs won't do it unless there is strong > > motivation: > > - political mandate to do so > > - political incentive (like tax break) > > - customer asking for it > > The first two are outside the realm of IETF. The last one will only be > > driven by the new applications > > requiring/working better with IPv6. Nothing here that this wg can do > > about. > > > Just keep in mind that some governments have mandated that all services be > transitioned to IPv6 by fixed dates (off the top of my head I know that > Japan and the EU have mandated dates) but I am not sure what the penalties > are for failing to meet these mandates. From owner-v6ops@ops.ietf.org Tue Mar 16 03:34: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 DAA17975 for ; Tue, 16 Mar 2004 03:34:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A0e-000ASn-Bc for v6ops-data@psg.com; Tue, 16 Mar 2004 08:33:12 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39zh-000AFS-Js for v6ops@ops.ietf.org; Tue, 16 Mar 2004 08:32:13 +0000 content-class: urn:content-classes:message Subject: RE: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] Date: Tue, 16 Mar 2004 03:32:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLLjWL+yIS1PyvTLWkJ0HMXmdMugAAST3A From: "Soliman Hesham" To: "Pekka Savola" Cc: "Florent Parent" , X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > L2TP appears very heavyweight (even the spec is over 100 pages) for > this specific purpose, especially for some scenarios -- e.g., 3GPP > network for UE tunneling. =3D> I don't think the 3GPP deployments will use either L2TP or TSP. I think they'll want something like ISATAP if native connectivity is not available. >=20 > So, my personal gut feeling at this point is that L2TP is probably > applicable in the environments which already have the machinery in > place, but is a pain to set-up, and has significant complexity and > overhead which are probably drawbacks in a few scenarios at least. =3D> Other than the above scenario, I don't see any problems with it. Especially when the alternative is to develop a new protocol. The point is, it's already implemented by several vendors and deployed, why would we want to invent something=20 new in this space? "Too complex" is not a good reason IMHO. >=20 > We could actually achieve more than L2TP with simply IPsec with NAT > traversal (as outlined in a separate thread previously) -- but there > are some issues here to be investigated -- the biggest problem AFAICS > is the implementation status. But I'm not certain this is a feasible > approach in all the scenarios either... =3D> Exactly, also protecting traffic with IPsec was never a requirement that must be satisfied by all transition mechanisms. Hesham >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 From owner-v6ops@ops.ietf.org Tue Mar 16 03:49: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 DAA18454 for ; Tue, 16 Mar 2004 03:49:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3AEW-000D8H-Nb for v6ops-data@psg.com; Tue, 16 Mar 2004 08:47:32 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B3AEE-000D4R-3N for v6ops@ops.ietf.org; Tue, 16 Mar 2004 08:47:14 +0000 Received: (qmail 13074 invoked by uid 417); 16 Mar 2004 08:47:13 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 16 Mar 2004 08:47:13 -0000 Received: from XPNERICK ([212.150.211.163]) by softhome.net with esmtp; Tue, 16 Mar 2004 01:47:11 -0700 Message-ID: <002101c40b33$33b9d1b0$64051eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: Subject: IPv6 Governmental requirements (was focussing energies) Date: Tue, 16 Mar 2004 10:46:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am responding on list for the benefit of anyone else who might be interested here are some useful state of IPv6 documents: http://www.ipv6tf-sc.org/html/public/ipv6tf-sc_pu_d3_4v1_3.pdf: (look at section 6 for a country by country review) IPv6 Moving towards Realistic World: http://www.chinaipv6council.com/news_en.jsp?id=062F9C2961E30D2516B7340AA13BCA39DEB1302DE63AB47B1D2DE637C21A5C7B From the European e-Europe 2005: (http://europa.eu.int/information_society/eeurope/2005/all_about/action_plan /index_en.htm) The Barcelona European Council called on the Commission to draw up an eEurope action plan focussing on "the widespread availability and use of broadband networks throughout the Union by 2005 and the development of Internet protocol IPv6 .. and the security of networks and information, eGovernment, eLearning, eHealth and eBusiness" IPv6 allocation Percentage in Asia Pacific (from http://www.ipv6.org.tw/eng/index_E.shtml0 Japan:63(51%) Korea:17(14%) Taiwan:13(11%) Australlia:5(4%) Singapore:5(4%) Taiwan's plans that between 2006 and 2007 to Complete IPv6 deployment in full scale, such that any network equipment and application can easily connect to the Internet with IPv6. and to Replace IPv4 with IPv6, and make IPv6 the popular Internet Protocol (http://www.ipv6.org.tw/eng/Milestone.htm) I will keep looking for more Eric ----- Original Message ----- From: "Pekka Savola" To: "EricLKlein" Sent: 15 March, 2004 9:11 PM Subject: Re: focussing energies > off-list > > On Mon, 15 Mar 2004, EricLKlein wrote: > > From: "Alain Durand" > > > > > > a) the best model is to get ISPs to deploy IPv6 to their customer. No > > > transition mechanism is better > > > than anything else. Most ISPs won't do it unless there is strong > > > motivation: > > > - political mandate to do so > > > - political incentive (like tax break) > > > - customer asking for it > > > The first two are outside the realm of IETF. The last one will only be > > > driven by the new applications > > > requiring/working better with IPv6. Nothing here that this wg can do > > > about. > > > > > Just keep in mind that some governments have mandated that all services be > > transitioned to IPv6 by fixed dates (off the top of my head I know that > > Japan and the EU have mandated dates) but I am not sure what the penalties > > are for failing to meet these mandates. > > Do you have pointers about the latter? EU has not made any of such > mandates -- just sent notes to the local governments stating like > "prepare for v6, thanks". > > Any reference would be useful -- I might have missed something. > > -- > 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 Mar 16 04:04: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 EAA18993 for ; Tue, 16 Mar 2004 04:04:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ATW-000GFr-N5 for v6ops-data@psg.com; Tue, 16 Mar 2004 09:03:02 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B3ATM-000GEy-0V for v6ops@ops.ietf.org; Tue, 16 Mar 2004 09:02:52 +0000 Received: (qmail 29029 invoked by uid 417); 16 Mar 2004 09:02:51 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 16 Mar 2004 09:02:51 -0000 Received: from XPNERICK ([212.150.211.163]) by softhome.net with esmtp; Tue, 16 Mar 2004 02:02:50 -0700 Message-ID: <005c01c40b35$62da1c50$64051eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> <4056BA42.84D81796@zurich.ibm.com> Subject: Re: focussing energies Date: Tue, 16 Mar 2004 11:02:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Brian E Carpenter" > The EU has certainly not mandated any such thing. They burnt their fingers > badly with OSI mandates 15 years ago, and are unlikely to repeat that > mistake. There is substantial EU support for IPv6 deployment, but that > is far from being a mandate. > > Brian Correct, they have initiated the eEurope 2005 program that is "recommends" deployment by 2005, with each country forming their own plan. It looks like the UK and France are pushing to be first with several others in close second (only Italy seems to be without a plan). Eric From owner-v6ops@ops.ietf.org Tue Mar 16 06:19: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 GAA24210 for ; Tue, 16 Mar 2004 06:19:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3CYk-000A5K-RC for v6ops-data@psg.com; Tue, 16 Mar 2004 11:16:34 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3CYa-000A26-A0 for v6ops@ops.ietf.org; Tue, 16 Mar 2004 11:16:24 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i2GBGEm03709; Tue, 16 Mar 2004 03:16:14 -0800 From: bill Message-Id: <200403161116.i2GBGEm03709@karoshi.com> Subject: Re: static vs dynamic To: huitema@windows.microsoft.com (Christian Huitema) Date: Tue, 16 Mar 2004 03:16:14 -0800 (PST) Cc: pekkas@netcore.fi (Pekka Savola), H.Soliman@flarion.com (Soliman Hesham), Alain.Durand@Sun.COM (Alain Durand), v6ops@ops.ietf.org In-Reply-To: from "Christian Huitema" at Mar 15, 2004 11:12:34 PM 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.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I think you're missing the context here. Would you build an > > application which would only work if the user's IPv6 address is > > static, and not for the others? > > > > At least when I have coded apps, I have to design them to work with > > everyone :). > > Yup. In particular, applications must work on laptops. When a laptop > roams to a new WiFi hot spot, it gets a new address. Applications are > expected to go on working... > > -- Christian Huitema three areas where static wins big: ) BGP peering ) DNS servers ) Network Management Sorry folks, there are things that (until there is a compelling reason to dump them) will pretty much require static IP addresses. Good Luck. --bill From owner-v6ops@ops.ietf.org Tue Mar 16 06:48:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25703 for ; Tue, 16 Mar 2004 06:48:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3D0c-000Dwt-4m for v6ops-data@psg.com; Tue, 16 Mar 2004 11:45:22 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B3D0J-000DvZ-E6 for v6ops@ops.ietf.org; Tue, 16 Mar 2004 11:45:03 +0000 Received: (qmail 17789 invoked by uid 417); 16 Mar 2004 11:45:03 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 16 Mar 2004 11:45:03 -0000 Received: from XPNERICK ([212.150.211.163]) by softhome.net with esmtp; Tue, 16 Mar 2004 04:45:01 -0700 Message-ID: <007b01c40b4c$0b315920$64051eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <200403161116.i2GBGEm03709@karoshi.com> Subject: Re: static vs dynamic Date: Tue, 16 Mar 2004 13:44:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message From: "bill" > > > I think you're missing the context here. Would you build an > > > application which would only work if the user's IPv6 address is > > > static, and not for the others? > > > > > > At least when I have coded apps, I have to design them to work with > > > everyone :). > > > > Yup. In particular, applications must work on laptops. When a laptop > > roams to a new WiFi hot spot, it gets a new address. Applications are > > expected to go on working... > > > > -- Christian Huitema > > three areas where static wins big: > > ) BGP peering > ) DNS servers > ) Network Management > > Sorry folks, there are things that (until there is a compelling reason to dump them) > will pretty much require static IP addresses. Good Luck. > I tend to agree that there will be cases where some IP addresses will need to stay static. For example many devices have a static loop back address used to identify it to the network management which would have a hard time understanding what devices are during the autodiscovery process if the same device changes addresses but not location or connections. Where you have devices that change connections (like laptops or PCs on DHCP) then you need to support changing addresses, but for peering (AS to AS or BGP) and DNS servers or network (or element) managers these need to have a static address or the services will not continue to work. From owner-v6ops@ops.ietf.org Tue Mar 16 07:06: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 HAA26237 for ; Tue, 16 Mar 2004 07:06:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3DJL-000Hgv-Rz for v6ops-data@psg.com; Tue, 16 Mar 2004 12:04:43 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3DJB-000Hg9-BC for v6ops@ops.ietf.org; Tue, 16 Mar 2004 12:04:33 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i2GC4To04495; Tue, 16 Mar 2004 04:04:29 -0800 From: bill Message-Id: <200403161204.i2GC4To04495@karoshi.com> Subject: Re: static vs dynamic To: ericlklein@softhome.net (EricLKlein) Date: Tue, 16 Mar 2004 04:04:29 -0800 (PST) Cc: v6ops@ops.ietf.org In-Reply-To: <007b01c40b4c$0b315920$64051eac@ttitelecom.com> from "EricLKlein" at Mar 16, 2004 01:44:28 PM 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.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 > ----- Original Message From: "bill" > > > > I think you're missing the context here. Would you build an > > > > application which would only work if the user's IPv6 address is > > > > static, and not for the others? > > > > > > > > At least when I have coded apps, I have to design them to work with > > > > everyone :). > > > > > > Yup. In particular, applications must work on laptops. When a laptop > > > roams to a new WiFi hot spot, it gets a new address. Applications are > > > expected to go on working... > > > > > > -- Christian Huitema > > > > three areas where static wins big: > > > > ) BGP peering > > ) DNS servers > > ) Network Management > > > > Sorry folks, there are things that (until there is a compelling reason to > dump them) > > will pretty much require static IP addresses. Good Luck. > > > > I tend to agree that there will be cases where some IP addresses will need > to stay static. For example many devices have a static loop back address > used to identify it to the network management which would have a hard time > understanding what devices are during the autodiscovery process if the same > device changes addresses but not location or connections. > > Where you have devices that change connections (like laptops or PCs on DHCP) > then you need to support changing addresses, but for peering (AS to AS or > BGP) and DNS servers or network (or element) managers these need to have a > static address or the services will not continue to work. > too right. just thought I'd chime in here w/ stuff that was discussed eight years ago in the IPv6 transition wg mtgs... some folks active now were not active in the discussion then. --bill From owner-v6ops@ops.ietf.org Tue Mar 16 08:01: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 IAA28540 for ; Tue, 16 Mar 2004 08:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3E99-000Orh-WD for v6ops-data@psg.com; Tue, 16 Mar 2004 12:58:15 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3E8z-000Oqc-Cz for v6ops@ops.ietf.org; Tue, 16 Mar 2004 12:58:05 +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 2D5E38722; Tue, 16 Mar 2004 13:58:04 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: focussing energies Date: Tue, 16 Mar 2004 13:57:07 +0100 Organization: Unfix MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <005c01c40b35$62da1c50$64051eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQLNdsVQEm6UgTsQWiakTUkeFjwHAAH70wg Message-Id: <20040316125804.2D5E38722@purgatory.unfix.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 EricLKlein wrote: > From: "Brian E Carpenter" > > The EU has certainly not mandated any such thing. They burnt their fingers > > badly with OSI mandates 15 years ago, and are unlikely to repeat that > > mistake. There is substantial EU support for IPv6 deployment, but that > > is far from being a mandate. > > > > Brian > > Correct, they have initiated the eEurope 2005 program that is > "recommends" deployment by 2005, with each country forming their own plan. > It looks like the UK and France are pushing to be first with several others > in close second (only Italy seems to be without a plan). FYI and OT: even The Netherlands seems to be without a plan. Or to be precise the dutch _goverment_ seems to be without a plan. They noticed that there was this big bucket full of money and suddenly they are hiring stupid 'consultants' who 'know IPv6' and let them write reports why the businesses should start doing IPv6. The fun part here is that IPv6 has been around in the ISP world for quite some time already in the Netherlands taking quite a big lead actually in comparison to some of the bigger countries. I would even go so far as trying to say that the Netherlands has a global top 10 listing of well connected IPv6 countries. But this is the IETF and not a political list ;) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFb5ogAAmzoAn138+q4Mt8nB4M2zufqBpTUH SS4kAJ4jSE+QyxT6OZ9kBQLFtzRoOIEqaQ== =Oj4u -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Tue Mar 16 09:05: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 JAA01803 for ; Tue, 16 Mar 2004 09:05:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3F9Q-0008lv-7X for v6ops-data@psg.com; Tue, 16 Mar 2004 14:02:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3F9F-0008kV-05 for v6ops@ops.ietf.org; Tue, 16 Mar 2004 14:02:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2GE2DE20561; Tue, 16 Mar 2004 16:02:13 +0200 Date: Tue, 16 Mar 2004 16:02:13 +0200 (EET) From: Pekka Savola To: bill cc: Christian Huitema , Soliman Hesham , Alain Durand , Subject: Re: static vs dynamic In-Reply-To: <200403161116.i2GBGEm03709@karoshi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 16 Mar 2004, bill wrote: > ) BGP peering > ) DNS servers > ) Network Management > > Sorry folks, there are things that (until there is a compelling reason to dump them) > will pretty much require static IP addresses. Good Luck. None of these seems applicable to the unmanaged networks scenario, which was the context. (Well, except if you want to delegate reverse/forward DNS tree to a server in unmanaged network itself, but I don't think this is so "unmanaged" any more :). -- 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 Mar 16 12:17: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 MAA11792 for ; Tue, 16 Mar 2004 12:17:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3I85-000Aug-JY for v6ops-data@psg.com; Tue, 16 Mar 2004 17:13:25 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3I7v-000Au5-3p for v6ops@ops.ietf.org; Tue, 16 Mar 2004 17:13:15 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i2GHD9106762; Tue, 16 Mar 2004 09:13:09 -0800 From: bill Message-Id: <200403161713.i2GHD9106762@karoshi.com> Subject: Re: static vs dynamic To: pekkas@netcore.fi (Pekka Savola) Date: Tue, 16 Mar 2004 09:13:09 -0800 (PST) Cc: bmanning@karoshi.com (bill), huitema@windows.microsoft.com (Christian Huitema), H.Soliman@flarion.com (Soliman Hesham), Alain.Durand@Sun.COM (Alain Durand), v6ops@ops.ietf.org In-Reply-To: from "Pekka Savola" at Mar 16, 2004 04:02:13 PM 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.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > On Tue, 16 Mar 2004, bill wrote: > > ) BGP peering > > ) DNS servers > > ) Network Management > > > > Sorry folks, there are things that (until there is a compelling reason to dump them) > > will pretty much require static IP addresses. Good Luck. > > None of these seems applicable to the unmanaged networks scenario, > which was the context. (Well, except if you want to delegate > reverse/forward DNS tree to a server in unmanaged network itself, but > I don't think this is so "unmanaged" any more :). > -- > Pekka Savola "You each name yourselves king, yet the then the context was lost. and even "unmanaged" networks should have some nod to having instrumentation and auditing capabilities... IMHO of course. --bill From owner-v6ops@ops.ietf.org Tue Mar 16 14:38: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 OAA20043 for ; Tue, 16 Mar 2004 14:38:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3KLv-0004an-1O for v6ops-data@psg.com; Tue, 16 Mar 2004 19:35:51 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3KLc-0004VM-84 for v6ops@ops.ietf.org; Tue, 16 Mar 2004 19:35:32 +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 i2GJZGWA019500; Tue, 16 Mar 2004 11:35:17 -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 i2GJZEQ00628; Tue, 16 Mar 2004 20:35:14 +0100 (MET) Date: Tue, 16 Mar 2004 11:35:17 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Re :automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] To: soohong.park@samsung.com Cc: Pekka Savola , JORDI PALET MARTINEZ , "v6ops@ops.ietf.org " In-Reply-To: "Your message with ID" <0HUM008MYW4WWR@ms3.samsung.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt I think the technique in this draft is useful to consider in what Alain called case b) (where the ISP is providing the IPv6 service but is doing it using tunneling over IPv4 to avoid upgrading all their infrastructure to support IPv6 on day one). Erik From owner-v6ops@ops.ietf.org Tue Mar 16 14:39: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 OAA20087 for ; Tue, 16 Mar 2004 14:39:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3KNT-0004op-Ec for v6ops-data@psg.com; Tue, 16 Mar 2004 19:37:27 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3KNI-0004oE-UT for v6ops@ops.ietf.org; Tue, 16 Mar 2004 19:37:16 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2GJb4ex008828; Tue, 16 Mar 2004 12:37:05 -0700 (MST) 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 i2GJb2Q00725; Tue, 16 Mar 2004 20:37:02 +0100 (MET) Date: Tue, 16 Mar 2004 11:37:04 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] To: Pekka Savola Cc: Alain Durand , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The problem is worse with transition mechanisms, especially the ones > which traverse NATs, but the situation may improve as soon as we can > get rid of them. In any case, such mechanisms can provide a stable > as long as they can keep the NAT/IP mappings stable -- which is, for a > properly designed application, maybe sufficient. I guess I don't understand what "such mechanisms" refer to above. I don't know if mechanisms like Teredo can provide a stable IPv6 address when the nat mappings change, but doing TB/UDP for nat traversal should be able to provide stable IP addresses/prefixes in this case. Erik From owner-v6ops@ops.ietf.org Tue Mar 16 15:13: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 PAA21611 for ; Tue, 16 Mar 2004 15:13:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3KuS-000Abv-5c for v6ops-data@psg.com; Tue, 16 Mar 2004 20:11:32 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Ku8-000Aad-Ke for v6ops@ops.ietf.org; Tue, 16 Mar 2004 20:11:12 +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 34-md50000000453.tmp for ; Tue, 16 Mar 2004 21:16:28 +0100 Message-ID: <23bb01c40b93$637b9cc0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> <4056BA42.84D81796@zurich.ibm.com> <005c01c40b35$62da1c50$64051eac@ttitelecom.com> Subject: Re: focussing energies Date: Tue, 16 Mar 2004 21:15:10 +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, 16 Mar 2004 21:16:28 +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.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 Well, certainly is not a "mandate" as such, but a high level = recommendation (some times is more important and respected that a = mandate), and a strong push and help at the same time. By the way, Spain is the one that is leading, even stronger than France. = Also I will say Germany is pushing now stronger than UK. Regards, Jordi ----- Original Message -----=20 From: "EricLKlein" To: Sent: Tuesday, March 16, 2004 10:02 AM Subject: Re: focussing energies >=20 > From: "Brian E Carpenter" > > The EU has certainly not mandated any such thing. They burnt their = fingers > > badly with OSI mandates 15 years ago, and are unlikely to repeat = that > > mistake. There is substantial EU support for IPv6 deployment, but = that > > is far from being a mandate. > > > > Brian >=20 > Correct, they have initiated the eEurope 2005 program that is = "recommends" > deployment by 2005, with each country forming their own plan. It looks = like > the UK and France are pushing to be first with several others in close > second (only Italy seems to be without a plan). > Eric > ********************************** 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 Mar 16 15:18: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 PAA22111 for ; Tue, 16 Mar 2004 15:18:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Kze-000BVQ-UG for v6ops-data@psg.com; Tue, 16 Mar 2004 20:16:54 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3KzU-000BTV-1I for v6ops@ops.ietf.org; Tue, 16 Mar 2004 20:16:44 +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 39-md50000000453.tmp for ; Tue, 16 Mar 2004 21:22:03 +0100 Message-ID: <245f01c40b94$2b785bf0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20040316125804.2D5E38722@purgatory.unfix.org> Subject: Re: focussing energies Date: Tue, 16 Mar 2004 21:20:46 +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, 16 Mar 2004 21:22:03 +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.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 Jerome, Is coming ... wait until after summer and stay tuned ;-) Regards, Jordi ----- Original Message -----=20 From: "Jeroen Massar" To: "'EricLKlein'" ; Sent: Tuesday, March 16, 2004 1:57 PM Subject: RE: focussing energies > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > EricLKlein wrote: >=20 > > From: "Brian E Carpenter" > > > The EU has certainly not mandated any such thing. They burnt their = fingers > > > badly with OSI mandates 15 years ago, and are unlikely to repeat = that > > > mistake. There is substantial EU support for IPv6 deployment, but = that > > > is far from being a mandate. > > > > > > Brian > >=20 > > Correct, they have initiated the eEurope 2005 program that is=20 > > "recommends" deployment by 2005, with each country forming their own = plan.=20 > > It looks like the UK and France are pushing to be first with several = others > > in close second (only Italy seems to be without a plan). >=20 > FYI and OT: even The Netherlands seems to be without a plan. > Or to be precise the dutch _goverment_ seems to be without a plan. > They noticed that there was this big bucket full of money and > suddenly they are hiring stupid 'consultants' who 'know IPv6' > and let them write reports why the businesses should start > doing IPv6. The fun part here is that IPv6 has been around > in the ISP world for quite some time already in the Netherlands > taking quite a big lead actually in comparison to some of > the bigger countries. I would even go so far as trying to say > that the Netherlands has a global top 10 listing of well > connected IPv6 countries. >=20 > But this is the IETF and not a political list ;) >=20 > Greets, > Jeroen >=20 > -----BEGIN PGP SIGNATURE----- > Version: Unfix PGP for Outlook > Comment: Jeroen Massar / http://unfix.org/~jeroen/ >=20 > iQBGBAERAgAQCRApqihSMz58IwUCQFb5ogAAmzoAn138+q4Mt8nB4M2zufqBpTUH > SS4kAJ4jSE+QyxT6OZ9kBQLFtzRoOIEqaQ=3D=3D > =3DOj4u > -----END PGP SIGNATURE----- > ********************************** 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 Mar 16 15:19:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22209 for ; Tue, 16 Mar 2004 15:19:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3L0t-000BjG-G2 for v6ops-data@psg.com; Tue, 16 Mar 2004 20:18:11 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3L0i-000BhQ-Tt for v6ops@ops.ietf.org; Tue, 16 Mar 2004 20:18:00 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 16 Mar 2004 12:18:03 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Tue, 16 Mar 2004 12:18:11 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Mar 2004 12:17:57 -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, 16 Mar 2004 12:18:11 -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, 16 Mar 2004 12:17:48 -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, 16 Mar 2004 12:17:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Tue, 16 Mar 2004 12:17:55 -0800 Message-ID: Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] thread-index: AcQLjukDQJ0FVDm4TGC+j/uH7e2haQABLMkg From: "Christian Huitema" To: "Erik Nordmark" , "Pekka Savola" Cc: "Alain Durand" , X-OriginalArrivalTime: 16 Mar 2004 20:17:47.0184 (UTC) FILETIME=[BF5CBB00:01C40B93] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > The problem is worse with transition mechanisms, especially the ones > > which traverse NATs, but the situation may improve as soon as we can > > get rid of them. In any case, such mechanisms can provide a stable > > as long as they can keep the NAT/IP mappings stable -- which is, for a > > properly designed application, maybe sufficient. >=20 > I guess I don't understand what "such mechanisms" refer to above. > I don't know if mechanisms like Teredo can provide a stable IPv6 address > when the nat mappings change, but doing TB/UDP for nat traversal should be > able to provide stable IP addresses/prefixes in this case. In practice the NAT mappings do not change and the Teredo address remains reasonably stable. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Mar 16 16:09: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 QAA24701 for ; Tue, 16 Mar 2004 16:09:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Llx-000Mck-Rr for v6ops-data@psg.com; Tue, 16 Mar 2004 21:06:49 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Lln-000Map-2J for v6ops@ops.ietf.org; Tue, 16 Mar 2004 21:06:39 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2GL6cwr029139 for ; Tue, 16 Mar 2004 14:06:38 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUO00IWLTB1PG@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 16 Mar 2004 14:06:38 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUO00CNCTB0E1@mail.sun.net> for v6ops@ops.ietf.org; Tue, 16 Mar 2004 14:06:37 -0700 (MST) Date: Tue, 16 Mar 2004 13:06:35 -0800 From: Alain Durand Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] In-reply-to: To: Christian Huitema Cc: Pekka Savola , v6ops@ops.ietf.org, Erik Nordmark Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 16, 2004, at 12:17 PM, Christian Huitema wrote: > >>> The problem is worse with transition mechanisms, especially the ones >>> which traverse NATs, but the situation may improve as soon as we can >>> get rid of them. In any case, such mechanisms can provide a stable >>> as long as they can keep the NAT/IP mappings stable -- which is, for > a >>> properly designed application, maybe sufficient. >> >> I guess I don't understand what "such mechanisms" refer to above. >> I don't know if mechanisms like Teredo can provide a stable IPv6 > address >> when the nat mappings change, but doing TB/UDP for nat traversal > should be >> able to provide stable IP addresses/prefixes in this case. > > In practice the NAT mappings do not change and the Teredo address > remains reasonably stable. unless the global IPv4 address of the NAT box is changed every 24 hours by the ISP... - Alain. From owner-v6ops@ops.ietf.org Tue Mar 16 18:00: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 SAA02379 for ; Tue, 16 Mar 2004 18:00:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3NVh-000OFC-GA for v6ops-data@psg.com; Tue, 16 Mar 2004 22:58:09 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3NVW-000OBf-7H for v6ops@ops.ietf.org; Tue, 16 Mar 2004 22:57:58 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 22:53:00 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:34:49 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079426088452; Tue, 16 Mar 2004 08:34:48 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:34:47 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A0e-000ASn-Bc for v6ops-data@psg.com; Tue, 16 Mar 2004 08:33:12 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39zh-000AFS-Js for v6ops@ops.ietf.org; Tue, 16 Mar 2004 08:32:13 +0000 content-class: urn:content-classes:message Subject: RE: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] Date: Tue, 16 Mar 2004 03:32:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLLjWL+yIS1PyvTLWkJ0HMXmdMugAAST3A From: "Soliman Hesham" To: "Pekka Savola" Cc: "Florent Parent" , X-OriginalArrivalTime: 16 Mar 2004 08:34:47.0546 (UTC) FILETIME=[8A56BDA0:01C40B31] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > L2TP appears very heavyweight (even the spec is over 100 pages) for > this specific purpose, especially for some scenarios -- e.g., 3GPP > network for UE tunneling. =3D> I don't think the 3GPP deployments will use either L2TP or TSP. I think they'll want something like ISATAP if native connectivity is not available. >=20 > So, my personal gut feeling at this point is that L2TP is probably > applicable in the environments which already have the machinery in > place, but is a pain to set-up, and has significant complexity and > overhead which are probably drawbacks in a few scenarios at least. =3D> Other than the above scenario, I don't see any problems with it. Especially when the alternative is to develop a new protocol. The point is, it's already implemented by several vendors and deployed, why would we want to invent something=20 new in this space? "Too complex" is not a good reason IMHO. >=20 > We could actually achieve more than L2TP with simply IPsec with NAT > traversal (as outlined in a separate thread previously) -- but there > are some issues here to be investigated -- the biggest problem AFAICS > is the implementation status. But I'm not certain this is a feasible > approach in all the scenarios either... =3D> Exactly, also protecting traffic with IPsec was never a requirement that must be satisfied by all transition mechanisms. Hesham >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 From owner-v6ops@ops.ietf.org Tue Mar 16 18:00: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 SAA02433 for ; Tue, 16 Mar 2004 18:00:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3NWc-000OTb-P6 for v6ops-data@psg.com; Tue, 16 Mar 2004 22:59:06 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3NWR-000ORT-TP for v6ops@ops.ietf.org; Tue, 16 Mar 2004 22:58:56 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 22:53:46 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:34:49 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079426088452; Tue, 16 Mar 2004 08:34:48 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:34:47 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A0e-000ASn-Bc for v6ops-data@psg.com; Tue, 16 Mar 2004 08:33:12 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39zh-000AFS-Js for v6ops@ops.ietf.org; Tue, 16 Mar 2004 08:32:13 +0000 content-class: urn:content-classes:message Subject: RE: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] Date: Tue, 16 Mar 2004 03:32:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLLjWL+yIS1PyvTLWkJ0HMXmdMugAAST3A From: "Soliman Hesham" To: "Pekka Savola" Cc: "Florent Parent" , X-OriginalArrivalTime: 16 Mar 2004 08:34:47.0546 (UTC) FILETIME=[8A56BDA0:01C40B31] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > L2TP appears very heavyweight (even the spec is over 100 pages) for > this specific purpose, especially for some scenarios -- e.g., 3GPP > network for UE tunneling. =3D> I don't think the 3GPP deployments will use either L2TP or TSP. I think they'll want something like ISATAP if native connectivity is not available. >=20 > So, my personal gut feeling at this point is that L2TP is probably > applicable in the environments which already have the machinery in > place, but is a pain to set-up, and has significant complexity and > overhead which are probably drawbacks in a few scenarios at least. =3D> Other than the above scenario, I don't see any problems with it. Especially when the alternative is to develop a new protocol. The point is, it's already implemented by several vendors and deployed, why would we want to invent something=20 new in this space? "Too complex" is not a good reason IMHO. >=20 > We could actually achieve more than L2TP with simply IPsec with NAT > traversal (as outlined in a separate thread previously) -- but there > are some issues here to be investigated -- the biggest problem AFAICS > is the implementation status. But I'm not certain this is a feasible > approach in all the scenarios either... =3D> Exactly, also protecting traffic with IPsec was never a requirement that must be satisfied by all transition mechanisms. Hesham >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 From owner-v6ops@ops.ietf.org Tue Mar 16 18:01: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 SAA02474 for ; Tue, 16 Mar 2004 18:01:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3NX1-000OcU-Gh for v6ops-data@psg.com; Tue, 16 Mar 2004 22:59:31 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3NWS-000ORT-RA for v6ops@ops.ietf.org; Tue, 16 Mar 2004 22:58:56 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 22:53:48 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:34:49 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079426088452; Tue, 16 Mar 2004 08:34:48 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:34:47 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A0e-000ASn-Bc for v6ops-data@psg.com; Tue, 16 Mar 2004 08:33:12 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39zh-000AFS-Js for v6ops@ops.ietf.org; Tue, 16 Mar 2004 08:32:13 +0000 content-class: urn:content-classes:message Subject: RE: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] Date: Tue, 16 Mar 2004 03:32:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLLjWL+yIS1PyvTLWkJ0HMXmdMugAAST3A From: "Soliman Hesham" To: "Pekka Savola" Cc: "Florent Parent" , X-OriginalArrivalTime: 16 Mar 2004 08:34:47.0546 (UTC) FILETIME=[8A56BDA0:01C40B31] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > L2TP appears very heavyweight (even the spec is over 100 pages) for > this specific purpose, especially for some scenarios -- e.g., 3GPP > network for UE tunneling. =3D> I don't think the 3GPP deployments will use either L2TP or TSP. I think they'll want something like ISATAP if native connectivity is not available. >=20 > So, my personal gut feeling at this point is that L2TP is probably > applicable in the environments which already have the machinery in > place, but is a pain to set-up, and has significant complexity and > overhead which are probably drawbacks in a few scenarios at least. =3D> Other than the above scenario, I don't see any problems with it. Especially when the alternative is to develop a new protocol. The point is, it's already implemented by several vendors and deployed, why would we want to invent something=20 new in this space? "Too complex" is not a good reason IMHO. >=20 > We could actually achieve more than L2TP with simply IPsec with NAT > traversal (as outlined in a separate thread previously) -- but there > are some issues here to be investigated -- the biggest problem AFAICS > is the implementation status. But I'm not certain this is a feasible > approach in all the scenarios either... =3D> Exactly, also protecting traffic with IPsec was never a requirement that must be satisfied by all transition mechanisms. Hesham >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 From owner-v6ops@ops.ietf.org Tue Mar 16 18:01: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 SAA02509 for ; Tue, 16 Mar 2004 18:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3NWD-000ONb-WA for v6ops-data@psg.com; Tue, 16 Mar 2004 22:58:41 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3NVX-000OBf-AS for v6ops@ops.ietf.org; Tue, 16 Mar 2004 22:57:59 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 22:53:00 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:34:49 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079426088452; Tue, 16 Mar 2004 08:34:48 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:34:47 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A0e-000ASn-Bc for v6ops-data@psg.com; Tue, 16 Mar 2004 08:33:12 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B39zh-000AFS-Js for v6ops@ops.ietf.org; Tue, 16 Mar 2004 08:32:13 +0000 content-class: urn:content-classes:message Subject: RE: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] Date: Tue, 16 Mar 2004 03:32:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Using L2TP [RE: Need for TSP? RE: Tunneling scenarios and mechanisms evaluation] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLLjWL+yIS1PyvTLWkJ0HMXmdMugAAST3A From: "Soliman Hesham" To: "Pekka Savola" Cc: "Florent Parent" , X-OriginalArrivalTime: 16 Mar 2004 08:34:47.0546 (UTC) FILETIME=[8A56BDA0:01C40B31] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > L2TP appears very heavyweight (even the spec is over 100 pages) for > this specific purpose, especially for some scenarios -- e.g., 3GPP > network for UE tunneling. =3D> I don't think the 3GPP deployments will use either L2TP or TSP. I think they'll want something like ISATAP if native connectivity is not available. >=20 > So, my personal gut feeling at this point is that L2TP is probably > applicable in the environments which already have the machinery in > place, but is a pain to set-up, and has significant complexity and > overhead which are probably drawbacks in a few scenarios at least. =3D> Other than the above scenario, I don't see any problems with it. Especially when the alternative is to develop a new protocol. The point is, it's already implemented by several vendors and deployed, why would we want to invent something=20 new in this space? "Too complex" is not a good reason IMHO. >=20 > We could actually achieve more than L2TP with simply IPsec with NAT > traversal (as outlined in a separate thread previously) -- but there > are some issues here to be investigated -- the biggest problem AFAICS > is the implementation status. But I'm not certain this is a feasible > approach in all the scenarios either... =3D> Exactly, also protecting traffic with IPsec was never a requirement that must be satisfied by all transition mechanisms. Hesham >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 From owner-v6ops@ops.ietf.org Tue Mar 16 18:01:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02530 for ; Tue, 16 Mar 2004 18:01:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3NXI-000OmP-Qq for v6ops-data@psg.com; Tue, 16 Mar 2004 22:59:48 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3NWT-000ORT-KN for v6ops@ops.ietf.org; Tue, 16 Mar 2004 22:58:57 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 22:54:33 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:53:34 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:23:35 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079389414824; Mon, 15 Mar 2004 22:23:34 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:23:33 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B30S3-000HxI-30 for v6ops-data@psg.com; Mon, 15 Mar 2004 22:20:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B30Rs-000HvE-CN for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:20:40 +0000 Received: from consulintel02 ([212.76.240.58]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 35-md50000000409.tmp for ; Mon, 15 Mar 2004 23:25:56 +0100 Message-ID: <1b5801c40adc$50ae2750$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> Subject: Re: focussing energies Date: Mon, 15 Mar 2004 23:24:41 +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, 15 Mar 2004 23:25:56 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.76.240.58 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-OriginalArrivalTime: 15 Mar 2004 22:23:34.0340 (UTC) FILETIME=[27679840:01C40ADC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, and more may be coming from EU in the comming months ... ----- Original Message -----=20 From: "EricLKlein" To: Sent: Monday, March 15, 2004 8:03 PM Subject: Re: focussing energies > From: "Alain Durand" > > > > a) the best model is to get ISPs to deploy IPv6 to their customer. = No > > transition mechanism is better > > than anything else. Most ISPs won't do it unless there is strong > > motivation: > > - political mandate to do so > > - political incentive (like tax break) > > - customer asking for it > > The first two are outside the realm of IETF. The last one will only = be > > driven by the new applications > > requiring/working better with IPv6. Nothing here that this wg can do > > about. > > > Just keep in mind that some governments have mandated that all = services be > transitioned to IPv6 by fixed dates (off the top of my head I know = that > Japan and the EU have mandated dates) but I am not sure what the = penalties > are for failing to meet these mandates. > ********************************** 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 Mar 16 18:01: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 SAA02550 for ; Tue, 16 Mar 2004 18:01:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3NXh-000OyX-5O for v6ops-data@psg.com; Tue, 16 Mar 2004 23:00:13 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3NWU-000ORT-De for v6ops@ops.ietf.org; Tue, 16 Mar 2004 22:58:58 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 22:54:25 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:53:32 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:23:35 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079389414824; Mon, 15 Mar 2004 22:23:34 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:23:33 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B30S3-000HxI-30 for v6ops-data@psg.com; Mon, 15 Mar 2004 22:20:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B30Rs-000HvE-CN for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:20:40 +0000 Received: from consulintel02 ([212.76.240.58]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 35-md50000000409.tmp for ; Mon, 15 Mar 2004 23:25:56 +0100 Message-ID: <1b5801c40adc$50ae2750$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> Subject: Re: focussing energies Date: Mon, 15 Mar 2004 23:24:41 +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, 15 Mar 2004 23:25:56 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.76.240.58 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-OriginalArrivalTime: 15 Mar 2004 22:23:34.0340 (UTC) FILETIME=[27679840:01C40ADC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, and more may be coming from EU in the comming months ... ----- Original Message -----=20 From: "EricLKlein" To: Sent: Monday, March 15, 2004 8:03 PM Subject: Re: focussing energies > From: "Alain Durand" > > > > a) the best model is to get ISPs to deploy IPv6 to their customer. = No > > transition mechanism is better > > than anything else. Most ISPs won't do it unless there is strong > > motivation: > > - political mandate to do so > > - political incentive (like tax break) > > - customer asking for it > > The first two are outside the realm of IETF. The last one will only = be > > driven by the new applications > > requiring/working better with IPv6. Nothing here that this wg can do > > about. > > > Just keep in mind that some governments have mandated that all = services be > transitioned to IPv6 by fixed dates (off the top of my head I know = that > Japan and the EU have mandated dates) but I am not sure what the = penalties > are for failing to meet these mandates. > ********************************** 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 Mar 16 18:02: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 SAA02574 for ; Tue, 16 Mar 2004 18:02:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3NYL-000PKn-E7 for v6ops-data@psg.com; Tue, 16 Mar 2004 23:00:53 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3NY2-000P7D-H3 for v6ops@ops.ietf.org; Tue, 16 Mar 2004 23:00:34 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 22:54:30 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:53:33 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:23:35 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079389414824; Mon, 15 Mar 2004 22:23:34 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:23:33 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B30S3-000HxI-30 for v6ops-data@psg.com; Mon, 15 Mar 2004 22:20:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B30Rs-000HvE-CN for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:20:40 +0000 Received: from consulintel02 ([212.76.240.58]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 35-md50000000409.tmp for ; Mon, 15 Mar 2004 23:25:56 +0100 Message-ID: <1b5801c40adc$50ae2750$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> Subject: Re: focussing energies Date: Mon, 15 Mar 2004 23:24:41 +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, 15 Mar 2004 23:25:56 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.76.240.58 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-OriginalArrivalTime: 15 Mar 2004 22:23:34.0340 (UTC) FILETIME=[27679840:01C40ADC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, and more may be coming from EU in the comming months ... ----- Original Message -----=20 From: "EricLKlein" To: Sent: Monday, March 15, 2004 8:03 PM Subject: Re: focussing energies > From: "Alain Durand" > > > > a) the best model is to get ISPs to deploy IPv6 to their customer. = No > > transition mechanism is better > > than anything else. Most ISPs won't do it unless there is strong > > motivation: > > - political mandate to do so > > - political incentive (like tax break) > > - customer asking for it > > The first two are outside the realm of IETF. The last one will only = be > > driven by the new applications > > requiring/working better with IPv6. Nothing here that this wg can do > > about. > > > Just keep in mind that some governments have mandated that all = services be > transitioned to IPv6 by fixed dates (off the top of my head I know = that > Japan and the EU have mandated dates) but I am not sure what the = penalties > are for failing to meet these mandates. > ********************************** 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 Mar 16 18:02: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 SAA02635 for ; Tue, 16 Mar 2004 18:02:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3NYk-000PVB-54 for v6ops-data@psg.com; Tue, 16 Mar 2004 23:01:18 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3NY3-000P7D-EO for v6ops@ops.ietf.org; Tue, 16 Mar 2004 23:00:35 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 22:54:27 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:53:33 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:23:35 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079389414824; Mon, 15 Mar 2004 22:23:34 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:23:33 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B30S3-000HxI-30 for v6ops-data@psg.com; Mon, 15 Mar 2004 22:20:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B30Rs-000HvE-CN for v6ops@ops.ietf.org; Mon, 15 Mar 2004 22:20:40 +0000 Received: from consulintel02 ([212.76.240.58]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 35-md50000000409.tmp for ; Mon, 15 Mar 2004 23:25:56 +0100 Message-ID: <1b5801c40adc$50ae2750$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> Subject: Re: focussing energies Date: Mon, 15 Mar 2004 23:24:41 +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, 15 Mar 2004 23:25:56 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.76.240.58 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-OriginalArrivalTime: 15 Mar 2004 22:23:34.0340 (UTC) FILETIME=[27679840:01C40ADC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, and more may be coming from EU in the comming months ... ----- Original Message -----=20 From: "EricLKlein" To: Sent: Monday, March 15, 2004 8:03 PM Subject: Re: focussing energies > From: "Alain Durand" > > > > a) the best model is to get ISPs to deploy IPv6 to their customer. = No > > transition mechanism is better > > than anything else. Most ISPs won't do it unless there is strong > > motivation: > > - political mandate to do so > > - political incentive (like tax break) > > - customer asking for it > > The first two are outside the realm of IETF. The last one will only = be > > driven by the new applications > > requiring/working better with IPv6. Nothing here that this wg can do > > about. > > > Just keep in mind that some governments have mandated that all = services be > transitioned to IPv6 by fixed dates (off the top of my head I know = that > Japan and the EU have mandated dates) but I am not sure what the = penalties > are for failing to meet these mandates. > ********************************** 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 Mar 16 18:58: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 SAA06638 for ; Tue, 16 Mar 2004 18:58:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3OQu-000EuX-OV for v6ops-data@psg.com; Tue, 16 Mar 2004 23:57:16 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3OQE-000Eku-2Z for v6ops@ops.ietf.org; Tue, 16 Mar 2004 23:56:34 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 23:47:55 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 09:05:01 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079427900929; Tue, 16 Mar 2004 09:05:00 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 09:04:59 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ATW-000GFr-N5 for v6ops-data@psg.com; Tue, 16 Mar 2004 09:03:02 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B3ATM-000GEy-0V for v6ops@ops.ietf.org; Tue, 16 Mar 2004 09:02:52 +0000 Received: (qmail 29029 invoked by uid 417); 16 Mar 2004 09:02:51 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 16 Mar 2004 09:02:51 -0000 Received: from XPNERICK ([212.150.211.163]) by softhome.net with esmtp; Tue, 16 Mar 2004 02:02:50 -0700 Message-ID: <005c01c40b35$62da1c50$64051eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> <4056BA42.84D81796@zurich.ibm.com> Subject: Re: focussing energies Date: Tue, 16 Mar 2004 11:02:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Mar 2004 09:05:00.0241 (UTC) FILETIME=[C2CA0C10:01C40B35] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Brian E Carpenter" > The EU has certainly not mandated any such thing. They burnt their fingers > badly with OSI mandates 15 years ago, and are unlikely to repeat that > mistake. There is substantial EU support for IPv6 deployment, but that > is far from being a mandate. > > Brian Correct, they have initiated the eEurope 2005 program that is "recommends" deployment by 2005, with each country forming their own plan. It looks like the UK and France are pushing to be first with several others in close second (only Italy seems to be without a plan). Eric From owner-v6ops@ops.ietf.org Tue Mar 16 18:59: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 SAA06677 for ; Tue, 16 Mar 2004 18:59:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3OR9-000Ewk-64 for v6ops-data@psg.com; Tue, 16 Mar 2004 23:57:31 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3OQC-000Eku-ID for v6ops@ops.ietf.org; Tue, 16 Mar 2004 23:56:32 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 23:47:55 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 09:05:01 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079427900929; Tue, 16 Mar 2004 09:05:00 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 09:04:59 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ATW-000GFr-N5 for v6ops-data@psg.com; Tue, 16 Mar 2004 09:03:02 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B3ATM-000GEy-0V for v6ops@ops.ietf.org; Tue, 16 Mar 2004 09:02:52 +0000 Received: (qmail 29029 invoked by uid 417); 16 Mar 2004 09:02:51 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 16 Mar 2004 09:02:51 -0000 Received: from XPNERICK ([212.150.211.163]) by softhome.net with esmtp; Tue, 16 Mar 2004 02:02:50 -0700 Message-ID: <005c01c40b35$62da1c50$64051eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> <4056BA42.84D81796@zurich.ibm.com> Subject: Re: focussing energies Date: Tue, 16 Mar 2004 11:02:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Mar 2004 09:05:00.0241 (UTC) FILETIME=[C2CA0C10:01C40B35] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Brian E Carpenter" > The EU has certainly not mandated any such thing. They burnt their fingers > badly with OSI mandates 15 years ago, and are unlikely to repeat that > mistake. There is substantial EU support for IPv6 deployment, but that > is far from being a mandate. > > Brian Correct, they have initiated the eEurope 2005 program that is "recommends" deployment by 2005, with each country forming their own plan. It looks like the UK and France are pushing to be first with several others in close second (only Italy seems to be without a plan). Eric From owner-v6ops@ops.ietf.org Tue Mar 16 18:59: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 SAA06703 for ; Tue, 16 Mar 2004 18:59:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ORX-000F5a-Va for v6ops-data@psg.com; Tue, 16 Mar 2004 23:57:55 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3OQD-000Eku-AR for v6ops@ops.ietf.org; Tue, 16 Mar 2004 23:56:33 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 23:47:55 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 09:05:01 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079427900929; Tue, 16 Mar 2004 09:05:00 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 09:04:59 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ATW-000GFr-N5 for v6ops-data@psg.com; Tue, 16 Mar 2004 09:03:02 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B3ATM-000GEy-0V for v6ops@ops.ietf.org; Tue, 16 Mar 2004 09:02:52 +0000 Received: (qmail 29029 invoked by uid 417); 16 Mar 2004 09:02:51 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 16 Mar 2004 09:02:51 -0000 Received: from XPNERICK ([212.150.211.163]) by softhome.net with esmtp; Tue, 16 Mar 2004 02:02:50 -0700 Message-ID: <005c01c40b35$62da1c50$64051eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> <4056BA42.84D81796@zurich.ibm.com> Subject: Re: focussing energies Date: Tue, 16 Mar 2004 11:02:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Mar 2004 09:05:00.0241 (UTC) FILETIME=[C2CA0C10:01C40B35] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Brian E Carpenter" > The EU has certainly not mandated any such thing. They burnt their fingers > badly with OSI mandates 15 years ago, and are unlikely to repeat that > mistake. There is substantial EU support for IPv6 deployment, but that > is far from being a mandate. > > Brian Correct, they have initiated the eEurope 2005 program that is "recommends" deployment by 2005, with each country forming their own plan. It looks like the UK and France are pushing to be first with several others in close second (only Italy seems to be without a plan). Eric From owner-v6ops@ops.ietf.org Tue Mar 16 18:59: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 SAA06729 for ; Tue, 16 Mar 2004 18:59:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3OQM-000Eod-G2 for v6ops-data@psg.com; Tue, 16 Mar 2004 23:56:42 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3OQB-000Eku-G9 for v6ops@ops.ietf.org; Tue, 16 Mar 2004 23:56:31 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 23:47:56 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 09:05:01 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079427900929; Tue, 16 Mar 2004 09:05:00 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 09:04:59 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ATW-000GFr-N5 for v6ops-data@psg.com; Tue, 16 Mar 2004 09:03:02 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B3ATM-000GEy-0V for v6ops@ops.ietf.org; Tue, 16 Mar 2004 09:02:52 +0000 Received: (qmail 29029 invoked by uid 417); 16 Mar 2004 09:02:51 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 16 Mar 2004 09:02:51 -0000 Received: from XPNERICK ([212.150.211.163]) by softhome.net with esmtp; Tue, 16 Mar 2004 02:02:50 -0700 Message-ID: <005c01c40b35$62da1c50$64051eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> <4056BA42.84D81796@zurich.ibm.com> Subject: Re: focussing energies Date: Tue, 16 Mar 2004 11:02:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Mar 2004 09:05:00.0241 (UTC) FILETIME=[C2CA0C10:01C40B35] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Brian E Carpenter" > The EU has certainly not mandated any such thing. They burnt their fingers > badly with OSI mandates 15 years ago, and are unlikely to repeat that > mistake. There is substantial EU support for IPv6 deployment, but that > is far from being a mandate. > > Brian Correct, they have initiated the eEurope 2005 program that is "recommends" deployment by 2005, with each country forming their own plan. It looks like the UK and France are pushing to be first with several others in close second (only Italy seems to be without a plan). Eric From owner-v6ops@ops.ietf.org Tue Mar 16 19:14: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 TAA07405 for ; Tue, 16 Mar 2004 19:14:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3OfO-000J6m-Iy for v6ops-data@psg.com; Wed, 17 Mar 2004 00:12:14 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3OfD-000J4u-Fg for v6ops@ops.ietf.org; Wed, 17 Mar 2004 00:12:03 +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 35-md50000000459.tmp for ; Wed, 17 Mar 2004 01:17:18 +0100 Message-ID: <28c101c40bb5$089b5440$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> <4056BA42.84D81796@zurich.ibm.com> <005c01c40b35$62da1c50$64051eac@ttitelecom.com> Subject: Re: focussing energies Date: Wed, 17 Mar 2004 01:16:01 +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, Wed, 17 Mar 2004 01:17:18 +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.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 said, Spain is the faster mover ;-), then France, Germany, ... And Italy is working on a plan, that hopefully will be ready after = summer, maximum end of year time frame. Regards, Jordi ----- Original Message -----=20 From: "EricLKlein" To: Sent: Tuesday, March 16, 2004 10:02 AM Subject: Re: focussing energies >=20 > From: "Brian E Carpenter" > > The EU has certainly not mandated any such thing. They burnt their = fingers > > badly with OSI mandates 15 years ago, and are unlikely to repeat = that > > mistake. There is substantial EU support for IPv6 deployment, but = that > > is far from being a mandate. > > > > Brian >=20 > Correct, they have initiated the eEurope 2005 program that is = "recommends" > deployment by 2005, with each country forming their own plan. It looks = like > the UK and France are pushing to be first with several others in close > second (only Italy seems to be without a plan). > Eric > ********************************** 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 Mar 16 19:19:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07598 for ; Tue, 16 Mar 2004 19:19:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Okd-000K7l-LO for v6ops-data@psg.com; Wed, 17 Mar 2004 00:17:39 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Ojp-000K0b-2M for v6ops@ops.ietf.org; Wed, 17 Mar 2004 00:16:49 +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 i2H0GkWA008252; Tue, 16 Mar 2004 16:16:47 -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 i2H0GiQ26083; Wed, 17 Mar 2004 01:16:45 +0100 (MET) Date: Tue, 16 Mar 2004 16:16:48 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] To: Rob Austein Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20040313073945.4F79E18E0@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Terado is excessively complex for the case of a user who wants IPv6 > capability from an IPv4-only ISP and has the ability to replace the > NAT box. Yes, Terado could probably be used in this case instead of > 6to4; pigs also fly just fine, given sufficient thrust [RFC1925], but > that doesn't make either of these a good idea. Since I feel responsible for triggering Pekka's question let me try to explain myself. In a world with native, 6to4, and teredo we need to be concerned with the operational issues of gettting relays deployed to enable communication between the 3 different universes: - native to/from 6to4 - native to/from teredo - 6to4 to/from teredo Can we simplify the deployment of these so that we can reduce the likelyhood of ending up with a partitioned IPv6 Internet? A possibly way to simply this would be to have a single type of relay which can relay between all three. Using the same relay hopefully doesn't change how deployed 6to4 routers work. Erik From owner-v6ops@ops.ietf.org Tue Mar 16 19:50: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 TAA08876 for ; Tue, 16 Mar 2004 19:50:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3PEY-0001lH-JM for v6ops-data@psg.com; Wed, 17 Mar 2004 00:48:34 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3PE7-0001gD-W7 for v6ops@ops.ietf.org; Wed, 17 Mar 2004 00:48:08 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 00:46:34 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 06:13:30 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079417609344; Tue, 16 Mar 2004 06:13:29 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 06:13:28 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37nf-000GQt-5h for v6ops-data@psg.com; Tue, 16 Mar 2004 06:11:39 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B37nU-000GOR-8L for v6ops@ops.ietf.org; Tue, 16 Mar 2004 06:11:28 +0000 content-class: urn:content-classes:message Subject: RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Tue, 16 Mar 2004 01:11:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLGl7xw/0R0ldnR8y7kD7AZA5pGAAAc25g From: "Soliman Hesham" To: "Alain Durand" Cc: X-OriginalArrivalTime: 16 Mar 2004 06:13:28.0875 (UTC) FILETIME=[CCA837B0:01C40B1D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Alain Durand > Sent: Tuesday, March 16, 2004 12:39 AM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: v6 deployment in general [Re: tunnel broker=20 > deployment [RE: > Tunneling scenarios and mechanisms evaluation]] >=20 >=20 >=20 > On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote: > > > >> Stable addresses across reboot may be necessary. > >> I want to be able to build apps that take advantage of=20 > the large IPv6 > >> address space and consider that addresses are stable. > > > > So, you want to build a simple application. Don't we=20 > all.. :) But I > > don't think this is something we can guarantee even with native > > access. =20 =3D> Yes we can ! Why not?=20 ISPs just aren't offering static v4 addresses=20 > today=20 =3D> Yes they are ! You just pay more for them. Hesham From owner-v6ops@ops.ietf.org Tue Mar 16 19:50: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 TAA08922 for ; Tue, 16 Mar 2004 19:50:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3PEH-0001iV-To for v6ops-data@psg.com; Wed, 17 Mar 2004 00:48:17 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3PE7-0001gD-1E for v6ops@ops.ietf.org; Wed, 17 Mar 2004 00:48:07 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 00:46:33 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 06:13:29 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079417609344; Tue, 16 Mar 2004 06:13:29 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 06:13:28 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37nf-000GQt-5h for v6ops-data@psg.com; Tue, 16 Mar 2004 06:11:39 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B37nU-000GOR-8L for v6ops@ops.ietf.org; Tue, 16 Mar 2004 06:11:28 +0000 content-class: urn:content-classes:message Subject: RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Tue, 16 Mar 2004 01:11:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLGl7xw/0R0ldnR8y7kD7AZA5pGAAAc25g From: "Soliman Hesham" To: "Alain Durand" Cc: X-OriginalArrivalTime: 16 Mar 2004 06:13:28.0875 (UTC) FILETIME=[CCA837B0:01C40B1D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Alain Durand > Sent: Tuesday, March 16, 2004 12:39 AM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: v6 deployment in general [Re: tunnel broker=20 > deployment [RE: > Tunneling scenarios and mechanisms evaluation]] >=20 >=20 >=20 > On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote: > > > >> Stable addresses across reboot may be necessary. > >> I want to be able to build apps that take advantage of=20 > the large IPv6 > >> address space and consider that addresses are stable. > > > > So, you want to build a simple application. Don't we=20 > all.. :) But I > > don't think this is something we can guarantee even with native > > access. =20 =3D> Yes we can ! Why not?=20 ISPs just aren't offering static v4 addresses=20 > today=20 =3D> Yes they are ! You just pay more for them. Hesham From owner-v6ops@ops.ietf.org Tue Mar 16 19:50: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 TAA08940 for ; Tue, 16 Mar 2004 19:50:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3PEp-0001u6-E3 for v6ops-data@psg.com; Wed, 17 Mar 2004 00:48:51 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3PE8-0001gD-Ob for v6ops@ops.ietf.org; Wed, 17 Mar 2004 00:48:08 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 00:46:33 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 06:13:29 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079417609344; Tue, 16 Mar 2004 06:13:29 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 06:13:28 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37nf-000GQt-5h for v6ops-data@psg.com; Tue, 16 Mar 2004 06:11:39 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B37nU-000GOR-8L for v6ops@ops.ietf.org; Tue, 16 Mar 2004 06:11:28 +0000 content-class: urn:content-classes:message Subject: RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Tue, 16 Mar 2004 01:11:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLGl7xw/0R0ldnR8y7kD7AZA5pGAAAc25g From: "Soliman Hesham" To: "Alain Durand" Cc: X-OriginalArrivalTime: 16 Mar 2004 06:13:28.0875 (UTC) FILETIME=[CCA837B0:01C40B1D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Alain Durand > Sent: Tuesday, March 16, 2004 12:39 AM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: v6 deployment in general [Re: tunnel broker=20 > deployment [RE: > Tunneling scenarios and mechanisms evaluation]] >=20 >=20 >=20 > On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote: > > > >> Stable addresses across reboot may be necessary. > >> I want to be able to build apps that take advantage of=20 > the large IPv6 > >> address space and consider that addresses are stable. > > > > So, you want to build a simple application. Don't we=20 > all.. :) But I > > don't think this is something we can guarantee even with native > > access. =20 =3D> Yes we can ! Why not?=20 ISPs just aren't offering static v4 addresses=20 > today=20 =3D> Yes they are ! You just pay more for them. Hesham From owner-v6ops@ops.ietf.org Tue Mar 16 19:50: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 TAA08958 for ; Tue, 16 Mar 2004 19:50:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3PF6-0001xB-7L for v6ops-data@psg.com; Wed, 17 Mar 2004 00:49:08 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3PE9-0001gD-HP for v6ops@ops.ietf.org; Wed, 17 Mar 2004 00:48:09 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 00:46:34 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 06:13:30 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079417609344; Tue, 16 Mar 2004 06:13:29 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 06:13:28 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37nf-000GQt-5h for v6ops-data@psg.com; Tue, 16 Mar 2004 06:11:39 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B37nU-000GOR-8L for v6ops@ops.ietf.org; Tue, 16 Mar 2004 06:11:28 +0000 content-class: urn:content-classes:message Subject: RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Tue, 16 Mar 2004 01:11:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLGl7xw/0R0ldnR8y7kD7AZA5pGAAAc25g From: "Soliman Hesham" To: "Alain Durand" Cc: X-OriginalArrivalTime: 16 Mar 2004 06:13:28.0875 (UTC) FILETIME=[CCA837B0:01C40B1D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Alain Durand > Sent: Tuesday, March 16, 2004 12:39 AM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: v6 deployment in general [Re: tunnel broker=20 > deployment [RE: > Tunneling scenarios and mechanisms evaluation]] >=20 >=20 >=20 > On Mar 15, 2004, at 1:11 PM, Pekka Savola wrote: > > > >> Stable addresses across reboot may be necessary. > >> I want to be able to build apps that take advantage of=20 > the large IPv6 > >> address space and consider that addresses are stable. > > > > So, you want to build a simple application. Don't we=20 > all.. :) But I > > don't think this is something we can guarantee even with native > > access. =20 =3D> Yes we can ! Why not?=20 ISPs just aren't offering static v4 addresses=20 > today=20 =3D> Yes they are ! You just pay more for them. Hesham From owner-v6ops@ops.ietf.org Tue Mar 16 20:49: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 UAA12226 for ; Tue, 16 Mar 2004 20:49:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Q9D-000FzU-LG for v6ops-data@psg.com; Wed, 17 Mar 2004 01:47:07 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Q8v-000Fw7-0N for v6ops@ops.ietf.org; Wed, 17 Mar 2004 01:46:49 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:32:52 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:55:53 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:21 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079420780541; Tue, 16 Mar 2004 07:06:20 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:19 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B38cn-000OVO-QM for v6ops-data@psg.com; Tue, 16 Mar 2004 07:04:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B38cU-000OTA-IQ for v6ops@ops.ietf.org; Tue, 16 Mar 2004 07:04:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G747r14966; Tue, 16 Mar 2004 09:04:07 +0200 Date: Tue, 16 Mar 2004 09:04:07 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: focussing energies In-Reply-To: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 16 Mar 2004 07:06:19.0994 (UTC) FILETIME=[2ECA93A0:01C40B25] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a very important topic, but as it mostly goes to issues beyond our control, let's hope the thread does not get out of hand... On Mon, 15 Mar 2004, Alain Durand wrote: [...] > b) assisted tunneling works best in the scenario of an ISP willing > to offer IPv6 service but not ready yet to pay to deploy native > service. Those mechanisms, like tunnel broker, not only provide IPv6 > connectivity to the user, but also to help the ISP to jump start > IPv6 service to its customers at low cost. This is an area where > standardization from this wg could help a lot. > > c) when ISPs are not cooperating, there is the choice between two evils: > - fully automatic solutions, with their share of complexity, security > issues,... > - tunnel brokers operated by third parties, with possible sub-optimal > paths and complex set-up. [...] > The point I'm trying to make is that, IMHO, this wg should not spend to > much effort on c) > [i.e. there are implemented solution, let's document them and move on] > because: > 1) either IPv6 will take off and ISPs will start to cooperate, thus > we're back to case b) > 2) ISP still don't cooperate in the near future, meaning that they see > IPv6 as going nowhere, > so why should this wg and software vendors invest in complex > transition mechanisms? There is a middle ground here: ISPs not knowing when is the right take to start taking IPv6 seriously, and actually deploying it in a fast-track fashion. Most, especially those who look the red/black bottom line, have been just biding their time. They wait for the user demand or some push from any direction. This push could be achieved either through a) [which is outside of our scope] or through some v6 application getting popular. Barring outside agencies, we seem to need to work on enabling that "application landslide". More of that below. > and focus its energies on standardizing a > solution for b) My take on this is that being able to crack the chicken-and-egg problem is likely to take a while -- measured in years. We have to provide means for app developers to deploy v6 applications which might make IPv6 fly. In the general case, deploying v6 applications is only possible if there is sufficient IPv6 penetration, e.g., through the use of automatic transition mechanisms. (Otherwise the app developers just keep using IPv4 band-aids, and we never get to IPv6 in the first place -- and similarly, if an app is v4-capable, the users/vendors don't see the push to move to v6!) So, my personal gut feeling is that we need to tackle the first subcase of c), while the second is not useful for the mass deployment. If all goes well, this stage would be only short-term. b) is equally interesting; if coupled with a) in particular, the local ISPs might be keen to offer some IPv6 service. This is probably something that could be applicable for a slighly longer term than c) subcase 1). -- 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 Mar 16 20:50: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 UAA12251 for ; Tue, 16 Mar 2004 20:50:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Q9R-000G1B-DN for v6ops-data@psg.com; Wed, 17 Mar 2004 01:47:21 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Q8s-000Fw7-Ca for v6ops@ops.ietf.org; Wed, 17 Mar 2004 01:46:46 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:32:44 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:55:52 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:21 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079420780541; Tue, 16 Mar 2004 07:06:20 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:19 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B38cn-000OVO-QM for v6ops-data@psg.com; Tue, 16 Mar 2004 07:04:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B38cU-000OTA-IQ for v6ops@ops.ietf.org; Tue, 16 Mar 2004 07:04:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G747r14966; Tue, 16 Mar 2004 09:04:07 +0200 Date: Tue, 16 Mar 2004 09:04:07 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: focussing energies In-Reply-To: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 16 Mar 2004 07:06:19.0994 (UTC) FILETIME=[2ECA93A0:01C40B25] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a very important topic, but as it mostly goes to issues beyond our control, let's hope the thread does not get out of hand... On Mon, 15 Mar 2004, Alain Durand wrote: [...] > b) assisted tunneling works best in the scenario of an ISP willing > to offer IPv6 service but not ready yet to pay to deploy native > service. Those mechanisms, like tunnel broker, not only provide IPv6 > connectivity to the user, but also to help the ISP to jump start > IPv6 service to its customers at low cost. This is an area where > standardization from this wg could help a lot. > > c) when ISPs are not cooperating, there is the choice between two evils: > - fully automatic solutions, with their share of complexity, security > issues,... > - tunnel brokers operated by third parties, with possible sub-optimal > paths and complex set-up. [...] > The point I'm trying to make is that, IMHO, this wg should not spend to > much effort on c) > [i.e. there are implemented solution, let's document them and move on] > because: > 1) either IPv6 will take off and ISPs will start to cooperate, thus > we're back to case b) > 2) ISP still don't cooperate in the near future, meaning that they see > IPv6 as going nowhere, > so why should this wg and software vendors invest in complex > transition mechanisms? There is a middle ground here: ISPs not knowing when is the right take to start taking IPv6 seriously, and actually deploying it in a fast-track fashion. Most, especially those who look the red/black bottom line, have been just biding their time. They wait for the user demand or some push from any direction. This push could be achieved either through a) [which is outside of our scope] or through some v6 application getting popular. Barring outside agencies, we seem to need to work on enabling that "application landslide". More of that below. > and focus its energies on standardizing a > solution for b) My take on this is that being able to crack the chicken-and-egg problem is likely to take a while -- measured in years. We have to provide means for app developers to deploy v6 applications which might make IPv6 fly. In the general case, deploying v6 applications is only possible if there is sufficient IPv6 penetration, e.g., through the use of automatic transition mechanisms. (Otherwise the app developers just keep using IPv4 band-aids, and we never get to IPv6 in the first place -- and similarly, if an app is v4-capable, the users/vendors don't see the push to move to v6!) So, my personal gut feeling is that we need to tackle the first subcase of c), while the second is not useful for the mass deployment. If all goes well, this stage would be only short-term. b) is equally interesting; if coupled with a) in particular, the local ISPs might be keen to offer some IPv6 service. This is probably something that could be applicable for a slighly longer term than c) subcase 1). -- 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 Mar 16 20:50: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 UAA12288 for ; Tue, 16 Mar 2004 20:50:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3QAE-000GJa-Sx for v6ops-data@psg.com; Wed, 17 Mar 2004 01:48:10 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Q9g-000G6K-2X for v6ops@ops.ietf.org; Wed, 17 Mar 2004 01:47:36 +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 i2H1lNWA024535; Tue, 16 Mar 2004 17:47:24 -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 i2H1lLQ06091; Wed, 17 Mar 2004 02:47:21 +0100 (MET) Date: Tue, 16 Mar 2004 17:47:25 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt To: Pekka Savola Cc: Erik Nordmark , v6ops@ops.ietf.org, jonne.soininen@nokia.com, huitema@microsoft.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.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 Odd that only you seem to feel it is worth-while to comment on the need for proxynd; does nobody else care enough? First of all, I agree with you that removing reasons for NAT boxes needing to exist is something we should all do in the IETF; they make the network non-transparent and make it much harder to use some existing applications as well as creating/deploying new applications. Our disagreements seem to be whether ndproxy is an effective and useful means for doing this. > There is no stopping them if they want to get paid by the /128, of > course. I'm thinking this from the perspective of the ISP: what's the > simplest thing for them to deploy. It certainly doesn't seem to be > prefix delegation. RA-based advertisement on a point-to-point link > seems like an obvious means. I'd like to understand why DHCP prefix delegation isn't the simplest thing. Is this something you think is broken in our standards? Or in implementations of the standards? As an aside I find it odd that when the car is broken one would look for parts in the garage and kitchen to try to build a bicycle and use that instead of the car. Shouldn't we try to fix the car instead? > I'm not even sure how one would go about > giving the user a /128 in the first place. Easy. Whether using stateless or stateful address configuration, the ISP can send RA's without any on-link prefixes to the customer's box. This means no prefix is made available to the pt-pt link between the ISP's router and the customer's box. Hence the customer's box can only use the configured IPv6 address. > So, what I'm trying to see is the easiest way an ISP could deal with > "basic IPv6 usage case" (seems to be a /64 advertisement), which would > still encourage for the better service (/48 prefix delegation). The > case where the ISP absolutely wants just support one IP address is out > of scope here. I think RFC 3177 makes it clear that /48 should be the default. And if the car (DHCP prefix delegation) isn't working well, let's work on fixing it. > Another angle here is how are you going to deal with the case where > you have to have stacked gateways. E.g., the home gateway is doing > prefix delegation, and advertising /64's on its links. One of the > nodes at home is also a router, and behind it is a host. How do you > get v6 to that host behind the node? That's a very common scenario > today. I think it in most cases you could probably move that node to > the same link, but in some cases (e.g., mismatching media) it might > not be possible. But here you wander into the ZEROUTER domain which you've already said is out of scope. If I can discuss it with you using the word "rant" I'd do that. The solution you want in this space is something which allows plug&play of the devices that glue together the stacking. And since you don't know how the customer will plug things together, I think you must deal with loops. It is true that ndproxy as written can handle this, but it handles it by running IEEE 802.1D spanning tree protocol over all media - including non-IEEE 802 media - without specifying the details of how to carry IEEE 802 bridge PDUs over Avian Carriers, bluetooth, etc. That doesn't seem like the best approach. An approach like draft-perlman-zerouter-rbridge-00.txt, which builds a (very thin) overlay above the link layer between the rbridges look a lot more interesting to me; no need to carry bridge PDUs around etc. > > FWIW I take exception to you calling my explanation a "rant" - that > > is pretty close to an ad-hominum attack IMHO. Perhaps I should complain > > about your behavior to the WG co-chairs :-( > > Discussing the applicability of ND-proxy in ZEROUTER environments > appeared to be rather out of scope here.. because we're not discussing > applying it in those environments. So, the point of your anti- > ND-proxying note was IMHO well written, but not something that > belonged here -- rather maybe IPv6 WG which is working on ND-proxy. > Sorry if I called that "ranting"; I don't see that as a too negative > term myself -- perhaps because I feel I'm ranting a lot myself on some > occasions ;-) Apology accepted. But you seem to be talking about the ZEROUTER problem statement just as much as I am; the problem is having multiple different L2 technologies and wanting to plug those together without any explicit configuration of the boxes that connect the different L2 technologies together. > When you consider the applicability of SEND, it's probably highly > useful in environments like enterprise networks, server farms, etc. > (in case someone breaks in there and would start hijacking etc.), in > public WLAN (and other) environments where you deal with untrusted > users, and similar cases. > > It is probably not so necessary in a home network, or in the > point-to-point link between the ISP and a home network (where the ISP > can DoS/MitM/etc. you in any case). What about a home network which is also a free public WLAN? Given that WEP is not adding much security, having SEND would make it possible to open up 802.11 home networks for public access (apart from resource management issues). > So, my gut feeling is that people think -- ok, it's fine that ND-proxy > doesn't work with SEND. Let's not try to fix either SEND or ND-proxy. I'd sure like to have that question be asked in the SEND, IPV6, and V6OPS WGs - my capacity for reading peoples minds is quite limited. > The critical issue here, IMHO, is whether the hosts which are unaware > of whether ND-proxy is used or not can enable SEND or not. That is, > we wouldn't want the vendors to turn SEND off by default if that meant > the hosts would not work with ND-proxy. > > I don't think this is the case, but I could be wrong. I think this > depends on what kind of "triggers" SEND-capable nodes get from the > network before generating CGA addresses etc. -- do the e.g., wait for > the first SEND-enabled RA/NA, or whatever -- or do they always start > immediately (which might be a bit redundant until SEND is commonly > deployed). I don't see how this can be combined in a meaningful way. If a host has a default config to do SEND, then a packet from a ND proxy will look like an attacker (it will not look like an insecure node since the peer will have a CGA address AFAIK). > (But this is something that should probably go to either SEND or IPv6 > WG...) Agreed. > Discussing its applicability in ZEROUTER etc. enviroments is out of > scope, but ND-proxy, in simpler setups, could be in scope here. Could you specify the problem statement that covers "simpler setups" but where loops are somehow impossible to create by the consumer? > > We already have DHCP prefix delegation as a solution to the problem at > > the connection to the ISP. How many solutions do we need in this space? > > I believe this is a separate problem. You must be having a problem statement in mind which is tailored to ndproxy as the solution. Such narrow problem statements are not very helpful IMHO - we need to understand the problem space here. Erik From owner-v6ops@ops.ietf.org Tue Mar 16 20:50: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 UAA12324 for ; Tue, 16 Mar 2004 20:50:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Q9q-000GCg-9b for v6ops-data@psg.com; Wed, 17 Mar 2004 01:47:46 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Q8t-000Fw7-Fo for v6ops@ops.ietf.org; Wed, 17 Mar 2004 01:46:47 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:32:44 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:55:52 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:21 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079420780541; Tue, 16 Mar 2004 07:06:20 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:19 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B38cn-000OVO-QM for v6ops-data@psg.com; Tue, 16 Mar 2004 07:04:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B38cU-000OTA-IQ for v6ops@ops.ietf.org; Tue, 16 Mar 2004 07:04:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G747r14966; Tue, 16 Mar 2004 09:04:07 +0200 Date: Tue, 16 Mar 2004 09:04:07 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: focussing energies In-Reply-To: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 16 Mar 2004 07:06:19.0994 (UTC) FILETIME=[2ECA93A0:01C40B25] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a very important topic, but as it mostly goes to issues beyond our control, let's hope the thread does not get out of hand... On Mon, 15 Mar 2004, Alain Durand wrote: [...] > b) assisted tunneling works best in the scenario of an ISP willing > to offer IPv6 service but not ready yet to pay to deploy native > service. Those mechanisms, like tunnel broker, not only provide IPv6 > connectivity to the user, but also to help the ISP to jump start > IPv6 service to its customers at low cost. This is an area where > standardization from this wg could help a lot. > > c) when ISPs are not cooperating, there is the choice between two evils: > - fully automatic solutions, with their share of complexity, security > issues,... > - tunnel brokers operated by third parties, with possible sub-optimal > paths and complex set-up. [...] > The point I'm trying to make is that, IMHO, this wg should not spend to > much effort on c) > [i.e. there are implemented solution, let's document them and move on] > because: > 1) either IPv6 will take off and ISPs will start to cooperate, thus > we're back to case b) > 2) ISP still don't cooperate in the near future, meaning that they see > IPv6 as going nowhere, > so why should this wg and software vendors invest in complex > transition mechanisms? There is a middle ground here: ISPs not knowing when is the right take to start taking IPv6 seriously, and actually deploying it in a fast-track fashion. Most, especially those who look the red/black bottom line, have been just biding their time. They wait for the user demand or some push from any direction. This push could be achieved either through a) [which is outside of our scope] or through some v6 application getting popular. Barring outside agencies, we seem to need to work on enabling that "application landslide". More of that below. > and focus its energies on standardizing a > solution for b) My take on this is that being able to crack the chicken-and-egg problem is likely to take a while -- measured in years. We have to provide means for app developers to deploy v6 applications which might make IPv6 fly. In the general case, deploying v6 applications is only possible if there is sufficient IPv6 penetration, e.g., through the use of automatic transition mechanisms. (Otherwise the app developers just keep using IPv4 band-aids, and we never get to IPv6 in the first place -- and similarly, if an app is v4-capable, the users/vendors don't see the push to move to v6!) So, my personal gut feeling is that we need to tackle the first subcase of c), while the second is not useful for the mass deployment. If all goes well, this stage would be only short-term. b) is equally interesting; if coupled with a) in particular, the local ISPs might be keen to offer some IPv6 service. This is probably something that could be applicable for a slighly longer term than c) subcase 1). -- 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 Mar 16 20:50: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 UAA12346 for ; Tue, 16 Mar 2004 20:50:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3QAU-000GMK-Uy for v6ops-data@psg.com; Wed, 17 Mar 2004 01:48:26 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Q8u-000Fw7-85 for v6ops@ops.ietf.org; Wed, 17 Mar 2004 01:46:48 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:32:49 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:55:53 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:21 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079420780541; Tue, 16 Mar 2004 07:06:20 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:19 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B38cn-000OVO-QM for v6ops-data@psg.com; Tue, 16 Mar 2004 07:04:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B38cU-000OTA-IQ for v6ops@ops.ietf.org; Tue, 16 Mar 2004 07:04:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G747r14966; Tue, 16 Mar 2004 09:04:07 +0200 Date: Tue, 16 Mar 2004 09:04:07 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: focussing energies In-Reply-To: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 16 Mar 2004 07:06:19.0994 (UTC) FILETIME=[2ECA93A0:01C40B25] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a very important topic, but as it mostly goes to issues beyond our control, let's hope the thread does not get out of hand... On Mon, 15 Mar 2004, Alain Durand wrote: [...] > b) assisted tunneling works best in the scenario of an ISP willing > to offer IPv6 service but not ready yet to pay to deploy native > service. Those mechanisms, like tunnel broker, not only provide IPv6 > connectivity to the user, but also to help the ISP to jump start > IPv6 service to its customers at low cost. This is an area where > standardization from this wg could help a lot. > > c) when ISPs are not cooperating, there is the choice between two evils: > - fully automatic solutions, with their share of complexity, security > issues,... > - tunnel brokers operated by third parties, with possible sub-optimal > paths and complex set-up. [...] > The point I'm trying to make is that, IMHO, this wg should not spend to > much effort on c) > [i.e. there are implemented solution, let's document them and move on] > because: > 1) either IPv6 will take off and ISPs will start to cooperate, thus > we're back to case b) > 2) ISP still don't cooperate in the near future, meaning that they see > IPv6 as going nowhere, > so why should this wg and software vendors invest in complex > transition mechanisms? There is a middle ground here: ISPs not knowing when is the right take to start taking IPv6 seriously, and actually deploying it in a fast-track fashion. Most, especially those who look the red/black bottom line, have been just biding their time. They wait for the user demand or some push from any direction. This push could be achieved either through a) [which is outside of our scope] or through some v6 application getting popular. Barring outside agencies, we seem to need to work on enabling that "application landslide". More of that below. > and focus its energies on standardizing a > solution for b) My take on this is that being able to crack the chicken-and-egg problem is likely to take a while -- measured in years. We have to provide means for app developers to deploy v6 applications which might make IPv6 fly. In the general case, deploying v6 applications is only possible if there is sufficient IPv6 penetration, e.g., through the use of automatic transition mechanisms. (Otherwise the app developers just keep using IPv4 band-aids, and we never get to IPv6 in the first place -- and similarly, if an app is v4-capable, the users/vendors don't see the push to move to v6!) So, my personal gut feeling is that we need to tackle the first subcase of c), while the second is not useful for the mass deployment. If all goes well, this stage would be only short-term. b) is equally interesting; if coupled with a) in particular, the local ISPs might be keen to offer some IPv6 service. This is probably something that could be applicable for a slighly longer term than c) subcase 1). -- 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 Mar 16 22:27:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16331 for ; Tue, 16 Mar 2004 22:27:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Ret-000E1E-St for v6ops-data@psg.com; Wed, 17 Mar 2004 03:23:55 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3LvW-000OVL-9Z for v6ops@ops.ietf.org; Tue, 16 Mar 2004 21:16:42 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 16 Mar 2004 13:16:54 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Tue, 16 Mar 2004 13:16:59 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Mar 2004 13:16:41 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 16 Mar 2004 13:16:38 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 16 Mar 2004 13:17:04 -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); Tue, 16 Mar 2004 13:18:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Tue, 16 Mar 2004 13:16:40 -0800 Message-ID: Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] thread-index: AcQLmqvGrPhmcFS5Smq91DSLtnge1wAALnCQ From: "Christian Huitema" To: Cc: "Pekka Savola" , , "Erik Nordmark" X-OriginalArrivalTime: 16 Mar 2004 21:18:01.0349 (UTC) FILETIME=[29928B50:01C40B9C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > In practice the NAT mappings do not change and the Teredo address > > remains reasonably stable. >=20 > unless the global IPv4 address of the NAT box is changed every 24 hours > by the ISP... The Teredo code will detect that change, and inform the applications on the box that the local IP addresses have changed. This is supposed to trigger whatever update is necessary in the application, e.g., a dynamic DNS update.=20 Note that the ISP who go to the trouble of renumbering their subscribers' IPv4 address every 24 hours are very likely to renumber the IPv6 prefix every 24 hours, for the same reason.=20 -- Christian Huitema=20 From owner-v6ops@ops.ietf.org Tue Mar 16 22:43:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16778 for ; Tue, 16 Mar 2004 22:43:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3RwB-000HST-P8 for v6ops-data@psg.com; Wed, 17 Mar 2004 03:41:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Rw0-000HRH-Pp for v6ops@ops.ietf.org; Wed, 17 Mar 2004 03:41:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2H3fZc01683 for ; Wed, 17 Mar 2004 05:41:35 +0200 Date: Wed, 17 Mar 2004 05:41:35 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: list administratrivia: mail loop Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, As you may have noted there was a mail loop around, with mails getting sent back to the list; like: Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Q8u-000Fw7-85 for v6ops@ops.ietf.org; Wed, 17 Mar 2004 01:46:48 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:32:49 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 16 Mar 2004 17:55:53 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 07:06:21 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079420780541; Tue, 16 Mar 2004 07:06:20 +0000 I've unsubscribed a few persons temporarily and sent them an off-list heads-up on 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 Wed Mar 17 00:22: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 AAA20455 for ; Wed, 17 Mar 2004 00:22:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3TSw-000G3l-4t for v6ops-data@psg.com; Wed, 17 Mar 2004 05:19:42 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3TSl-000Fyd-GQ for v6ops@ops.ietf.org; Wed, 17 Mar 2004 05:19:31 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 16 Mar 2004 21:19:43 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Mar 2004 21:19:35 -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); Tue, 16 Mar 2004 21:19: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); Tue, 16 Mar 2004 21:18:27 -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); Tue, 16 Mar 2004 21:17:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] Date: Tue, 16 Mar 2004 21:19:27 -0800 Message-ID: Thread-Topic: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] thread-index: AcQLtjUj5ClRbm4CSWC2aQpdNibDWwAKFiEQ From: "Christian Huitema" To: "Erik Nordmark" , "Rob Austein" Cc: X-OriginalArrivalTime: 17 Mar 2004 05:17:38.0858 (UTC) FILETIME=[2A4DF0A0:01C40BDF] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Erik Nordmark > Sent: Tuesday, March 16, 2004 4:17 PM > To: Rob Austein > Cc: v6ops@ops.ietf.org > Subject: Re: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios > and mechanisms evaluation] >=20 > > Terado is excessively complex for the case of a user who wants IPv6 > > capability from an IPv4-only ISP and has the ability to replace the > > NAT box. Yes, Terado could probably be used in this case instead of > > 6to4; pigs also fly just fine, given sufficient thrust [RFC1925], but > > that doesn't make either of these a good idea. >=20 > Since I feel responsible for triggering Pekka's question let me > try to explain myself. >=20 > In a world with native, 6to4, and teredo we need to be concerned with > the operational issues of gettting relays deployed to enable communication > between the 3 different universes: > - native to/from 6to4 > - native to/from teredo > - 6to4 to/from teredo >=20 > Can we simplify the deployment of these so that we can reduce the > likelihood of ending up with a partitioned IPv6 Internet? In fact, Teredo will work if we have:=20 - native to/from 6to4 - native to/from Teredo You will simply get 6to4-native-Teredo. Note that we are also deploying host-based Teredo relay in the next Windows XP service pack. A dual-stack Windows host with either 6to4 or native connectivity will know how to send packets to Teredo peers using Teredo over UDP and IPv4, effectively offloading the network based Teredo relays. -- Christian Huitema=09 =20 From owner-v6ops@ops.ietf.org Wed Mar 17 00:22: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 AAA20473 for ; Wed, 17 Mar 2004 00:22:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3TTb-000GDY-Tx for v6ops-data@psg.com; Wed, 17 Mar 2004 05:20:23 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3TTQ-000GAk-EC for v6ops@ops.ietf.org; Wed, 17 Mar 2004 05:20:13 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2H5KBwr005107 for ; Tue, 16 Mar 2004 22:20:11 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUP00ADUG5M5J@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 16 Mar 2004 22:20:11 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUP002HOG5L76@mail.sun.net> for v6ops@ops.ietf.org; Tue, 16 Mar 2004 22:20:10 -0700 (MST) Date: Tue, 16 Mar 2004 21:20:06 -0800 From: Alain Durand Subject: Re: Re :automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] In-reply-to: <0HUM008MYW4WWR@ms3.samsung.com> To: soohong.park@samsung.com Cc: Pekka Savola , JORDI PALET MARTINEZ , "v6ops@ops.ietf.org " Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: multipart/alternative; boundary="Boundary_(ID_d6DPdDVjD2lDRjJiMnokvA)" References: <0HUM008MYW4WWR@ms3.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Boundary_(ID_d6DPdDVjD2lDRjJiMnokvA) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7BIT On Mar 15, 2004, at 12:12 PM, PARK SOO HONG wrote: > not sure these draft are related to this thread since I didn't follow > up this issue. Thank you for sharing those draft. > http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt The idea of using DHCP from the ISP to the CPE of the user to indicate a tunnel endpoint which act as tunnel server is interesting. However, I do not understand why you add a netmask to it. Also, sending more than one IP address for tunnel endpoint seems to add complexity for little gain, so I would favor a simpler version that advertise only one endpoint. > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ctep-opt > -00.txt This one makes me more perplex... This seems to me like a routing protocol that does not want to say its name. It somehow says: to reach IPv6 destination X, tunnel to Ipv6 destination Y I'm not sure I understand the purpose of this... Why doing routing with an IPv6 in Ipv6 encapsulation? btw, is it a DHC document or an individual submission? - Alain. --Boundary_(ID_d6DPdDVjD2lDRjJiMnokvA) Content-type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7BIT On Mar 15, 2004, at 12:12 PM, PARK SOO HONG wrote: Arialnot sure these draft are related to this thread since I didn't follow up this issue. Thank you for sharing those draft. Arial0000,0000,EEEEhttp://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt The idea of using DHCP from the ISP to the CPE of the user to indicate a tunnel endpoint which act as tunnel server is interesting. However, I do not understand why you add a netmask to it. Also, sending more than one IP address for tunnel endpoint seems to add complexity for little gain, so I would favor a simpler version that advertise only one endpoint. Arial0000,0000,EEEEhttp://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ctep-opt-00.txt This one makes me more perplex... This seems to me like a routing protocol that does not want to say its name. It somehow says: to reach IPv6 destination X, tunnel to Ipv6 destination Y I'm not sure I understand the purpose of this... Why doing routing with an IPv6 in Ipv6 encapsulation? btw, is it a DHC document or an individual submission? - Alain. --Boundary_(ID_d6DPdDVjD2lDRjJiMnokvA)-- From owner-v6ops@ops.ietf.org Wed Mar 17 07:51: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 HAA04098 for ; Wed, 17 Mar 2004 07:51:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3aRr-000PXk-Mp for v6ops-data@psg.com; Wed, 17 Mar 2004 12:47:03 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3aRg-000PVP-8J for v6ops@ops.ietf.org; Wed, 17 Mar 2004 12:46:52 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUQ00L010U2P1@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 17 Mar 2004 21:46:50 +0900 (KST) Received: from ep_ms3_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUQ0096T0U1A4@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 17 Mar 2004 21:46:49 +0900 (KST) Received: from ep_spt04 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUQ00GA40U1JN@ms3.samsung.com> for v6ops@ops.ietf.org; Wed, 17 Mar 2004 21:46:49 +0900 (KST) Content-return: prohibited Date: Wed, 17 Mar 2004 12:47:10 +0000 (GMT) From: PARK SOO HONG Subject: Re :Re: Re :automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation] X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2JpbA==?= =?windows-1252?B?ZSBQbGF0Zm9ybSBMYWI/UmVzZWFyY2hlcg==?= To: Alain Durand Cc: PARK SOO HONG , Pekka Savola , JORDI PALET MARTINEZ , "v6ops@ops.ietf.org " Reply-to: soohong.park@samsung.com Message-id: <0HUQ00GA50U1JN@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040317124645109@soohong.park X-MTR: 20040317124645109@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle


> http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt

The idea of using DHCP from the ISP to the CPE of the user to indicate
a tunnel endpoint which act as tunnel server is interesting.
However, I do not understand why you add a netmask to it.
Also, sending more than one IP address for tunnel endpoint seems
to add complexity for little gain, so I would favor a simpler version
that advertise only one endpoint.

 

Daniel> Yes, and I already received this point, so revised draft will be available soon

 


> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ctep-opt 
> -00.txt

This one makes me more perplex...
This seems to me like a routing protocol that does not want to say its  
name.
It somehow says: to reach IPv6 destination X, tunnel to Ipv6  
destination Y
I'm not sure I understand the purpose of this... Why doing routing with  
an IPv6 in Ipv6 encapsulation?

 

 

Daniel> This discussion happened at this dhc meeting too. So I am trying

to clarify this point with a revised draft soon... hope this helps

 


btw,  is it a DHC document or an individual submission?

 

Sure, it's a dhc work item so far...

 


    - Alain.


Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


From owner-v6ops@ops.ietf.org Wed Mar 17 08:19: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 IAA05261 for ; Wed, 17 Mar 2004 08:19:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3avM-0006rH-N5 for v6ops-data@psg.com; Wed, 17 Mar 2004 13:17:32 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3avA-0006p8-BC for v6ops@ops.ietf.org; Wed, 17 Mar 2004 13:17:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HDHHC08867; Wed, 17 Mar 2004 15:17:17 +0200 Date: Wed, 17 Mar 2004 15:17:17 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: Myung-Ki Shin Subject: Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, Below are my presonal comments/final edits to the the WG last call of the application transition document. semi-editorial/substantial -------------------------- necessary. However, these wrapper applications will actually probably have to do more than just perform a DNS lookup or figure out the literal IP address given. Thus, they may get complex, and ==> remove "probably" because this is a fact. :) There is an another consideration on IPv6 address literals in SMTP commands [RFC 2821], i.e., [IPv6: 2001:db8::1]. ==> reword to better flesh this out, e.g.: One should note that some applications may also represent IPv6 address literals differently; for example, SMTP [RFC 2821] uses [IPv6:2001:db8::1]. ... When selecting the destination address, applications usually ask a resolver for the destination IP address. The resolver returns a set of valid IP addresses from a hostname. Unless applications have a specific reason to select any particular destination address, they should just try each element in the list until the communication succeeds. ==> it seems that 5.4.1 does not mention the case of app selecting source address at all. Add a new paragraph like: In some cases, the application may need to specify its source address. Then the destination address selection process picks the best destination for the source address (instead of picking the best source address for the chosen destination address). Note that there may be an increase in complexity for IP-version independent applications which have to specify the source address (especially for client applications; fortunately, specifying the source address is not typically required), if it is not yet known which protocol will be used for communication. ... FIXME: Application framing has relations e.g. with Path MTU Discovery and application design which need to be analyzed better. ==> apparently in application layer framing, some considerations are still TBD. Flesh these out a bit, by replacing the paragraph with like: Note that the most optimal ALF depends on dynamic factors such as Path MTU or whether IPv4 or IPv6 is being used (due to different header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.). These have to be taken into consideration when implementing application framing. ... When possible, applications should store names, such as FQDNs, instead of storing addresses. ==> make this more generic, e.g. by rewording to: When possible, applications should store names such as FQDNs, or other protocol-independent identities instead of storing addresses. ... Another problem is/has been that IPv6 multicast does not yet have a standardized mechanism for traditional Any Source Multicast for Interdomain multicast. ==> this is no longer quite true (and wouldn't be a good way to state this in an RFC in any case), so reword slightly: Another problem has been that IPv6 multicast in Interdomain using the traditional Any Source Multicast has not been possible. ... IPv4 and IPv6, but it is likely that PIM-SSM will become more widely deployed in IPv6 due to its simpler architecture. ==> s/likely/possible/ -- it's difficult to predict the future! :) Both are from the basic socket extensions for IPv6. Since these functions are not protocol independent, we should write code for the different address families. A more detailed examples are described in appendix A. Note that inet_ntop()/inet_pton() lose the scope identifier (if used e.g. with link-local addresses) in the conversions, contrary to the getaddrinfo()/getnameinfo() functions. ==> As we want to achieve protocol-independence it's IMHO bad practice to not be clear what's the recommendation. I would: 1) describe the first paragraph above better, and possibly also 2) move the examples using getaddrinfo/getnameinfo from appendix A here. Below is my suggestion for the text if we're doing that: ====== 6.2.3 Binary/presentation format conversion In addition, we should consider the binary and presentation address format conversion APIs. The following functions convert network address structure in its presentation address format and vice versa: inet_ntop() inet_pton() Both are from the basic socket extensions for IPv6. However, these conversion functions are protocol-dependent; instead it is better to use getnameinfo()/getaddrinfo() as follows (inet_pton and inet_ntop equivalents are described in Appendix A). Conversion from network address structure to presentation format can be written: struct sockaddr_storage ss; char addrStr[INET6_ADDRSTRLEN]; char servStr[NI_MAXSERV]; int error; /* fill ss structure */ error = getnameinfo((struct sockaddr *)&ss, sizeof(ss), addrStr, sizeof(addrStr), servStr, sizeof(servStr), NI_NUMERICHOST); Conversions from presentation format to network address structure can be written as follows: struct addrinfo hints, *res; char addrStr[INET6_ADDRSTRLEN]; int error; /* fill addrStr buffer */ memset(&hints, 0, sizeof(hints)); hints.ai_family = AF_UNSPEC; error = getaddrinfo(addrStr, NULL, &hints, &res); if (error != 0) { /* handle getaddrinfo error */ } /* res->ai_addr contains the network address structure */ /* ... */ freeaddrinfo(res); --- -- -- - -- - Appendix A. Other Binary/Presentation Format Conversions Section 6.2.3 described the preferred way of performing binary/presentation format conversions; these can also be done using inet_pton() and inet_ntop() by writing protocol-dependent code. This is not recommended, but provided here for reference and comparison. Note that inet_ntop()/inet_pton() lose the scope identifier (if used e.g. with link-local addresses) in the conversions, contrary to the getaddrinfo()/getnameinfo() functions. A.1 Binary to Presentation Using inet_ntop() [[ text from A.1 up until "buffer length." ]] A.2 Presentation to Binary Using inet_pton() [[ similar ]] ====== Note: in the following examples, the socket() return value error handling could be simplied by substituting special checking of specific error numbers by always continuing on with the socket loop. Whether this is a better idea should be considered in more detail. ==> remote the "Whether" -sentence. 8. Security considerations A number of transition mechananisms define ways of constructing IPv6 adddresses using IPv4 addresses. There are a number of kinds of IPv4 addresses that require careful treatment due to know security issues [TRANSEC]. ==> this paragraph seems irrelevant to the application transition, so remove (also the reference). Instead, add something like: There are a number of security considerations with IPv6 transition but those are outside the scope of this memo. To ensure the availability and robustness of the service even when transitioning to IPv6, this memo described a number of ways to make applications more resistant to failures by cycling through addresses until a working one is found. Doing this properly is critical to avoid unavailability and loss of service. ... One particular point about application transition is how IPv4- mapped IPv6-addresses are handled. The use in the API can be seen as both a merit (easier application transition) and as a burden (difficulty in ensuring whether the use was legimate) [V6MAPPED]. This may have to be considered in more detail. ==> s/may have to/should/ ==> s/detail/detail when designing applications/ 9. Acknowledgements ==> I think it would be appropriate to acknowledge or refer to other work which has been made before or after starting this process; for example, [IP-GGF] and [AF-APP] are listed in references, but not referred in the body. Those could be good candidates for mentioning here. editorial --------- Case 1 : IPv4-only applications in a dual-stack node. IPv6 protocol is introduced in a node, but applications are not yet ported to IPv6. ==> s/to IPv6/to support IPv6/ 3. Problems with IPv6 application transition ==> in all of the section headings, use uppercasing except for certain small words; like: Problems with IPv6 Application Transition if a server application does not support IPv6 yet, but runs on a dual-stack machine for other IPv6 services, and this is listed with an AAAA record in the DNS, the client application will fail to ==> s/an AAAA/a AAAA/ (three different places) ==> s/this is/this host is/ In consequence, the application should request all IP addresses without address family constraints and try all the records returned from the DNS, in some order, until a working address is found. In particular, the application has to be able to handle all IP versions returned from the DNS. ==> here, one should add a reference to [DNSOPV6] which was already added to the references; either immediately after this paragraph, or with a statement like "This issue is discussed in more detail in [DNSOPV6]." When [BIA] or [BIS] is used, the problem described in section 3.2 becomes an issue --the IPv4 client in a [BIS]/[BIA] node trying to connect to an IPv4 server in a dual stack system-- arises. ==> remove "becomes an issue" or move it to replaces "arises" at the end. [BIS] or [BIA] does not work with all kinds of applications. In ==> s/does/do/ ? As we have seen in the previous section, applications should be ported to IPv6. The easiest way to port an IPv4 application is to substitute the old IPv4 API references with the new IPv6 one-to-one API mapping. ==> s/one-to-one API mapping/APIs with one-to-one mapping/ telnet6). This case is undesirable since maintaining two versions of the same source code per application, could be a difficult task. In addition, this approach would cause problems for the users when ==> remove "," before "could" Most implementations of dual stack allow IPv6-only applications to interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to IPv6 applications on a dual-stack node, reach their destination because their addresses are mapped to IPv6 ones using IPv4-mapped IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4 address x.y.z.w. ==> remove "," before "reach" This option could be useful if applications use new IPv6 features, such as flowlabel. ==> s/flowlabel/Flow Label/ The first method is not recommended because of a significant amount of problems associated with selecting the right applications.This scenario is described in sections 3.2 and 3.3. ==> s/This scenario is/ These problems are/ regarding IPv4-mapped IPv6 addresses on the wire are legitimate but disabling it internally breaks one transition mechanism for server apps which were originally written to bind and listen to a single socket using a wildcard address. This forces the software developer ==> s/bind/bind()/ ==> s/listen/listen()/ ==> s/apps/applications/ could be removed. Since we have only one version of each application, the source code will be typically easy to maintain and to modify, and there are no problems managing which application to select for which purpose. ==> s/purpose/communication/ Implementations typically by-default prefer IPv6 if the remote node and application support it. However, if IPv6 connections fail, dual applications will automatically try IPv4 ones. The resolver returns a list of valid addresses for the remote node and applications can iterate through all, first trying IPv6 ones, until connection succeeds. ==> s/dual applications/version-independent applications/ ==> s/, first trying IPv6 ones,/of them/ -- that was already stated. If the source code is written in a protocol-dependent way, the application will suport IPv4 and IPv6 explicitly using 2 separate ==> s/suport/support/ Note that there are some differences in bind() implementation, whether you can first bind to the IPv6 wildcard address, and then the IPv4. ==> reword: Note that there are some differences in bind() implementation, whether you can first bind to the IPv6, and then IPv4, wildcard addresses. ... - Network information storage: IP address data structures. The new structures must contain 128-bit IP addresses. The use of generic address structures, which can store any address family, is recommended. Sometimes special addresses are hard-coded in the application source; developers should pay attention to them in order to use the new address format. Some of these special IP addresses are: wildcard local, loopback and broadcast. IPv6 does not have the broadcast addresses, so applications can use multicast instead. ==> add new paragraph before "Sometimes" ? ==> s/source/source code/. - Network configuration options. They are used when configuring different communication models for Input/Output (I/O) operations (blocking/nonblocking, I/O multiplexing, etc) and should be translated to the IPv6 ones. ==> s/etc/etc./ Applications can use 1280 octets as a data length. [RFC 2460] specifies an IPv6 requirement that every link in the Internet have a Maximum Transmission Unit (MTU) of 1280 octets or greater. ==> reword to be more fluent: Applications can use 1280 octets as a data length: every IPv6 link must have a Maximum Transmission Unit (MTU) of 1280 octets or greater [RFC 2460]. ... - The same node can reach a destination host using different IP addresses. ==> expand this a bit by rewording: - The same node can reach a destination host using different IP addresses, possibly with a different protocol version. ... to peer systems with their own rendez-vous and discovery ==> remove "-". These can perform hostname/address and service name/port lookups, though the features can be turned off if desirable. getaddrinfo() can return multiple addresses, as below: ==> s/get/Get/ As well, it is not preferred to hardcode AF-dependent knowledge into the program. The construct like below should be avoided: ==> s/As well, it/It/ * - no server at all, if getaddrinfo supports IPv6, but the * system doesn't, and socket(AF_INET6, ...) exists with an * error. ==> s/exists/exits/ * - an IPv4 connection to the IPv4 destination, * - an IPv6 connection to an IPv6 destination, ==> s/the/an/ In a client code, when multiple addresses are returned from getaddrinfo(), we should try all of them until connection succeds. When a failure occurs with socket(), connect(), bind(), or some other function, go on to try the next address. ==> s/succeds/succeeds/ ==> s/go on/the code should go on/ [2893BIS] E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers," , February 2003, Work-in-progress. ==> move this to Informative, because it's not required reading, and could cause blockage 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 Wed Mar 17 08:55: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 IAA06600 for ; Wed, 17 Mar 2004 08:55:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3bSr-000FTG-Lu for v6ops-data@psg.com; Wed, 17 Mar 2004 13:52:09 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3bSV-000FOr-Cz for v6ops@ops.ietf.org; Wed, 17 Mar 2004 13:51:47 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B3bST-0006xE-00; Wed, 17 Mar 2004 13:51:46 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B3bST-0006x9-00; Wed, 17 Mar 2004 13:51:45 +0000 Received: from zurich.ibm.com (sig-9-145-173-122.de.ibm.com [9.145.173.122]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2HDphF65164; Wed, 17 Mar 2004 13:51:44 GMT Message-ID: <40583938.B4646164@zurich.ibm.com> Date: Wed, 17 Mar 2004 12:40:40 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Christian Huitema CC: Erik Nordmark , Rob Austein , v6ops@ops.ietf.org Subject: Re: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf > > Of Erik Nordmark > > Sent: Tuesday, March 16, 2004 4:17 PM > > To: Rob Austein > > Cc: v6ops@ops.ietf.org > > Subject: Re: 6to4 being replaced by Teredo only? [Re: Tunneling > scenarios > > and mechanisms evaluation] > > > > > Terado is excessively complex for the case of a user who wants IPv6 > > > capability from an IPv4-only ISP and has the ability to replace the > > > NAT box. Yes, Terado could probably be used in this case instead of > > > 6to4; pigs also fly just fine, given sufficient thrust [RFC1925], > but > > > that doesn't make either of these a good idea. > > > > Since I feel responsible for triggering Pekka's question let me > > try to explain myself. > > > > In a world with native, 6to4, and teredo we need to be concerned with > > the operational issues of gettting relays deployed to enable > communication > > between the 3 different universes: > > - native to/from 6to4 > > - native to/from teredo > > - 6to4 to/from teredo > > > > Can we simplify the deployment of these so that we can reduce the > > likelihood of ending up with a partitioned IPv6 Internet? > > In fact, Teredo will work if we have: > - native to/from 6to4 > - native to/from Teredo > You will simply get 6to4-native-Teredo. I fully agree. I think we should use native IPv6 as the "lowest common denominator" (although "lowest" is perhaps the wrong word :-). This seems to give a much better exit strategy from coexistence. Brian > > Note that we are also deploying host-based Teredo relay in the next > Windows XP service pack. A dual-stack Windows host with either 6to4 or > native connectivity will know how to send packets to Teredo peers using > Teredo over UDP and IPv4, effectively offloading the network based > Teredo relays. > > -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Mar 17 09:12: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 JAA07276 for ; Wed, 17 Mar 2004 09:12:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3bkD-000KS0-T4 for v6ops-data@psg.com; Wed, 17 Mar 2004 14:10:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3bju-000KN5-GN for v6ops@ops.ietf.org; Wed, 17 Mar 2004 14:09:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HE9jB09694; Wed, 17 Mar 2004 16:09:45 +0200 Date: Wed, 17 Mar 2004 16:09:45 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: SUMMARY: Tunneling scenarios and mechanisms evaluation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, As the list has had over 100 messages in less than a week, with a lot of subthreads, let me try to summarize what seem to have been the most important issues; let's hope I didn't forget or misinterpret anything. Some of these threads are still active, so this, like internet-drafts, is still work-in-progress :-) On the next steps and/or "action points": ----------------------------------------- [If you're interested in working on these contact the chairs and/or the persons already on the job..] - we should produce a draft describing different issues relating to "auto-discovery" of tunnel servers quickly. (e.g., anycasting, DNS, DHCP, etc.). This would help us to understand the problem space better. Jordi already promised to help with this, but more eyes & fast fingers might not hurt to get a first version out quickly (e.g., 1-2 weeks). - we should produce a draft describing how to select the "right" transition mechanism in all the cases, and what are the implications. That's less critical work, as we don't yet know which transition mechanisms we would have on the table, but useful as well. Jordi, at least, will be working on this, but more eyes & fast fingers would not hurt, obviously. - we need to figure out more exactly how widely proto-41 forwarding is supported, and precisely how. This could be done in a draft or a web page. This is rather important as well, if we want to make assumptions on the availability of the feature. I assume Jordi will be working on this. (Similarly, it's important to know about the different NAT types wrt. Teredo, but this is already in progress in MIDCOM WG it seems..) - we should produce a draft describing the issues relating to concerns about the division of IPv6 Internet into three: native, 6to4 and Teredo. This should also describe the approaches to mitigate the problems (e.g., the precise means of "local relay deployment"). This should form a basis for "cost analysis" people called for in the IETF59 meeting when there was no concensus for going forward with Teredo yet. This is critical work and the first draft should be out within a month at most. No volunteers at the moment -- contact the chairs. - we could produce a draft or some kind of list of "desirable features" if we were to design a new tunnel broker/setup protocol, i.e., try to combine the features of the current proposals, and try to look for what's missing and/or could be better. It is not yet clear whether we *want* to have such a "best of all worlds" protocol, but the thread showed some interest on trying to come up with something. This also should be produced quickly. Sign up if interested.. - we could try to produce a draft on "procedures/considerations" regarding how IPsec (+ NAT traversal) could be used for secure IPv6-in-IPv4 tunneling, even with dynamic/private IPv4 addresses. There are some issues to be fleshed out here, but probably no need for protocol modifications. It seems that it would be pretty important to have at least a rough draft out soonish, to evaluate the viability for e.g. the 3rd party tunnel or IPv6 VPN scenarios. Anyone interested..? There's already one severely overloaded person signed up, but we need more.. On mechanisms: -------------- - "Tunnel server management" (rather obvious) is something we should be working on. - Teredo seems to be a rather strict requirement in the absence of widespread support from ISPs. However, there is concern about how well it can be made to interoperate with native and 6to4 "clouds". - Deprecating 6to4 was suggested to simplify Teredo interactions, but there has been quite a bit of pushback for this; some felt in particular that 6to4 fulfilled an important role esp. when v4 gateway is upgraded. - ISATAP is mainly interesting in "sparse" deployment case, which can typically also be handled by a tunnel server. On the other hand, it has been proposased in "dense" deployment case as well, as a means to avoid dual-stack deployment. This is probably not where we want to go. But this is still open. - A question was raised whether L2TP could fit the "tunnel server" model. It's relatively simple if the architecture is already in place, but otherwise it may be too big a bother to set up. So, it's certainly going to be used, but whether it could be the only recommended solution for TB usage cases is another issue altogether. - In the mechanisms analysis, we should try to figure out, somehow, how to insert the "home gateway is doing the v6 tunneling" -case into the mechanism/scenarios evaluation. Also, does it need special consideration whether a mechanism gives you a /128, /64 or /48 prefix? On generic deployment issues: ----------------------------- - There were different views on whether we should be aiming for wide-spread deployment ("for John Doe") or for some specific interest groups (which could accummulate the critical mass for "IPv6 demand elsewhere"). However, it seems unlikely that a killer application would just appear before v6 *capability* has been sufficiently widely deployed -- otherwise the app designers will just stick to IPv4. Further, the process is likely to take multiple years at least, so we'd probably have to design the deployment for the "general mass", even though we want to retire the transition mechanisms (or at least some of them) when we get there. - discovering the existence of 3rd party tunnel brokers is difficult especially for non-technical people. Whether automatic this discovery is worth the effort is another question still. (But discovery of a local tunnel broker could be very useful.) - there are few incentives for ISPs to deploy tunnel broker service to 3rd parties -- especially if the service would be free, non-pilot -service, and would work well. - app designers can't assume, except if they are designing apps to be used in specific contexts only (e.g., enterprise networks) that IPv6 addresses will be static in the longer term (e.g., through reboots). - there was some debate on how much effort should be put to the case where the user's ISP keeps changing the user's v4 address "on-the-fly" intentionally. Can we/should we work around that, with realization that we're trying to "outsmart" the ISP who's trying all it can to enforce some kind of service policy? - there was some debate on how often home gateways/NAT boxes are being replaced. I argued for the timespan of at least (about) 3+ years, Jordi thought they would be changed much more often. This has an implication on whether we can get proto-41 support in the boxes, or how quickly the users would switch their NAT box to one supporting IPv6 if it was available. It seems that unless there is a strong killer app, this is dependent on the lifetime of the NAT box, they are not replaced just for fun. - there seemed to be at least some agreement that at least the 3rd party tunnel broker case was not particularly useful focus for efforts. -END- From owner-v6ops@ops.ietf.org Wed Mar 17 09:28: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 JAA07687 for ; Wed, 17 Mar 2004 09:28:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3bzy-000O0G-Dy for v6ops-data@psg.com; Wed, 17 Mar 2004 14:26:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3bzf-000Nwi-BV for v6ops@ops.ietf.org; Wed, 17 Mar 2004 14:26:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HEPxS09906; Wed, 17 Mar 2004 16:25:59 +0200 Date: Wed, 17 Mar 2004 16:25:59 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 16 Mar 2004, Erik Nordmark wrote: > > The problem is worse with transition mechanisms, especially the ones > > which traverse NATs, but the situation may improve as soon as we can > > get rid of them. In any case, such mechanisms can provide a stable > > as long as they can keep the NAT/IP mappings stable -- which is, for a > > properly designed application, maybe sufficient. > > I guess I don't understand what "such mechanisms" refer to above. > I don't know if mechanisms like Teredo can provide a stable IPv6 address > when the nat mappings change, but doing TB/UDP for nat traversal should be > able to provide stable IP addresses/prefixes in this case. The point is to keep the NAT (etc.) mappings open as long as possible so that they don't change -- and if they change, that'd be due to ISP trying to enforce the user to a specific policy (e.g., changing v4 addesses on the fly) -- and I'm not sure if it's worth trying to outsmart ISPs. Stupidity always wins, with the customer in even a bigger mess in the end.. :-/ As for what Christian said about Teredo reacting to these on-the-fly address changes -- the spec says nothing of the sort, but may be of course done by the implementation. Might not hurt to add some text on that specific 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 Wed Mar 17 09:53:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08942 for ; Wed, 17 Mar 2004 09:53:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3cO5-0004IQ-54 for v6ops-data@psg.com; Wed, 17 Mar 2004 14:51:17 +0000 Received: from [217.29.77.55] (helo=eolo.mix-it.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3cNt-0004EE-T0 for v6ops@ops.ietf.org; Wed, 17 Mar 2004 14:51:06 +0000 Received: from mix-it.net (pcraffaele.mix-it.net [217.29.77.12]) by eolo.mix-it.net (8.12.8/8.12.8) with ESMTP id i2HEp4ow012741 for ; Wed, 17 Mar 2004 15:51:04 +0100 Message-ID: <405865D2.9080505@mix-it.net> Date: Wed, 17 Mar 2004 15:50:58 +0100 From: "Raffaele D'Albenzio" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: focussing energies References: <5A46CCDE-76A8-11D8-9F71-00039376A6AA@sun.com> <001101c40ac0$2d6b45a0$04f7fea9@ttitelecom.com> <4056BA42.84D81796@zurich.ibm.com> <005c01c40b35$62da1c50$64051eac@ttitelecom.com> In-Reply-To: <005c01c40b35$62da1c50$64051eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Italy started working in order to have a plan in the next months. Bye, Raffaele. EricLKlein wrote: >From: "Brian E Carpenter" > > >>The EU has certainly not mandated any such thing. They burnt their fingers >>badly with OSI mandates 15 years ago, and are unlikely to repeat that >>mistake. There is substantial EU support for IPv6 deployment, but that >>is far from being a mandate. >> >> Brian >> >> > >Correct, they have initiated the eEurope 2005 program that is "recommends" >deployment by 2005, with each country forming their own plan. It looks like >the UK and France are pushing to be first with several others in close >second (only Italy seems to be without a plan). >Eric > > > > From owner-v6ops@ops.ietf.org Wed Mar 17 10:06:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09847 for ; Wed, 17 Mar 2004 10:06:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ca1-0007uj-DU for v6ops-data@psg.com; Wed, 17 Mar 2004 15:03:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3cZq-0007sZ-Iu for v6ops@ops.ietf.org; Wed, 17 Mar 2004 15:03:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HF3Pu10606 for ; Wed, 17 Mar 2004 17:03:25 +0200 Date: Wed, 17 Mar 2004 17:03:25 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: staying on track: no layer 10 please [Re: focussing energies] In-Reply-To: <405865D2.9080505@mix-it.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (co-chair hat on) (Not saying Raffaele or anyone else in particular, but in general..) Please -- let's try to kill this thread about government mandates, how far IPv6 deployment is in each country, etc. This could go on for long, and there are enough tough issues to discuss on the list already :-) Thanks! On Wed, 17 Mar 2004, Raffaele D'Albenzio wrote: > Italy started working in order to have a plan in the next months. > > Bye, > Raffaele. > > EricLKlein wrote: > > >From: "Brian E Carpenter" > > > > > >>The EU has certainly not mandated any such thing. They burnt their fingers > >>badly with OSI mandates 15 years ago, and are unlikely to repeat that > >>mistake. There is substantial EU support for IPv6 deployment, but that > >>is far from being a mandate. > >> > >> Brian > >> > >> > > > >Correct, they have initiated the eEurope 2005 program that is "recommends" > >deployment by 2005, with each country forming their own plan. It looks like > >the UK and France are pushing to be first with several others in close > >second (only Italy seems to be without a plan). > >Eric > > > > > > > > > > -- 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 Mar 17 10:41: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 KAA12837 for ; Wed, 17 Mar 2004 10:41:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3d96-000GFZ-4H for v6ops-data@psg.com; Wed, 17 Mar 2004 15:39:52 +0000 Received: from [24.203.190.116] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3d8v-000G8Q-8a for v6ops@ops.ietf.org; Wed, 17 Mar 2004 15:39:41 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i2HFdYIx016765; Wed, 17 Mar 2004 10:39:34 -0500 (EST) Date: Wed, 17 Mar 2004 10:39:34 -0500 From: Florent Parent To: Pekka Savola , Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Message-ID: <1301370000.1079537973@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.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Wednesday, March 17, 2004 16:25:59 +0200 Pekka Savola wrote: > On Tue, 16 Mar 2004, Erik Nordmark wrote: >> > The problem is worse with transition mechanisms, especially the ones >> > which traverse NATs, but the situation may improve as soon as we can >> > get rid of them. In any case, such mechanisms can provide a stable >> > as long as they can keep the NAT/IP mappings stable -- which is, for a >> > properly designed application, maybe sufficient. >> >> I guess I don't understand what "such mechanisms" refer to above. >> I don't know if mechanisms like Teredo can provide a stable IPv6 address >> when the nat mappings change, but doing TB/UDP for nat traversal should >> be able to provide stable IP addresses/prefixes in this case. > > The point is to keep the NAT (etc.) mappings open as long as possible > so that they don't change -- and if they change, that'd be due to ISP > trying to enforce the user to a specific policy (e.g., changing v4 > addesses on the fly) -- and I'm not sure if it's worth trying to > outsmart ISPs. Stupidity always wins, with the customer in even a > bigger mess in the end.. :-/ No one is trying to "outsmart" ISPs. To add to Erik comment: whether it's the nat mapping or whatever event occurs that changes your IPv4 address/port, the point is that TB + nat traversal can guarantee that the user will have a stable IPv6 address/prefix. The user IPv6 address is tied with the user identification, not to its (temporary) IPv4 address (and port number). This feature (stable IPv6 address/prefix) is an important benefit to the end-users, IMHO. Florent From owner-v6ops@ops.ietf.org Wed Mar 17 10:51: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 KAA13414 for ; Wed, 17 Mar 2004 10:51:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3dIg-000Ivr-9i for v6ops-data@psg.com; Wed, 17 Mar 2004 15:49:46 +0000 Received: from [24.203.190.116] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3dIV-000ItB-Ku for v6ops@ops.ietf.org; Wed, 17 Mar 2004 15:49:35 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i2HFnOIx001605; Wed, 17 Mar 2004 10:49:24 -0500 (EST) Date: Wed, 17 Mar 2004 10:49:24 -0500 From: Florent Parent To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: SUMMARY: Tunneling scenarios and mechanisms evaluation Message-ID: <1309280000.1079538564@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.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Wednesday, March 17, 2004 16:09:45 +0200 Pekka Savola wrote: > - there was some debate on how much effort should be put to the case > where the user's ISP keeps changing the user's v4 address > "on-the-fly" intentionally. Can we/should we work around that, > with realization that we're trying to "outsmart" the ISP who's > trying all it can to enforce some kind of service policy? > This is a bit too focused on ISP *intentionally* changing client IPv4 address. As I stated in another thread, I think this should be more about IPv6 address stability for the end-user. Florent From owner-v6ops@ops.ietf.org Wed Mar 17 11:12: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 LAA15520 for ; Wed, 17 Mar 2004 11:12:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3dbs-000OYl-MT for v6ops-data@psg.com; Wed, 17 Mar 2004 16:09:36 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3dbZ-000OUU-VR for v6ops@ops.ietf.org; Wed, 17 Mar 2004 16:09:18 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15402; Wed, 17 Mar 2004 11:09:14 -0500 (EST) Message-Id: <200403171609.LAA15402@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-02.txt Date: Wed, 17 Mar 2004 11:09:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.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 : Security Considerations for 6to4 Author(s) : P. Savola Filename : draft-ietf-v6ops-6to4-security-02.txt Pages : 39 Date : 2004-3-12 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-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-6to4-security-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-6to4-security-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-3-17113229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-6to4-security-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-security-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17113229.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Mar 17 11:13: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 LAA15844 for ; Wed, 17 Mar 2004 11:13:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ddy-000P3h-Rv for v6ops-data@psg.com; Wed, 17 Mar 2004 16:11:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3ddf-000OyR-KM for v6ops@ops.ietf.org; Wed, 17 Mar 2004 16:11:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HGB6i11771; Wed, 17 Mar 2004 18:11:06 +0200 Date: Wed, 17 Mar 2004 18:11:06 +0200 (EET) From: Pekka Savola To: Florent Parent cc: Erik Nordmark , Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] In-Reply-To: <1301370000.1079537973@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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 17 Mar 2004, Florent Parent wrote: > No one is trying to "outsmart" ISPs. To add to Erik comment: whether it's > the nat mapping or whatever event occurs that changes your IPv4 > address/port, the point is that TB + nat traversal can guarantee that the > user will have a stable IPv6 address/prefix. The user IPv6 address is tied > with the user identification, not to its (temporary) IPv4 address (and port > number). This feature (stable IPv6 address/prefix) is an important benefit > to the end-users, IMHO. There are tradeoffs to consider here, of course.. e.g.: - signalling overhead required when tying the v6 prefix to something else than IPv4 address, port or something like that. - user authentication overhead and management complexity. - the recovery time; i.e., how long does it take to detect something bad has happened? How long does it take to recover from this incident? Note that unless this is very quick, the result may actually be pretty close to IPv6 address changing (if e.g. the TCP connections get broken in the meantime) -- and all we might not actually gain much in the "ISP is changing the address on the fly" -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 Wed Mar 17 11:53: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 LAA20527 for ; Wed, 17 Mar 2004 11:53:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3eGg-0009rg-6z for v6ops-data@psg.com; Wed, 17 Mar 2004 16:51:46 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3eGV-0009i1-GB for v6ops@ops.ietf.org; Wed, 17 Mar 2004 16:51:35 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 08:51:29 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Mar 2004 08:51:39 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 08:51:28 -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); Wed, 17 Mar 2004 08:51:26 -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, 17 Mar 2004 08:51:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Wed, 17 Mar 2004 08:51:32 -0800 Message-ID: Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] thread-index: AcQMLH++CYNFdZtSSKas2vgOBFNLrgAE3tFQ From: "Christian Huitema" To: "Pekka Savola" , "Erik Nordmark" Cc: X-OriginalArrivalTime: 17 Mar 2004 16:51:39.0960 (UTC) FILETIME=[1E55DB80:01C40C40] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > As for what Christian said about Teredo reacting to these on-the-fly > address changes -- the spec says nothing of the sort, but may be of > course done by the implementation. Might not hurt to add some text on > that specific case. Check the section on maintenance. The client is supposed to regularly repeat the qualification procedure, and will detect a change in mappings. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Mar 17 12:39: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 MAA24561 for ; Wed, 17 Mar 2004 12:39:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ey2-000KeK-Tp for v6ops-data@psg.com; Wed, 17 Mar 2004 17:36:34 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3exr-000KcM-HZ for v6ops@ops.ietf.org; Wed, 17 Mar 2004 17:36:23 +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 D8BE38751; Wed, 17 Mar 2004 18:36:19 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Florent Parent'" Cc: "'Erik Nordmark'" , Subject: RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Wed, 17 Mar 2004 18:35:23 +0100 Organization: Unfix MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcQMOtHBYga3b0geRUGX33Ph0V+w/AACY+sQ Message-Id: <20040317173619.D8BE38751@purgatory.unfix.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Savola wrote: > On Wed, 17 Mar 2004, Florent Parent wrote: > > No one is trying to "outsmart" ISPs. To add to Erik comment: whether it's > > the nat mapping or whatever event occurs that changes your IPv4 > > address/port, the point is that TB + nat traversal can guarantee that the > > user will have a stable IPv6 address/prefix. The user IPv6 address is tied > > with the user identification, not to its (temporary) IPv4 address (and port > > number). This feature (stable IPv6 address/prefix) is an important benefit > > to the end-users, IMHO. > > There are tradeoffs to consider here, of course.. e.g.: > > - signalling overhead required when tying the v6 prefix to something > else than IPv4 address, port or something like that. > > - user authentication overhead and management complexity. What the solution I propose here and am already using is that we seperate the above into two sections: - Authorisation + Tunnel Configuration & Setup - Notifying to the Tunnel _Server_ of the current IP. The first part is currently handled by a non-drafted, but protocol as described on http://www.sixxs.net/tools/configservice/ We are working to moving this to TSP which should become the defacto standard in tunnel setup and configuration. The second part can and is being solved using draft-massar-v6ops-heartbeat-00 for proto-41 tunnels. Though this can also be applied to the IPv6-over-UDP protocol which Hexago is proposing in their TSP client, though the latter could better support the same kind of authentication the heartbeat protocol uses inside the UDP packet itself. Signalling overhead is about 200 bytes every heartbeat including IPv4 and UDP headers. This only has an advantage IMHO as it does have quite a good means of authentication, thus avoids spoofing. > - the recovery time; i.e., how long does it take to detect something > bad has happened? How long does it take to recover from this > incident? Note that unless this is very quick, the result may > actually be pretty close to IPv6 address changing (if e.g. the TCP > connections get broken in the meantime) -- and all we might not > actually gain much in the "ISP is changing the address on the fly" > -case. Changing of IP's can be notified immediatly to the POP using the heartbeat protocol. Typically the heartbeat is set to be sent every 60 seconds and/or when the client detects an IP change. OS's like Windows have API interfaces for this, unices mostly have to rely on the dhcpcd notifying the client. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFiMWwAAMicAn2lK6DQTC7DqFHQDcrxmOhT0 maxkAJ0TwFeYuYUP3AVrfO+t6jhZnJL1Sg== =hTFs -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Mar 17 17:17:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12071 for ; Wed, 17 Mar 2004 17:17:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3jJ1-000Mbp-Vy for v6ops-data@psg.com; Wed, 17 Mar 2004 22:14:31 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3jIr-000MZL-Ct for v6ops@ops.ietf.org; Wed, 17 Mar 2004 22:14:21 +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 i2HMEBWA021259; Wed, 17 Mar 2004 14:14:12 -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 i2HMEAQ09661; Wed, 17 Mar 2004 23:14:10 +0100 (MET) Date: Wed, 17 Mar 2004 14:14:13 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] 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.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 > > > The problem is worse with transition mechanisms, especially the ones > > > which traverse NATs, but the situation may improve as soon as we can > > > get rid of them. In any case, such mechanisms can provide a stable > > > as long as they can keep the NAT/IP mappings stable -- which is, for a > > > properly designed application, maybe sufficient. > > > > I guess I don't understand what "such mechanisms" refer to above. > > I don't know if mechanisms like Teredo can provide a stable IPv6 address > > when the nat mappings change, but doing TB/UDP for nat traversal should be > > able to provide stable IP addresses/prefixes in this case. > > The point is to keep the NAT (etc.) mappings open as long as possible > so that they don't change -- and if they change, that'd be due to ISP > trying to enforce the user to a specific policy (e.g., changing v4 > addesses on the fly) -- and I'm not sure if it's worth trying to > outsmart ISPs. Stupidity always wins, with the customer in even a > bigger mess in the end.. :-/ I still don't understand what you were trying to say in the first paragraph above. That paragraph doesn't take into account that one can build tunnel broker UDP tunneling schemes where the IPv6 address/prefix is stable when the NAT mapping changes. Was that paragraph only talking about Teredo? I read it as attempting to make a more general statement. On the third paragraph above, the NAT mapping might change for multiple reasons - one of them being the ISP forcing a new external IP address of the NAT box. Others being the NAT state timing out for various reasons (having lived 3 years behind a ISDN NAT box which looses the UDP port mapping when the ISDN line is dropped due to lack of traffic I've seen this). Erik One can build From owner-v6ops@ops.ietf.org Wed Mar 17 17:23: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 RAA12202 for ; Wed, 17 Mar 2004 17:23:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3jQ8-000OcH-Bv for v6ops-data@psg.com; Wed, 17 Mar 2004 22:21:52 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3jPx-000OZJ-IR for v6ops@ops.ietf.org; Wed, 17 Mar 2004 22:21:41 +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 i2HMLVWA025419; Wed, 17 Mar 2004 14:21:31 -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 i2HMLTQ09862; Wed, 17 Mar 2004 23:21:29 +0100 (MET) Date: Wed, 17 Mar 2004 14:21:32 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] To: Pekka Savola Cc: Florent Parent , 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.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 > There are tradeoffs to consider here, of course.. e.g.: > > - signalling overhead required when tying the v6 prefix to something > else than IPv4 address, port or something like that. > > - user authentication overhead and management complexity. > > - the recovery time; i.e., how long does it take to detect something > bad has happened? How long does it take to recover from this > incident? Note that unless this is very quick, the result may > actually be pretty close to IPv6 address changing (if e.g. the TCP > connections get broken in the meantime) -- and all we might not > actually gain much in the "ISP is changing the address on the fly" > -case. FWIW RFC 3519 seems to do a reasonable job of accomplishing this in the context of MIPv4. Refreshing the NAT mapping and detecting when it might have been changed can be done using ICMP echos to the tunnel server. When a failure is suspected the host can redo the registeration protocol. In genenral you can't detect the failure (mapping change) without sending and receiving packets, but that is just a case of quick failure recovery having a cost. So I think the rocket science has already been invented in RFC 3519 - just need to carry it to a different registration protocol. Erik From owner-v6ops@ops.ietf.org Wed Mar 17 17:26:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12313 for ; Wed, 17 Mar 2004 17:26:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3jSy-000PcZ-3H for v6ops-data@psg.com; Wed, 17 Mar 2004 22:24:48 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3jSf-000PTS-HR for v6ops@ops.ietf.org; Wed, 17 Mar 2004 22:24:29 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2HMOQp9016605; Wed, 17 Mar 2004 15:24:26 -0700 (MST) 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 i2HMOOQ09917; Wed, 17 Mar 2004 23:24:24 +0100 (MET) Date: Wed, 17 Mar 2004 14:24:27 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] To: Christian Huitema Cc: Erik Nordmark , Rob Austein , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > In fact, Teredo will work if we have: > - native to/from 6to4 > - native to/from Teredo > You will simply get 6to4-native-Teredo. > > Note that we are also deploying host-based Teredo relay in the next > Windows XP service pack. A dual-stack Windows host with either 6to4 or > native connectivity will know how to send packets to Teredo peers using > Teredo over UDP and IPv4, effectively offloading the network based > Teredo relays. That helps, but I think we also need to look at what can be done from IETF's perspective to "encourage" the deployment of the needed relays in the network. Erik From owner-v6ops@ops.ietf.org Thu Mar 18 00:28: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 AAA04296 for ; Thu, 18 Mar 2004 00:28:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3q1g-000MR2-OM for v6ops-data@psg.com; Thu, 18 Mar 2004 05:25:04 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3q1N-000MLa-Hc for v6ops@ops.ietf.org; Thu, 18 Mar 2004 05:24:45 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B721613397; Thu, 18 Mar 2004 00:24:44 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 00:24:44 -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: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Thu, 18 Mar 2004 00:24:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC0959@tayexc13.americas.cpqcorp.net> Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Thread-Index: AcQKuMZDIDSwCaJsSRW1oKFIlRUPFAB7+dsw From: "Bound, Jim" To: "Pekka Savola" , "Alain Durand" Cc: X-OriginalArrivalTime: 18 Mar 2004 05:24:44.0549 (UTC) FILETIME=[5272FB50:01C40CA9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Suggestions to take or leave Pekka: Just build specifications. Stop trying to define and mandate policy. Provide specs that inform of dangers. No one cares or listens to anytbing else from a standards body. 6to4 is a done deal. Security notes are good. Other mechansims are TBD with ISATAP and TSP leading behind 6to4. Manual config will always exist. More adoption will need more mechanisms for the tool box. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Monday, March 15, 2004 1:08 PM > To: Alain Durand > Cc: v6ops@ops.ietf.org > Subject: v6 deployment in general [Re: tunnel broker=20 > deployment [RE: Tunneling scenarios and mechanisms evaluation]] >=20 > On Mon, 15 Mar 2004, Alain Durand wrote: > > On Mar 14, 2004, at 11:23 PM, Pekka Savola wrote: > > >> This won't work with non-static IP's and getting the same prefix=20 > > >> back though, > > > > > > Sure; but this would probably be sufficient for the average John=20 > > > Doe, right? > >=20 > > What John Doe wants is irrelevant. What the IPv6=20 > applications require=20 > > is. >=20 > Also, on the other hand, IPv6 is rather irrelevant unless we=20 > can make the assumption that it will be used by John Doe. =20 > I.e., if we want to change the Internet, we need mass. Guys=20 > like John Doe are the key to obtaining that critical mass. >=20 > > Now, are you telling us that the potential IPv6 'killer=20 > apps' will not=20 > > need stable addresses? Making this assumption is very=20 > dangerous, IMHO. >=20 > I'm not saying that at all. I'm just saying that there are=20 > limits to the requirements for the duration of such=20 > addresses. For example, must John Doe's address stay stable=20 > if he shuts down his home PC, and leavs for 1-week trip to=20 > Tahiti, and then returns? =20 >=20 > It might not hurt, but the applications and the systems must=20 > IMHO be designed to deal with the situation that when they=20 > (re)start, the address might be different. I.e., the lifetime=20 > of the address does not > *necessarily* have to be longer than the lifetime of the=20 > application process. >=20 > On the other hand, as long as John Doe's home PC stays=20 > powered on and connected to the Internet, his address should=20 > stay stable. >=20 > > >> They found MSN, Yahoo, Google, KaZaA etc. Friends tell=20 > that is the=20 > > >> trick to it, if there is interresting enough content=20 > even 13 year=20 > > >> olds can configure it. > > > > > > Right. If we assume IPv6 would have killer applications=20 > which would=20 > > > make the users really eager to get it, sure -- everything would=20 > > > probably be simpler. But in the absence of such, we need=20 > to forward=20 > > > without them :-). > >=20 > > In the absence of such, what is the justification of IPv6? >=20 > I'd rather not open this can of worms, but leave it as an=20 > exercise of the reader. >=20 > As some have pointed out, we wouldn't have needed anything=20 > other than dual-stack (or the like) if we assumed that there=20 > will be strong killer app. When such app would appear,=20 > everyone would just upgrade, end of story, happy end. =20 > Unfortunately, IMHO, we need to move forward without making=20 > an assumption that such an app would miraculously appear;=20 > there will probably be ones (e.g., some p2p apps) which will=20 > help to drive the transition along, but again, this is=20 > something we should be counting on. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 00:30: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 AAA04360 for ; Thu, 18 Mar 2004 00:30:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3q4b-000NGY-5s for v6ops-data@psg.com; Thu, 18 Mar 2004 05:28:05 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3q4Q-000NEJ-8U for v6ops@ops.ietf.org; Thu, 18 Mar 2004 05:27:54 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 611BB1117B; Thu, 18 Mar 2004 00:27:53 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 00:27:53 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Approaches to use IPsec to secure v6-over-v4 tunnels Date: Thu, 18 Mar 2004 00:27:41 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC095B@tayexc13.americas.cpqcorp.net> Thread-Topic: Approaches to use IPsec to secure v6-over-v4 tunnels Thread-Index: AcQKvM5X3rl1HYioT0KwtOZ1M0waEAB7JVpA From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 18 Mar 2004 05:27:53.0183 (UTC) FILETIME=[C2E23EF0:01C40CA9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable We know how to do this we are doing it now on networks. We don't need = the IETF's help. Yes we have discussed this in depth. This is not the = issue. Issue is PKI. IETF should help with PKI. This is also in many = tutorials for admins being trained on IPv6 now. thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Monday, March 15, 2004 1:36 PM > To: v6ops@ops.ietf.org > Subject: Approaches to use IPsec to secure v6-over-v4 tunnels >=20 > Hi, >=20 > This issue has never been fully discussed before, so I=20 > thought about it a bit. >=20 > How do we set up secure v6-over-v4 tunnels (in the control &=20 > data plane security sense) for client <-> tunnel-server=20 > communication? How feasible is this? >=20 > I'm mostly interested in investigating whether IPsec could be=20 > used as a "transport mechanism" for traversing NATs or=20 > managing the "configured tunnel end-point setup" when the=20 > address is dynamic. =20 > IPsec may not be feasible in all the scenarios, but if IPsec=20 > could be used to simplify a number of different cases, and=20 > security would come in as bonus, I guess it wouldn't hurt.. :) >=20 > Basically, if you need data plane security (i.e., transport=20 > security), we go down to IPsec. Some control plane security=20 > might be manageable with ad-hoc mechanisms, such as=20 > hashing/keying methods or return routability. >=20 > Now, as for IPsec, there seem to be two ways to deal with this: >=20 > 1) IPv4 IPsec tunnel mode with IPv6 payload transform, resulting to: >=20 > (In both, I'm excluding the authentication part, or ESP padding.) >=20 > IPv4 header - 20 bytes > ESP header - 8 bytes > IPv6 header - 40 bytes > [IPv6 payload] >=20 > 2) IPv4 IPsec in transport mode with IPv4 transform, resulting to: >=20 > IPv4 header - 20 bytes [next-header set to 41: implicit v6-over-v4] > ESP header - 8 bytes > IPv6 header - 40 bytes > [IPv6 payload] >=20 > So, both the approaches seem to be equivalent. Only, the=20 > mixed-IP version transforms, 1), is only supported by a=20 > couple of implementations, while I think 2) is more commonplace. =20 >=20 > 2) would additionally require a co-located configured tunnel=20 > management to the IPsec endpoints. If the method was used=20 > with dynamic addresses, this could be quite problematic,=20 > unless IPsec provides some triggers to "reconfigure" the=20 > configured tunnel to accommodate new tunnel-endpoint. A=20 > different approach is having some kind of pseudo-interface=20 > which would not have these issues, but I think we already got=20 > out of those... :) >=20 > So, the overhead of about 28 bytes compared to 20 of=20 > v6-over-v4 tunnel in IP. >=20 > If you encapsulate IPsec in UDP for NAT traversal, that's 8=20 > additional bytes. That part is commonly implemented. Note=20 > that NAT traversal obviously only works when the other=20 > end-point has a public address. >=20 > It seems a simple deployment for client <-> tunnel-server=20 > communication could be obtained using either mechanism, with=20 > 2) requiring zero implementation, only (rather complex)=20 > management for the tunnel-end point (if=20 > dynamic/NAT-traversed) in configured tunneling. So, in a=20 > sense 1) gives you simplicity when =CDPsec has to deal with=20 > that particular dynamicity complexity. >=20 > Are there any flaws or missing points in this analysis? Thoughts? >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 00:30: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 AAA04382 for ; Thu, 18 Mar 2004 00:30:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3q5Q-000NXl-EP for v6ops-data@psg.com; Thu, 18 Mar 2004 05:28:56 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3q5F-000NU4-CI for v6ops@ops.ietf.org; Thu, 18 Mar 2004 05:28:45 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 6513D13627; Thu, 18 Mar 2004 00:28:44 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 00:28:44 -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: focussing energies Date: Thu, 18 Mar 2004 00:28:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC095C@tayexc13.americas.cpqcorp.net> Thread-Topic: focussing energies Thread-Index: AcQKwMpqIQ1bextYTyq4XqBshYqw2wB6QYYw From: "Bound, Jim" To: "EricLKlein" , X-OriginalArrivalTime: 18 Mar 2004 05:28:44.0031 (UTC) FILETIME=[E13108F0:01C40CA9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable U.S. DOD date is 2008. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of EricLKlein > Sent: Monday, March 15, 2004 2:03 PM > To: v6ops@ops.ietf.org > Subject: Re: focussing energies >=20 > From: "Alain Durand" > > > > a) the best model is to get ISPs to deploy IPv6 to their=20 > customer. No=20 > > transition mechanism is better than anything else. Most=20 > ISPs won't do=20 > > it unless there is strong > > motivation: > > - political mandate to do so > > - political incentive (like tax break) > > - customer asking for it > > The first two are outside the realm of IETF. The last one=20 > will only be=20 > > driven by the new applications requiring/working better with IPv6.=20 > > Nothing here that this wg can do about. > > > Just keep in mind that some governments have mandated that=20 > all services be transitioned to IPv6 by fixed dates (off the=20 > top of my head I know that Japan and the EU have mandated=20 > dates) but I am not sure what the penalties are for failing=20 > to meet these mandates. >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 00:40: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 AAA04837 for ; Thu, 18 Mar 2004 00:40:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3qEA-0000DH-KA for v6ops-data@psg.com; Thu, 18 Mar 2004 05:37:58 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3qE0-0000AL-8o for v6ops@ops.ietf.org; Thu, 18 Mar 2004 05:37:48 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 28CC712B6E; Thu, 18 Mar 2004 00:37:47 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 00:37:46 -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: focussing energies Date: Thu, 18 Mar 2004 00:37:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC095D@tayexc13.americas.cpqcorp.net> Thread-Topic: focussing energies Thread-Index: AcQLkz2jBpDhbVuwTU2I5oqyiUZXCQBFy8xQ From: "Bound, Jim" To: "JORDI PALET MARTINEZ" , X-OriginalArrivalTime: 18 Mar 2004 05:37:46.0984 (UTC) FILETIME=[24D11680:01C40CAB] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable the only mandate with real backing and serious is U.S. DOD and all 3G IMS must be IPv6. Separate an objective from a mandate. Two different things.=20 See NAv6TF response to the U.S. Department of Commerce IPv6 RFC too: http://www.nav6tf.org/slides/NAv6TF_Response_NTIA_IPv6_RFC_FINAL.pdf Being used in many forums now too. Note the industry is highly concerned about the IETF TTM to meet techcnology requirements. To much debae and not enough deliverables. Recall what happened to SC7 in ISO many years ago they were replaced by the IETF. IETF is replacable too for some functions one being Ipv6 Transition. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ > Sent: Tuesday, March 16, 2004 3:15 PM > To: v6ops@ops.ietf.org > Subject: Re: focussing energies >=20 > Well, certainly is not a "mandate" as such, but a high level=20 > recommendation (some times is more important and respected=20 > that a mandate), and a strong push and help at the same time. >=20 > By the way, Spain is the one that is leading, even stronger=20 > than France. Also I will say Germany is pushing now stronger than UK. >=20 > Regards, > Jordi >=20 > ----- Original Message ----- > From: "EricLKlein" > To: > Sent: Tuesday, March 16, 2004 10:02 AM > Subject: Re: focussing energies >=20 >=20 > >=20 > > From: "Brian E Carpenter" > > > The EU has certainly not mandated any such thing. They=20 > burnt their fingers > > > badly with OSI mandates 15 years ago, and are unlikely to=20 > repeat that > > > mistake. There is substantial EU support for IPv6=20 > deployment, but that > > > is far from being a mandate. > > > > > > Brian > >=20 > > Correct, they have initiated the eEurope 2005 program that=20 > is "recommends" > > deployment by 2005, with each country forming their own=20 > plan. It looks like > > the UK and France are pushing to be first with several=20 > others in close > > second (only Italy seems to be without a plan). > > Eric > >=20 >=20 > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be=20 > privileged or confidential. The information is intended to be=20 > for the use of the individual(s) named above. If you are not=20 > the intended recipient be aware that any disclosure, copying,=20 > distribution or use of the contents of this information,=20 > including attached files, is prohibited. >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 00:40:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04856 for ; Thu, 18 Mar 2004 00:40:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3qEr-0000Oy-C2 for v6ops-data@psg.com; Thu, 18 Mar 2004 05:38:41 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3qEg-0000Lz-Ga for v6ops@ops.ietf.org; Thu, 18 Mar 2004 05:38:30 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 06EEDAA1F; Thu, 18 Mar 2004 00:38:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 00:38:29 -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: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Thu, 18 Mar 2004 00:38:19 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC095E@tayexc13.americas.cpqcorp.net> Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Thread-Index: AcQLjukDQJ0FVDm4TGC+j/uH7e2haQABLMkgAEXkq3A= From: "Bound, Jim" To: "Christian Huitema" , "Erik Nordmark" , "Pekka Savola" Cc: "Alain Durand" , X-OriginalArrivalTime: 18 Mar 2004 05:38:29.0860 (UTC) FILETIME=[3E5F7240:01C40CAB] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This does not hold true with twice-nat correct? thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Christian Huitema > Sent: Tuesday, March 16, 2004 3:18 PM > To: Erik Nordmark; Pekka Savola > Cc: Alain Durand; v6ops@ops.ietf.org > Subject: RE: v6 deployment in general [Re: tunnel broker=20 > deployment [RE: Tunneling scenarios and mechanisms evaluation]] >=20 >=20 > > > The problem is worse with transition mechanisms,=20 > especially the ones=20 > > > which traverse NATs, but the situation may improve as=20 > soon as we can=20 > > > get rid of them. In any case, such mechanisms can=20 > provide a stable=20 > > > as long as they can keep the NAT/IP mappings stable --=20 > which is, for > a > > > properly designed application, maybe sufficient. > >=20 > > I guess I don't understand what "such mechanisms" refer to above. > > I don't know if mechanisms like Teredo can provide a stable IPv6 > address > > when the nat mappings change, but doing TB/UDP for nat traversal > should be > > able to provide stable IP addresses/prefixes in this case. >=20 > In practice the NAT mappings do not change and the Teredo=20 > address remains reasonably stable. >=20 > -- Christian Huitema >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 00:41:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04917 for ; Thu, 18 Mar 2004 00:41:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3qFj-0000cR-1T for v6ops-data@psg.com; Thu, 18 Mar 2004 05:39:35 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3qFY-0000Za-HL for v6ops@ops.ietf.org; Thu, 18 Mar 2004 05:39:24 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 146EEAC98; Thu, 18 Mar 2004 00:39:24 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 00:39:23 -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: focussing energies Date: Thu, 18 Mar 2004 00:39:14 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC095F@tayexc13.americas.cpqcorp.net> Thread-Topic: focussing energies Thread-Index: AcQLsq5Grj7SSEmwR4Cpr6ongrhpKwA+KUcQ From: "Bound, Jim" To: "EricLKlein" , X-OriginalArrivalTime: 18 Mar 2004 05:39:23.0883 (UTC) FILETIME=[5E92B3B0:01C40CAB] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable recommend is not the same as mandate. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of EricLKlein > Sent: Tuesday, March 16, 2004 4:02 AM > To: v6ops@ops.ietf.org > Subject: Re: focussing energies >=20 >=20 > From: "Brian E Carpenter" > > The EU has certainly not mandated any such thing. They burnt their=20 > > fingers badly with OSI mandates 15 years ago, and are unlikely to=20 > > repeat that mistake. There is substantial EU support for IPv6=20 > > deployment, but that is far from being a mandate. > > > > Brian >=20 > Correct, they have initiated the eEurope 2005 program that is=20 > "recommends" > deployment by 2005, with each country forming their own plan.=20 > It looks like the UK and France are pushing to be first with=20 > several others in close second (only Italy seems to be=20 > without a plan). > Eric >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 00:43:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05009 for ; Thu, 18 Mar 2004 00:43:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3qHF-0001GQ-Nj for v6ops-data@psg.com; Thu, 18 Mar 2004 05:41:09 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3qH4-0001D1-Ug for v6ops@ops.ietf.org; Thu, 18 Mar 2004 05:40:59 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6FA95F8C5; Thu, 18 Mar 2004 00:40:58 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 00:40: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: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] Date: Thu, 18 Mar 2004 00:40:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC0960@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 being replaced by Teredo only? [Re: Tunneling scenarios and mechanisms evaluation] Thread-Index: AcQLtZDBHUXH1LrVRdO2hYOrWO2JwgA9eNTw From: "Bound, Jim" To: "Erik Nordmark" , "Rob Austein" Cc: X-OriginalArrivalTime: 18 Mar 2004 05:40:58.0177 (UTC) FILETIME=[96C6D310:01C40CAB] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable then change the subject title and discussion. I don't think it is possible to do here in less than 4 years. By then it will be a moot point. =20 /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Erik Nordmark > Sent: Tuesday, March 16, 2004 7:17 PM > To: Rob Austein > Cc: v6ops@ops.ietf.org > Subject: Re: 6to4 being replaced by Teredo only? [Re:=20 > Tunneling scenarios and mechanisms evaluation] >=20 > > Terado is excessively complex for the case of a user who wants IPv6=20 > > capability from an IPv4-only ISP and has the ability to replace the=20 > > NAT box. Yes, Terado could probably be used in this case=20 > instead of=20 > > 6to4; pigs also fly just fine, given sufficient thrust=20 > [RFC1925], but=20 > > that doesn't make either of these a good idea. >=20 > Since I feel responsible for triggering Pekka's question let=20 > me try to explain myself. >=20 > In a world with native, 6to4, and teredo we need to be=20 > concerned with the operational issues of gettting relays=20 > deployed to enable communication between the 3 different universes: > - native to/from 6to4 > - native to/from teredo > - 6to4 to/from teredo >=20 > Can we simplify the deployment of these so that we can reduce=20 > the likelyhood of ending up with a partitioned IPv6 Internet? > A possibly way to simply this would be to have a single type=20 > of relay which can relay between all three. > Using the same relay hopefully doesn't change how deployed=20 > 6to4 routers work. >=20 > Erik >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 02:25:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23952 for ; Thu, 18 Mar 2004 02:25:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3rrP-000MSI-5V for v6ops-data@psg.com; Thu, 18 Mar 2004 07:22:35 +0000 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3rrD-000MRC-T4 for v6ops@ops.ietf.org; Thu, 18 Mar 2004 07:22:24 +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 i2I7cxfM023016; Thu, 18 Mar 2004 16:38:59 +0900 (KST) Message-ID: <40594E37.9711DF20@pec.etri.re.kr> Date: Thu, 18 Mar 2004 16:22:31 +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: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt(fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks, Pekka. I agree on all of your edits and suggestions. At this time, I'm preparing the revision (-02) of this draft. After publication (-02), I think this document will be ready to go to the IESG. Thanks, Myung-Ki. Pekka Savola wrote: > Hi, > > Below are my presonal comments/final edits to the the WG last call of > the application transition document. > > semi-editorial/substantial > -------------------------- > > necessary. However, these wrapper applications will actually > probably have to do more than just perform a DNS lookup or figure > out the literal IP address given. Thus, they may get complex, and > > ==> remove "probably" because this is a fact. :) > > There is an another consideration on IPv6 address literals in SMTP > commands [RFC 2821], i.e., [IPv6: 2001:db8::1]. > > ==> reword to better flesh this out, e.g.: > > One should note that some applications may also represent IPv6 address > literals differently; for example, SMTP [RFC 2821] uses > [IPv6:2001:db8::1]. > > ... > > When selecting the destination address, applications usually ask a > resolver for the destination IP address. The resolver returns a set > of valid IP addresses from a hostname. Unless applications have a > specific reason to select any particular destination address, they > should just try each element in the list until the communication > succeeds. > > ==> it seems that 5.4.1 does not mention the case of app selecting source > address at all. Add a new paragraph like: > > In some cases, the application may need to specify its source > address. Then the destination address selection process picks the best > destination for the source address (instead of picking the best source > address for the chosen destination address). Note that there may > be an increase in complexity for IP-version independent applications > which have to specify the source address (especially for client > applications; fortunately, specifying the source address is not > typically required), if it is not yet known which protocol will be used > for communication. > > ... > > FIXME: Application framing has relations e.g. with Path MTU > Discovery and application design which need to be analyzed better. > > ==> apparently in application layer framing, some considerations are still > TBD. Flesh these out a bit, by replacing the paragraph with like: > > Note that the most optimal ALF depends on dynamic factors such > as Path MTU or whether IPv4 or IPv6 is being used (due to different > header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.). > These have to be taken into consideration when implementing > application framing. > > ... > > When possible, applications should store names, such as FQDNs, > instead of storing addresses. > > ==> make this more generic, e.g. by rewording to: > > When possible, applications should store names such as FQDNs, > or other protocol-independent identities instead of storing > addresses. > > ... > > Another problem is/has been that IPv6 multicast does not yet have a > standardized mechanism for traditional Any Source Multicast for > Interdomain multicast. > > ==> this is no longer quite true (and wouldn't be a good way to state > this in an RFC in any case), so reword slightly: > > Another problem has been that IPv6 multicast in Interdomain using > the traditional Any Source Multicast has not been possible. > > ... > > IPv4 and IPv6, but it is likely that PIM-SSM will become more > widely deployed in IPv6 due to its simpler architecture. > > ==> s/likely/possible/ -- it's difficult to predict the future! :) > > Both are from the basic socket extensions for IPv6. Since these > functions are not protocol independent, we should write code for > the different address families. > > A more detailed examples are described in appendix A. > > Note that inet_ntop()/inet_pton() lose the scope identifier (if > used e.g. with link-local addresses) in the conversions, contrary > to the getaddrinfo()/getnameinfo() functions. > > ==> As we want to achieve protocol-independence it's IMHO bad practice to > not be clear what's the recommendation. I would: > > 1) describe the first paragraph above better, and possibly also > 2) move the examples using getaddrinfo/getnameinfo from appendix A here. > > Below is my suggestion for the text if we're doing that: > ====== > 6.2.3 Binary/presentation format conversion > > In addition, we should consider the binary and presentation address > format conversion APIs. The following functions convert network > address structure in its presentation address format and vice > versa: > > inet_ntop() > inet_pton() > > Both are from the basic socket extensions for IPv6. However, these > conversion functions are protocol-dependent; instead it is better to > use getnameinfo()/getaddrinfo() as follows (inet_pton and inet_ntop > equivalents are described in Appendix A). > > Conversion from network address structure to presentation format > can be written: > > struct sockaddr_storage ss; > char addrStr[INET6_ADDRSTRLEN]; > char servStr[NI_MAXSERV]; > int error; > > /* fill ss structure */ > > error = getnameinfo((struct sockaddr *)&ss, sizeof(ss), > addrStr, sizeof(addrStr), > servStr, sizeof(servStr), > NI_NUMERICHOST); > > Conversions from presentation format to network address structure > can be written as follows: > > struct addrinfo hints, *res; > char addrStr[INET6_ADDRSTRLEN]; > int error; > > /* fill addrStr buffer */ > > memset(&hints, 0, sizeof(hints)); > hints.ai_family = AF_UNSPEC; > > error = getaddrinfo(addrStr, NULL, &hints, &res); > if (error != 0) { > /* handle getaddrinfo error */ > } > > /* res->ai_addr contains the network address structure */ > /* ... */ > freeaddrinfo(res); > --- -- -- - -- - > > Appendix A. Other Binary/Presentation Format Conversions > > Section 6.2.3 described the preferred way of performing > binary/presentation format conversions; these can also be > done using inet_pton() and inet_ntop() by writing > protocol-dependent code. This is not recommended, but provided > here for reference and comparison. > > Note that inet_ntop()/inet_pton() lose the scope identifier (if > used e.g. with link-local addresses) in the conversions, contrary > to the getaddrinfo()/getnameinfo() functions. > > A.1 Binary to Presentation Using inet_ntop() > > [[ text from A.1 up until "buffer length." ]] > > A.2 Presentation to Binary Using inet_pton() > > [[ similar ]] > ====== > > Note: in the following examples, the socket() return value error > handling could be simplied by substituting special checking of > specific error numbers by always continuing on with the socket > loop. Whether this is a better idea should be considered in more > detail. > > ==> remote the "Whether" -sentence. > > 8. Security considerations > > A number of transition mechananisms define ways of constructing > IPv6 adddresses using IPv4 addresses. There are a number of kinds > of IPv4 addresses that require careful treatment due to know > security issues [TRANSEC]. > > ==> this paragraph seems irrelevant to the application transition, so > remove (also the reference). Instead, add something like: > > There are a number of security considerations with IPv6 transition > but those are outside the scope of this memo. > > To ensure the availability and robustness of the service even when > transitioning to IPv6, this memo described a number of ways to > make applications more resistant to failures by cycling through > addresses until a working one is found. Doing this properly is > critical to avoid unavailability and loss of service. > > ... > > One particular point about application transition is how IPv4- > mapped IPv6-addresses are handled. The use in the API can be seen > as both a merit (easier application transition) and as a burden > (difficulty in ensuring whether the use was legimate) [V6MAPPED]. > This may have to be considered in more detail. > > ==> s/may have to/should/ > ==> s/detail/detail when designing applications/ > > 9. Acknowledgements > > ==> I think it would be appropriate to acknowledge or refer to other work > which has been made before or after starting this process; for example, > [IP-GGF] and [AF-APP] are listed in references, but not referred in the > body. Those could be good candidates for mentioning here. > > editorial > --------- > > Case 1 : IPv4-only applications in a dual-stack node. > IPv6 protocol is introduced in a node, but > applications are not yet ported to IPv6. > > ==> s/to IPv6/to support IPv6/ > > 3. Problems with IPv6 application transition > > ==> in all of the section headings, use uppercasing except for certain small > words; like: Problems with IPv6 Application Transition > > if a server application does not support IPv6 yet, but runs on a > dual-stack machine for other IPv6 services, and this is listed with > an AAAA record in the DNS, the client application will fail to > > ==> s/an AAAA/a AAAA/ (three different places) > ==> s/this is/this host is/ > > In consequence, the application should request all IP addresses > without address family constraints and try all the records returned > from the DNS, in some order, until a working address is found. In > particular, the application has to be able to handle all IP > versions returned from the DNS. > > ==> here, one should add a reference to [DNSOPV6] which was already added to > the references; either immediately after this paragraph, or with a statement > like "This issue is discussed in more detail in [DNSOPV6]." > > When [BIA] or [BIS] is used, the problem described in section 3.2 > becomes an issue --the IPv4 client in a [BIS]/[BIA] node trying to > connect to an IPv4 server in a dual stack system-- arises. > > ==> remove "becomes an issue" or move it to replaces "arises" at the end. > > [BIS] or [BIA] does not work with all kinds of applications. In > > ==> s/does/do/ ? > > As we have seen in the previous section, applications should be > ported to IPv6. The easiest way to port an IPv4 application is to > substitute the old IPv4 API references with the new IPv6 one-to-one > API mapping. > > ==> s/one-to-one API mapping/APIs with one-to-one mapping/ > > telnet6). This case is undesirable since maintaining two versions > of the same source code per application, could be a difficult task. > In addition, this approach would cause problems for the users when > > ==> remove "," before "could" > > Most implementations of dual stack allow IPv6-only applications to > interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to > IPv6 applications on a dual-stack node, reach their destination > because their addresses are mapped to IPv6 ones using IPv4-mapped > IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4 > address x.y.z.w. > > ==> remove "," before "reach" > > This > option could be useful if applications use new IPv6 features, such > as flowlabel. > > ==> s/flowlabel/Flow Label/ > > The first method is not recommended because of a significant amount > of problems associated with selecting the right applications.This > scenario is described in sections 3.2 and 3.3. > > ==> s/This scenario is/ These problems are/ > > regarding IPv4-mapped IPv6 addresses on the wire are legitimate but > disabling it internally breaks one transition mechanism for server > apps which were originally written to bind and listen to a single > socket using a wildcard address. This forces the software developer > > ==> s/bind/bind()/ > ==> s/listen/listen()/ > ==> s/apps/applications/ > > could be removed. Since we have only one version of each > application, the source code will be typically easy to maintain and > to modify, and there are no problems managing which application to > select for which purpose. > > ==> s/purpose/communication/ > > Implementations typically by-default prefer IPv6 if the remote node > and application support it. However, if IPv6 connections fail, > dual applications will automatically try IPv4 ones. The resolver > returns a list of valid addresses for the remote node and > applications can iterate through all, first trying IPv6 ones, until > connection succeeds. > > ==> s/dual applications/version-independent applications/ > ==> s/, first trying IPv6 ones,/of them/ -- that was already stated. > > If the source code is written in a protocol-dependent way, the > application will suport IPv4 and IPv6 explicitly using 2 separate > > ==> s/suport/support/ > > Note that there are some differences in bind() > implementation, whether you can first bind to the IPv6 wildcard > address, and then the IPv4. > > ==> reword: > > Note that there are some differences in bind() > implementation, whether you can first bind to the IPv6, and > then IPv4, wildcard addresses. > > ... > > - Network information storage: IP address data structures. > The new structures must contain 128-bit IP addresses. The use of > generic address structures, which can store any address family, > is recommended. > Sometimes special addresses are hard-coded in the application > source; developers should pay attention to them in order to use > the new address format. Some of these special IP addresses are: > wildcard local, loopback and broadcast. IPv6 does not have > the broadcast addresses, so applications can use multicast > instead. > > ==> add new paragraph before "Sometimes" ? > > ==> s/source/source code/. > > - Network configuration options. > They are used when configuring different communication models > for Input/Output (I/O) operations (blocking/nonblocking, I/O > multiplexing, etc) and should be translated to the IPv6 ones. > > ==> s/etc/etc./ > > Applications can use 1280 octets as a data length. [RFC 2460] > specifies an IPv6 requirement that every link in the Internet have > a Maximum Transmission Unit (MTU) of 1280 octets or greater. > > ==> reword to be more fluent: > > Applications can use 1280 octets as a data length: every IPv6 > link must have a Maximum Transmission Unit (MTU) of 1280 octets > or greater [RFC 2460]. > > ... > > - The same node can reach a destination host using different > IP addresses. > > ==> expand this a bit by rewording: > > - The same node can reach a destination host using different > IP addresses, possibly with a different protocol version. > > ... > > to peer systems with their own rendez-vous and discovery > > ==> remove "-". > > These can perform hostname/address and service name/port lookups, > though the features can be turned off if desirable. getaddrinfo() > can return multiple addresses, as below: > > ==> s/get/Get/ > > As well, it is not preferred to hardcode AF-dependent knowledge > into the program. The construct like below should be avoided: > > ==> s/As well, it/It/ > > * - no server at all, if getaddrinfo supports IPv6, but the > * system doesn't, and socket(AF_INET6, ...) exists with an > * error. > > ==> s/exists/exits/ > > * - an IPv4 connection to the IPv4 destination, > * - an IPv6 connection to an IPv6 destination, > > ==> s/the/an/ > > In a client code, when multiple addresses are returned from > getaddrinfo(), we should try all of them until connection succeds. > When a failure occurs with socket(), connect(), bind(), or some > other function, go on to try the next address. > > ==> s/succeds/succeeds/ > ==> s/go on/the code should go on/ > > [2893BIS] E. Nordmark, "Transition Mechanisms for IPv6 Hosts and > Routers," , February 2003, > Work-in-progress. > > ==> move this to Informative, because it's not required reading, and could > cause blockage 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 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Myung-Ki Shin | mkshin@pec.etri.re.kr ETRI/PEC | 161 Kajong-Dong, Yusong-Gu, | Taejon, 305-350, Korea | Tel:+82-42-860-4847 | Fax:+82-42-861-5404 | http://pec.etri.re.kr/~mkshin/ From owner-v6ops@ops.ietf.org Thu Mar 18 03:02: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 DAA25712 for ; Thu, 18 Mar 2004 03:02:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3sR5-0003VL-HM for v6ops-data@psg.com; Thu, 18 Mar 2004 07:59:27 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B3sQu-0003Oc-Sx for v6ops@ops.ietf.org; Thu, 18 Mar 2004 07:59:16 +0000 Received: (qmail 14027 invoked by uid 417); 18 Mar 2004 07:59:16 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 18 Mar 2004 07:59:16 -0000 Received: from XPNERICK ([212.150.211.163]) by softhome.net with esmtp; Thu, 18 Mar 2004 00:59:13 -0700 Message-ID: <002a01c40cbe$d5c98590$64051eac@ttitelecom.com> From: "EricLKlein" To: "Bound, Jim" , "JORDI PALET MARTINEZ" , v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B05DC095D@tayexc13.americas.cpqcorp.net> Subject: Re: focussing energies Date: Thu, 18 Mar 2004 09:58:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Bound, Jim" > the only mandate with real backing and serious is U.S. DOD and all 3G > IMS must be IPv6. Separate an objective from a mandate. Two different > things. IMHO I tend to think that the "killer app" that we keep looking for will work out to be 3G or other wireless network, as there is a need for a single carrier to carry many thousands (or millions if you look at the AT&T Wireless plus Cingular network) so here is where it will happen first. From owner-v6ops@ops.ietf.org Thu Mar 18 05:00:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00232 for ; Thu, 18 Mar 2004 05:00:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3uH4-000N1c-SD for v6ops-data@psg.com; Thu, 18 Mar 2004 09:57:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3uGt-000N0A-Cx for v6ops@ops.ietf.org; Thu, 18 Mar 2004 09:57:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2I9usp28107; Thu, 18 Mar 2004 11:56:55 +0200 Date: Thu, 18 Mar 2004 11:56:54 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: RE: Approaches to use IPsec to secure v6-over-v4 tunnels In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B05DC095B@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 18 Mar 2004, Bound, Jim wrote: > We know how to do this we are doing it now on networks. We don't > need the IETF's help. Yes we have discussed this in depth. This is > not the issue. Issue is PKI. IETF should help with PKI. This is > also in many tutorials for admins being trained on IPv6 now. Could you clarify what you mean with "We" here? :) Even if you are bright enough to figure it on your own, that doesn't mean everyone else is -- there seems to be ample evidence to the contrary :). So, at least an Internet-Draft would be useful, to identify the issues concerned. Whether an Informational RFC would be useful or not would remain to be seen. I also brought this up in the security area, and they certainly thought this is interesting -- and non-trivial. -- 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 Mar 18 05:09: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 FAA00621 for ; Thu, 18 Mar 2004 05:09:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3uRV-000Ot1-U5 for v6ops-data@psg.com; Thu, 18 Mar 2004 10:08:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3uRK-000Os0-J9 for v6ops@ops.ietf.org; Thu, 18 Mar 2004 10:07:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IA7l928316; Thu, 18 Mar 2004 12:07:47 +0200 Date: Thu, 18 Mar 2004 12:07:47 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: keeping NAT mappings stable [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 17 Mar 2004, Erik Nordmark wrote: > > > > The problem is worse with transition mechanisms, especially the ones > > > > which traverse NATs, but the situation may improve as soon as we can > > > > get rid of them. In any case, such mechanisms can provide a stable > > > > as long as they can keep the NAT/IP mappings stable -- which is, for a > > > > properly designed application, maybe sufficient. > > > > > > I guess I don't understand what "such mechanisms" refer to above. > > > I don't know if mechanisms like Teredo can provide a stable IPv6 address > > > when the nat mappings change, but doing TB/UDP for nat traversal should be > > > able to provide stable IP addresses/prefixes in this case. > > > > The point is to keep the NAT (etc.) mappings open as long as possible > > so that they don't change -- and if they change, that'd be due to ISP > > trying to enforce the user to a specific policy (e.g., changing v4 > > addesses on the fly) -- and I'm not sure if it's worth trying to > > outsmart ISPs. Stupidity always wins, with the customer in even a > > bigger mess in the end.. :-/ > > I still don't understand what you were trying to say in the first paragraph > above. > That paragraph doesn't take into account that one can build > tunnel broker UDP tunneling schemes where the IPv6 address/prefix > is stable when the NAT mapping changes. Of course -- but such technology will have additional complexity in terms of signalling (the most important one: user must be authenticated/identified -- in the case of more or less anonymous service, this may not be feasible). The point is that there can be mechanisms which tie the stability of v6 prefix to the stability of the v4 address [/port]. This seems to be sufficient for a less advanced user, for a transition mechanism. The v6 prefix stability irrespective of v4 address[/port] would be an optional, additional signalling method, to be used where user authentication is feasible. > Was that paragraph only talking about Teredo? I read it as attempting to > make a more general statement. Teredo is currently an example of this; STEP in ad-hoc mode is another. This is a more generic issue, especially if we want to ensure zero-configured IPv6 deployment in ISPs' non-upgraded access networks. > On the third paragraph above, the NAT mapping might change for > multiple reasons - one of them being the ISP forcing a new external IP > address of the NAT box. Others being the NAT state timing out for various > reasons (having lived 3 years behind a ISDN NAT box which looses the UDP > port mapping when the ISDN line is dropped due to lack of traffic > I've seen this). Of course; the point is avoiding loosing the mapping. But if it gets lost, you either renumber (v6 and possibly v4) or reconfigure the tunnel end-point (if supported and possible). Depending on quickly you are able to detect this, you may or may not be able to prevent v6 TCP connections failing during the failure period. -- 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 Mar 18 05:21: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 FAA01029 for ; Thu, 18 Mar 2004 05:21:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3udK-0000Pc-B5 for v6ops-data@psg.com; Thu, 18 Mar 2004 10:20:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3ud9-0000Ob-4t for v6ops@ops.ietf.org; Thu, 18 Mar 2004 10:20:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IAJvX28503; Thu, 18 Mar 2004 12:19:57 +0200 Date: Thu, 18 Mar 2004 12:19:57 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Florent Parent , Subject: stable vs address-derived v6 prefix [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 17 Mar 2004, Erik Nordmark wrote: > > There are tradeoffs to consider here, of course.. e.g.: > > > > - signalling overhead required when tying the v6 prefix to something > > else than IPv4 address, port or something like that. > > > > - user authentication overhead and management complexity. > > > > - the recovery time; i.e., how long does it take to detect something > > bad has happened? How long does it take to recover from this > > incident? Note that unless this is very quick, the result may > > actually be pretty close to IPv6 address changing (if e.g. the TCP > > connections get broken in the meantime) -- and all we might not > > actually gain much in the "ISP is changing the address on the fly" > > -case. > > FWIW RFC 3519 seems to do a reasonable job of accomplishing this > in the context of MIPv4. Sure. There is no dispute of that. But MIPv4 has assumptions which I do not agree with. It assumes you have an authenticated association with the Home Agent. Here, the respective element is the tunnel server. I do not want to require such authenticated association -- which is required if you want to have a stable v6 prefix which is independent of v4 address [/port]. I think this is a useful additional mechanism which can be used when authentication is available, but when it isn't -- there is no use requiring it! In that case, all you can do is somehow tie the prefix to an address[/port] or some magic token transmitted in the packet. But unless it's carried in every packet, this is something that has to be remembered by the server. > Refreshing the NAT mapping and detecting when it might have been > changed can be done using ICMP echos to the tunnel server. When a > failure is suspected the host can redo the registeration protocol. > > In genenral you can't detect the failure (mapping change) without sending > and receiving packets, but that is just a case of quick failure recovery > having a cost. Agree with all of that -- and we already have mechanisms on the table doing something like this. > So I think the rocket science has already been invented in RFC 3519 > - just need to carry it to a different registration protocol. Yep -- or something like that. I guess draft-thubert-nemo-ipv4-traversal-01 is already doing that in v6 context; but again, that builds on top of MIP[v4]. I think the critical point here is whether we require this registration protocol / user authentication in the mechanism, or whether it's an optional step. IMHO, we must not require that. -- 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 Mar 18 06:24:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03671 for ; Thu, 18 Mar 2004 06:24:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3vas-000Akb-Bl for v6ops-data@psg.com; Thu, 18 Mar 2004 11:21:46 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3vah-000Ahi-Aw for v6ops@ops.ietf.org; Thu, 18 Mar 2004 11:21:35 +0000 content-class: urn:content-classes:message Subject: RE: Approaches to use IPsec to secure v6-over-v4 tunnels Date: Thu, 18 Mar 2004 06:21:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Approaches to use IPsec to secure v6-over-v4 tunnels Thread-Index: AcQM0UVFwr/mu2O9QBSXV6J7J4JQIQACGaNw From: "Soliman Hesham" To: "Pekka Savola" Cc: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > We know how to do this we are doing it now on networks. We don't > > need the IETF's help. Yes we have discussed this in=20 > depth. This is > > not the issue. Issue is PKI. IETF should help with PKI. This is > > also in many tutorials for admins being trained on IPv6 now. >=20 > Could you clarify what you mean with "We" here? :) Even if you are > bright enough to figure it on your own, that doesn't mean everyone > else is -- there seems to be ample evidence to the contrary :). So, > at least an Internet-Draft would be useful, to identify the issues > concerned. Whether an Informational RFC would be useful or not would > remain to be seen. =3D> I'm trying to understand whether the non-trivial part is implementation-related or interoperation-related. In the implementation space there are certainly issues like whether the IPsec HW has been upgraded to handle this without doing=20 IPv6 in IPv4 in IPv4 (i.e. IPv4 tunnel mode for a tunnelled IPv6 packet). But when it comes to interoperability I'm not sure if there is an issue. I thought that this would work out of the box.=20 Hesham >=20 > I also brought this up in the security area, and they certainly=20 > thought this is interesting -- and non-trivial. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 07:14: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 HAA05588 for ; Thu, 18 Mar 2004 07:14:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3wNX-000J80-6M for v6ops-data@psg.com; Thu, 18 Mar 2004 12:12:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3wNL-000J6Q-GY for v6ops@ops.ietf.org; Thu, 18 Mar 2004 12:11:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2ICBm630143; Thu, 18 Mar 2004 14:11:48 +0200 Date: Thu, 18 Mar 2004 14:11:48 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org, , Subject: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 16 Mar 2004, Erik Nordmark wrote: > First of all, I agree with you that removing reasons for NAT boxes > needing to exist is something we should all do in the IETF; they > make the network non-transparent and make it much harder to use some > existing applications as well as creating/deploying new applications. > > Our disagreements seem to be whether ndproxy is an effective and useful > means for doing this. Agree. > > There is no stopping them if they want to get paid by the /128, of > > course. I'm thinking this from the perspective of the ISP: what's the > > simplest thing for them to deploy. It certainly doesn't seem to be > > prefix delegation. RA-based advertisement on a point-to-point link > > seems like an obvious means. > > I'd like to understand why DHCP prefix delegation isn't the simplest thing. > Is this something you think is broken in our standards? Or in implementations > of the standards? > > As an aside I find it odd that when the car is broken one would look > for parts in the garage and kitchen to try to build a bicycle and use that > instead of the car. Shouldn't we try to fix the car instead? See the "simpler prefix delegation" thread I just started on IPv6 WG list. > > I'm not even sure how one would go about > > giving the user a /128 in the first place. > > Easy. > > Whether using stateless or stateful address configuration, > the ISP can send RA's without any on-link prefixes to the customer's box. > This means no prefix is made available to the pt-pt link between > the ISP's router and the customer's box. Hence the customer's box > can only use the configured IPv6 address. But how does the customer's box get it's own (global) addess? Do you assume you run something like PPPv6 on the link, which assigns one address and that's it? > > Another angle here is how are you going to deal with the case where > > you have to have stacked gateways. E.g., the home gateway is doing > > prefix delegation, and advertising /64's on its links. One of the > > nodes at home is also a router, and behind it is a host. How do you > > get v6 to that host behind the node? That's a very common scenario > > today. I think it in most cases you could probably move that node to > > the same link, but in some cases (e.g., mismatching media) it might > > not be possible. > [...] > The solution you want in this space is something which allows plug&play of > the devices that glue together the stacking. And since you don't know how > the customer will plug things together, I think you must deal with loops. > > It is true that ndproxy as written can handle this, but it handles > it by running IEEE 802.1D spanning tree protocol over all media - including > non-IEEE 802 media - without specifying the details of how to carry IEEE 802 > bridge PDUs over Avian Carriers, bluetooth, etc. > That doesn't seem like the best approach. > An approach like draft-perlman-zerouter-rbridge-00.txt, which builds > a (very thin) overlay above the link layer between the rbridges look > a lot more interesting to me; no need to carry bridge PDUs around etc. Moved as a thread under a new thread on IPv6 WG list; seems like the best place to argue about the feature-set, as they're specifying it. > But you seem to be talking about the ZEROUTER problem statement just as > much as I am; the problem is having multiple different L2 technologies > and wanting to plug those together without any explicit configuration of > the boxes that connect the different L2 technologies together. The number of boxes to be plugged together is also a factor. How I interpreted the ZEROUTER scope (I could be wrong; I never looked it for long) was that any number of routers, in any topology would be in scope. > > When you consider the applicability of SEND, it's probably highly > > useful in environments like enterprise networks, server farms, etc. > > (in case someone breaks in there and would start hijacking etc.), in > > public WLAN (and other) environments where you deal with untrusted > > users, and similar cases. > > > > It is probably not so necessary in a home network, or in the > > point-to-point link between the ISP and a home network (where the ISP > > can DoS/MitM/etc. you in any case). > > What about a home network which is also a free public WLAN? > Given that WEP is not adding much security, having SEND would make > it possible to open up 802.11 home networks for public access > (apart from resource management issues). This is a good point. SEND + CGA helps a bit in the local link, between the nodes; ND-proxy does not prevent that. This is also possible in the local subnet (to a large degree), as long you're not running ND-proxy on the WLAN bridge (you should use bridging instead, because you can!). On the other hand, SEND + certificates, for router verification, does not help here in any case, because I don't think the ISP offering only /64 would be supporting SEND (if they would, it would no longer be a "simple" setup -- and they'd be giving a /48). So, I don't think this is all that critical issue in practice. > > So, my gut feeling is that people think -- ok, it's fine that ND-proxy > > doesn't work with SEND. Let's not try to fix either SEND or ND-proxy. > > I'd sure like to have that question be asked in the SEND, IPV6, and V6OPS > WGs - my capacity for reading peoples minds is quite limited. This should be brought up after the other threads in SEND and IPv6 WG cease. > > The critical issue here, IMHO, is whether the hosts which are unaware > > of whether ND-proxy is used or not can enable SEND or not. That is, > > we wouldn't want the vendors to turn SEND off by default if that meant > > the hosts would not work with ND-proxy. > > > > I don't think this is the case, but I could be wrong. I think this > > depends on what kind of "triggers" SEND-capable nodes get from the > > network before generating CGA addresses etc. -- do the e.g., wait for > > the first SEND-enabled RA/NA, or whatever -- or do they always start > > immediately (which might be a bit redundant until SEND is commonly > > deployed). > > I don't see how this can be combined in a meaningful way. > If a host has a default config to do SEND, then a packet from a ND proxy will > look like an attacker (it will not look like an insecure node since the peer > will have a CGA address AFAIK). Right -- but what is the alternative? The ISP would not be supporting SEND in any case. > > Discussing its applicability in ZEROUTER etc. enviroments is out of > > scope, but ND-proxy, in simpler setups, could be in scope here. > > Could you specify the problem statement that covers "simpler setups" > but where loops are somehow impossible to create by the consumer? We are not preventing the customer from shooting him/herself in the foot in many other specifications either -- why is this relevant here? :) They can plug their routers upside down, advertise prefixes which don't work, forget to enable IPv6 forwarding, etc. -- a lot of different ways to get yourself in a mess. Further, I don't think anyone is thinking of enabling proxy-ND by default. Just clearly state that proxy-ND should not be combined, and if absolutely have to combine them, only plug them in series. But this was included in the IPv6 ML thread. > > > We already have DHCP prefix delegation as a solution to the problem at > > > the connection to the ISP. How many solutions do we need in this space? > > > > I believe this is a separate problem. > > You must be having a problem statement in mind which is tailored to > ndproxy as the solution. Such narrow problem statements are not very helpful > IMHO - we need to understand the problem space here. I believe the "simple home setup" is sufficiently common, but narrow problem space. -- 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 Mar 18 08:40: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 IAA09999 for ; Thu, 18 Mar 2004 08:40:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3xgt-0006rH-DX for v6ops-data@psg.com; Thu, 18 Mar 2004 13:36:07 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3xgi-0006nI-KT for v6ops@ops.ietf.org; Thu, 18 Mar 2004 13:35:56 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1F33EFBFC; Thu, 18 Mar 2004 08:35:56 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 08:35:55 -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: Approaches to use IPsec to secure v6-over-v4 tunnels Date: Thu, 18 Mar 2004 08:35:46 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC097D@tayexc13.americas.cpqcorp.net> Thread-Topic: Approaches to use IPsec to secure v6-over-v4 tunnels Thread-Index: AcQMz1z/l5YayjKSToWZ/mLSEwGh/AAHnwDw From: "Bound, Jim" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 18 Mar 2004 13:35:55.0840 (UTC) FILETIME=[F0B51C00:01C40CED] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable those working with enterprises to deploy IPv6 currently vendors, consulting firms, the enterprises, et al. /jim=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Thursday, March 18, 2004 4:57 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: Approaches to use IPsec to secure v6-over-v4 tunnels >=20 > On Thu, 18 Mar 2004, Bound, Jim wrote: > > We know how to do this we are doing it now on networks. We=20 > don't need=20 > > the IETF's help. Yes we have discussed this in depth. This is not=20 > > the issue. Issue is PKI. IETF should help with PKI. This=20 > is also in=20 > > many tutorials for admins being trained on IPv6 now. >=20 > Could you clarify what you mean with "We" here? :) Even if=20 > you are bright enough to figure it on your own, that doesn't=20 > mean everyone else is -- there seems to be ample evidence to=20 > the contrary :). So, at least an Internet-Draft would be=20 > useful, to identify the issues concerned. Whether an=20 > Informational RFC would be useful or not would remain to be seen. >=20 > I also brought this up in the security area, and they=20 > certainly thought this is interesting -- and non-trivial. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 18 13:38: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 NAA29667 for ; Thu, 18 Mar 2004 13:38:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B42MA-0007nM-N6 for v6ops-data@psg.com; Thu, 18 Mar 2004 18:35:02 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B42J1-0007Jq-Gq for v6ops@ops.ietf.org; Thu, 18 Mar 2004 18:31:47 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 10:31:41 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 18 Mar 2004 10:31:21 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 18 Mar 2004 10:31:42 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 10:31:36 -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); Thu, 18 Mar 2004 10:32:09 -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, 18 Mar 2004 10:33:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] Date: Thu, 18 Mar 2004 10:31:51 -0800 Message-ID: Thread-Topic: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]] thread-index: AcQLm2gviDT8HoDaSqK/a6IRw3YfkgAMCb0Q From: "Dave Thaler" To: "Alain Durand" Cc: "Pekka Savola" , , "Erik Nordmark" , "Christian Huitema" X-OriginalArrivalTime: 18 Mar 2004 18:33:15.0673 (UTC) FILETIME=[7A139890:01C40D17] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Alain Durand writes: > On Mar 16, 2004, at 12:17 PM, Christian Huitema wrote: > > In practice the NAT mappings do not change and the Teredo address > > remains reasonably stable. >=20 > unless the global IPv4 address of the NAT box is changed every 24 hours=20 > by the ISP... Since we all want to see IPv6 native deployed, I'll point out that the same sort of ISP could use DHCPv6 and change the IPv6 address every 24 hours too. Hence providing addresses more stable than native connectivity gives is not always a good thing as it could result in an incentive for clients to not want/use native IPv6. Instead, if an app needs more address stability that what native connectivity (IPv4 or IPv6) gives, perhaps it would be better off using a mechanism such as a Mobile IPv6 home address. -Dave From owner-v6ops@ops.ietf.org Thu Mar 18 14: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 OAA03202 for ; Thu, 18 Mar 2004 14:44:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B43OR-000HlZ-82 for v6ops-data@psg.com; Thu, 18 Mar 2004 19:41:27 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B43O7-000HkM-O6 for v6ops@ops.ietf.org; Thu, 18 Mar 2004 19:41:08 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2IJf7wr018629 for ; Thu, 18 Mar 2004 12:41:07 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUS0068SEOHQQ@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 18 Mar 2004 12:41:06 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUS00CJCEOGE4@mail.sun.net> for v6ops@ops.ietf.org; Thu, 18 Mar 2004 12:41:05 -0700 (MST) Date: Thu, 18 Mar 2004 11:41:04 -0800 From: Alain Durand Subject: Re: focussing energies In-reply-to: <002a01c40cbe$d5c98590$64051eac@ttitelecom.com> To: EricLKlein Cc: JORDI PALET MARTINEZ , "Bound, Jim" , v6ops@ops.ietf.org Message-id: <315072F7-7914-11D8-8787-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <9C422444DE99BC46B3AD3C6EAFC9711B05DC095D@tayexc13.americas.cpqcorp.net> <002a01c40cbe$d5c98590$64051eac@ttitelecom.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT When I started this thread, the point was 'where this wg should focus' energy from a protocol perspective, not on various mandate & killer apps. I apologize to this group if the thread I started has derived into this. Please, as Pekka asked, lets get back to protocol design. - Alain. From owner-v6ops@ops.ietf.org Thu Mar 18 19:38: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 TAA19612 for ; Thu, 18 Mar 2004 19:38:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B47xw-000K0G-UQ for v6ops-data@psg.com; Fri, 19 Mar 2004 00:34:24 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B47xm-000Jz1-0u for v6ops@ops.ietf.org; Fri, 19 Mar 2004 00:34:14 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 16:34:13 -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); Thu, 18 Mar 2004 16:34:22 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 18 Mar 2004 16:34:13 -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); Thu, 18 Mar 2004 16:34:22 -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); Thu, 18 Mar 2004 16:34:49 -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); Thu, 18 Mar 2004 16:34:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Enterprise scenario text proposal Date: Thu, 18 Mar 2004 16:34:08 -0800 Message-ID: Thread-Topic: Enterprise scenario text proposal thread-index: AcQNSMgdSDlEplZdSBunPGcajTLb2Q== From: "Dave Thaler" To: X-OriginalArrivalTime: 19 Mar 2004 00:34:17.0578 (UTC) FILETIME=[E993FCA0:01C40D49] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable From the minutes: > Dave Thaler: As the slide says, enterprise scenarios document doesn't yet > give much help in what's required. But Enterprises want v6 with little > overhead in any case. > Jonne: not discussing enterprise today, Dave should contribute to > Enterprise work. To start following up on my action item, here's text I'll propose for possible addition to the draft-savola-v6ops-tunneling-00.txt draft. For now, I only consider "Scenario 1" (as defined in=20 draft-ietf-v6ops-ent-scenarios-01.txt), which is making IPv6 equivalent to IPv4. Personally I don't consider scenario 2 (supporting only a particular set of apps) as significantly unique to the enterprise scenarios and as it's not in any of the other non-enterprise scenarios, I will ignore it. I leave scenario 3 (essentially IPv4 over native=20 IPv6) to others, as I don't have data on that scenario and it's not clear to me whether it's really enterprise specific (could this arise in 3GPP? I don't know). +'s indicate proposed additions to the existing draft. --- 3.3 Enterprise Scenarios The only scenario which is obvious at the moment is when the enterprise wishes to deploy IPv6 without changing the gear to be dual-stack, without injecting IPv6 into existing VLANs, or without adding additional IPv6 routers in the VLANs. + There are three subcases of this scenario: + + 1. When the enterprise does not NAT between different parts + of the internal network. This case is useful to separate + from case 2 merely because it is generally the common case, + where simplicity is the most highly valued. + + 2. When NATs exist within the enterprise network, e.g., to connect + branch offices to the corporate network. + + 3. When the enterprise internally uses multicast applications/protocols + that they want to transition to IPv6. Here the enterprise has=20 + already deployed intra-domain IPv4 multicast to support this usage. + As with case 1, there are no internal NATs in this case since IPv4 + multicast itself does not cross NATs. +=20 + NAT traversal must be supported in case 2, and IPv6 multicast must + be supported in case 3. +=20 + The need for direct connectivity in all cases is strong due to two=20 + factors:=20 + * the high end-to-end bandwidth requirements for enterprise=20 + applications, e.g., many clients accessing various servers,=20 + such that bottlenecks occur if all traffic must be funneled=20 + through one or a few tunnel endpoints; + * the use of collaborative applications, possibly including=20 + high-bandwidth streams such as audio/video. + + Finally, most enterprise networks currently lack IPv6 expertise, and + have a great need to keep costs low. Hence simplicity and low=20 + infrastructure costs are also required. --- 4.1 Scenarios Evaluation +++++++++ NAT-T Direct ISP Secure Simple Low Multicast Overhead Unman 1.1 * * N - - - - Unman 1.2 * N * -/* - - - Unman 2 * - * - * - - 3GPP 1 N -/* * - * * - 3GPP 2 N -/* * - * * - + Enterprise 1 N -/* * * * - - + Enterprise 2 * -/* * - * - - + Enterprise 3 N -/* * - * - * Legend: * =3D MUST; - =3D Nice to have; N =3D No + Multicast support indicates whether the mechanism must be able + to support multicast traffic. --- 4.2 Mechanisms Evaluation One should note that we are not evaluating the specific version of the specification, but rather the mechanism in a more generic sense ("which features could this mechanism easily be made to work with?"). +++++ NAT-T Direct ISP Secure Simple Low Impl. Depl. Mcast Overhead Teredo Y Y N Y N N R Y N ISATAP N Y@ Y N/R R Y Y R? N TSP Y N Y? Y R N R R? Y? STEP Y N Y Y Y/R Y N N Y? + L2TP Y N Y Y N N Y Y Y + 6to4 N Y N N Y Y Y Y N + 6over4 N Y Y R Y Y Y R Y @: intra-site, no NATs in the path Legend: Y =3D Yes; R =3D Relatively good; N =3D No + Multicast indicates whether the mechanism is able to support=20 + multicast traffic. --- -Dave From owner-v6ops@ops.ietf.org Thu Mar 18 20:02: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 UAA20654 for ; Thu, 18 Mar 2004 20:02:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B48ND-000PEi-Bl for v6ops-data@psg.com; Fri, 19 Mar 2004 01:00:31 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B48N2-000PA0-M6 for v6ops@ops.ietf.org; Fri, 19 Mar 2004 01:00:20 +0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2J10Bng000304; Thu, 18 Mar 2004 17:00:11 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i2J10AlE028450; Thu, 18 Mar 2004 20:00:10 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i2J10AQU018044; Thu, 18 Mar 2004 20:00:10 -0500 (EST) Message-Id: <200403190100.i2J10AQU018044@thunk.east.sun.com> From: Bill Sommerfeld To: "Bound, Jim" cc: "Pekka Savola" , v6ops@ops.ietf.org Subject: Re: Approaches to use IPsec to secure v6-over-v4 tunnels In-Reply-To: Your message of "Thu, 18 Mar 2004 00:27:41 EST." <9C422444DE99BC46B3AD3C6EAFC9711B05DC095B@tayexc13.americas.cpqcorp.net> Reply-to: sommerfeld@east.sun.com Date: Thu, 18 Mar 2004 20:00:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > We know how to do this we are doing it now on networks. We don't > need the IETF's help. Yes we have discussed this in depth. This is > not the issue. Issue is PKI. IETF should help with PKI. This is > also in many tutorials for admins being trained on IPv6 now. are you following the newly created "pki4ipsec" working group? From owner-v6ops@ops.ietf.org Fri Mar 19 01:34: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 BAA03991 for ; Fri, 19 Mar 2004 01:34:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4DXs-0007SY-5S for v6ops-data@psg.com; Fri, 19 Mar 2004 06:31:52 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4DXh-0007Rd-6C for v6ops@ops.ietf.org; Fri, 19 Mar 2004 06:31:41 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A4D66BB56; Fri, 19 Mar 2004 01:31:40 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 01:31:40 -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: focussing energies Date: Fri, 19 Mar 2004 01:31:28 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC09FC@tayexc13.americas.cpqcorp.net> Thread-Topic: focussing energies Thread-Index: AcQNIPlH2b3Yl6U9RGGYy+QWBuxGtgAWoLBw From: "Bound, Jim" To: , "EricLKlein" Cc: "JORDI PALET MARTINEZ" , X-OriginalArrivalTime: 19 Mar 2004 06:31:40.0453 (UTC) FILETIME=[D6870D50:01C40D7B] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Agreed. I would add telling the market how/what to deploy is out of bounds too. Pekka S. is the biggest offender. Start off with a list of protocols for design each with their own thread I suggest. /jim=20 > -----Original Message----- > From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM]=20 > Sent: Thursday, March 18, 2004 2:41 PM > To: EricLKlein > Cc: JORDI PALET MARTINEZ; Bound, Jim; v6ops@ops.ietf.org > Subject: Re: focussing energies >=20 > When I started this thread, the point was 'where this wg=20 > should focus'=20 > energy > from a protocol perspective, not on various mandate & killer apps. > I apologize to this group if the thread I started has derived=20 > into this. > Please, as Pekka asked, lets get back to protocol design. >=20 > - Alain. >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Mar 19 04:15:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23543 for ; Fri, 19 Mar 2004 04:15:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4G42-0009w7-9g for v6ops-data@psg.com; Fri, 19 Mar 2004 09:13:14 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4G3r-0009ui-4j for v6ops@ops.ietf.org; Fri, 19 Mar 2004 09:13:03 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2J9ClVC087590; Fri, 19 Mar 2004 09:12:49 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2J9C65p237586; Fri, 19 Mar 2004 10:12:06 +0100 Received: from zurich.ibm.com (sig-9-145-224-110.de.ibm.com [9.145.224.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA280614; Fri, 19 Mar 2004 10:12:01 +0100 Message-ID: <405AABD1.8EFD27A8@zurich.ibm.com> Date: Fri, 19 Mar 2004 09:14:09 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > (co-chair hat on) > > Just a reminder -- the WGLC for the application transition document > was issued just prior to the IETF, and still runs for about a week or > so. Please provide feedback. Thanks! "A week or so" expires today or so :-) Most of my comments on the previous version have been addressed. I remain a little unhappy about one paragraph. Here's the previous interchange between me and Pekka: > > > 7. Transition mechanism considerations > > > > > > A mechanism, [NAT-PT], introduces a special set of addresses, > > > formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 > > > addresses, translated by NAT-PT DNS-ALG. In some cases, one might > > > be tempted to handle these differently. > > > > > > However, IPv6 applications must not be required to distinguish > > > "normal" and "NAT-PT translated" addresses (or any other kind of > > > special addresses, including the IPv6-mapped IPv4-addresses): that > > > would be completely unscalable, and if such distinction must be > > > made, it must be done elsewhere (e.g. kernel, system libraries). > > (BC)> > I'm not sure why it would be unscalable - messy, yes, but not unscalable. > (PS)> Maybe we're using different words to describe the same issue. I call > this unscalable because I do not want to see every application to > implement it's own version of this (about 50% of them being probably > incorrect or otherwise wrong :-). > (BC)> > Also, what if an application *wants* to treat a NAT-PT based session differently > > (i.e. implement some legacy features because it knows that the other end > > is IPv4)? Shouldn't the socket API be capable of telling the upper layer > > "this address was translated"? > (PS)> Maybe yes, but the point is that APIs do not provide these *today*. > If they did, I don't think there would be all that many problems > having something like this implemented as part of APIs. (back to today...) I see Pekka's points but the phrase "that would be completely unscalable" still worries me. Could we replace it, for example by "that would be completely impractical" ? Incidentally, this document is referenced by the GGF draft on IPv6 guidelines for GGF protocol designers, which by strange coincidence finishes WG Last Call over in the GGF today too. See http://forge.gridforum.org/projects/ipv6-wg/document/draft-ggf-ipv6-ip-independent-guide-00/en/1 (Warning- some mailers may split this URL into two pieces.) Brian From owner-v6ops@ops.ietf.org Fri Mar 19 04:44: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 EAA24617 for ; Fri, 19 Mar 2004 04:44:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4GWJ-000E6P-QY for v6ops-data@psg.com; Fri, 19 Mar 2004 09:42:27 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4GW0-000E2O-Qo for v6ops@ops.ietf.org; Fri, 19 Mar 2004 09:42:08 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2J9g6Ot017646 for ; Fri, 19 Mar 2004 09:42:07 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA16173 for ; Fri, 19 Mar 2004 09:42:02 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2J9g2L19494 for v6ops@ops.ietf.org; Fri, 19 Mar 2004 09:42:02 GMT Date: Fri, 19 Mar 2004 09:42:01 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Enterprise scenario text proposal Message-ID: <20040319094201.GD18934@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, We are deploying IPv6 in an enterprise here (1,500 users, ~1,000 hosts) and are documenting the process within the 6NET project. I can certainly write up this experience and issues (there is a "similar" draft for an ISP deploying customer dialup/DSL provision in Japan). Pekka is OK with the idea, and we can probably produce this within the next 4 weeks as a first draft. A specific example may help discussion. Regarding 3.3, we *have* deployed by injecting prefixes into VLANs, and I know other etnerprises that are doing the same. We also have full SSM and ASM multicast v6 running enterprise-wide, and have for example used Flute/Mad for reliable IPv6 multicast file sharing around a number of European academic enterprise sites. The gaps are largely with commercial apps, like MS Exchange, but I'll cite them all in the draft. Tim On Thu, Mar 18, 2004 at 04:34:08PM -0800, Dave Thaler wrote: > >From the minutes: > > Dave Thaler: As the slide says, enterprise scenarios document doesn't > yet > > give much help in what's required. But Enterprises want v6 with > little > > overhead in any case. > > Jonne: not discussing enterprise today, Dave should contribute to > > Enterprise work. > > To start following up on my action item, here's text I'll propose for > possible addition to the draft-savola-v6ops-tunneling-00.txt draft. > For now, I only consider "Scenario 1" (as defined in > draft-ietf-v6ops-ent-scenarios-01.txt), which is making IPv6 equivalent > to IPv4. Personally I don't consider scenario 2 (supporting only a > particular set of apps) as significantly unique to the enterprise > scenarios and as it's not in any of the other non-enterprise scenarios, > I will ignore it. I leave scenario 3 (essentially IPv4 over native > IPv6) to others, as I don't have data on that scenario and it's not > clear to me whether it's really enterprise specific (could this arise > in 3GPP? I don't know). > > +'s indicate proposed additions to the existing draft. > > --- > 3.3 Enterprise Scenarios > > The only scenario which is obvious at the moment is when the > enterprise wishes to deploy IPv6 without changing the gear to be > dual-stack, without injecting IPv6 into existing VLANs, or without > adding additional IPv6 routers in the VLANs. > > + There are three subcases of this scenario: > + > + 1. When the enterprise does not NAT between different parts > + of the internal network. This case is useful to separate > + from case 2 merely because it is generally the common case, > + where simplicity is the most highly valued. > + > + 2. When NATs exist within the enterprise network, e.g., to connect > + branch offices to the corporate network. > + > + 3. When the enterprise internally uses multicast > applications/protocols > + that they want to transition to IPv6. Here the enterprise has > + already deployed intra-domain IPv4 multicast to support this > usage. > + As with case 1, there are no internal NATs in this case since IPv4 > > + multicast itself does not cross NATs. > + > + NAT traversal must be supported in case 2, and IPv6 multicast must > + be supported in case 3. > + > + The need for direct connectivity in all cases is strong due to two > + factors: > + * the high end-to-end bandwidth requirements for enterprise > + applications, e.g., many clients accessing various servers, > + such that bottlenecks occur if all traffic must be funneled > + through one or a few tunnel endpoints; > + * the use of collaborative applications, possibly including > + high-bandwidth streams such as audio/video. > + > + Finally, most enterprise networks currently lack IPv6 expertise, and > + have a great need to keep costs low. Hence simplicity and low > + infrastructure costs are also required. > > --- > > 4.1 Scenarios Evaluation > > +++++++++ > NAT-T Direct ISP Secure Simple Low Multicast > Overhead > Unman 1.1 * * N - - - - > Unman 1.2 * N * -/* - - - > Unman 2 * - * - * - - > 3GPP 1 N -/* * - * * - > 3GPP 2 N -/* * - * * - > + Enterprise 1 N -/* * * * - - > + Enterprise 2 * -/* * - * - - > + Enterprise 3 N -/* * - * - * > > Legend: * = MUST; - = Nice to have; N = No > > + Multicast support indicates whether the mechanism must be able > + to support multicast traffic. > > > --- > 4.2 Mechanisms Evaluation > > One should note that we are not evaluating the specific version of > the specification, but rather the mechanism in a more generic sense > ("which features could this mechanism easily be made to work with?"). > > +++++ > NAT-T Direct ISP Secure Simple Low Impl. Depl. Mcast > Overhead > Teredo Y Y N Y N N R Y N > ISATAP N Y@ Y N/R R Y Y R? N > TSP Y N Y? Y R N R R? Y? > STEP Y N Y Y Y/R Y N N Y? > + L2TP Y N Y Y N N Y Y Y > + 6to4 N Y N N Y Y Y Y N > + 6over4 N Y Y R Y Y Y R Y > > @: intra-site, no NATs in the path > > Legend: Y = Yes; R = Relatively good; N = No > > + Multicast indicates whether the mechanism is able to support > + multicast traffic. > > --- > > -Dave > > From owner-v6ops@ops.ietf.org Fri Mar 19 06:26: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 GAA26656 for ; Fri, 19 Mar 2004 06:26:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4HbA-000OvY-AW for v6ops-data@psg.com; Fri, 19 Mar 2004 10:51:32 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4Haz-000Ott-2X for v6ops@ops.ietf.org; Fri, 19 Mar 2004 10:51:21 +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 165AF876D; Fri, 19 Mar 2004 11:31:18 +0100 (CET) From: "Jeroen Massar" To: "'Dave Thaler'" , Subject: RE: Enterprise scenario text proposal Date: Fri, 19 Mar 2004 11:30:23 +0100 Organization: Unfix 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: AcQNSMgdSDlEplZdSBunPGcajTLb2QAU2B8w In-Reply-To: Message-Id: <20040319103118.165AF876D@purgatory.unfix.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Thaler wrote: > 4.2 Mechanisms Evaluation > > One should note that we are not evaluating the specific version of > the specification, but rather the mechanism in a more generic sense > ("which features could this mechanism easily be made to work with?"). > > > +++++ > NAT-T Direct ISP Secure Simple Low Impl. > Depl. Mcast > Overhead > Teredo Y Y N Y N N R Y N > ISATAP N Y@ Y N/R R Y Y R? N > TSP Y N Y? Y R N R R? Y? > STEP Y N Y Y Y/R Y N N Y? > + L2TP Y N Y Y N N Y Y Y > + 6to4 N Y N N Y Y Y Y N > + 6over4 N Y Y R Y Y Y R Y In cases of TSP and STEP I don't think these should be listed here, as these two are configuration methods, while Teredo/isatap/l2tp/6to4/6over4 are protocols that go over the link after being configured by such a method. TSP can do 6over4, but also 6inudp4 or whatever it is called and it can be used to configure a machine to setup a l2tp connection and some others, depending on the availability of a protocol. When TSP uses 6over4 as a protocol it thus doesn't support NAT-T. Also 6over4 is spoofable when one is able to spoof IPv4 packets. Eg mentioned by the following, but I guess that is why it is 'R' ;) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-disco.pdf Simplicity of 6over4 depends on the configuration method and or knowledge of the person setting it up or is it meant as 'simplicity of the protocol' ? There are also at least two seperate Teredo implementations but I guess you are more aware of those ;) TSP and STEP thus can do Multicast depending on the protocol it uses. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFrLvgAA74UAoJwAYobVb2ST59w04uUbrHom ENukAJ4932rV8w+VRjnlv3QYCm5AGStzrw== =F7WQ -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Fri Mar 19 06: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 GAA27270 for ; Fri, 19 Mar 2004 06:37:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4IH7-000Mkf-2M for v6ops-data@psg.com; Fri, 19 Mar 2004 11:34:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4IGn-000MeJ-7s for v6ops@ops.ietf.org; Fri, 19 Mar 2004 11:34:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2JBYT420010; Fri, 19 Mar 2004 13:34:29 +0200 Date: Fri, 19 Mar 2004 13:34:29 +0200 (EET) From: Pekka Savola To: Dave Thaler cc: v6ops@ops.ietf.org Subject: Re: Enterprise scenario text proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for your input. A few comments inline.. On Thu, 18 Mar 2004, Dave Thaler wrote: > --- > 3.3 Enterprise Scenarios > > The only scenario which is obvious at the moment is when the > enterprise wishes to deploy IPv6 without changing the gear to be > dual-stack, without injecting IPv6 into existing VLANs, or without > adding additional IPv6 routers in the VLANs. > > + There are three subcases of this scenario: > + > + 1. When the enterprise does not NAT between different parts > + of the internal network. This case is useful to separate > + from case 2 merely because it is generally the common case, > + where simplicity is the most highly valued. Fine with me. Also, adding a notion that private addresses (even if no internal NAT) are often used. > + 2. When NATs exist within the enterprise network, e.g., to connect > + branch offices to the corporate network. I'm not sure of how applicable this is, but fine with me. > + 3. When the enterprise internally uses multicast > applications/protocols > + that they want to transition to IPv6. Here the enterprise has > + already deployed intra-domain IPv4 multicast to support this > usage. > + As with case 1, there are no internal NATs in this case since IPv4 > + multicast itself does not cross NATs. There are a few enterprises which are using multicast very extensively at the moment. Not many, but a few (like in stock brokering/financing). These must have the possibility to transitioning to IPv6. However, I must disagree with the proposal to require that their special requirements must have to be supported by IPv6 *tunneling* -- such enterprises also run routers which are feature-rich (as they're doing native v4 multicast) to support IPv6 -- there seems to be little excuse not to do that properly! > + The need for direct connectivity in all cases is strong due to two > + factors: > + * the high end-to-end bandwidth requirements for enterprise > + applications, e.g., many clients accessing various servers, > + such that bottlenecks occur if all traffic must be funneled > + through one or a few tunnel endpoints; Isn't this quite a strong case for non-tunneled IPv6? "Dense" deployment seems to call for better deployment model :) > + Finally, most enterprise networks currently lack IPv6 expertise, and > + have a great need to keep costs low. Hence simplicity and low > + infrastructure costs are also required. Doesn't this apply to every scenario ?!?! :) > 4.1 Scenarios Evaluation > +++++++++ > NAT-T Direct ISP Secure Simple Low Multicast > Overhead > Unman 1.1 * * N - - - - > Unman 1.2 * N * -/* - - - > Unman 2 * - * - * - - > 3GPP 1 N -/* * - * * - > 3GPP 2 N -/* * - * * - > + Enterprise 1 N -/* * * * - - > + Enterprise 2 * -/* * - * - - > + Enterprise 3 N -/* * - * - * I think "ISP" support in this is not applicable -- as in the other scenarios we're considering connectivity to the ISP -- here, it's not applicable. Or maybe this would have to be reworded to be more general like "Infrastructure requirement" but not sure if that would make sense either. I'm confused why you require security in one scenario but only have it as nice-to-have in others. As already stated, I'm hesitant about adding multicast requirement here; however, I agree that this is something that might not hurt to evaluate. If we had to specify a mechanism just to meet this scenario, I'm not sure if it would be have good ROI. > 4.2 Mechanisms Evaluation > > One should note that we are not evaluating the specific version of > the specification, but rather the mechanism in a more generic sense > ("which features could this mechanism easily be made to work with?"). > > +++++ > NAT-T Direct ISP Secure Simple Low Impl. Depl. Mcast > Overhead > Teredo Y Y N Y N N R Y N > ISATAP N Y@ Y N/R R Y Y R? N > TSP Y N Y? Y R N R R? Y? > STEP Y N Y Y Y/R Y N N Y? > + L2TP Y N Y Y N N Y Y Y > + 6to4 N Y N N Y Y Y Y N > + 6over4 N Y Y R Y Y Y R Y (For the record, Dave is referring to RFC2529 with "6over4" :) 6over4 is Y@; 6to4 was already in in my working copy. 6over4 implementation is what I'd classify as R or R? -- I know of one, and I have seen no indication that this would get any better. Deployment R? or N? respectively.. -- 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 Mar 19 06:37: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 GAA27294 for ; Fri, 19 Mar 2004 06:37:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4II0-000N0r-G5 for v6ops-data@psg.com; Fri, 19 Mar 2004 11:35:48 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4IHh-000MvK-4C for v6ops@ops.ietf.org; Fri, 19 Mar 2004 11:35:29 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 19 Mar 2004 03:42:13 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2JBZPU7005676 for ; Fri, 19 Mar 2004 06:35:26 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-23.cisco.com [10.86.242.23]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGX59100; Fri, 19 Mar 2004 06:35:24 -0500 (EST) Message-Id: <4.3.2.7.2.20040319055603.00c43600@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Mar 2004 06:35:21 -0500 To: v6ops@ops.ietf.org From: Ralph Droms Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In section 4.1.2, while the statement "The basic use of DHCP is insecure." is technically true, it does not apply to the discussion of DHCPv6 prefix delegation. Section 15 of RFC3396 gives specific guidelines for the use of DHCPv6 authentication for DHCPv6 PD. DHCPv6 authentication is defined as part of the base DHCPv6 specification, in section 21 of RFC3315. The statement "To be useful in such environment in practice, the practical details of managing the DHCP authentication need to be analyzed." needs to be explained. How is the authentication specified in RFC3315 and recommended for DHCPv6 PD in RFC3396 not adequate? What are the security implications of ND proxy? - Ralph At 05:47 PM 3/16/2004 -0800, Erik Nordmark wrote: > > There is no stopping them if they want to get paid by the /128, of > > course. I'm thinking this from the perspective of the ISP: what's the > > simplest thing for them to deploy. It certainly doesn't seem to be > > prefix delegation. RA-based advertisement on a point-to-point link > > seems like an obvious means. > >I'd like to understand why DHCP prefix delegation isn't the simplest thing. >Is this something you think is broken in our standards? Or in implementations >of the standards? > >As an aside I find it odd that when the car is broken one would look >for parts in the garage and kitchen to try to build a bicycle and use that >instead of the car. Shouldn't we try to fix the car instead? > > > I'm not even sure how one would go about > > giving the user a /128 in the first place. > >Easy. > >Whether using stateless or stateful address configuration, >the ISP can send RA's without any on-link prefixes to the customer's box. >This means no prefix is made available to the pt-pt link between >the ISP's router and the customer's box. Hence the customer's box >can only use the configured IPv6 address. > > > So, what I'm trying to see is the easiest way an ISP could deal with > > "basic IPv6 usage case" (seems to be a /64 advertisement), which would > > still encourage for the better service (/48 prefix delegation). The > > case where the ISP absolutely wants just support one IP address is out > > of scope here. > >I think RFC 3177 makes it clear that /48 should be the default. >And if the car (DHCP prefix delegation) isn't working well, let's work >on fixing it. > > > Another angle here is how are you going to deal with the case where > > you have to have stacked gateways. E.g., the home gateway is doing > > prefix delegation, and advertising /64's on its links. One of the > > nodes at home is also a router, and behind it is a host. How do you > > get v6 to that host behind the node? That's a very common scenario > > today. I think it in most cases you could probably move that node to > > the same link, but in some cases (e.g., mismatching media) it might > > not be possible. > >But here you wander into the ZEROUTER domain which you've already said >is out of scope. >If I can discuss it with you using the word "rant" I'd do that. >The solution you want in this space is something which allows plug&play of >the devices that glue together the stacking. And since you don't know how >the customer will plug things together, I think you must deal with loops. > >It is true that ndproxy as written can handle this, but it handles >it by running IEEE 802.1D spanning tree protocol over all media - including >non-IEEE 802 media - without specifying the details of how to carry IEEE 802 >bridge PDUs over Avian Carriers, bluetooth, etc. >That doesn't seem like the best approach. >An approach like draft-perlman-zerouter-rbridge-00.txt, which builds >a (very thin) overlay above the link layer between the rbridges look >a lot more interesting to me; no need to carry bridge PDUs around etc. > > > > FWIW I take exception to you calling my explanation a "rant" - that > > > is pretty close to an ad-hominum attack IMHO. Perhaps I should complain > > > about your behavior to the WG co-chairs :-( > > > > Discussing the applicability of ND-proxy in ZEROUTER environments > > appeared to be rather out of scope here.. because we're not discussing > > applying it in those environments. So, the point of your anti- > > ND-proxying note was IMHO well written, but not something that > > belonged here -- rather maybe IPv6 WG which is working on ND-proxy. > > Sorry if I called that "ranting"; I don't see that as a too negative > > term myself -- perhaps because I feel I'm ranting a lot myself on some > > occasions ;-) > >Apology accepted. > >But you seem to be talking about the ZEROUTER problem statement just as >much as I am; the problem is having multiple different L2 technologies >and wanting to plug those together without any explicit configuration of >the boxes that connect the different L2 technologies together. > > > > When you consider the applicability of SEND, it's probably highly > > useful in environments like enterprise networks, server farms, etc. > > (in case someone breaks in there and would start hijacking etc.), in > > public WLAN (and other) environments where you deal with untrusted > > users, and similar cases. > > > > It is probably not so necessary in a home network, or in the > > point-to-point link between the ISP and a home network (where the ISP > > can DoS/MitM/etc. you in any case). > >What about a home network which is also a free public WLAN? >Given that WEP is not adding much security, having SEND would make >it possible to open up 802.11 home networks for public access >(apart from resource management issues). > > > So, my gut feeling is that people think -- ok, it's fine that ND-proxy > > doesn't work with SEND. Let's not try to fix either SEND or ND-proxy. > >I'd sure like to have that question be asked in the SEND, IPV6, and V6OPS >WGs - my capacity for reading peoples minds is quite limited. > > > The critical issue here, IMHO, is whether the hosts which are unaware > > of whether ND-proxy is used or not can enable SEND or not. That is, > > we wouldn't want the vendors to turn SEND off by default if that meant > > the hosts would not work with ND-proxy. > > > > I don't think this is the case, but I could be wrong. I think this > > depends on what kind of "triggers" SEND-capable nodes get from the > > network before generating CGA addresses etc. -- do the e.g., wait for > > the first SEND-enabled RA/NA, or whatever -- or do they always start > > immediately (which might be a bit redundant until SEND is commonly > > deployed). > >I don't see how this can be combined in a meaningful way. >If a host has a default config to do SEND, then a packet from a ND proxy will >look like an attacker (it will not look like an insecure node since the peer >will have a CGA address AFAIK). > > > (But this is something that should probably go to either SEND or IPv6 > > WG...) > >Agreed. > > > Discussing its applicability in ZEROUTER etc. enviroments is out of > > scope, but ND-proxy, in simpler setups, could be in scope here. > >Could you specify the problem statement that covers "simpler setups" >but where loops are somehow impossible to create by the consumer? > > > > We already have DHCP prefix delegation as a solution to the problem at > > > the connection to the ISP. How many solutions do we need in this space? > > > > I believe this is a separate problem. > >You must be having a problem statement in mind which is tailored to >ndproxy as the solution. Such narrow problem statements are not very helpful >IMHO - we need to understand the problem space here. > > Erik From owner-v6ops@ops.ietf.org Fri Mar 19 07:05: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 HAA28421 for ; Fri, 19 Mar 2004 07:05:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4Iil-0009q8-7w for v6ops-data@psg.com; Fri, 19 Mar 2004 12:03:27 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4IiZ-0009nN-TV for v6ops@ops.ietf.org; Fri, 19 Mar 2004 12:03:16 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9B356FF16 for ; Fri, 19 Mar 2004 07:03:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 07:03:15 -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: Enterprise scenario text proposal Date: Fri, 19 Mar 2004 07:03:00 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05DC0A04@tayexc13.americas.cpqcorp.net> Thread-Topic: Enterprise scenario text proposal Thread-Index: AcQNSMgdSDlEplZdSBunPGcajTLb2QAYNxog From: "Bound, Jim" To: "Dave Thaler" , X-OriginalArrivalTime: 19 Mar 2004 12:03:15.0348 (UTC) FILETIME=[28CF1D40:01C40DAA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Dave, Will respond later traveling and cannot right this moment. But your missing DSTM and you entered the analysis for enterprise scenarios and we do not want to go there until after the scenarios are done. So will not respond to that later. Also we have enterprises moving directly to IPv6 Native as a strategy as soon as possilbe using dual stack so legacy v4 can be supported if required. thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dave Thaler > Sent: Thursday, March 18, 2004 7:34 PM > To: v6ops@ops.ietf.org > Subject: Enterprise scenario text proposal >=20 > From the minutes: > > Dave Thaler: As the slide says, enterprise scenarios=20 > document doesn't > yet > > give much help in what's required. But Enterprises want v6 with > little > > overhead in any case. > > Jonne: not discussing enterprise today, Dave should contribute to=20 > > Enterprise work. >=20 > To start following up on my action item, here's text I'll=20 > propose for possible addition to the=20 > draft-savola-v6ops-tunneling-00.txt draft. > For now, I only consider "Scenario 1" (as defined in=20 > draft-ietf-v6ops-ent-scenarios-01.txt), which is making IPv6=20 > equivalent to IPv4. Personally I don't consider scenario 2=20 > (supporting only a particular set of apps) as significantly=20 > unique to the enterprise scenarios and as it's not in any of=20 > the other non-enterprise scenarios, I will ignore it. I=20 > leave scenario 3 (essentially IPv4 over native > IPv6) to others, as I don't have data on that scenario and=20 > it's not clear to me whether it's really enterprise specific=20 > (could this arise in 3GPP? I don't know). >=20 > +'s indicate proposed additions to the existing draft. >=20 > --- > 3.3 Enterprise Scenarios >=20 > The only scenario which is obvious at the moment is when the > enterprise wishes to deploy IPv6 without changing the gear to be > dual-stack, without injecting IPv6 into existing VLANs, or without > adding additional IPv6 routers in the VLANs. >=20 > + There are three subcases of this scenario: > + > + 1. When the enterprise does not NAT between different parts > + of the internal network. This case is useful to separate > + from case 2 merely because it is generally the common case, > + where simplicity is the most highly valued. > + > + 2. When NATs exist within the enterprise network, e.g., to connect > + branch offices to the corporate network. > + > + 3. When the enterprise internally uses multicast > applications/protocols > + that they want to transition to IPv6. Here the enterprise has=20 > + already deployed intra-domain IPv4 multicast to support this > usage. > + As with case 1, there are no internal NATs in this case=20 > since IPv4 >=20 > + multicast itself does not cross NATs. > +=20 > + NAT traversal must be supported in case 2, and IPv6=20 > multicast must =20 > + be supported in case 3. > +=20 > + The need for direct connectivity in all cases is strong due to two > + factors:=20 > + * the high end-to-end bandwidth requirements for enterprise=20 > + applications, e.g., many clients accessing various servers,=20 > + such that bottlenecks occur if all traffic must be funneled=20 > + through one or a few tunnel endpoints; > + * the use of collaborative applications, possibly including=20 > + high-bandwidth streams such as audio/video. > + > + Finally, most enterprise networks currently lack IPv6=20 > expertise, and =20 > + have a great need to keep costs low. Hence simplicity and low =20 > + infrastructure costs are also required. >=20 > --- >=20 > 4.1 Scenarios Evaluation >=20 > +++++++++ > NAT-T Direct ISP Secure Simple Low Multicast > Overhead > Unman 1.1 * * N - - - - > Unman 1.2 * N * -/* - - - > Unman 2 * - * - * - - > 3GPP 1 N -/* * - * * - > 3GPP 2 N -/* * - * * - > + Enterprise 1 N -/* * * * - - > + Enterprise 2 * -/* * - * - - > + Enterprise 3 N -/* * - * - * >=20 > Legend: * =3D MUST; - =3D Nice to have; N =3D No >=20 > + Multicast support indicates whether the mechanism must be able to=20 > + support multicast traffic. >=20 >=20 > --- > 4.2 Mechanisms Evaluation >=20 > One should note that we are not evaluating the specific version of > the specification, but rather the mechanism in a more generic sense > ("which features could this mechanism easily be made to=20 > work with?"). >=20 > =20 > +++++ > NAT-T Direct ISP Secure Simple Low Impl. =20 > Depl. Mcast > Overhead > Teredo Y Y N Y N N R Y N > ISATAP N Y@ Y N/R R Y Y R? N > TSP Y N Y? Y R N R R? Y? > STEP Y N Y Y Y/R Y N N Y? > + L2TP Y N Y Y N N Y Y Y > + 6to4 N Y N N Y Y Y Y N > + 6over4 N Y Y R Y Y Y R Y >=20 > @: intra-site, no NATs in the path >=20 > Legend: Y =3D Yes; R =3D Relatively good; N =3D No >=20 > + Multicast indicates whether the mechanism is able to support =20 > + multicast traffic. >=20 > --- >=20 > -Dave >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Mar 19 14:22: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 OAA16878 for ; Fri, 19 Mar 2004 14:22:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4PRY-000Kjg-TK for v6ops-data@psg.com; Fri, 19 Mar 2004 19:14:08 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4PRO-000Khm-7i for v6ops@ops.ietf.org; Fri, 19 Mar 2004 19:13:58 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2JJDrQ18199; Fri, 19 Mar 2004 11:13:53 -0800 X-mProtect: <200403191913> 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 smtpdbMKcdP; Fri, 19 Mar 2004 11:13:51 PST Message-ID: <405B4682.6090101@iprg.nokia.com> Date: Fri, 19 Mar 2004 11:14:10 -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: dthaler@microsoft.com, mohitt@microsoft.com, chirayu@chirayu.org CC: v6ops@ops.ietf.org Subject: NDProxy issue References: <"Your message with ID" <4.3.2.7.2.20040319055603.00c43600@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Submitting this issue report to the NDProxy authors, and also cc'ing v6ops due to the recent discussions there: Fred ftemplin@iprg.nokia.com Description of issue: Path MTU black holes with NDProxy Submitter name: Fred L. Templin Submitter email address: ftemplin@iprg.nokia.com Date first submitted: March 19, 2004 Reference: http://ops.ietf.org/lists/v6ops/v6ops.2004/msg00296.html Comment type: ['T'echnical | 'E'ditorial] - Technical Priority: ['S' Must fix | '1' Should fix | '2' May fix ] - Must fix Section: 4.1.1 Rationale/Explanation of issue: Lengthy description of problem: From ([NDproxy], section 4.1.1): "Whenever any packet is to be forwarded out an interface whose MTU is smaller than the size of the packet, the ND proxy drops the packet and sends a Packet Too Big message back to the source, as described in [ICMPv6]." "any packet" in the above should read: "any IPv6 packet". Even so, the text assumes that the IPv6 header is available for the NDProxy to inspect, and this will not necessarily always be the case (e.g., for packets that pass through the proxy between neighbors using IPv6 header compression). When the IPv6 header is not available, the ND proxy is left with no option other than silent-drop, resulting in a Path MTU black hole. By way of the example from ([NDProxy], section 5): A---|---P---|---B a p1 p2 b Suppose A and B have performed the initial IPv6 ND exchange, with the ND messages proxied by P as per the specification. But, suppose also that A and B negotiate IPv6 header compression, i.e., they establish per-hop state that allows headers to be reconstituted when immutable parts are omitted over-the-wire. When A sends a packet with a compressed IPv6 header that is no larger than the MTU of segment (a->p1), but larger than the MTU of segment (p2->b), P will be unable to return an ICMPv6 "packet too big". Requested change: There would not appear to be a simple and scalable method to address the issue within the context of the current specification, since [NDProxy] only specifies L2 address rewriting for proxied IPv6 packets and not any additional "deep packet inspection". In order for P to be able to return an ICMPv6 "packet too big" in the above example, it would require some means for "snooping" the IPv6 header compression negotiation between A and B and also maintaining a "mirror image" of the header compression state. Moveover, P has no way of preventing A and B from negotiating header compression, nor any way of anticipating the header compression method to be negotiated. Possible resolutions appear to be: 1) Note the path MTU black hole issue, 2) Recommend that IPv6 header compression be disabled when an NDProxy may occur along the path, 3) devise an alternate scheme for preventing the black holes. From owner-v6ops@ops.ietf.org Fri Mar 19 15:47:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21739 for ; Fri, 19 Mar 2004 15:47:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4Qrg-000HLb-5Z for v6ops-data@psg.com; Fri, 19 Mar 2004 20:45:12 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4QrN-000HHR-JU for v6ops@ops.ietf.org; Fri, 19 Mar 2004 20:44:53 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2JKiiS22398; Fri, 19 Mar 2004 12:44:44 -0800 X-mProtect: <200403192044> 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 smtpdkq2ceW; Fri, 19 Mar 2004 12:44:43 PST Message-ID: <405B5BCF.5010200@iprg.nokia.com> Date: Fri, 19 Mar 2004 12:45:03 -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: Ralph Droms CC: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt References: <"Your message with ID" <4.3.2.7.2.20040319055603.00c43600@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ralph, Ralph Droms wrote: > What are the security implications of ND proxy? I believe that the implications are somewhat different if native IPv6 is used vs. IPv6 tunneled over IPv4. In the case of native IPv6, ([NDPROXY], section 4.1.4) seems to provide opportunity for, e.g., simple man-in-the-middle redirection attacks, since the model requires that the NDproxy be able to change the addresses that appear in the TLLA options of proxied IPv6 redirect messages. When IPv6 is tunneled over IPv4, the NDProxy effectively becomes an ARP Proxy, and the TLLA options in the encapsulated IPv6 redirect messages are unchanged. (Or, if they are changed, the receiver should be able to detect this if the sender is using some form of authentication for the IPv6 ND messages it sends.) Based on the security and path MTU issues, it seems that: - native IPv6 should be used between IPv6 neighbors on the same segment, or neighbors that are separated by simple L2 bridges that connect segments of like media - IPv6 tunneled over IPv4 should be used between IPv6 neighbors when an NDProxy occurs along the path In other words, the NDProxy can be greatly simplified (and issues such as security; path MTU black holes can be avoided) if only IPv4 ND messages (and not IPv6) are proxied. This would reduce the functionality of the NDProxy to that of the existing ARP proxy model, which I believe others have mentioned as widely deployed in operational scenarios. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Mar 19 21:15: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 VAA06463 for ; Fri, 19 Mar 2004 21:15:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4Vuz-000Au6-Ro for v6ops-data@psg.com; Sat, 20 Mar 2004 02:08:57 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4Vuz-000AtR-1N for v6ops@ops.ietf.org; Sat, 20 Mar 2004 02:08:57 +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 i2K28jWA027002; Fri, 19 Mar 2004 18:08:46 -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 i2K28hQ07241; Sat, 20 Mar 2004 03:08:43 +0100 (MET) Date: Fri, 19 Mar 2004 18:08:46 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: stable vs address-derived v6 prefix [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] To: Pekka Savola Cc: Erik Nordmark , Florent Parent , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > But MIPv4 has assumptions which I do not agree with. It assumes you > have an authenticated association with the Home Agent. Here, the > respective element is the tunnel server. > > I do not want to require such authenticated association -- which is > required if you want to have a stable v6 prefix which is independent > of v4 address [/port]. I think this is a useful additional mechanism > which can be used when authentication is available, but when it isn't > -- there is no use requiring it! You appear to be looking for a free lunch. Sufficiently secure, operationally robust, direct paths, and no need to "register". That is an overconstrained problem IMHO. I personally prefer "sufficiently secure" over the "no need to register" given the world we live in today. And lots of people seem to think it is ok to register to get a free email account at yahoo, hotmail, etc. Why do we think asking them to do the same thing to enable the cool applications running on IPv6 is out of the question? > I think the critical point here is whether we require this > registration protocol / user authentication in the mechanism, or > whether it's an optional step. IMHO, we must not require that. I actually think it is a mistake to define mechanisms that are *not capable* of doing registration with the same type of "tracability" that is done to sign up for a free email account. Whether different ISPs want to *use* that mechanism would be up to them. But without them in the specifications and as mandatory to implement we can easily end up with IPv6(transition) being perceived as less secure than IPv4. Erik From owner-v6ops@ops.ietf.org Fri Mar 19 21:15:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06481 for ; Fri, 19 Mar 2004 21:15:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4Vv8-000Av8-KG for v6ops-data@psg.com; Sat, 20 Mar 2004 02:09:06 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4Vv7-000Auu-Qe for v6ops@ops.ietf.org; Sat, 20 Mar 2004 02:09:05 +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 i2K28rng022740; Fri, 19 Mar 2004 18:08:54 -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 i2K28pQ07246; Sat, 20 Mar 2004 03:08:51 +0100 (MET) Date: Fri, 19 Mar 2004 18:08:53 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] To: Pekka Savola Cc: Erik Nordmark , v6ops@ops.ietf.org, jonne.soininen@nokia.com, huitema@microsoft.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.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 > > Whether using stateless or stateful address configuration, > > the ISP can send RA's without any on-link prefixes to the customer's box. > > This means no prefix is made available to the pt-pt link between > > the ISP's router and the customer's box. Hence the customer's box > > can only use the configured IPv6 address. > > But how does the customer's box get it's own (global) addess? Do you > assume you run something like PPPv6 on the link, which assigns one > address and that's it? That isn't the only choice. DHCPv6 and stateless address autoconfiguration works as well. (There is a reason the prefix options have a separate "on-link" flag and "addrconf" flag.) > SEND + CGA helps a bit in the local link, between the nodes; > ND-proxy does not prevent that. AFAIK ND-proxy is incompatible with using SEND. full stop. You can't do any proxy advertisements transparently to the hosts and still have SEND work. > > Could you specify the problem statement that covers "simpler setups" > > but where loops are somehow impossible to create by the consumer? > > We are not preventing the customer from shooting him/herself in the > foot in many other specifications either -- why is this relevant here? Could you please point me at an IETF standard related to routing which can create persistent routing loops where ttl is not decremented? I never recall seeing such a beast. Folks in the routing area seem to have a aversion to creating persistent routing loops; even though temporary loops occur at L3 and the damanage is limited due to the ttl decrement. But ndproxy explicitly doesn't decrement the ttl/hop limit! That is why I am extremely concerned here. Erik From owner-v6ops@ops.ietf.org Fri Mar 19 21:34: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 VAA07090 for ; Fri, 19 Mar 2004 21:34:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4WHf-000Dkx-Kt for v6ops-data@psg.com; Sat, 20 Mar 2004 02:32:23 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4WHc-000Dka-BD for v6ops@ops.ietf.org; Sat, 20 Mar 2004 02:32:20 +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 6173D877D; Sat, 20 Mar 2004 03:32:13 +0100 (CET) From: "Jeroen Massar" To: "'Erik Nordmark'" , "'Pekka Savola'" Cc: "'Florent Parent'" , Subject: RE: stable vs address-derived v6 prefix [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] Date: Sat, 20 Mar 2004 03:32:04 +0100 Organization: Unfix 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: AcQOIUzkEV5ZM030SeapAKRl1veb5AAAIlVg In-Reply-To: Message-Id: <20040320023213.6173D877D@purgatory.unfix.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Nordmark wrote: > I personally prefer "sufficiently secure" over the "no need > to register" > given the world we live in today. > And lots of people seem to think it is ok to register to get > a free email account at yahoo, hotmail, etc. > Why do we think asking them to do the same thing to enable the cool > applications running on IPv6 is out of the question? Requiring a signup and user address/info details cuts down on the abuse with huge hops. Indeed it is very easy for most people to sign up for things like Yahoo/MSN/... etc thus signing up for a TB service shouldn't be that hard either. I also think that that is more like a political thing and not a protocol thing. We could look at it from a protocol side by creating a protocol which standardizes registration and then having a standard tool that does that part for them. But many services would not like that as they want to show their big flashy spammy logo's just to advertise themselves even though the service is free you want some feedback. > > I think the critical point here is whether we require this > > registration protocol / user authentication in the mechanism, or > > whether it's an optional step. IMHO, we must not require that. > > I actually think it is a mistake to define mechanisms that are *not > capable* of doing registration with the same type of > "tracability" that is done to sign up for a free email account. > Whether different ISPs want to *use* that mechanism would be > up to them. > But without them in the specifications and as mandatory to implement > we can easily end up with IPv6(transition) being perceived as > less secure than IPv4. ISP's should decide for themselves if they want to require user authentication and registration. Freenet6 for instance is quite public and anonymous and thus has a big load of users. SixXS requires that every single user that wants a tunnel supplies us with full name and address details including a valid phonenumber, we decided on this for one prime reason: cutting down on the abuse. It's simply not feasible in our eyes to run a public and free service when jane doe can come in and abuse it, mostly happening on IRC, which will only make ones service unusable and thus totally useless. Many TB's have disabled port 6600-7000 connectivity because of that too. At least that is my point of view. Thus: a protocol should make it possible to have anonymous _and_ authenticated mechanisms, per choice of the entity deploying the mechanism. The anonymous mechanisms could use some kind of cookie method to allow the user to 'autoregister' and when they come back present the cookie and allowing them to get their former prefix back, add a lifetime to that and we have a transition-dhcp protocol. Cookies should not rely on the IPv4 address as that might change. I am a proponent of stable addresses btw, thus having the above for anonymous users helps dealing with that. Also rfc3041 is not for me ;) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFutJAAAjMEAoIxwcBYAhz+B9pOPyHEMZ3tP 4B+PAJ9HqorF5t8ONKDtoVS23L//0zQSIg== =gLdl -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sat Mar 20 03:33:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01988 for ; Sat, 20 Mar 2004 03:33:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4bs9-0001Ws-D5 for v6ops-data@psg.com; Sat, 20 Mar 2004 08:30:25 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4Mit-000Aqe-Qw for v6ops@ops.ietf.org; Fri, 19 Mar 2004 16:19:52 +0000 Received: from fernando.gont.com.ar ([200.68.222.242]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id NAA13316; Fri, 19 Mar 2004 13:46:38 -0400 Message-Id: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Mar 2004 13:27:29 -0300 To: Pekka Savola , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting 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.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 At 04:52 05/03/2004 +0200, Pekka Savola wrote: >TCP timeouts when connecting to a destination, but when the >destination is unreachable (e.g., because you don't have global IPv6 >routes, your first-hop router is not operational, the packets are sent >on-link by default, etc.), TCP does not abort the connectivity (and >try the next address quicker -- instead of waiting for the TCP >timeout). Not sure if I got it right. Do you mean TCP does not abort the conectivity, and thus the *application* cannot try the next address quicker? >2.3.1.1 TCP Connection Termination > One solution is for TCP to abort connections in SYN-SENT or > SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable > message. But what if this scenario arises for all the addresses, because of a transient problem? The application won't cycle again, and will return an error. And the *transient* problem could disappear perhaps 5 seconds later... IMHO, if you had a "higher-level" connect(), this behavior would make sense, as you could handle the whole issue, in a transparent way to the application. Does it really make sense to handle the whole connection establishment issue inside the app, instead of inside the API itself? I think that if we're debating this, we're implicitly assuming that applications want to connect to say www.example.com, and not one specific IP address to which it maps to. So why not implement such a "higher-level" connect(), and handle all the relevant issues inside the API? > When [HOSTREQS] was written, most applications would mostly only try > one address when establishing communication with a destination. Not > aborting a connection was a sane thing to do if re-trying a single > address was a better alternative over quitting the application > altogether. With IPv6, and especially on dual stack systems, > destinations are often assigned multiple addresses (at least one IPv4 > and one IPv6 address), and applications iterate through destination > addresses when attempting connections. Doesn't the problem really have to do with having applications performing such a low-level action? Just my two cents, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Sat Mar 20 03:34: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 DAA02006 for ; Sat, 20 Mar 2004 03:34:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4brq-0000zo-KL for v6ops-data@psg.com; Sat, 20 Mar 2004 08:30:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4I04-0006kQ-NQ for v6ops@ops.ietf.org; Fri, 19 Mar 2004 11:17:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2JBH6R19670; Fri, 19 Mar 2004 13:17:06 +0200 Date: Fri, 19 Mar 2004 13:17:06 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt (fwd) In-Reply-To: <405AABD1.8EFD27A8@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Mar 2004, Brian E Carpenter wrote: > I see Pekka's points but the phrase "that would be completely unscalable" > still worries me. Could we replace it, for example by > "that would be completely impractical" ? That's fine with me. -- 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 Sat Mar 20 03:34:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02026 for ; Sat, 20 Mar 2004 03:34:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4bsU-00026b-EL for v6ops-data@psg.com; Sat, 20 Mar 2004 08:30:46 +0000 Received: from [4.16.89.28] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4RJK-000O0X-Ag for v6ops@ops.ietf.org; Fri, 19 Mar 2004 21:13:46 +0000 Received: from eaglet (127.0.0.1:3307) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 19 Mar 2004 13:17:02 -0800 From: "Tony Hain" To: Subject: Recent navel gazing - we need to stop wasting cycles on FUD Date: Fri, 19 Mar 2004 13:13:50 -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: AcQN9xMQXBx/3DdIQueOHv8aK3VpLw== X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=1.4 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Several recent threads are about trying to out-guess the market and pick the one-size-fits-all answer to deployment. The entire point of the scenarios documents was to focus the communities on their area of expertise, so we don't continue arguing that 'we don't need X for my environment, therefore we don't need X'. While it is appropriate to point out when specific mechanisms are or are not useful, it is not appropriate to force the entire diverse Internet into a single, or even restricted set, deployment approach. We are close to finishing the work on scenarios so we can start applying the proposed tools to them. Rather than the continuing efforts to kill off technologies out of context, the applicability work needs to be completed. While it is useful to make sure we have minimal duplication and overlap, as I look at the proposed tool set I don't see any useful reduction. We can discuss the mechanics of any individual tool, but only in the context that we know exactly what problem we are solving. The continuing FUD is based on application of a tool in an environment that it is specifically not suited for. FWIW as I see the tools and their application; 6to4 - Enterprise -> allows multiple subnet deployments behind the tunnel endpoint with a public IPv4 address. - Unmanaged -> this is both simple, and in common use as an automated prefix delegation approach. ISATAP - Enterprise -> where the apps & hosts move before the infrastructure (this is reasonable both from the perspective of demonstrating value, and from the perspective that hosts are generally upgraded before infrastructure), - ISP -> it has value in the Cable operator environment where the management side of the gateway is addressed in private IPv4 space, yet the gateway needs to tunnel across older DOCSIS equipment that will take years to replace (6to4 would work with public addresses, and manual config is always an option). Teredo - Unmanaged -> automated single subnet & needed to deal with the NAT managed by someone else problem (home / hotel / airport ...). - ISP -> automated single subnet & needed to deal with the NAT managed by someone else problem (the charging for addresses approach has resulted in customers deploying infrastructure, and getting a service behind that device is proving to be an issue). Tunnel brokers as a class - ISP -> for the aggressive ISP that wants to take mindshare away from local competitors, there is an opportunity to offer new applications (this is really no different than the Dial-up ISP case tunneling over the lethargic PSTN). Translators as a class - 3G -> needed if IPv6 only handsets are expected to directly reach the legacy IPv4 Internet or devices that have not reached their economic end of life Application gateways - 3G / ISP / Enterprise & Unmanaged -> useful if IPv6-only appliances appear in mass before infrastructure gets upgraded (see Sony press releases). Each of these tools solves a different subset of the problem space. It is up to the market to decide which have value. The IETF's role is to make sure that the mechanisms are well documented so all implementations have the opportunity to interoperate. If there are operational recommendations or warnings those are also appropriate to document. Attempts to kill off technology X because some people think the market will want Y only ensures that technology X will be implemented differently by each vendor. All of these technologies need to be on the standards track, and the recent discussion about making them experimental is BS that needs to stop. We can't have a reasoned discussion about the useful / extraneous features of any technology until we nail the target deployment environments. Tony From owner-v6ops@ops.ietf.org Sat Mar 20 09:44: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 JAA11665 for ; Sat, 20 Mar 2004 09:44:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4hdW-000BlA-N7 for v6ops-data@psg.com; Sat, 20 Mar 2004 14:39:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4hdU-000Bkc-Vs for v6ops@ops.ietf.org; Sat, 20 Mar 2004 14:39:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2KEd0d08088; Sat, 20 Mar 2004 16:39:01 +0200 Date: Sat, 20 Mar 2004 16:39:00 +0200 (EET) From: Pekka Savola To: Fernando Gont cc: tcpm@ietf.org, , Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Mar 2004, Fernando Gont wrote: > At 04:52 05/03/2004 +0200, Pekka Savola wrote: > >TCP timeouts when connecting to a destination, but when the > >destination is unreachable (e.g., because you don't have global IPv6 > >routes, your first-hop router is not operational, the packets are sent > >on-link by default, etc.), TCP does not abort the connectivity (and > >try the next address quicker -- instead of waiting for the TCP > >timeout). > > Not sure if I got it right. Do you mean TCP does not abort the conectivity, > and thus the *application* cannot try the next address quicker? Yep, that's what I meant (and by application, I mean both the app and the APIs/libraries it's using). > >2.3.1.1 TCP Connection Termination > > One solution is for TCP to abort connections in SYN-SENT or > > SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable > > message. > > But what if this scenario arises for all the addresses, because of a > transient problem? > The application won't cycle again, and will return an error. And the > *transient* problem could disappear perhaps 5 seconds later... Note that this applies to new connections only. Yes, this is a trade-off. The assumption is that with big transient problems, all the addresses {at least of the same address family} are unreachable, or none of them are. So, you either have to choose between having TCP connect() try retrying for dozens of seconds (hoping the transient to go away) or failing completely. The tradeoff recommended was that it's better to fail completely; this works better for transient and non-transient failures, except for the case where the transient failure was so short that the TCP retry mechanism could be the feasible failure recovery mechanism for that. I don't think it is.. Obviously, there could be a flag to indicate to the stack whether you want this behaviour or not. > Does it really make sense to handle the whole connection establishment > issue inside the app, instead of inside the API itself? Those are the core APIs we have today. We could have better ones, but IMHO I think we need to fix problems in the current ones as long as we don't have a widely-deployed alternative. > I think that if we're debating this, we're implicitly assuming that > applications want to connect to say www.example.com, and not one specific > IP address to which it maps to. > > So why not implement such a "higher-level" connect(), and handle all the > relevant issues inside the API? Defining such APIs is probably beyond the scope of the work we can do, and the things we can fix except in the 5+ year timeframe.. but if I get you right, you're proposing that instead of: 1) getaddrinfo() or gethostbyname() and connect for one address, [where, arguably, TCP retry timeout could be warranted -- I don't think so myself, but you could argue for it] 2) getaddrinfo() / gethostbyname() loop to connect to one address [where TCP retry timeout could not be warranted] You'd be proposing to create a new function to accomplish 2) in such a manner that it would also react to ICMP messages, etc? > > When [HOSTREQS] was written, most applications would mostly only try > > one address when establishing communication with a destination. Not > > aborting a connection was a sane thing to do if re-trying a single > > address was a better alternative over quitting the application > > altogether. With IPv6, and especially on dual stack systems, > > destinations are often assigned multiple addresses (at least one IPv4 > > and one IPv6 address), and applications iterate through destination > > addresses when attempting connections. > > Doesn't the problem really have to do with having applications performing > such a low-level action? At some point, someone has to decide which behaviour is desirable. Isn't this only hiding the same policy decision inside an abstraction layer -- and the same could be achieved by e.g. a setsockopt() flag? (I don't deny that better APIs would not hurt, but we still seem to require low-level C-like primitives, and unless there are additional ones implemented there, we still have to fix the problems somehow..) -- 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 Sat Mar 20 09:45: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 JAA11699 for ; Sat, 20 Mar 2004 09:45:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4hhX-000Cdq-6Y for v6ops-data@psg.com; Sat, 20 Mar 2004 14:43:51 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4hhW-000CdM-5h for v6ops@ops.ietf.org; Sat, 20 Mar 2004 14:43:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2KEhfF08163; Sat, 20 Mar 2004 16:43:41 +0200 Date: Sat, 20 Mar 2004 16:43:41 +0200 (EET) From: Pekka Savola To: Fred Templin cc: dthaler@microsoft.com, , , Subject: Re: NDProxy issue In-Reply-To: <405B4682.6090101@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Mar 2004, Fred Templin wrote: > Suppose A and B have performed the initial IPv6 ND exchange, > with the ND messages proxied by P as per the specification. But, > suppose also that A and B negotiate IPv6 header compression, i.e., > they establish per-hop state that allows headers to be reconstituted > when immutable parts are omitted over-the-wire. When A sends > a packet with a compressed IPv6 header that is no larger than the > MTU of segment (a->p1), but larger than the MTU of segment > (p2->b), P will be unable to return an ICMPv6 "packet too big". [...] > Possible resolutions appear to be: 1) Note the path MTU black > hole issue, 2) Recommend that IPv6 header compression be > disabled when an NDProxy may occur along the path, 3) devise > an alternate scheme for preventing the black holes. FWIW, it seems obvious that we should do something like 2); Header Compression breaks _so_ many other things in the specs that we should not be trying to address it here. Whether or not this deployment scenario is obvious enough (to be a disallowed one) is probably a matter of opinion. -- 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 Sat Mar 20 09:50: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 JAA11865 for ; Sat, 20 Mar 2004 09:50:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4hmS-000Dnk-23 for v6ops-data@psg.com; Sat, 20 Mar 2004 14:48:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4hmR-000DnH-4m for v6ops@ops.ietf.org; Sat, 20 Mar 2004 14:48:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2KEmgC08250; Sat, 20 Mar 2004 16:48:42 +0200 Date: Sat, 20 Mar 2004 16:48:42 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Ralph Droms , Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: <405B5BCF.5010200@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Mar 2004, Fred Templin wrote: > When IPv6 is tunneled over IPv4, the NDProxy effectively becomes > an ARP Proxy, and the TLLA options in the encapsulated IPv6 redirect > messages are unchanged. (Or, if they are changed, the receiver should > be able to detect this if the sender is using some form of authentication > for the IPv6 ND messages it sends.) There must be some confusion here; ND-proxy, as proposed, is only meant to proxy IPv6 traffic, not e.g. IPv4 proto-41 packets. > Based on the security and path MTU issues, it seems that: I think this is rather questionable. ND-proxy is already deployed on the path, so that it by design is able to do pretty much everything. No different from a router, for example. So I don't see the issues here. -- 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 Sat Mar 20 10:05: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 KAA12463 for ; Sat, 20 Mar 2004 10:05:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4i0s-000HrL-8i for v6ops-data@psg.com; Sat, 20 Mar 2004 15:03:50 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4i0q-000Hr6-Uo for v6ops@ops.ietf.org; Sat, 20 Mar 2004 15:03:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2KF3fv08511; Sat, 20 Mar 2004 17:03:41 +0200 Date: Sat, 20 Mar 2004 17:03:41 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Florent Parent , Subject: Re: stable vs address-derived v6 prefix [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Mar 2004, Erik Nordmark wrote: > > But MIPv4 has assumptions which I do not agree with. It assumes you > > have an authenticated association with the Home Agent. Here, the > > respective element is the tunnel server. > > > > I do not want to require such authenticated association -- which is > > required if you want to have a stable v6 prefix which is independent > > of v4 address [/port]. I think this is a useful additional mechanism > > which can be used when authentication is available, but when it isn't > > -- there is no use requiring it! > > You appear to be looking for a free lunch. > Sufficiently secure, operationally robust, direct paths, and no > need to "register". > That is an overconstrained problem IMHO. That certainly is; but I am do not want to solve "direct paths" in this kind of "tunnel server" solution -- and then I do not think the problem space is over-constrained. As a matter of fact, Alain Durand reminded that "stable prefix" scenario introduces stricter security requirements in a sense -- as noted in your multi6 security presentation on 3rd party bombing. You'll basically have to do (at least) return routability when you're doing any actions associated with the v6 prefix. If you tie the v6 prefix to the address/port you use, there is no need for that. > I personally prefer "sufficiently secure" over the "no need to register" > given the world we live in today. > And lots of people seem to think it is ok to register to get > a free email account at yahoo, hotmail, etc. > Why do we think asking them to do the same thing to enable the cool > applications running on IPv6 is out of the question? I think it is important to enable a process where this could be done transparently -- and easily enough. Whether they would still want to do authentication is a separate issue. Many (most?) people don't know how to subscribe a free email support (much less find one -- which is another difficult problem!), but we want to enable IPv6 at their desks as well :). > > I think the critical point here is whether we require this > > registration protocol / user authentication in the mechanism, or > > whether it's an optional step. IMHO, we must not require that. > > I actually think it is a mistake to define mechanisms that are *not > capable* of doing registration with the same type of "tracability" that > is done to sign up for a free email account. This type of traceability is available from the tunnel server logs, similar to traceability of someone sending emails off such an account (many of which do not show the IP address of the sender). -- 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 Sat Mar 20 10: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 KAA13259 for ; Sat, 20 Mar 2004 10:13:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4i8L-000JKy-Fu for v6ops-data@psg.com; Sat, 20 Mar 2004 15:11:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4i8K-000JKT-8y for v6ops@ops.ietf.org; Sat, 20 Mar 2004 15:11:32 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2KFBTk08591; Sat, 20 Mar 2004 17:11:29 +0200 Date: Sat, 20 Mar 2004 17:11:29 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org, , Subject: Re: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Mar 2004, Erik Nordmark wrote: > > SEND + CGA helps a bit in the local link, between the nodes; > > ND-proxy does not prevent that. > > AFAIK ND-proxy is incompatible with using SEND. full stop. > You can't do any proxy advertisements transparently to the hosts and > still have SEND work. SEND nodes are still capable to use SEND when they're (all) behind the same ND-proxy. Obviously, when they work in the "transition" mode, they will also process non-SEND messages, such as those that originate beyond ND proxy. So, you can actually use a degree of SEND with ND-proxy, but I think it does not work *through* the ND proxy. Depending on where you deploy it (and where you deploy the SEND nodes), this may be relevant. > > > Could you specify the problem statement that covers "simpler setups" > > > but where loops are somehow impossible to create by the consumer? > > > > We are not preventing the customer from shooting him/herself in the > > foot in many other specifications either -- why is this relevant here? > > Could you please point me at an IETF standard related to routing which > can create persistent routing loops where ttl is not decremented? > I never recall seeing such a beast. Folks in the routing area seem > to have a aversion to creating persistent routing loops; even though > temporary loops occur at L3 and the damanage is limited due to > the ttl decrement. > But ndproxy explicitly doesn't decrement the ttl/hop limit! > That is why I am extremely concerned here. Luckily enough ND-proxy is not going to be IETF standard, but Informational :). Nobody has bothered to document (different flavors of) proxy-ARP, but that's there in the similar way as well -- without spanning tree, and seems to be working whereever it's used. -- 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 Sat Mar 20 10:27: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 KAA13953 for ; Sat, 20 Mar 2004 10:27:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4iLZ-000M50-Az for v6ops-data@psg.com; Sat, 20 Mar 2004 15:25:13 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4iLX-000M4I-QT for v6ops@ops.ietf.org; Sat, 20 Mar 2004 15:25:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2KFP7r08759; Sat, 20 Mar 2004 17:25:07 +0200 Date: Sat, 20 Mar 2004 17:25:07 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org Subject: Re: Recent navel gazing - we need to stop wasting cycles on FUD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Mar 2004, Tony Hain wrote: > 6to4 > - Enterprise -> allows multiple subnet deployments behind the tunnel > endpoint with a public IPv4 address. I don't think any serious enterprise would want to do anything as unreliable as 6to4. Just get a configured tunnel w/ prefix delegation or native access. > - Unmanaged -> this is both simple, and in common use as an automated prefix > delegation approach. Agreed, esp. when the gateway is upgraded. Unfortunately, the quality is rather bad still. > ISATAP > - Enterprise -> where the apps & hosts move before the infrastructure (this > is reasonable both from the perspective of demonstrating value, and from the > perspective that hosts are generally upgraded before infrastructure), All you need is one tunnel box e.g. to act as a tunnel server, it's not an "all or no infrastructure" deal. Similarly, if you use VLANs inside the enterprise, more often than not, you could inject native v6 in all the VLANs just by deploying one router (see the draft about this). Sites have deployed native v6 using these methods over 3 years ago, and still running.. > - ISP -> it has value in the Cable operator environment where the management > side of the gateway is addressed in private IPv4 space, yet the gateway > needs to tunnel across older DOCSIS equipment that will take years to > replace (6to4 would work with public addresses, and manual config is always > an option). Any particular reason why a tunnel server solution would not be applicable? > Teredo > - Unmanaged -> automated single subnet & needed to deal with the NAT managed > by someone else problem (home / hotel / airport ...). Right. > - ISP -> automated single subnet & needed to deal with the NAT managed by > someone else problem (the charging for addresses approach has resulted in > customers deploying infrastructure, and getting a service behind that device > is proving to be an issue). I don't think I understand what you mean for _ISP_ here. Deploying a Teredo relay/server for its customers? I don't think they'll bother, because such relays/servers must be deployed globally as well, so what benefit would it bring to them? But if someone wants to do it, why not... > Tunnel brokers as a class > - ISP -> for the aggressive ISP that wants to take mindshare away from local > competitors, there is an opportunity to offer new applications (this is > really no different than the Dial-up ISP case tunneling over the lethargic > PSTN). It's interesting that you don't see tunnel brokers as a solution for an ISP that wants to offer v6 to its *own* users. Any particular reason why not? You're making assumption that the TB service for other users would not be free, right? (Otherwise the ISP would not have a point -- but would rather just advertise like "switch to us, we offer you free tunnel broker if you get your v4 service from us!"). -- 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 Sat Mar 20 11:12: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 LAA15160 for ; Sat, 20 Mar 2004 11:12:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4j1o-00073J-Fn for v6ops-data@psg.com; Sat, 20 Mar 2004 16:08:52 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4j1n-00072u-Gm for v6ops@ops.ietf.org; Sat, 20 Mar 2004 16:08:51 +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); Sat, 20 Mar 2004 08:08:50 -0800 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 20 Mar 2004 08:08:50 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 20 Mar 2004 08:08:54 -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); Sat, 20 Mar 2004 08:08:03 -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); Sat, 20 Mar 2004 08:08:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: Recent navel gazing - we need to stop wasting cycles on FUD Date: Sat, 20 Mar 2004 08:08:47 -0800 Message-ID: Thread-Topic: Recent navel gazing - we need to stop wasting cycles on FUD thread-index: AcQN9xMQXBx/3DdIQueOHv8aK3VpLwAnbsmw From: "Christian Huitema" To: "Tony Hain" , X-OriginalArrivalTime: 20 Mar 2004 16:08:40.0994 (UTC) FILETIME=[9C642020:01C40E95] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree with Tony's message. This group should stop the nasty competition between solutions and recognize that different solutions have different domains of applications. In particular, we should recognize that when solutions are deployed and have independent implementations, they probably meet two key criteria: someone needs them, otherwise they would not be deployed; and the specification is reasonably easy to implement, or there would not be interoperability. It is fairly clear that 6to4, ISATAP, and Teredo meet this bar today. Some version of tunnel broker should easily meet the bar in the short term; it certainly meets the deployment bar, but we probably have to stabilize the spec. -- Christian Huitema > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Tony Hain > Sent: Friday, March 19, 2004 1:14 PM > To: v6ops@ops.ietf.org > Subject: Recent navel gazing - we need to stop wasting cycles on FUD >=20 > Several recent threads are about trying to out-guess the market and pick > the > one-size-fits-all answer to deployment. The entire point of the scenarios > documents was to focus the communities on their area of expertise, so we > don't continue arguing that 'we don't need X for my environment, therefore > we don't need X'. While it is appropriate to point out when specific > mechanisms are or are not useful, it is not appropriate to force the > entire > diverse Internet into a single, or even restricted set, deployment > approach. >=20 >=20 > We are close to finishing the work on scenarios so we can start applying > the > proposed tools to them. Rather than the continuing efforts to kill off > technologies out of context, the applicability work needs to be completed. > While it is useful to make sure we have minimal duplication and overlap, > as > I look at the proposed tool set I don't see any useful reduction. We can > discuss the mechanics of any individual tool, but only in the context that > we know exactly what problem we are solving. The continuing FUD is based > on > application of a tool in an environment that it is specifically not suited > for. >=20 > FWIW as I see the tools and their application; >=20 > 6to4 > - Enterprise -> allows multiple subnet deployments behind the tunnel > endpoint with a public IPv4 address. > - Unmanaged -> this is both simple, and in common use as an automated > prefix > delegation approach. >=20 > ISATAP > - Enterprise -> where the apps & hosts move before the infrastructure > (this > is reasonable both from the perspective of demonstrating value, and from > the > perspective that hosts are generally upgraded before infrastructure), > - ISP -> it has value in the Cable operator environment where the > management > side of the gateway is addressed in private IPv4 space, yet the gateway > needs to tunnel across older DOCSIS equipment that will take years to > replace (6to4 would work with public addresses, and manual config is > always > an option). >=20 > Teredo > - Unmanaged -> automated single subnet & needed to deal with the NAT > managed > by someone else problem (home / hotel / airport ...). > - ISP -> automated single subnet & needed to deal with the NAT managed by > someone else problem (the charging for addresses approach has resulted in > customers deploying infrastructure, and getting a service behind that > device > is proving to be an issue). >=20 > Tunnel brokers as a class > - ISP -> for the aggressive ISP that wants to take mindshare away from > local > competitors, there is an opportunity to offer new applications (this is > really no different than the Dial-up ISP case tunneling over the lethargic > PSTN). >=20 > Translators as a class > - 3G -> needed if IPv6 only handsets are expected to directly reach the > legacy IPv4 Internet or devices that have not reached their economic end > of > life >=20 > Application gateways > - 3G / ISP / Enterprise & Unmanaged -> useful if IPv6-only appliances > appear > in mass before infrastructure gets upgraded (see Sony press releases). >=20 > Each of these tools solves a different subset of the problem space. It is > up > to the market to decide which have value. The IETF's role is to make sure > that the mechanisms are well documented so all implementations have the > opportunity to interoperate. If there are operational recommendations or > warnings those are also appropriate to document. Attempts to kill off > technology X because some people think the market will want Y only ensures > that technology X will be implemented differently by each vendor. All of > these technologies need to be on the standards track, and the recent > discussion about making them experimental is BS that needs to stop. We > can't > have a reasoned discussion about the useful / extraneous features of any > technology until we nail the target deployment environments. >=20 > Tony >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sat Mar 20 14:46: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 OAA21316 for ; Sat, 20 Mar 2004 14:46:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4mNF-000EiX-C2 for v6ops-data@psg.com; Sat, 20 Mar 2004 19:43:13 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4mND-000Ehy-1V for v6ops@ops.ietf.org; Sat, 20 Mar 2004 19:43:11 +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 62-md50000000105.tmp for ; Sat, 20 Mar 2004 20:48:33 +0100 Message-ID: <05fb01c40eb4$1d480da0$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Recent navel gazing - we need to stop wasting cycles on FUD Date: Sat, 20 Mar 2004 20:47:00 +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, Sat, 20 Mar 2004 20:48:33 +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.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 also agree, as I indicated in the Seoul meeting. I also will like to have as less mechanism as possible (no idea if 4 is = enough or we need 7 or 11), but while we warrantee that a user can = ALWAYS, in ANY situation, get IPv6 with any kind of IPv4 connection. We probably need to fix the specs, yes, and make them as much perfect as = possible, yes also, but not if that will take more than 5-6 months (may = be is unrealistic ?). Regards, Jordi ----- Original Message -----=20 From: "Christian Huitema" To: "Tony Hain" ; Sent: Saturday, March 20, 2004 5:08 PM Subject: RE: Recent navel gazing - we need to stop wasting cycles on FUD I agree with Tony's message. This group should stop the nasty competition between solutions and recognize that different solutions have different domains of applications. In particular, we should recognize that when solutions are deployed and have independent implementations, they probably meet two key criteria: someone needs them, otherwise they would not be deployed; and the specification is reasonably easy to implement, or there would not be interoperability. It is fairly clear that 6to4, ISATAP, and Teredo meet this bar today. Some version of tunnel broker should easily meet the bar in the short term; it certainly meets the deployment bar, but we probably have to stabilize the spec. -- Christian Huitema > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Tony Hain > Sent: Friday, March 19, 2004 1:14 PM > To: v6ops@ops.ietf.org > Subject: Recent navel gazing - we need to stop wasting cycles on FUD >=20 > Several recent threads are about trying to out-guess the market and pick > the > one-size-fits-all answer to deployment. The entire point of the scenarios > documents was to focus the communities on their area of expertise, so we > don't continue arguing that 'we don't need X for my environment, therefore > we don't need X'. While it is appropriate to point out when specific > mechanisms are or are not useful, it is not appropriate to force the > entire > diverse Internet into a single, or even restricted set, deployment > approach. >=20 >=20 > We are close to finishing the work on scenarios so we can start applying > the > proposed tools to them. Rather than the continuing efforts to kill off > technologies out of context, the applicability work needs to be completed. > While it is useful to make sure we have minimal duplication and overlap, > as > I look at the proposed tool set I don't see any useful reduction. We can > discuss the mechanics of any individual tool, but only in the context that > we know exactly what problem we are solving. The continuing FUD is based > on > application of a tool in an environment that it is specifically not suited > for. >=20 > FWIW as I see the tools and their application; >=20 > 6to4 > - Enterprise -> allows multiple subnet deployments behind the tunnel > endpoint with a public IPv4 address. > - Unmanaged -> this is both simple, and in common use as an automated > prefix > delegation approach. >=20 > ISATAP > - Enterprise -> where the apps & hosts move before the infrastructure > (this > is reasonable both from the perspective of demonstrating value, and from > the > perspective that hosts are generally upgraded before infrastructure), > - ISP -> it has value in the Cable operator environment where the > management > side of the gateway is addressed in private IPv4 space, yet the gateway > needs to tunnel across older DOCSIS equipment that will take years to > replace (6to4 would work with public addresses, and manual config is > always > an option). >=20 > Teredo > - Unmanaged -> automated single subnet & needed to deal with the NAT > managed > by someone else problem (home / hotel / airport ...). > - ISP -> automated single subnet & needed to deal with the NAT managed by > someone else problem (the charging for addresses approach has resulted in > customers deploying infrastructure, and getting a service behind that > device > is proving to be an issue). >=20 > Tunnel brokers as a class > - ISP -> for the aggressive ISP that wants to take mindshare away from > local > competitors, there is an opportunity to offer new applications (this is > really no different than the Dial-up ISP case tunneling over the lethargic > PSTN). >=20 > Translators as a class > - 3G -> needed if IPv6 only handsets are expected to directly reach the > legacy IPv4 Internet or devices that have not reached their economic end > of > life >=20 > Application gateways > - 3G / ISP / Enterprise & Unmanaged -> useful if IPv6-only appliances > appear > in mass before infrastructure gets upgraded (see Sony press releases). >=20 > Each of these tools solves a different subset of the problem space. It is > up > to the market to decide which have value. The IETF's role is to make sure > that the mechanisms are well documented so all implementations have the > opportunity to interoperate. If there are operational recommendations or > warnings those are also appropriate to document. Attempts to kill off > technology X because some people think the market will want Y only ensures > that technology X will be implemented differently by each vendor. All of > these technologies need to be on the standards track, and the recent > discussion about making them experimental is BS that needs to stop. We > can't > have a reasoned discussion about the useful / extraneous features of any > technology until we nail the target deployment environments. >=20 > Tony >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Mar 22 02:45: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 CAA08686 for ; Mon, 22 Mar 2004 02:45:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5K2q-0008Br-Kq for v6ops-data@psg.com; Mon, 22 Mar 2004 07:40:24 +0000 Received: from [4.16.89.28] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5EQh-0002xg-Ud for v6ops@ops.ietf.org; Mon, 22 Mar 2004 01:40:40 +0000 Received: from eaglet (127.0.0.1:3285) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Sun, 21 Mar 2004 17:40:41 -0800 From: "Tony Hain" To: "'Pekka Savola'" Cc: Subject: RE: Recent navel gazing - we need to stop wasting cycles on FUD Date: Sun, 21 Mar 2004 17:40:42 -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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQOj/4iZRFzERTtQd657n4o3zi63QBHZ0xw X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Fri, 19 Mar 2004, Tony Hain wrote: > > 6to4 > > - Enterprise -> allows multiple subnet deployments behind the tunnel > > endpoint with a public IPv4 address. > > I don't think any serious enterprise would want to do anything as > unreliable as 6to4. Just get a configured tunnel w/ prefix delegation > or native access. The interesting thing to note is that one person's opinion doesn't matter. The market has done just fine in the past without a supervising nanny. > > > - Unmanaged -> this is both simple, and in common use as an automated > prefix > > delegation approach. > > Agreed, esp. when the gateway is upgraded. Unfortunately, the quality > is rather bad still. The IETF is about defining the technology. Implementations are for the market to sort out. > > > ISATAP > > - Enterprise -> where the apps & hosts move before the infrastructure > (this > > is reasonable both from the perspective of demonstrating value, and from > the > > perspective that hosts are generally upgraded before infrastructure), > > All you need is one tunnel box e.g. to act as a tunnel server, it's > not an "all or no infrastructure" deal. Similarly, if you use VLANs > inside the enterprise, more often than not, you could inject native v6 > in all the VLANs just by deploying one router (see the draft about > this). Sites have deployed native v6 using these methods over 3 years > ago, and still running.. You clearly have never figured out ISATAP, so please quit trying, and quit spewing nonsense. > > > - ISP -> it has value in the Cable operator environment where the > management > > side of the gateway is addressed in private IPv4 space, yet the gateway > > needs to tunnel across older DOCSIS equipment that will take years to > > replace (6to4 would work with public addresses, and manual config is > always > > an option). > > Any particular reason why a tunnel server solution would not be > applicable? Automation. > > > Teredo > > - Unmanaged -> automated single subnet & needed to deal with the NAT > managed > > by someone else problem (home / hotel / airport ...). > > Right. > > > - ISP -> automated single subnet & needed to deal with the NAT managed > by > > someone else problem (the charging for addresses approach has resulted > in > > customers deploying infrastructure, and getting a service behind that > device > > is proving to be an issue). > > I don't think I understand what you mean for _ISP_ here. Deploying a > Teredo relay/server for its customers? I don't think they'll bother, > because such relays/servers must be deployed globally as well, so what > benefit would it bring to them? But if someone wants to do it, why > not... The point is that the ISP wants to deploy a service on the home wireless network, but doesn't own the NAT because they have forced their customer to deploy that by charging for addresses. Since they don't own a critical piece of the infrastructure they need a way to tunnel through it. > > > Tunnel brokers as a class > > - ISP -> for the aggressive ISP that wants to take mindshare away from > local > > competitors, there is an opportunity to offer new applications (this is > > really no different than the Dial-up ISP case tunneling over the > lethargic > > PSTN). > > It's interesting that you don't see tunnel brokers as a solution for > an ISP that wants to offer v6 to its *own* users. Any particular > reason why not? They have not been asking for it. > > You're making assumption that the TB service for other users would not > be free, right? (Otherwise the ISP would not have a point -- but > would rather just advertise like "switch to us, we offer you free > tunnel broker if you get your v4 service from us!"). I make no assumptions about service offerings. I only note that tunneling over lame service providers has a historical precedent, so technologies like tunnel brokers that allow that mode of operation are viable in the market. Tony From owner-v6ops@ops.ietf.org Mon Mar 22 06:22: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 GAA16748 for ; Mon, 22 Mar 2004 06:22:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5NRc-000OUQ-OW for v6ops-data@psg.com; Mon, 22 Mar 2004 11:18:12 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5NKV-000GN4-6i for v6ops@ops.ietf.org; Mon, 22 Mar 2004 11:10:51 +0000 Received: from fernando.gont.com.ar ([200.68.222.175]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id IAA24427; Mon, 22 Mar 2004 08:38:21 -0400 Message-Id: <4.3.2.7.2.20040322073643.00b1b4a0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Mar 2004 08:18:12 -0300 To: Pekka Savola From: Fernando Gont Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting Cc: tcpm@ietf.org, , In-Reply-To: References: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.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.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 At 16:39 20/03/2004 +0200, Pekka Savola wrote: > > Does it really make sense to handle the whole connection establishment > > issue inside the app, instead of inside the API itself? >Those are the core APIs we have today. We could have better ones, but >IMHO I think we need to fix problems in the current ones as long as we >don't have a widely-deployed alternative. IMHO, there are two points to note: * If you fix the current ones so that their behavior is "acceptable" to the application programmer, then it'll be harder to introduce a new API. People is reluctant to change, so they must have a reason for learning a new API. If you try to fix the current one, they will find fewer reasons for the change. * You said "we don't have a widely-deployed alternative". Unless you meant "we don't have a well-tested alternative", I'd say that it's a chicken-and-egg problem. That means, for an API to be widely deployed, people would have to use it. And for people to use it, they should be able to find a good reason to do it. Yes, I'm aware that my proposal my sound as a long-term solution. But, IMHO, it will certainly be harder to introduce a new API if you actually want to do it "in long term". I guess "timing" is an issue, here. > > I think that if we're debating this, we're implicitly assuming that > > applications want to connect to say www.example.com, and not one specific > > IP address to which it maps to. > > > > So why not implement such a "higher-level" connect(), and handle all the > > relevant issues inside the API? > >Defining such APIs is probably beyond the scope of the work we can do, >and the things we can fix except in the 5+ year timeframe.. but if I >get you right, you're proposing that instead of: > > 1) getaddrinfo() or gethostbyname() and connect for one address, >[where, arguably, TCP retry timeout could be warranted -- I don't >think so myself, but you could argue for it] > > 2) getaddrinfo() / gethostbyname() loop to connect to one address >[where TCP retry timeout could not be warranted] > >You'd be proposing to create a new function to accomplish 2) in such a >manner that it would also react to ICMP messages, etc? Exactly. Then, within that function, each individual connect() could react to ICMP messages a as you proposed, but if all addresses fail because of ICMP errors, it could let TCP retry in the hope the transiet problem will dissappear. [....] > > Doesn't the problem really have to do with having applications performing > > such a low-level action? > >At some point, someone has to decide which behaviour is desirable. >Isn't this only hiding the same policy decision inside an abstraction >layer Yes, but even when the difference may sound subtle, IMHO it's not. Having that abstraction layer is what let's you choose a policy, without having the risk of causing any harm to existing apps. That way, if you ever need to change the low-level-connect() behavoir for whatever reason, you could still do it. As far as the high-level connect() behaves the same, there would be no problem. Think about it. Why should an application programmer care about TCP retries, ICMP erros, an the like? In the same way, why should he care about setting "strange" options such as SO_REUSEADDR on his listening socket? Should *he* really handle byte-ordering issues by means of htons() and the like? >-- and the same could be achieved by e.g. a setsockopt() flag? Strictly speaking, you *could* do that. But then you'd have all programmers implementing themselves a function you could provide them. You'd have all them implementing the getaddrinfo()/gethostbyname() loop, setting a strange socket option, etc. Why not provide them with a well-tested function, and let them spend their time implementing their application itself? >(I don't deny that better APIs would not hurt, but we still seem to >require low-level C-like primitives, and unless there are additional >ones implemented there, we still have to fix the problems somehow..) Well, the low-level ones could be provided as part of the new API. Or along with the providing a new API, the current one could be modified as you suggest. It wouldn't hurt too much if the *low-level* API aborted a connection establishment because an ICMP error is received. Being a *low-level* API, you'd be suppossed to know the details behind the function. Best Regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Mon Mar 22 08:11:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22059 for ; Mon, 22 Mar 2004 08:11:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5PAF-000DqM-48 for v6ops-data@psg.com; Mon, 22 Mar 2004 13:08:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5PAD-000Dpe-Ez for v6ops@ops.ietf.org; Mon, 22 Mar 2004 13:08:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2MD88N15106; Mon, 22 Mar 2004 15:08:08 +0200 Date: Mon, 22 Mar 2004 15:08:08 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: <4.3.2.7.2.20040319055603.00c43600@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Mar 2004, Ralph Droms wrote: > In section 4.1.2, while the statement "The basic use of DHCP is insecure." > is technically true, it does not apply to the discussion of DHCPv6 prefix > delegation. Section 15 of RFC3396 gives specific guidelines for the use of > DHCPv6 authentication for DHCPv6 PD. DHCPv6 authentication is defined as > part of the base DHCPv6 specification, in section 21 of RFC3315. Right. > The statement "To be useful in such environment in practice, the practical > details of managing the DHCP authentication need to be analyzed." needs to > be explained. How is the authentication specified in RFC3315 and > recommended for DHCPv6 PD in RFC3396 not adequate? (Operational) key management seems problematic, even though DHCP provides support for that. Maybe reword: The basic use of DHCP is insecure. This may be a problem if the link between gateway and ISP is shared by multiple subscribers. DHCP specification includes authentication options, but does not describe the task of managing the keys, and how the information would be shared between the customer and the ISP. To be useful in such environment in practice, the practical details of managing the DHCP authentication need to be analyzed. to: DHCP is insecure unless authentication is used. This may be a particular problem if the link between gateway and ISP is shared by multiple subscribers. DHCP specification includes authentication options, but the operational procedures for managing the keys and methods for sharing the required information between the customer and the ISP are unclear. To be secure in such environment in practice, the practical details of managing the DHCP authentication need to be analyzed. Perhaps that is a bit more fair statement of the issue(s) involved. > What are the security implications of ND proxy? Roughly equal or slightly worse, but then again, it would probably not be applicable in this specific ("multiple subscribers in one big LAN") environment 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 Mon Mar 22 08:29: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 IAA22966 for ; Mon, 22 Mar 2004 08:29:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5PS6-000HCi-JZ for v6ops-data@psg.com; Mon, 22 Mar 2004 13:26:50 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5PS5-000HCF-17 for v6ops@ops.ietf.org; Mon, 22 Mar 2004 13:26:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2MDQjg15322; Mon, 22 Mar 2004 15:26:45 +0200 Date: Mon, 22 Mar 2004 15:26:45 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org Subject: RE: Recent navel gazing - we need to stop wasting cycles on FUD In-Reply-To: <200403220140.i2M1eif06327@netcore.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 21 Mar 2004, Tony Hain wrote: > > I don't think any serious enterprise would want to do anything as > > unreliable as 6to4. Just get a configured tunnel w/ prefix delegation > > or native access. > > The interesting thing to note is that one person's opinion doesn't matter. > The market has done just fine in the past without a supervising nanny. I don't think the market has, due to a number of reasons. We would probably not be here and now, discussing IPv6 deployment if it had ;-). The bottom line is that v6ops WG is chartered from the start to give BCP and Info documents on deployment. Whether the market wants to conform or ignore that is of course up to them. > > > ISATAP > > > - Enterprise -> where the apps & hosts move before the infrastructure > > (this > > > is reasonable both from the perspective of demonstrating value, and from > > the > > > perspective that hosts are generally upgraded before infrastructure), > > > > All you need is one tunnel box e.g. to act as a tunnel server, it's > > not an "all or no infrastructure" deal. Similarly, if you use VLANs > > inside the enterprise, more often than not, you could inject native v6 > > in all the VLANs just by deploying one router (see the draft about > > this). Sites have deployed native v6 using these methods over 3 years > > ago, and still running.. > > You clearly have never figured out ISATAP, so please quit trying, and quit > spewing nonsense. I see zero technical content in your reply, so following up is probably not productive. > > > - ISP -> it has value in the Cable operator environment where the > > management > > > side of the gateway is addressed in private IPv4 space, yet the gateway > > > needs to tunnel across older DOCSIS equipment that will take years to > > > replace (6to4 would work with public addresses, and manual config is > > always > > > an option). > > > > Any particular reason why a tunnel server solution would not be > > applicable? > > Automation. Good. That's an easily fixable problem, already in the works. Nobody just seemed to bother to add automation to the tunnel setup systems, but that can be remedied. > > > - ISP -> automated single subnet & needed to deal with the NAT managed > > by > > > someone else problem (the charging for addresses approach has resulted > > in > > > customers deploying infrastructure, and getting a service behind that > > device > > > is proving to be an issue). > > > > I don't think I understand what you mean for _ISP_ here. Deploying a > > Teredo relay/server for its customers? I don't think they'll bother, > > because such relays/servers must be deployed globally as well, so what > > benefit would it bring to them? But if someone wants to do it, why > > not... > > The point is that the ISP wants to deploy a service on the home wireless > network, but doesn't own the NAT because they have forced their customer to > deploy that by charging for addresses. Since they don't own a critical piece > of the infrastructure they need a way to tunnel through it. [snip the rest] That doesn't seem to be a fundamentally all that different problem than the Teredo case you already mentioned. -- 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 Mar 22 18:07: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 SAA01755 for ; Mon, 22 Mar 2004 18:07:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5YT5-000OwH-Jp for v6ops-data@psg.com; Mon, 22 Mar 2004 23:04:27 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5YT3-000Ow1-Nw for v6ops@ops.ietf.org; Mon, 22 Mar 2004 23:04:26 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2MN4Owr001901 for ; Mon, 22 Mar 2004 16:04:25 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HV000HI62RCPR@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 22 Mar 2004 16:04:24 -0700 (MST) Received: from [192.168.1.100] ([129.152.225.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HV0007KJ2RAFM@mail.sun.net> for v6ops@ops.ietf.org; Mon, 22 Mar 2004 16:04:24 -0700 (MST) Date: Mon, 22 Mar 2004 15:04:22 -0800 From: Alain Durand Subject: Re: Recent navel gazing - we need to stop wasting cycles on FUD In-reply-to: To: Pekka Savola Cc: Tony Hain , v6ops@ops.ietf.org Message-id: <42033A47-7C55-11D8-87E3-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 20, 2004, at 7:25 AM, Pekka Savola wrote: > On Fri, 19 Mar 2004, Tony Hain wrote: >> 6to4 >> - Enterprise -> allows multiple subnet deployments behind the tunnel >> endpoint with a public IPv4 address. > > I don't think any serious enterprise would want to do anything as > unreliable as 6to4. Just get a configured tunnel w/ prefix delegation > or native access. I'd like to think of the company I work for as being serious. We are using 6to4. Not in the way you think, but we are still using it very seriously. Your comment is out of place. - Alain. From owner-v6ops@ops.ietf.org Tue Mar 23 00:10:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19903 for ; Tue, 23 Mar 2004 00:10:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5e84-000CKG-CJ for v6ops-data@psg.com; Tue, 23 Mar 2004 05:07:08 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5e83-000CK2-Ha for v6ops@ops.ietf.org; Tue, 23 Mar 2004 05:07:07 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2N570p9015853; Mon, 22 Mar 2004 22:07:01 -0700 (MST) 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 i2N56uQ11300; Tue, 23 Mar 2004 06:06:57 +0100 (MET) Date: Mon, 22 Mar 2004 21:06:56 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: stable vs address-derived v6 prefix [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] To: Jeroen Massar Cc: "'Erik Nordmark'" , "'Pekka Savola'" , "'Florent Parent'" , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20040320023213.6173D877D@purgatory.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.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 > Thus: a protocol should make it possible to have anonymous > _and_ authenticated mechanisms, per choice of the entity > deploying the mechanism. Agree completely. We shouldn't need two separate protocols/mechanisms for this. > The anonymous mechanisms could use > some kind of cookie method to allow the user to 'autoregister' > and when they come back present the cookie and allowing them > to get their former prefix back, add a lifetime to that and > we have a transition-dhcp protocol. Cookies should not rely > on the IPv4 address as that might change. I am a proponent > of stable addresses btw, thus having the above for anonymous > users helps dealing with that. Also rfc3041 is not for me ;) Good idea to look at a cookie approach. Presumably the provider of the tunnel service would decide when to reuse prefixes - a cookie might be used once and never again so some garbage collection mechanism is needed. But that is probably the case for manually registered tunnel users as well. Erik From owner-v6ops@ops.ietf.org Tue Mar 23 00:29: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 AAA20855 for ; Tue, 23 Mar 2004 00:29:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5eRz-000GB1-6R for v6ops-data@psg.com; Tue, 23 Mar 2004 05:27:43 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5eRt-000GA1-Q3 for v6ops@ops.ietf.org; Tue, 23 Mar 2004 05:27:37 +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 i2N5RQng010040; Mon, 22 Mar 2004 21:27:27 -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 i2N5RNQ11920; Tue, 23 Mar 2004 06:27:23 +0100 (MET) Date: Mon, 22 Mar 2004 21:27:24 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: stable vs address-derived v6 prefix [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]] To: Pekka Savola Cc: Erik Nordmark , Florent Parent , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > You appear to be looking for a free lunch. > > Sufficiently secure, operationally robust, direct paths, and no > > need to "register". > > That is an overconstrained problem IMHO. > > That certainly is; but I am do not want to solve "direct paths" in > this kind of "tunnel server" solution -- and then I do not think the > problem space is over-constrained. > Sorry about "direct paths" - but "stable prefix" was missing from the list. Perhaps Jeroen's idea about a cookie which can be created when autoregistering is a way to provide a stable prefix and sufficient security for the anonymous case. > As a matter of fact, Alain Durand reminded that "stable prefix" > scenario introduces stricter security requirements in a sense -- as > noted in your multi6 security presentation on 3rd party bombing. > You'll basically have to do (at least) return routability when you're > doing any actions associated with the v6 prefix. If you tie the v6 > prefix to the address/port you use, there is no need for that. Agreed. But as you've pointed out elsewhere, it might make sense to require an IPv4 return routability check as part of tunnel establishment to prevent a single packet with a spoofed IPv4 source address from creating a bogus tunnel. > > I actually think it is a mistake to define mechanisms that are *not > > capable* of doing registration with the same type of "tracability" that > > is done to sign up for a free email account. > > This type of traceability is available from the tunnel server logs, > similar to traceability of someone sending emails off such an account > (many of which do not show the IP address of the sender). But that would require the operator to run an abuse line which will go look for the IPv4 addresses (and email address if the tunnel was not autoregistered). An alternative might be the freenet6 approach of sticking this information in the reverse DNS entry so that a smart complainer can bypass the tunnel provider to more quickly get towards the offender. Erik From owner-v6ops@ops.ietf.org Tue Mar 23 00:34:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21122 for ; Tue, 23 Mar 2004 00:34:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5eXe-000HN4-0r for v6ops-data@psg.com; Tue, 23 Mar 2004 05:33:34 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5eXX-000HLu-3J for v6ops@ops.ietf.org; Tue, 23 Mar 2004 05:33:27 +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 i2N5Wing012008; Mon, 22 Mar 2004 21:32:45 -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 i2N5WfQ13962; Tue, 23 Mar 2004 06:32:41 +0100 (MET) Date: Mon, 22 Mar 2004 21:32:42 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] To: Pekka Savola Cc: Erik Nordmark , v6ops@ops.ietf.org, jonne.soininen@nokia.com, huitema@microsoft.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.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 > SEND nodes are still capable to use SEND when they're (all) behind the > same ND-proxy. Obviously, when they work in the "transition" mode, > they will also process non-SEND messages, such as those that originate > beyond ND proxy. So, you can actually use a degree of SEND with > ND-proxy, but I think it does not work *through* the ND proxy. > Depending on where you deploy it (and where you deploy the SEND > nodes), this may be relevant. Assuming you don't know which hosts implement and use SEND this is equivalent to saying it works when all the routers and all the hosts are on the same side of the ndproxy. Since nothing connects to the other side of the ndproxy I think you can disconnect the ndproxy as well. > Luckily enough ND-proxy is not going to be IETF standard, but > Informational :). Nobody has bothered to document (different flavors > of) proxy-ARP, but that's there in the similar way as well -- without > spanning tree, and seems to be working whereever it's used. The IPv6 WG charter has: Jun 04 Submit Proxy RA to IESG for Proposed Standard. So we are not that lucky unless something changes. Erik From owner-v6ops@ops.ietf.org Tue Mar 23 00:36: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 AAA21168 for ; Tue, 23 Mar 2004 00:36:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5eYy-000HmR-VO for v6ops-data@psg.com; Tue, 23 Mar 2004 05:34:56 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5eYy-000HmD-7P for v6ops@ops.ietf.org; Tue, 23 Mar 2004 05:34:56 +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 i2N5Ycng012584; Mon, 22 Mar 2004 21:34:43 -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 i2N5YYQ15733; Tue, 23 Mar 2004 06:34:34 +0100 (MET) Date: Mon, 22 Mar 2004 21:34:35 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] To: Pekka Savola Cc: Erik Nordmark , v6ops@ops.ietf.org, jonne.soininen@nokia.com, huitema@microsoft.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.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 > Luckily enough ND-proxy is not going to be IETF standard, but > Informational :). Nobody has bothered to document (different flavors > of) proxy-ARP, but that's there in the similar way as well -- without > spanning tree, and seems to be working whereever it's used. Sorry, I missed the last sentence. The proxy arp implementations I know of decrement ttl. Are there proxy arp implementations that do not decrement ttl? Can't compare that with ndproxy which doesn't decrement the hop count. Erik From owner-v6ops@ops.ietf.org Tue Mar 23 05: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 FAA15654 for ; Tue, 23 Mar 2004 05:12:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5ipY-000C02-KT for v6ops-data@psg.com; Tue, 23 Mar 2004 10:08:20 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5ipN-000ByH-M5 for v6ops@ops.ietf.org; Tue, 23 Mar 2004 10:08:09 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2NA88Ot025510 for ; Tue, 23 Mar 2004 10:08:08 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA20260 for ; Tue, 23 Mar 2004 10:08:03 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2NA83L06375 for v6ops@ops.ietf.org; Tue, 23 Mar 2004 10:08:03 GMT Date: Tue, 23 Mar 2004 10:08:03 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Recent navel gazing - we need to stop wasting cycles on FUD Message-ID: <20040323100803.GG4896@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <42033A47-7C55-11D8-87E3-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42033A47-7C55-11D8-87E3-00039376A6AA@sun.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Alain, In what way are you seriously using 6to4 in a large enterprise? I would estimate that 90%+ of the academic sites use manually configured tunnels. I don't know of any universities connecting to national services with 6to4 (there may be some, of course :). Tim On Mon, Mar 22, 2004 at 03:04:22PM -0800, Alain Durand wrote: > > On Mar 20, 2004, at 7:25 AM, Pekka Savola wrote: > > >On Fri, 19 Mar 2004, Tony Hain wrote: > >>6to4 > >>- Enterprise -> allows multiple subnet deployments behind the tunnel > >>endpoint with a public IPv4 address. > > > >I don't think any serious enterprise would want to do anything as > >unreliable as 6to4. Just get a configured tunnel w/ prefix delegation > >or native access. > > I'd like to think of the company I work for as being serious. > We are using 6to4. Not in the way you think, but we are still using it > very seriously. > > Your comment is out of place. > > - Alain. > From owner-v6ops@ops.ietf.org Tue Mar 23 05:40: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 FAA16556 for ; Tue, 23 Mar 2004 05:40:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5jJY-000HXQ-Iz for v6ops-data@psg.com; Tue, 23 Mar 2004 10:39:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5jJN-000HVq-II for v6ops@ops.ietf.org; Tue, 23 Mar 2004 10:39:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NAd1k02648; Tue, 23 Mar 2004 12:39:01 +0200 Date: Tue, 23 Mar 2004 12:39:01 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Tony Hain , Subject: Re: Recent navel gazing - we need to stop wasting cycles on FUD In-Reply-To: <42033A47-7C55-11D8-87E3-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 22 Mar 2004, Alain Durand wrote: > > I don't think any serious enterprise would want to do anything as > > unreliable as 6to4. Just get a configured tunnel w/ prefix delegation > > or native access. > > I'd like to think of the company I work for as being serious. > We are using 6to4. Not in the way you think, but we are still using it > very seriously. It's an entirely different ballgame if you don't use 6to4 for external connectivity (but internal only, as I recall from previous exchanges) .. so for the general 6to4 commectivity, I believe the comment is still rather accurate. -- 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 Mar 23 09:35:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29359 for ; Tue, 23 Mar 2004 09:35:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5mwJ-0005Be-Ng for v6ops-data@psg.com; Tue, 23 Mar 2004 14:31:35 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5mu9-0004of-5g for v6ops@ops.ietf.org; Tue, 23 Mar 2004 14:29:21 +0000 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 15:29:11 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : Recent navel gazing - we need to stop wasting cycles on FUD Date: Tue, 23 Mar 2004 15:29:11 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC245587F@ftrdmel3.rd.francetelecom.fr> Thread-Topic: Recent navel gazing - we need to stop wasting cycles on FUD Thread-Index: AcQN9xMQXBx/3DdIQueOHv8aK3VpLwC5oIlQ From: "BAUDOT Alain FTRD/DMI/CAE" To: "Tony Hain" , X-OriginalArrivalTime: 23 Mar 2004 14:29:11.0606 (UTC) FILETIME=[35990D60:01C410E3] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree with Tony's point. I guess, anyway, we have to take care about = mechanisms having pieces into different environments, since they may = have different requirements. Typical cases are obviously unman & ISP, or = enterprise & ISP, assuming that a reasonnable scaled deployment should = involve hopefully ISPs. Alain. -----Message d'origine----- De : owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] De la = part de Tony Hain Envoy=E9 : vendredi 19 mars 2004 22:14 =C0 : = v6ops@ops.ietf.org Objet : Recent navel gazing - we need to stop wasting = cycles on FUD Several recent threads are about trying to out-guess the market and pick = the one-size-fits-all answer to deployment. The entire point of the = scenarios documents was to focus the communities on their area of = expertise, so we don't continue arguing that 'we don't need X for my = environment, therefore we don't need X'. While it is appropriate to = point out when specific mechanisms are or are not useful, it is not = appropriate to force the entire diverse Internet into a single, or even = restricted set, deployment approach. We are close to finishing the work on scenarios so we can start applying = the proposed tools to them. Rather than the continuing efforts to kill = off technologies out of context, the applicability work needs to be = completed. While it is useful to make sure we have minimal duplication = and overlap, as I look at the proposed tool set I don't see any useful = reduction. We can discuss the mechanics of any individual tool, but only = in the context that we know exactly what problem we are solving. The = continuing FUD is based on application of a tool in an environment that = it is specifically not suited for.=20 FWIW as I see the tools and their application; 6to4=20 - Enterprise -> allows multiple subnet deployments behind the tunnel = endpoint with a public IPv4 address.=20 - Unmanaged -> this is both simple, and in common use as an automated = prefix delegation approach. ISATAP=20 - Enterprise -> where the apps & hosts move before the infrastructure = (this is reasonable both from the perspective of demonstrating value, = and from the perspective that hosts are generally upgraded before = infrastructure),=20 - ISP -> it has value in the Cable operator environment where the = management side of the gateway is addressed in private IPv4 space, yet = the gateway needs to tunnel across older DOCSIS equipment that will take = years to replace (6to4 would work with public addresses, and manual = config is always an option).=20 Teredo - Unmanaged -> automated single subnet & needed to deal with the NAT = managed by someone else problem (home / hotel / airport ...).=20 - ISP -> automated single subnet & needed to deal with the NAT managed = by someone else problem (the charging for addresses approach has = resulted in customers deploying infrastructure, and getting a service = behind that device is proving to be an issue).=20 Tunnel brokers as a class - ISP -> for the aggressive ISP that wants to take mindshare away from = local competitors, there is an opportunity to offer new applications = (this is really no different than the Dial-up ISP case tunneling over = the lethargic PSTN). Translators as a class - 3G -> needed if IPv6 only handsets are expected to directly reach the = legacy IPv4 Internet or devices that have not reached their economic end = of life Application gateways - 3G / ISP / Enterprise & Unmanaged -> useful if IPv6-only appliances = appear in mass before infrastructure gets upgraded (see Sony press = releases). Each of these tools solves a different subset of the problem space. It = is up to the market to decide which have value. The IETF's role is to = make sure that the mechanisms are well documented so all implementations = have the opportunity to interoperate. If there are operational = recommendations or warnings those are also appropriate to document. = Attempts to kill off technology X because some people think the market = will want Y only ensures that technology X will be implemented = differently by each vendor. All of these technologies need to be on the = standards track, and the recent discussion about making them = experimental is BS that needs to stop. We can't have a reasoned = discussion about the useful / extraneous features of any technology = until we nail the target deployment environments.=20 Tony=20 From owner-v6ops@ops.ietf.org Tue Mar 23 12:16: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 MAA13075 for ; Tue, 23 Mar 2004 12:16:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5pTR-000JSe-3v for v6ops-data@psg.com; Tue, 23 Mar 2004 17:13:57 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5pTJ-000JOj-MQ for v6ops@ops.ietf.org; Tue, 23 Mar 2004 17:13:49 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 09:13:13 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Mar 2004 09:13:49 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 09:14:04 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 09:13:47 -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); Tue, 23 Mar 2004 09:13:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.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: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] Date: Tue, 23 Mar 2004 09:13:03 -0800 Message-ID: Thread-Topic: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] thread-index: AcQQmIzzLlVQqZUmT5qdUkH7HK4LHwAX/Y6w From: "Christian Huitema" To: "Erik Nordmark" , "Pekka Savola" Cc: , X-OriginalArrivalTime: 23 Mar 2004 17:13:44.0300 (UTC) FILETIME=[322E9AC0:01C410FA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > Luckily enough ND-proxy is not going to be IETF standard, but > > Informational :). Nobody has bothered to document (different flavors > > of) proxy-ARP, but that's there in the similar way as well -- without > > spanning tree, and seems to be working whereever it's used. >=20 > Sorry, I missed the last sentence. >=20 > The proxy arp implementations I know of decrement ttl. > Are there proxy arp implementations that do not decrement ttl? >=20 > Can't compare that with ndproxy which doesn't decrement the hop count. Actually, I know of quite a few NAT boxes that do not decrement the TTL. I see "ndproxy" in much the same light as I see NAT: a cheap hack that allows multiple hosts to connect to a single attachment without explicitly requiring individual addresses or an explicit prefix. In the same application domain, I would rather see vendors shipping an IPv6 ndproxy than an IPv6 NAT.=20 Basic NDproxy only works with limited topologies. However, it does work well with the simple "single subnet in the home" topology. In that topology, even SEND makes sense -- at least between machines on the home network. The combination of "works well in many cases" and "can be deployed autonomously" is known to guarantee some deployment -- much like the same properties allowed the deployment of NAT, even as NAT were not described in any IETF standard.=20 I agree that IETF standardization should focus on multi-link subnets, which solves the very nasty "cascade of NAT" problems. However, there is a lot of value in a document that says "if you were thinking of developing an IPv6 NAT, please do NDproxy instead". The proper procedure may in fact be a publication as proposed standard, that could then be made obsolete by the proposed standard for multi-link subnets. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Mar 23 13:17: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 NAA16183 for ; Tue, 23 Mar 2004 13:17:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5qPw-0008B6-GL for v6ops-data@psg.com; Tue, 23 Mar 2004 18:14:24 +0000 Received: from [4.16.89.28] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5qPo-00089t-Ij for v6ops@ops.ietf.org; Tue, 23 Mar 2004 18:14:16 +0000 Received: from eaglet (127.0.0.1:4001) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 23 Mar 2004 10:14:20 -0800 From: "Tony Hain" To: "'Pekka Savola'" , "'Alain Durand'" Cc: Subject: RE: Recent navel gazing - we need to stop wasting cycles on FUD Date: Tue, 23 Mar 2004 10:14:14 -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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQQw2HgYd5r82I9TquSo6m6njrBywAPFxpQ X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=1.4 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Mon, 22 Mar 2004, Alain Durand wrote: > > > I don't think any serious enterprise would want to do anything as > > > unreliable as 6to4. Just get a configured tunnel w/ prefix delegation > > > or native access. > > > > I'd like to think of the company I work for as being serious. > > We are using 6to4. Not in the way you think, but we are still using it > > very seriously. > > It's an entirely different ballgame if you don't use 6to4 for external > connectivity (but internal only, as I recall from previous exchanges) > .. so for the general 6to4 commectivity, I believe the comment is > still rather accurate. The point is the validity of the statement really doesn't matter. There is a valid use for 6to4, as there is with all the other transition technologies on the table. There is no duplication between them we can identify (other than possibly in the tunnel broker collection), so we appear to have a minimum set. Thus they need to be standardized, which may include modifications from the current documents. We also have a set of environment descriptions, and a charter to identify which of the standardized technologies applies. Specifically 6to4 is on the list of Enterprise focused technologies, so how it gets used is what needs to be documented. We do not need to waste time trying to kill any one of the technologies simply because it does not provide a one-size-fits-all answer, or does not fit someone's NIH profile. While manually configured tunnels may appear more stable, they will only scale to a point. For the period beyond the scale limitations of manual tunnels and full deployment of native services, an automated tool like 6to4 allows deployment to continue. If any one network manager chooses not to deploy it, that is a local choice. The job of the IETF is to get the standardization work done, then provide hints about intended uses and potential challenges. The market is perfectly capable of figuring out which tools really apply to the local situation, and nothing the IETF publishes will change that. If the IETF chooses not to standardize the technologies or provide usage hints, the market will be left to pick from non-interoperating approaches, but will none the less meet its needs to achieve a haphazard deployment. Tony From owner-v6ops@ops.ietf.org Tue Mar 23 13:32: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 NAA16713 for ; Tue, 23 Mar 2004 13:32:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5qfb-000BSa-Ol for v6ops-data@psg.com; Tue, 23 Mar 2004 18:30:35 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5qfG-000BOb-35 for v6ops@ops.ietf.org; Tue, 23 Mar 2004 18:30:14 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2NIUCOr008388 for ; Tue, 23 Mar 2004 18:30:13 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA14965 for ; Tue, 23 Mar 2004 18:30:09 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2NIU9p21616 for v6ops@ops.ietf.org; Tue, 23 Mar 2004 18:30:09 GMT Date: Tue, 23 Mar 2004 18:30:09 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Recent navel gazing - we need to stop wasting cycles on FUD Message-ID: <20040323183009.GT19530@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Mar 23, 2004 at 10:14:14AM -0800, Tony Hain wrote: > While manually configured tunnels may > appear more stable, they will only scale to a point. For the period beyond > the scale limitations of manual tunnels and full deployment of native > services, an automated tool like 6to4 allows deployment to continue. Hi Tony, I think you're making very valid points. Experience in European NRENs is that in the absence of native university links, manual tunnels are used, rather than 6to4. Here, the rate of change of tunnel configuration (add/delete) is important, and I think the DFN had the largest count at some 300 enterprise sites (which interestingly have largely been moved to production addressing from 6bone, so there's another lesson to be learnt in there...). Routing also has to be configured for any university site attaching natively anyway... then there are other resources required such as addres space allocation/management, etc. I agree SOHO networks where the ISP has (tens+ of) thousands of customers is a different case. Tim From owner-v6ops@ops.ietf.org Tue Mar 23 15:49:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27766 for ; Tue, 23 Mar 2004 15:49:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5smb-000ERB-Pr for v6ops-data@psg.com; Tue, 23 Mar 2004 20:45:57 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5smW-000EQW-Nc for v6ops@ops.ietf.org; Tue, 23 Mar 2004 20:45:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27200; Tue, 23 Mar 2004 15:45:49 -0500 (EST) Message-Id: <200403232045.PAA27200@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-onlinkassumption-01.txt Date: Tue, 23 Mar 2004 15:45:49 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.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 : IPv6 Neighbor Discovery On-Link Assumption Considered Harmful Author(s) : S. Roy, et al. Filename : draft-ietf-v6ops-onlinkassumption-01.txt Pages : 9 Date : 2004-3-23 This document proposes a change to the IPv6 Neighbor Discovery conceptual host sending algorithm. According to the algorithm, when a host's default router list is empty, the host assumes that all destinations are on-link. This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-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-onlinkassumption-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-onlinkassumption-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-3-23155639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-onlinkassumption-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-onlinkassumption-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-23155639.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Mar 23 18:08: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 SAA09728 for ; Tue, 23 Mar 2004 18:08:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5uxJ-000MFi-2T for v6ops-data@psg.com; Tue, 23 Mar 2004 23:05:09 +0000 Received: from [66.163.170.82] (helo=smtp812.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B5uxH-000MF9-TX for v6ops@ops.ietf.org; Tue, 23 Mar 2004 23:05:07 +0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 23 Mar 2004 21:42:50 -0000 Message-ID: <013201c4111f$c9b29980$861167c0@adithya> From: "Mohan Parthasarathy" To: "Christian Huitema" , "Erik Nordmark" , "Pekka Savola" Cc: , References: Subject: Re: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] Date: Tue, 23 Mar 2004 13:42:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Luckily enough ND-proxy is not going to be IETF standard, but > > Informational :). Nobody has bothered to document (different flavors > > of) proxy-ARP, but that's there in the similar way as well -- without > > spanning tree, and seems to be working whereever it's used. >> >> Sorry, I missed the last sentence. >> >> The proxy arp implementations I know of decrement ttl. >> Are there proxy arp implementations that do not decrement ttl? >> >> Can't compare that with ndproxy which doesn't decrement the hop count. >Actually, I know of quite a few NAT boxes that do not decrement the TTL. Any reason why these boxes don't do it ? I thought that one of the original versions of the ND proxy draft specified that hop limit would be decremented. Was it removed later ? What is the reason for not needing hop count decrementing in ND-proxy ? thanks mohan >I see "ndproxy" in much the same light as I see NAT: a cheap hack that >allows multiple hosts to connect to a single attachment without >explicitly requiring individual addresses or an explicit prefix. In the >same application domain, I would rather see vendors shipping an IPv6 >ndproxy than an IPv6 NAT. >Basic NDproxy only works with limited topologies. However, it does work >well with the simple "single subnet in the home" topology. In that >topology, even SEND makes sense -- at least between machines on the home >network. The combination of "works well in many cases" and "can be >deployed autonomously" is known to guarantee some deployment -- much >like the same properties allowed the deployment of NAT, even as NAT were >not described in any IETF standard. > >I agree that IETF standardization should focus on multi-link subnets, >which solves the very nasty "cascade of NAT" problems. However, there is >a lot of value in a document that says "if you were thinking of >developing an IPv6 NAT, please do NDproxy instead". The proper procedure >may in fact be a publication as proposed standard, that could then be >made obsolete by the proposed standard for multi-link subnets. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Mar 24 01:28: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 BAA00179 for ; Wed, 24 Mar 2004 01:28:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B61ou-000GDO-6M for v6ops-data@psg.com; Wed, 24 Mar 2004 06:24:56 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B61oi-000G9L-O3 for v6ops@ops.ietf.org; Wed, 24 Mar 2004 06:24:44 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2O6Oiwr025117 for ; Tue, 23 Mar 2004 23:24:44 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HV200385HT7DB@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 23 Mar 2004 23:24:44 -0700 (MST) Received: from [192.168.1.101] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HV200KXZHT63N@mail.sun.net> for v6ops@ops.ietf.org; Tue, 23 Mar 2004 23:24:43 -0700 (MST) Date: Tue, 23 Mar 2004 22:24:40 -0800 From: Alain Durand Subject: Re: Recent navel gazing - we need to stop wasting cycles on FUD In-reply-to: <20040323100803.GG4896@login.ecs.soton.ac.uk> To: Tim Chown Cc: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <42033A47-7C55-11D8-87E3-00039376A6AA@sun.com> <20040323100803.GG4896@login.ecs.soton.ac.uk> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 23, 2004, at 2:08 AM, Tim Chown wrote: > Hi Alain, > > In what way are you seriously using 6to4 in a large enterprise? > > I would estimate that 90%+ of the academic sites use manually > configured > tunnels. I don't know of any universities connecting to national > services with 6to4 (there may be some, of course :). We have a scenario that is somehow equivalent to a very large enterprise with many branch offices connected together by a private IPv4 only network. An important characteristic is that there are no communication with the "outside" world, neither in v4 nor in v6, and this is by design. By outside, I mean outside of the enterprise, not outside of 6to4 2002::/16 prefix) I agree, this is different from the original intend of 6to4, and it is based on the premise that there are no communications to the outside world, neither in v4 nor in v6, except via IT-controlled proxies. In this scenario, 6to4 does marvels. Deploying IPv6 in a branch office is a 5 minute job, that is done by configuring 6to4 on one access router. However, I share the concerns of many that in other contexts, 6to4 may not be as desirable, especially if external connectivity is required. The point I'm trying to make is that one should not confuse, as Pekka did, the protocol with how one could use it. - Alain. From owner-v6ops@ops.ietf.org Wed Mar 24 02:12: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 CAA14703 for ; Wed, 24 Mar 2004 02:12:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B62Wz-000PT9-RM for v6ops-data@psg.com; Wed, 24 Mar 2004 07:10:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B62Wo-000PPx-73 for v6ops@ops.ietf.org; Wed, 24 Mar 2004 07:10:18 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2O7AH224017; Wed, 24 Mar 2004 09:10:17 +0200 Date: Wed, 24 Mar 2004 09:10:17 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: sebastien.roy@sun.com Subject: WG Last Call: On-link Assumption and IPv6 On by default Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, This is a WG Last Call for comments on sending two documents to the IESG: 1) draft-ietf-v6ops-onlinkassumption-01.txt, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", target category BCP. 2) draft-ietf-v6ops-v6onbydefault-01.txt "Issues with Dual Stack IPv6 on by Default", target category Informational. Please review the documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that these documents are ready to go to the IESG. The last call will end in about 2 weeks, on 7th April. Pekka & Jonne From owner-v6ops@ops.ietf.org Wed Mar 24 11:34: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 LAA04923 for ; Wed, 24 Mar 2004 11:34:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6BGn-0000UL-1Y for v6ops-data@psg.com; Wed, 24 Mar 2004 16:30:21 +0000 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6BGW-0000Sq-IT for v6ops@ops.ietf.org; Wed, 24 Mar 2004 16:30:04 +0000 Received: from fernando.gont.com.ar ([200.68.238.103]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id NAA10196; Wed, 24 Mar 2004 13:49:13 -0400 Message-Id: <4.3.2.7.2.20040323234802.00beca80@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Mar 2004 23:56:36 -0300 To: "Christian Huitema" , "Erik Nordmark" , "Pekka Savola" From: Fernando Gont Subject: RE: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] Cc: , 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.com X-Spam-Status: No, hits=-4.5 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 At 09:13 23/03/2004 -0800, Christian Huitema wrote: >I see "ndproxy" in much the same light as I see NAT: a cheap hack that >allows multiple hosts to connect to a single attachment without >explicitly requiring individual addresses or an explicit prefix. Why should a host *need* to "own" a public network attachment point in order to be able to connect to a public network? It's true that NATs, as we know them, have been deployed as a hack. However, that does not mean they *are* a hack. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-v6ops@ops.ietf.org Wed Mar 24 17:07:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24665 for ; Wed, 24 Mar 2004 17:07:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6GTt-00045g-EG for v6ops-data@psg.com; Wed, 24 Mar 2004 22:04:13 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6GTn-00044P-JY for v6ops@ops.ietf.org; Wed, 24 Mar 2004 22:04:07 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 24 Mar 2004 14:01:35 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2OM44RQ014175 for ; Wed, 24 Mar 2004 17:04:05 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.128]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHB71031; Wed, 24 Mar 2004 17:04:04 -0500 (EST) Message-Id: <4.3.2.7.2.20040324164856.02993b18@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Mar 2004 17:04:02 -0500 To: v6ops@ops.ietf.org From: Ralph Droms Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt In-Reply-To: References: <4.3.2.7.2.20040319055603.00c43600@flask.cisco.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.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 - comments in line... - Ralph At 03:08 PM 3/22/2004 +0200, Pekka Savola wrote: >On Fri, 19 Mar 2004, Ralph Droms wrote: > > In section 4.1.2, while the statement "The basic use of DHCP is insecure." > > is technically true, it does not apply to the discussion of DHCPv6 prefix > > delegation. Section 15 of RFC3396 gives specific guidelines for the > use of > > DHCPv6 authentication for DHCPv6 PD. DHCPv6 authentication is defined as > > part of the base DHCPv6 specification, in section 21 of RFC3315. > >Right. > > > The statement "To be useful in such environment in practice, the practical > > details of managing the DHCP authentication need to be analyzed." needs to > > be explained. How is the authentication specified in RFC3315 and > > recommended for DHCPv6 PD in RFC3396 not adequate? > >(Operational) key management seems problematic, even though DHCP >provides support for that. How is operational key management for the authentication mechanism described in RFC3315 more problematic than for other mechanisms that use shared keys? >Maybe reword: > > The basic use of DHCP is insecure. This may be a problem if the link > between gateway and ISP is shared by multiple subscribers. DHCP > specification includes authentication options, but does not describe > the task of managing the keys, and how the information would be > shared between the customer and the ISP. To be useful in such > environment in practice, the practical details of managing the DHCP > authentication need to be analyzed. > >to: > > DHCP is insecure unless authentication is used. This may be a > particular problem if the link between gateway and ISP is shared by > multiple subscribers. DHCP specification includes authentication > options, but the operational procedures for managing the keys and > methods for sharing the required information between the customer > and the ISP are unclear. To be secure in such environment in > practice, the practical details of managing the DHCP authentication > need to be analyzed. > >Perhaps that is a bit more fair statement of the issue(s) involved. No, I honestly don't think it's any more fair. Most service providers provide complete isolation of customer traffic through filtering even if the link appears to be shared among multiple customers. If customers do truly share a link, there are *many* other attacks available and pointing out DHCP as a specific problem is only telling part of the story. Finally, I still haven't heard an explanation of the requirement that "the practical details of managing the DHCP authentication need to be analyzed." DHCP can use a password provided by the service provider to the customer. What additional analysis do we need to perform? The issue of DHCPv6 security is adequately addressed in RFC3315 and need not be rehashed here. Anyone who reads RFC3315 (btw, the reference [DNSDHCPV6] is never cited anywhere in the body of the document) will see the security analysis for DHCPv6. > > What are the security implications of ND proxy? > >Roughly equal or slightly worse, but then again, it would probably not >be applicable in this specific ("multiple subscribers in one big LAN") >environment in any case. So ND proxy doesn't represent a security problem and requires no authentication because its scaling properties preclude its use in what you consider to be a typical deployment scenario? Whatever the situation, the security issues for ND proxy should be mentioned as well as those for DHCPv6. >-- >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 Mar 25 00:39: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 AAA15130 for ; Thu, 25 Mar 2004 00:39:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6NXW-000DGt-DB for v6ops-data@psg.com; Thu, 25 Mar 2004 05:36:26 +0000 Received: from [4.16.89.28] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6NXV-000DGh-DU for v6ops@ops.ietf.org; Thu, 25 Mar 2004 05:36:25 +0000 Received: from eaglet (127.0.0.1:4553) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 24 Mar 2004 21:36:30 -0800 From: "Tony Hain" To: "'Pekka Savola'" , Cc: Subject: RE: WG Last Call: On-link Assumption and IPv6 On by default Date: Wed, 24 Mar 2004 21:36:22 -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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQRb4OXsK95CTmVRniHXxmepLgL3QAmSaCw X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Onbydefault needs some minor wording changes, but is otherwise ready. Onlinkassumption has a whining tone, and is clearly not ready. Rather than pointing out issues, it tries to justify changing everyone's behavior to match a particular implementation. The most it should do is recommend a policy knob to disable the assumption. Tony draft-ietf-v6ops-v6onbydefault-01.txt 3.3 - tunneling discussion should point out the same is true for tunneling of IPv4, so this is really a misconfigured firewall, not an IPv6 problem 4. Applications also need to be aware that the fact that a dual stack destination's IPv6 address is published in the DNS does not necessarily imply that all services on that destination function over IPv6. This is also true for IPv4. Just because www.sun.com has an IPv4 address does not mean that the SMTP service works on that destination. 5. Section 3 should be moved to here, there is no need for a separate discussion with a pointer. draft-ietf-v6ops-onlinkassumption-01.txt 2. discussion about workaround should point out that many users don't have the appropriate privileges or knowledge to manually configure addresses 3.1 - so the text finds fault in address selection rules because an arguably broken implementation decides that an empty router list means that the local interface becomes the default router??? Rather than call the rules at fault, the section should point out the fallacy of that implementation approach. 3.2 - establishes an exaggerated scenario then complains that the result takes too long. The same would be true for a long list of IPv4 addresses where the only accessible one was the last on the list. 3.3 - is speculation about a particular implementation detail, not an even-handed discussion about alternatives. 2 is what the default action should be. 3.4 - this should be moved to the security considerations section. 4. rather than change the spec, this should simply recommend that implementations include a policy option to disable the 'on link assumption' if desired. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Pekka Savola > Sent: Tuesday, March 23, 2004 11:10 PM > To: v6ops@ops.ietf.org > Cc: sebastien.roy@sun.com > Subject: WG Last Call: On-link Assumption and IPv6 On by default > > Hi all, > > This is a WG Last Call for comments on sending two documents to the > IESG: > > 1) draft-ietf-v6ops-onlinkassumption-01.txt, > "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", > target category BCP. > > 2) draft-ietf-v6ops-v6onbydefault-01.txt > "Issues with Dual Stack IPv6 on by Default", > target category Informational. > > Please review the documents carefully, and send your feedback to the > list. Please also indicate whether or not you believe that these > documents are ready to go to the IESG. > > The last call will end in about 2 weeks, on 7th April. > > Pekka & Jonne From owner-v6ops@ops.ietf.org Thu Mar 25 05:41: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 FAA14177 for ; Thu, 25 Mar 2004 05:41:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6SGo-0007zP-Ow for v6ops-data@psg.com; Thu, 25 Mar 2004 10:39:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6SGm-0007yk-86 for v6ops@ops.ietf.org; Thu, 25 Mar 2004 10:39:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2PAdNQ17409; Thu, 25 Mar 2004 12:39:23 +0200 Date: Thu, 25 Mar 2004 12:39:23 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org, Subject: RE: WG Last Call: On-link Assumption and IPv6 On by default In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Tony, Thanks for good feedback. You raise good points, which warrant clarifications and/or more discussion on certain parts of the document(s). More inline.. On Wed, 24 Mar 2004, Tony Hain wrote: > Onbydefault needs some minor wording changes, but is otherwise ready. OK. > Onlinkassumption has a whining tone, and is clearly not ready. Rather than > pointing out issues, it tries to justify changing everyone's behavior to > match a particular implementation. The most it should do is recommend a > policy knob to disable the assumption. I have to personally disagree with this. I don't think this depends on the implementation technique (see below). Further, having a policy knob to disable the assumption would be harmful for most of the users, even though only few (if any?) would find it useful -- so if there is a knob, I think it would have to be to re-enable the assumption (more of this below as well). > draft-ietf-v6ops-v6onbydefault-01.txt > 3.3 - tunneling discussion should point out the same is true for tunneling > of IPv4, so this is really a misconfigured firewall, not an IPv6 problem Do you refer to the misconfigured firewall problem or the VPN problem? Those seem to be slightly different, and could maybe be discussed in subsections. I'm assuming the former. Yes, this seems like a misconfigured firewall. This should be mentioned more clearly. However, it's probably still worth stating, as we don't want everyone to completely block proto-41 as a safeguard. And besides, this cannot really be fixed, in general, by firewall config only -- consider Teredo which is infamous for burrowing through firewalls alike -- and you'll have difficult time trying to prevent that.. Automatic connectivity tools such as 6to4 or Teredo aren't expected to be commonplace, as with IPv6, so this seems to be an issue worth noting. > 4. Applications also need to be aware that the fact that a > dual stack destination's IPv6 address is published in the DNS does > not necessarily imply that all services on that destination function > over IPv6. > > This is also true for IPv4. Just because www.sun.com has an IPv4 address > does not mean that the SMTP service works on that destination. This seems slightly different, because www.sun.com is not listed as their MX record -- there is no reason anyone would assume it's the right place to send mail to @sun.com addresses? On the other hand, if www.sun.com listed both A and AAAA records, it should obviously work with either A and AAAA. The argument is that even if AAAA (or A) doesn't work (for whatever reason), one should fall back to the other. In in a sense, this is indeed similar with IPv4. For example, consider the case of www.sun.com having two A records. If the first doesn't work, you should be able to fall back to the second one. This gets more required, practical, and complicated (from app developer point of view) with the introduction of IPv6.. (typical v4 apps don't handle multiple addresses AFAIK, but that is a requirement for v4/v6 apps.) > 5. Section 3 should be moved to here, there is no need for a separate > discussion with a pointer. Did you mean section 3.3, not section 3? I assume so. Actually, Security considerations should be expanded to include more than just a pointer: discuss the issues in more general (I have comments pending on that). It may still be worth to have (longer) discussion in sect 3.3, and just refer (or summarize) that from Security Considerations, but that would probably remain to be seen. > draft-ietf-v6ops-onlinkassumption-01.txt > > 2. discussion about workaround should point out that many users don't have > the appropriate privileges or knowledge to manually configure addresses Good point. (Which can also go the other way: the hosts are not expected to have manually configured addresses unless the users have privileges to configure them -- thus reducing the need to cover for "two distinct prefixes on the link" -scenario in the first place.) > 3.1 - so the text finds fault in address selection rules because an arguably > broken implementation decides that an empty router list means that the local > interface becomes the default router??? Rather than call the rules at fault, > the section should point out the fallacy of that implementation approach. But isn't the result in the end still about the same, no matter what implementation technique would be used? If you have an empty router list (rather than a default on-link route), RFC2461 sect 5.2 still states that everything should be considered to be on-link. The implementation techniques appear to be equivalent in this scenario -- or could you elaborate? This is something warranting clarification in any case.. > 3.2 - establishes an exaggerated scenario then complains that the result > takes too long. The same would be true for a long list of IPv4 addresses > where the only accessible one was the last on the list. But this specific case would not happen with IPv4, as it has no on-link assumption, right? Obviously, if you do send out e.g. a lot of IPv4 TCP SYNs and get RSTs back except for the last one, the situation is the same (but that's a separate issue, discussed a bit in the v6onbydefault doc sect 2.3). > 3.3 - is speculation about a particular implementation detail, not an > even-handed discussion about alternatives. 2 is what the default action > should be. I see this case as a rather important detail (when analyzing that part of the spec -- in general it isn't necessarily too criticial), and probably not something best left for implementers' discretion -- because we'll get (and have gotten) inconsistent results. You say 2 is what it should be; some say 1 is the simplest bet; others say don't do anything because no action you make can lead to consistent results. Being targeted at BCP, if the recommendation was not to disable this feature altogether, the secondary resolution could be "well, if you implement it in any case, do it like this [gain WG consensus on what we would recommend in such a case]". Not sure if this is worth the effort, but could be brought up. > 3.4 - this should be moved to the security considerations section. It seems that section 3 is maybe more balanced with all the issues described there. That said, there should probably be more text in security considerations.. > 4. rather than change the spec, this should simply recommend that > implementations include a policy option to disable the 'on link assumption' > if desired. I have to disagree rather strongly with this. In RFC2461bis, this part of the conceptual algorithm has already been removed, and no clear arguments have been presented why this would be a problem. On the other hand, I would not object to having a toggle which would restore the on-link assumption behavior, if someone would want to still provide it for some unknown purposes. But to ensure that the default is sane for the general consumption, such toggles should be disabled by default. -- 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 Mar 25 05:54: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 FAA14507 for ; Thu, 25 Mar 2004 05:54:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6SUH-000Aqm-7p for v6ops-data@psg.com; Thu, 25 Mar 2004 10:53:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6SUF-000Aq0-Dz for v6ops@ops.ietf.org; Thu, 25 Mar 2004 10:53:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2PArD917641; Thu, 25 Mar 2004 12:53:13 +0200 Date: Thu, 25 Mar 2004 12:53:13 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: v6ops@ops.ietf.org Subject: DHCP auth in unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] In-Reply-To: <4.3.2.7.2.20040324164856.02993b18@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 24 Mar 2004, Ralph Droms wrote: > > > The statement "To be useful in such environment in practice, the practical > > > details of managing the DHCP authentication need to be analyzed." needs to > > > be explained. How is the authentication specified in RFC3315 and > > > recommended for DHCPv6 PD in RFC3396 not adequate? > > > >(Operational) key management seems problematic, even though DHCP > >provides support for that. > > How is operational key management for the authentication mechanism described > in RFC3315 more problematic than for other mechanisms that use shared keys? Those protocols are not often used 1) between administrative domains [where key management is arguably simpler] and 2) before getting IP addresses in the first place (that is, if you don't have an address yet, you cannot run mechanisms which help in making the key sharing simpler). > >Maybe reword: > > > > The basic use of DHCP is insecure. This may be a problem if the link > > between gateway and ISP is shared by multiple subscribers. DHCP > > specification includes authentication options, but does not describe > > the task of managing the keys, and how the information would be > > shared between the customer and the ISP. To be useful in such > > environment in practice, the practical details of managing the DHCP > > authentication need to be analyzed. > > > >to: > > > > DHCP is insecure unless authentication is used. This may be a > > particular problem if the link between gateway and ISP is shared by > > multiple subscribers. DHCP specification includes authentication > > options, but the operational procedures for managing the keys and > > methods for sharing the required information between the customer > > and the ISP are unclear. To be secure in such environment in > > practice, the practical details of managing the DHCP authentication > > need to be analyzed. > > > >Perhaps that is a bit more fair statement of the issue(s) involved. > > No, I honestly don't think it's any more fair. Most service providers > provide complete isolation of customer traffic through filtering even if the > link appears to be shared among multiple customers. But then it no longer is a shared link, and the above does not apply. But you raise a good point: I think we should spell out the obvious, that rather than trying to operate with *really* shared links, the operators should strongly consider mechanisms (any pointers?) which achieve the isolation, making the issues more complex. > If customers do truly > share a link, there are *many* other attacks available and pointing out DHCP > as a specific problem is only telling part of the story. Yep, but that's the only story being covered in that section of the document... > Finally, I still > haven't heard an explanation of the requirement that "the practical details > of managing the DHCP authentication need to be analyzed." DHCP can use a > password provided by the service provider to the customer. What additional > analysis do we need to perform? If they provide a password, that's fine. As long as it's clear how they provide it, and how it would end up being configured in the router. (Trivial if the ISP ships the box to the user, possibly non-trivial otherwise.) I think the shared key model also requires that the key stays as it forever (providing for better brute-force attacks against it), unless you do re-keying or the like somehow. But that would probably be equally problematic. > The issue of DHCPv6 security is adequately addressed in RFC3315 and need > not be rehashed here. Anyone who reads RFC3315 (btw, the reference > [DNSDHCPV6] is never cited anywhere in the body of the document) will > see the security analysis for DHCPv6. The security analysis in there is restricted to the scenario which may not be directly applicable here: This protocol is focused on solving the intradomain problem where the out-of-band exchange of a shared key is feasible. This is inter-domain, and whether sharing keys is feasible is an open question. (In some cases, with some constraints, it certainly seems to be possible, but...) > > > What are the security implications of ND proxy? > > > >Roughly equal or slightly worse, but then again, it would probably not > >be applicable in this specific ("multiple subscribers in one big LAN") > >environment in any case. > > So ND proxy doesn't represent a security problem and requires no > authentication because its scaling properties preclude its use in what you > consider to be a typical deployment scenario? Yep. > Whatever the situation, > the security issues for ND proxy should be mentioned as well as those > for DHCPv6. Agreed. -- 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 Mar 25 15:43: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 PAA20204 for ; Thu, 25 Mar 2004 15:43:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6bcw-0003BY-Pq for v6ops-data@psg.com; Thu, 25 Mar 2004 20:38:58 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6bcv-0003BF-0Y for v6ops@ops.ietf.org; Thu, 25 Mar 2004 20:38:57 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19573; Thu, 25 Mar 2004 15:38:54 -0500 (EST) Message-Id: <200403252038.PAA19573@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-09.txt Date: Thu, 25 Mar 2004 15:38:54 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.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 : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-09.txt Pages : 21 Date : 2004-3-25 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-analysis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-09.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-3-25154700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-25154700.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Mar 25 17:59: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 RAA29828 for ; Thu, 25 Mar 2004 17:59:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6dmT-000Oit-H3 for v6ops-data@psg.com; Thu, 25 Mar 2004 22:56:57 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6dmR-000Oih-Rd for v6ops@ops.ietf.org; Thu, 25 Mar 2004 22:56:56 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2PMusqY029540 for ; Thu, 25 Mar 2004 23:56:54 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 23:56:54 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 25 Mar 2004 23:56:54 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B1D@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: v6ops@ops.ietf.org Subject: comments on draft-ietf-v6ops-3gpp-analysis-09.txt Date: Thu, 25 Mar 2004 23:56:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Mar 2004 22:56:54.0081 (UTC) FILETIME=[77795B10:01C412BC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Some comments on the 3gpp analysis draft: Closer details for an applicable tunneling mechanism are not analyzed in this document. However, a simple host-to-router (automatic) tunneling mechanism may be a good fit. There is not yet consensus on the right approach. Primarily, ISATAP [ISATAP] has been proposed, but some issues have been raised about it, such as its unnecessary features and relative complexity for a simple task like this, and its inadequacy in providing security when crossing administrative domains. Proposed solution alternatives have been (at least) a simplified, but probably non-interoperable, version of ISATAP, and STEP [STEP]. In any case, further work is needed to find out the requirements for the scenario and to specify the mechanism. This paragraph seems to conclude that STEP is the superior solution. This stems from the STEP vs. ISATAP competition which I don't quite understand. There is not such a big difference between simplified host-to-router ISATAP implementations that are deployed today and the functions specified in STEP. So to start with IMO the above paragraph should mention the existence of these implementations and their interoperability since it is important for mobile operators/vendors to know that there is something they can use. Now it basically says the opposite i.e. no interoperability and wait for further work. The paragraph above also talks about ISATAP complexity and this does not match the experience with the deployed base. We're talking about supporting RA/RS over a tunnel interface and that doesn't seem like something complex. Also there is no need for the sort of security across administrative domains mentioned above in 3gpp networks, since it is handled at layer 2. /Karim This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Fri Mar 26 02:14: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 CAA03224 for ; Fri, 26 Mar 2004 02:14:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6lUe-000FnI-Hd for v6ops-data@psg.com; Fri, 26 Mar 2004 07:11:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6lUc-000Fn6-Vn for v6ops@ops.ietf.org; Fri, 26 Mar 2004 07:11:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2Q7B0R03590; Fri, 26 Mar 2004 09:11:00 +0200 Date: Fri, 26 Mar 2004 09:11:00 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B1D@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote: > This paragraph seems to conclude that STEP is the superior solution. It can be read both ways, but the intent is not to push any particular solution, but to try to present arguments for the both sides. (co-chair hat on) This document is on the IESG agenda next week. Unless they raise issues about this, it's likely that it will be changed. There was a poll on the text on the list on 23 Jan, and no objections were seen on the list. So the current text appears to reflect WG rough consensus. (co-chair hat off) I'll respond to your arguments in a separate message. -- 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 Mar 26 02:35: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 CAA04720 for ; Fri, 26 Mar 2004 02:35:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6lqu-000IlM-RR for v6ops-data@psg.com; Fri, 26 Mar 2004 07:34:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6lqs-000Ijg-S4 for v6ops@ops.ietf.org; Fri, 26 Mar 2004 07:34:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2Q7Y0b04088; Fri, 26 Mar 2004 09:34:00 +0200 Date: Fri, 26 Mar 2004 09:34:00 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B1D@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Commenting as just another bozo on the bus.. On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote: > This stems from the STEP vs. ISATAP competition which I don't quite > understand. There is not such a big difference between simplified > host-to-router ISATAP implementations that are deployed today and the > functions specified in STEP. OK, let's have a few. ISATAP uses a pseudo-interface (this is especially problematic if the implementation also has a 6to4 pseudo-interface, and one big reason why ISATAP should be avoided). ISATAP accepts proto-41 packets from anyone. ISATAP does direct tunneling between the nodes (even if they aren't in the same admin domain, if deployed as you propose). ISATAP relies that the site has made appropriate protections at its perimeter, or else its security properties fall apart. ISATAP was devised to be used inside a site, not across the sites. I do not know which specific simplified subset of ISATAP you have in mind, but these are fundamental issues with ISATAP as it is (and as it always has been). Some of these have been made worse (or new ones introduced) along the lifetime of ISATAP, so depending on what's implemented, it could be worse as well. > So to start with IMO the above paragraph > should mention the existence of these implementations and their > interoperability since it is important for mobile operators/vendors to > know that there is something they can use. Now it basically says the > opposite i.e. no interoperability and wait for further work. I do not think that is appropriate at all. If the WG has not made up its mind, WG document should not be pushing toward a solution which has known problems. Better not nudge towards any particular direction. Read closer about non-interoperability: it says basically that if we wanted to "simplify" or secure ISATAP considerably, that would likely require non-interoperable changes to the spec. It is not trying to say that current ISATAP implementations are non-interoperable. > The paragraph above also talks about ISATAP complexity and this does > not match the experience with the deployed base. We're talking about > supporting RA/RS over a tunnel interface and that doesn't seem like > something complex. It has much more to it than just RA/RS over a tunnel interface. > Also there is no need for the sort of security across > administrative domains mentioned above in 3gpp networks, since it is > handled at layer 2. I don't think you understand the issues that come into play when you deploy something to be used across administrative domains. The interface between domains must be carefully analyzed. It helps a lot if the interface is simple and easy to understand (IMHO which ISATAP isn't). It is one thing to say that the 3GPP operator has identified the user (whether using regular or pre-paid SIM or whatever) -- and consequently everything any user does to the operator, the Internet or the user would be magically trusted -- and another to consider what the user is able to believe. That is, 1) can the user trust the other 3GPP users who are doing direct tunneling to it, possibly injecting malicious packets (which they wouldn't be able to do, unless there was ISATAP), or 2) can the user trust that the 3GPP operator has secured *all* of its borders properly, so that either other users, or anyone in the internet could not inject maliscious packets to the user. L2 identification helps with none of this. All of these issues are much simpler with something resembling configured tunneling, which is why it's preferable. STEP and the like are just extensions of that model to make the tunnel easier to configure, but the security properties are still the same. -- 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 Mar 26 02:36: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 CAA04752 for ; Fri, 26 Mar 2004 02:36:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6lru-000Ise-H8 for v6ops-data@psg.com; Fri, 26 Mar 2004 07:35:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6lrs-000IsG-Pm for v6ops@ops.ietf.org; Fri, 26 Mar 2004 07:35:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2Q7Z3N04101; Fri, 26 Mar 2004 09:35:03 +0200 Date: Fri, 26 Mar 2004 09:35:03 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 26 Mar 2004, Pekka Savola wrote: > (co-chair hat on) > This document is on the IESG agenda next week. Unless they raise > issues about this, it's likely that it will be changed. Oops.. I meant the other way around -- "unlikely that is will be changed". Sorry for too fast typing. From owner-v6ops@ops.ietf.org Fri Mar 26 03:09: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 DAA05985 for ; Fri, 26 Mar 2004 03:09:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6mNw-000OK3-9t for v6ops-data@psg.com; Fri, 26 Mar 2004 08:08:12 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6mNt-000OJk-6H for v6ops@ops.ietf.org; Fri, 26 Mar 2004 08:08:09 +0000 content-class: urn:content-classes:message Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] Date: Fri, 26 Mar 2004 03:08:07 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] Thread-Index: AcQTBhlwutCRR4vHT9qThOyVIy154QAAKK0A From: "Soliman Hesham" To: "Pekka Savola" , "Karim El-Malki (HF/EAB)" Cc: , X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A comment on a couple of issues here. > OK, let's have a few. >=20 > ISATAP uses a pseudo-interface (this is especially problematic if the > implementation also has a 6to4 pseudo-interface, and one big reason > why ISATAP should be avoided). ISATAP accepts proto-41 packets from > anyone. ISATAP does direct tunneling between the nodes (even if they > aren't in the same admin domain, if deployed as you propose). ISATAP > relies that the site has made appropriate protections at its > perimeter, or else its security properties fall apart. ISATAP was > devised to be used inside a site, not across the sites. =3D> One answer to all of the above: The whole point of recommending a solution in specific scenarios is to assess the feasability of the solution to that particular deployment. None of the above is relevant for 3GPP: - On this point to point link ingress filtering in the GGSN=20 stops address spoofing. - It's always used in the same admin domain, logically, i.e. as far as the IP layer can see. - 6-to-4 is not recommended and should not be used by end hosts. We discussed this several times and even Brian C recommended against this a couple of years ago.=20 Given the above conditions, there is no security problems that we can see. > > So to start with IMO the above paragraph > > should mention the existence of these implementations and their > > interoperability since it is important for mobile=20 > operators/vendors to > > know that there is something they can use. Now it=20 > basically says the > > opposite i.e. no interoperability and wait for further work. >=20 > I do not think that is appropriate at all. If the WG has not made up > its mind, WG document should not be pushing toward a solution which > has known problems. Better not nudge towards any particular > direction. =3D> In other words make the doc vague and practically useles. This is the effect of not recommending anything.=20 Regarding the WG opinion, I haven't seen anyone apart from=20 you objecting to this. If I missed emails please point me to one. I asked several times to get WG concensus on this with no luck. What's the next step in the process ? How=20 do I elevate this to see what the WG thinks ? This process is taking way too long and is starting to look fruitless. In other words, I share all the concerns that Tony raised and I'd like the WG to address them.=20 Hesham From owner-v6ops@ops.ietf.org Fri Mar 26 05:06: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 FAA10589 for ; Fri, 26 Mar 2004 05:06:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6oBh-000E6p-6C for v6ops-data@psg.com; Fri, 26 Mar 2004 10:03:41 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6oBe-000E6b-J1 for v6ops@ops.ietf.org; Fri, 26 Mar 2004 10:03:38 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6oBd-0005zU-00 for v6ops@ops.ietf.org; Fri, 26 Mar 2004 10:03:37 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6oBd-0005zP-00 for v6ops@ops.ietf.org; Fri, 26 Mar 2004 10:03:37 +0000 Received: from zurich.ibm.com (sig-9-145-246-252.de.ibm.com [9.145.246.252]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2QA3aF126590 for ; Fri, 26 Mar 2004 10:03:37 GMT Message-ID: <4063E741.474C2E0D@zurich.ibm.com> Date: Fri, 26 Mar 2004 09:18:10 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D ACTION:draft-palet-v6ops-ipv6security-00.txt References: <200403082022.PAA26928@ietf.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A few comments (not including nits; this is in the spirit of an early review): > 1. = > Introduction = > = > The today=C6s Internet paradigms for security need a revision with t= he = > deployment of IPv6, offering end-to-end security capabilities. = > = > Current security policies based on a centric approach with unique = > border devices don=C6t longer apply. Often they are based in a firew= all = > or security gateway and statically configured rules. = And they don't work either, due to the "crunchy outside, soft inside" phenomenon (i.e. half of the enemies are inside the firewall). Additional= ly, note that the firewall model is deeply incompatible with the model of virtual organizations that is fundamental to Grid computing - virtual organizations cross all traditional security boundaries. > Keeping today=C6s static security model is a wrong approach, which = > disables the end-to-end features and advantages of IPv6. = "disables" is too strong - "interferes with" is more accurate. > Enforcing the nomadic users and devices to connect to Internet by = > means of the security device, is almost equivalent to disable the = > IPsec stack on each node, thus invalidating one of the key IPv6 = > advantages. = I don't think this is really true, with current solutions for IPSEC to traverse NAT, and future solutions from Midcom for firewall traversal. > On the other hand, is also true and perfectly understandable that = > there is a need to enforce security in the networks, in such way tha= t = > the network administrator has always the control over it. = It's the security administrator who wants control; she is often different= from the network administrator. Missing argument here: the current enterprise network security model prevents innovation. > 2. = > Distributed security model = Please credit Steve Bellovin and his colleagues, who first proposed a "distributed firewall" model a few years ago. = http://www.research.att.com/~smb/papers/distfw.pdf http://www.research.att.com/~smb/papers/ccs-df.ps = > The distributed security model implies the use of node or personal = > firewalls. = > = Not only that. It also implies the use of end-to-end applications level security (for example the Web Services security standards). > These node or personal firewalls must respect the security policy of= = > the network where they are attached. = It's more subtle than that. If the "home" security policy of a roaming sy= stem is *different* from the local policy where the system is connected, there= may be actual conflict between the policies. To take a trivial case, local policy might prohibit ICMP messages, but the home policy might require IC= MP probes for some checking purpose. So the solution must allow for resoluti= on of conflict between security policies. > This is possible in most of the situations because, even if IPsec an= d = > encryption are enforced for most of the communications, nodes often = > have powerful CPUs with unused cycles that will easily accommodate = > the extra required workload. = Sorry but that's nonsense. Particularly in the case of small roaming devi= ces, they *don't* have spare capacity. You can argue that capacity for securit= y should be provided by design, but you can't simply assume there will be s= uch capacity. > On the other hand, the central firewalls will be able to dedicate CP= U = > cycles to new functions, or be able to protect bigger networks. = Should intrusion detection be centralized or distributed? Also note that the central firewalls will need to support Midcom-style firewall traversal in future. > 4. = > The visiting node = > = =2E.. > = > Different visited networks have different security requirements. = > Consequently is required that those nomadic nodes dynamically = > accommodate their own security policy to the one defined in the = > visited network. = As noted above, this is subject to the need for conflict resolution when the policies are incompatible. > 6. = > The security policy server and protocol = =2E.. > = > When a node is attached to a visited network and receives the visite= d = > network security policy, basically there are two possible situations= : = > = > a) The network security policy is less or same restrictive than the = > node configuration. In this case, the node will not change its = > security policy configuration. = > = > b) The network security policy is more restrictive than the node = > configuration. In this case, the node will adapt its security = > configuration to at least match the one indicated by the security = > policy. = > = > Until the node performs and acknowledge the required security policy= = > configuration update, it will not be allowed to transfer/receive dat= a = > to/from other nodes either in the network or other connected = > networks. = Again the same point. If my employer's corporate security policy has requirement A and I visit a network whose policy has requirement Z, it is *not* true in general that A is either more or less restrictive than Z. It may be that they are simply incompatible. My employer would require that A wins and the host network would require that Z wins. So who wins? = =2E.. > A possible approach is to align this with the existing COPS [iii] an= d = > COPS-PR [iv] standards. = It's very unclear that COPS will be widely implemented. > 7. = > Single versus multiple point of attack = =2E.. > The failure of the central firewall could completely disconnect the = > network from Internet or other networks. In the case of a central = > policy server fail, the nodes can be configured by the security = > policy in such way that continue working, keeping the same security = > restrictions imposed by the policy server. = Instead of "same" I think you mean "most recent." On the other hand, during such a failure, there is a risk of incorrectly or partially configured hosts being wide open. How about a compromised host that pretends to conform to the central policy but is actually a hacker haven? > 8. = > Non-security-capable nodes and security workload distribution = > = > Increase in security often means increase in processing power. = > = > Some nodes could not have the required CPU cycles to afford the = > complete required security policy. = > = > The firewalls or even other security-capable nodes with free = > resources, could act as trusted security gateways for the non- > security-capable nodes. = > = > This seems only possible if minimum security verification can be don= e = > by those nodes, i.e. digital signature verification. = Why? They don't today. All you need is that if a host fails to say "yes, I installed your central security policy", then you treat it as a non-security-capable host. > 10. = > Virus and spam = > = > As part of the services offered by the distributed security model, i= t = > should be considered means to alleviate the effects of virus and = > spam. = It seems to me that this is far to complex and expensive to distribute. Spam/virus filters require contnuous updating of very sophisticated and large signature files. Since all email flows through mail servers anyway,= I can't see any argument for distributing this complexity. In any case, it's not an IPv6 issue. Brian From owner-v6ops@ops.ietf.org Fri Mar 26 05:19:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11133 for ; Fri, 26 Mar 2004 05:19:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6oOg-000Fg7-2W for v6ops-data@psg.com; Fri, 26 Mar 2004 10:17:06 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6oOZ-000Ffc-PQ for v6ops@ops.ietf.org; Fri, 26 Mar 2004 10:16:59 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6oOY-0006wK-00; Fri, 26 Mar 2004 10:16:58 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B6oOY-0006wF-00; Fri, 26 Mar 2004 10:16:58 +0000 Received: from zurich.ibm.com (sig-9-145-246-252.de.ibm.com [9.145.246.252]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2QAGvF123438; Fri, 26 Mar 2004 10:16:58 GMT Message-ID: <40640332.4B7FFEB9@zurich.ibm.com> Date: Fri, 26 Mar 2004 11:17:22 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Soliman Hesham CC: Pekka Savola , "Karim El-Malki (HF/EAB)" , v6ops@ops.ietf.org, Jonne.Soininen@nokia.com Subject: Re: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soliman, Soliman Hesham wrote: > > A comment on a couple of issues here. > > > OK, let's have a few. > > > > ISATAP uses a pseudo-interface (this is especially problematic if the > > implementation also has a 6to4 pseudo-interface, and one big reason > > why ISATAP should be avoided). ISATAP accepts proto-41 packets from > > anyone. ISATAP does direct tunneling between the nodes (even if they > > aren't in the same admin domain, if deployed as you propose). ISATAP > > relies that the site has made appropriate protections at its > > perimeter, or else its security properties fall apart. ISATAP was > > devised to be used inside a site, not across the sites. > > => One answer to all of the above: The whole point of recommending > a solution in specific scenarios is to assess the feasability > of the solution to that particular deployment. None of the above > is relevant for 3GPP: > - On this point to point link ingress filtering in the GGSN > stops address spoofing. > - It's always used in the same admin domain, logically, i.e. > as far as the IP layer can see. > - 6-to-4 is not recommended and should not be used by end > hosts. We discussed this several times and even Brian C > recommended against this a couple of years ago. I certainly can see no scenario in which a 6to4 interface and an ISATAP interface should be simultaneously active on the same IPv4 interface. These should definitely be mutually exclusive. And that should perhaps be stated in the document. > > Given the above conditions, there is no security problems > that we can see. > > > > So to start with IMO the above paragraph > > > should mention the existence of these implementations and their > > > interoperability since it is important for mobile > > operators/vendors to > > > know that there is something they can use. Now it > > basically says the > > > opposite i.e. no interoperability and wait for further work. > > > > I do not think that is appropriate at all. If the WG has not made up > > its mind, WG document should not be pushing toward a solution which > > has known problems. Better not nudge towards any particular > > direction. > > => In other words make the doc vague and practically useles. > This is the effect of not recommending anything. I think the issue here is that ISATAP is a complicated solution and not everybody is confident that it is good engineering to recommend it. And of course STEP is too new. > Regarding the WG opinion, I haven't seen anyone apart from > you objecting to this. If I missed emails please point me > to one. I asked several times to get WG concensus on this > with no luck. What's the next step in the process ? How > do I elevate this to see what the WG thinks ? Have you polled people privately to find out who is intending to productize ISATAP? In terms of a solid recommendation to the 3GPP industry, that is more important than anything. What is the status of ISATAP interoperability testing? Brian From owner-v6ops@ops.ietf.org Fri Mar 26 05:51:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12389 for ; Fri, 26 Mar 2004 05:51:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6ouJ-000Jhk-W1 for v6ops-data@psg.com; Fri, 26 Mar 2004 10:49:47 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6ouH-000JhC-2M for v6ops@ops.ietf.org; Fri, 26 Mar 2004 10:49:45 +0000 content-class: urn:content-classes:message Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] Date: Fri, 26 Mar 2004 05:49:45 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] Thread-Index: AcQTG3uYFAUjkyKuR4Oxi0a1LYiJgwAArjTg From: "Soliman Hesham" To: "Brian E Carpenter" Cc: "Pekka Savola" , "Karim El-Malki (HF/EAB)" , , X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Soliman, =3D> I prefer Hesham, one day I'll make sure=20 they make my first name appear in the right order ;) >=20 > I certainly can see no scenario in which a 6to4 interface and > an ISATAP interface should be simultaneously active on the > same IPv4 interface. These should definitely be mutually > exclusive. And that should perhaps be stated in the document. =3D> Agreed. > > =3D> In other words make the doc vague and practically useles. > > This is the effect of not recommending anything. >=20 > I think the issue here is that ISATAP is a complicated solution > and not everybody is confident that it is good engineering to > recommend it. And of course STEP is too new. =3D> I guess we can discuss whether it's complicated or=20 not. But in any case, it's implemented by several=20 major vendors. I'll let them speak for themselves. > Have you polled people privately to find out who is intending > to productize ISATAP?=20 =3D> Yes and the answers are positive. Again I'd like them to speak for themselves. In terms of a solid recommendation > to the 3GPP industry, that is more important than anything. What is > the status of ISATAP interoperability testing? =3D> I know of at least 2 interoperable implemenations that have been rigorously tested. Fred might know more. Hesham From owner-v6ops@ops.ietf.org Fri Mar 26 06:10: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 GAA13255 for ; Fri, 26 Mar 2004 06:10:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6pBs-000Min-SV for v6ops-data@psg.com; Fri, 26 Mar 2004 11:07:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6pBq-000MiH-Ij for v6ops@ops.ietf.org; Fri, 26 Mar 2004 11:07:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2QB7nE07345; Fri, 26 Mar 2004 13:07:49 +0200 Date: Fri, 26 Mar 2004 13:07:49 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: "Karim El-Malki (HF/EAB)" , , Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 26 Mar 2004, Soliman Hesham wrote: > => One answer to all of the above: The whole point of recommending > a solution in specific scenarios is to assess the feasability > of the solution to that particular deployment. None of the above > is relevant for 3GPP: > - On this point to point link ingress filtering in the GGSN > stops address spoofing. If that's enabled, that is. But as you see, this issue is not limited to being (or not being) able to spoof your IPv4 address. > - It's always used in the same admin domain, logically, i.e. > as far as the IP layer can see. You misunderstand the concept of administrative domains. Is the home user and his (hers) ISP in the same administrative domain as well? No, they are not. 3GPP UE is managed by the user, not the 3GPP operator. 3GPP operator cannot trust whoever uses the UE. UE users cannot trust other UE users. > - 6-to-4 is not recommended and should not be used by end > hosts. We discussed this several times and even Brian C > recommended against this a couple of years ago. Such recommendation is not grounded on reality. It is used by hosts by the million, and there is nothing we can do to get it out from there. I'd suspect many UEs would include 6to4 capability themselves (I seem to recall hearing some UE pilot stacks would have), e.g. for trying to obtain IPv6 access in WLANs. The problem is that if both of them are implemented, we end up in problems, unless the implementations enforce that the two pseudo-interfaces MUST NOT be allowed to be anchored to the same IPv4 address. > Given the above conditions, there is no security problems > that we can see. Perhaps you just don't look sufficiently hard enough :-) > This process is taking way too long and is starting to > look fruitless. In other words, I share all the concerns > that Tony raised and I'd like the WG to address them. To be frank, the argument has sounded a bit like, "we want to have a recommended solution soon, as long as it's the solution we have in mind". Where are the requirements? It seems in many cases, a driver for ISATAP has been its auto-discovery function. Oh really -- that's implementable in about every solution in a dozen of lines of code :). Not really a good reason to be blindfolded to just look at one solution, IMHO. -- 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 Mar 26 06:27:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13883 for ; Fri, 26 Mar 2004 06:27:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6pSn-000Olf-8Y for v6ops-data@psg.com; Fri, 26 Mar 2004 11:25:25 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6pSh-000Ok3-I1 for v6ops@ops.ietf.org; Fri, 26 Mar 2004 11:25:19 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2QBPIqY013231 for ; Fri, 26 Mar 2004 12:25:18 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 12:25:17 +0100 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HV9RB3JS; Fri, 26 Mar 2004 12:25:35 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Mar 2004 12:25:16 +0100 Message-ID: X-Sybari-Trust: f74b0a37 2c4885b5 ae329ef6 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: IPv6 Operations Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] Date: Fri, 26 Mar 2004 12:24:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Mar 2004 11:25:17.0880 (UTC) FILETIME=[04395380:01C41325] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, I am replying to the list (I missed that in the first message). > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 26. marts 2004 11:51 > To: Karen E. Nielsen (AH/TED) > Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on > draft-ietf-v6 ops-3gpp-analysis-09.txt] > > > On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote: > > > ISATAP uses a pseudo-interface (this is especially > problematic if the > > > implementation also has a 6to4 pseudo-interface, and one > big reason > > > why ISATAP should be avoided) > > > > I agree that this may be a problem if both pseudo-interfaces and > > anchored on the same IPv4 address - but otherwise I do not see a any > > problem here. > > Yes. This is very real if they use the same address. But from the > implementation point of view, this is a huge problem. How do they > ensure that this won't happen? Seems like a very difficult thing to > do. Well, I don't think that I understand why it is such a problem form the implementation point of view (I certainly wasn't for us, but then they may be some autoconfiguration issues that are escaping me). > > > You consider this to be a big issue - does this mean that > you consider a scenario > > where a node would want to establish both 6to4 and Isatap > communication > > by use the same IPv4 PDP context as likely ? > > I don't think this is practical in 3GPP scenario, but I can see that > the mobile nodes would implement 6to4 (for roaming outside of 3GPP). > And if they would implement ISATAP as well, a recipe for disaster > could be ready. > I am not really worried about the implementation details. > I don't think the interfaces would be enabled simultaneously in a 3GPP > network -- because there private addresses are used, and 6to4 is not > applicable in any case.. > I agree, I don't consider the scenario to be even remotely likely. > > ISATAP accepts proto-41 packets from > > > anyone. > > > > Well a proto-41 packet will be discarded by an > > Isatap interface/daemon unless it meets a few very specific > criteria's.... > > Depending on which specification you're looking at, this ranges from > "check that v4 and the isatap address match for certain packets, but > don't check for the rest" to "practically nothing". Depends on which > spec you're looking at... > May be, but let choose the most solid spec in this sense then. I assume we are allowed to improve the mechs and perhaps tune them according to the applicable scenarios. > But regardless of that, the fact stands that unless the site operator > blocks proto-41 at the edge, they can be injected to all the ISATAP > nodes. Even if there are checks for such packets, they can cause a > lot of harm. Checking that v4 and isatap address match does not help > that much in that regard, as the addresses are spoofable. > Well typically I think that the Isatap router will be located within the site or at the site edge, therefore proto-41 will not be a problem on the site edge. > > > ISATAP does direct tunneling between the nodes (even if they > > > aren't in the same admin domain, if deployed as you propose). > > > > You mean when nodes attached on different administrative domains > > uses the same Isatap prefix/the same administrative domain > > for Isatap tunnel endpoint, I assume. > > > > That will not be the case in 3GPP if the Isatap service/tunnel > > endpoint service is provided by the serving 3G ISP > > No, I mean that if the 3GPP operator provides the ISATAP endpoint, > it's in the different administrative domain as the UE. UE is managed > by the user, not the 3GPP operator. > I don't get this - typically the tunnel endpoint will be managed by some else than the user - right ? Thanks, Karen This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Fri Mar 26 07:12: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 HAA15619 for ; Fri, 26 Mar 2004 07:12:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6q8s-0004ri-VS for v6ops-data@psg.com; Fri, 26 Mar 2004 12:08:54 +0000 Received: from [63.103.94.24] (helo=ftmail2000.HQ.Flarion.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6q8s-0004rV-2O for v6ops@ops.ietf.org; Fri, 26 Mar 2004 12:08:54 +0000 content-class: urn:content-classes:message Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] Date: Fri, 26 Mar 2004 07:08:52 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt] Thread-Index: AcQTIpUxCyVc2R5NTVm6JnnwmNHkhgABX6eQ From: "Soliman Hesham" To: "Pekka Savola" Cc: "Karim El-Malki (HF/EAB)" , , X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > =3D> One answer to all of the above: The whole point of = recommending > > a solution in specific scenarios is to assess the feasability > > of the solution to that particular deployment. None of the above > > is relevant for 3GPP: > > - On this point to point link ingress filtering in the GGSN=20 > > stops address spoofing. >=20 > If that's enabled, that is. But as you see, this issue is=20 > not limited=20 > to being (or not being) able to spoof your IPv4 address. =3D> So this is a non-issue, ok? If it is, we can add=20 a sentence to reflect this requirement. >=20 > > - It's always used in the same admin domain, logically, i.e. > > as far as the IP layer can see. >=20 > You misunderstand the concept of administrative domains. Is=20 > the home=20 > user and his (hers) ISP in the same administrative domain as well? =20 > No, they are not. 3GPP UE is managed by the user, not the 3GPP=20 > operator. 3GPP operator cannot trust whoever uses the UE. UE users=20 > cannot trust other UE users. =3D> Huh??? How is this specific to ISATAP??? Any user can setup a tunnel to a tunnel agent and bomb someone else. This is the same for MIP. Ok, so you say the tunnel in other cases is secure and the user=20 can be identified. Here the tunnel is not secure of=20 course, but the user was authenticated and authorised for network access and can be tracked. Can you tell me how this is different from tracking an abusive MN that floods other nodes through its HA? >=20 > > - 6-to-4 is not recommended and should not be used by end > > hosts. We discussed this several times and even Brian C > > recommended against this a couple of years ago.=20 >=20 > Such recommendation is not grounded on reality. It is used by hosts > by the million, and there is nothing we can do to get it out from > there. =20 =3D> By the million? You're right, I'm not grounded in reality. At least not in your reality.... I'd suspect many UEs would include 6to4 capability themselves =3D> What is your suspicion grounded on? > (I seem to recall hearing some UE pilot stacks would have), e.g. for > trying to obtain IPv6 access in WLANs. =3D> I see. > > Given the above conditions, there is no security problems > > that we can see. >=20 > Perhaps you just don't look sufficiently hard enough :-) =3D> I assume you looked pretty hard, please write a threat=20 to the list and we can begin from there. I'm talking about a detailed threat here, not "User A floods User B". This might be the beginning of a productive discussion. Unlike the condescending statement above which is an=20 end to a discussion. =20 >=20 > To be frank, the argument has sounded a bit like, "we want to have a > recommended solution soon, as long as it's the solution we have in > mind". Where are the requirements? >=20 > It seems in many cases, a driver for ISATAP has been its > auto-discovery function. Oh really -- that's implementable in about > every solution in a dozen of lines of code :). Not really a good=20 > reason to be blindfolded to just look at one solution, IMHO. =3D> I'm not going to go into this again. We had both operators and vendors supporting this. In Seoul there was no objection to standardising ISATAP. You still haven't answered my question, why aren't you asking=20 the WG? Normally one person's opinion doesn't reverse WG concensus. Is this a special case? I'll move on from this if the WG concensus is to not support ISATAP in this scenario.=20 Hesham From owner-v6ops@ops.ietf.org Fri Mar 26 08:30: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 IAA19016 for ; Fri, 26 Mar 2004 08:30:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6rN2-000CoB-OQ for v6ops-data@psg.com; Fri, 26 Mar 2004 13:27:36 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6rN0-000Cnk-2C for v6ops@ops.ietf.org; Fri, 26 Mar 2004 13:27:34 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2QDRTYG013606 for ; Fri, 26 Mar 2004 14:27:33 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 14:27:28 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Mar 2004 14:27:28 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B1F@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] Date: Fri, 26 Mar 2004 14:27:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Mar 2004 13:27:28.0709 (UTC) FILETIME=[15BD0F50:01C41336] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote: > > This stems from the STEP vs. ISATAP competition which I don't quite > > understand. There is not such a big difference between simplified > > host-to-router ISATAP implementations that are deployed > today and the > > functions specified in STEP. > > OK, let's have a few. > > ISATAP uses a pseudo-interface (this is especially problematic if the > implementation also has a 6to4 pseudo-interface, and one big reason > why ISATAP should be avoided). ISATAP accepts proto-41 packets from > anyone. Just like an IPv6 host accepts IPv6 packets from anyone right? By using appropriate security (incl. ingress filtering) you limit the risks. But this is not a problem of ISATAP. > ISATAP does direct tunneling between the nodes (even if they > aren't in the same admin domain, if deployed as you propose). ISATAP > relies that the site has made appropriate protections at its > perimeter, or else its security properties fall apart. ISATAP was > devised to be used inside a site, not across the sites. And that's exactly what is proposed, it is always inside a site from the IP viewpoint. > > I do not know which specific simplified subset of ISATAP you have in > mind, but these are fundamental issues with ISATAP as it is > (and as it > always has been). Some of these have been made worse (or new ones > introduced) along the lifetime of ISATAP, so depending on what's > implemented, it could be worse as well. It has been implemented and used widely. You may claim that only a subset was used and I would be happy to agree. Still that is a reason for the ISATAP document to be modified to reflect what is deployed and any limitations but not a reason to discard it. I am certainly in favour of this and had already sent come comments to Fred Templin about this to share with the authors. > > > So to start with IMO the above paragraph > > should mention the existence of these implementations and their > > interoperability since it is important for mobile > operators/vendors to > > know that there is something they can use. Now it > basically says the > > opposite i.e. no interoperability and wait for further work. > > I do not think that is appropriate at all. If the WG has not made up > its mind, WG document should not be pushing toward a solution which > has known problems. Better not nudge towards any particular > direction. By ignoring the reality of what is out there this will make it harder for IPv6 to be deployed. Also you are just turning the tables since the text you wanted in that spec is specifically pushing for STEP. So if there is someone pushing for their solution which the WG has not adopted yet it's not me unlike what you seem to be hinting. I would like ISATAP to be given fair consideration, since it is anyway used today and a likely candidate for more deployment in the short run. Creating an ISATAP vs. STEP competiton as you are doing will just leave us with nothing to deploy since STEP is too new. > > Read closer about non-interoperability: it says basically that if we > wanted to "simplify" or secure ISATAP considerably, that would likely > require non-interoperable changes to the spec. It is not trying to > say that current ISATAP implementations are non-interoperable. Since current interoperable ISATAP implementations are already a "simplified" version your logic doesn't make sense. > > > The paragraph above also talks about ISATAP complexity and > this does > > not match the experience with the deployed base. We're > talking about > > supporting RA/RS over a tunnel interface and that doesn't seem like > > something complex. > > It has much more to it than just RA/RS over a tunnel interface. Again, it says deployed base. > > > Also there is no need for the sort of security across > > administrative domains mentioned above in 3gpp networks, > since it is > > handled at layer 2. > > I don't think you understand the issues that come into play when you > deploy something to be used across administrative domains. The > interface between domains must be carefully analyzed. It > helps a lot > if the interface is simple and easy to understand (IMHO which ISATAP > isn't). Actually I think your logic does not reflect at all how a 3gpp mobile network works. Once again, there is no crossing of administrative domains in the way you mean it. > > It is one thing to say that the 3GPP operator has identified the user > (whether using regular or pre-paid SIM or whatever) -- and > consequently everything any user does to the operator, the > Internet or > the user would be magically trusted -- and another to consider what > the user is able to believe. > That is, 1) can the user trust > the other > 3GPP users who are doing direct tunneling to it, possibly injecting > malicious packets (which they wouldn't be able to do, unless > there was > ISATAP), This has nothing to do with ISATAP. With native IPv6 or IPv4 users can just send each other packets and these packets are in no way less likely to be malicious than tunnelled packets. or 2) can the user trust that the 3GPP operator has secured > *all* of its borders properly, so that either other users, or anyone > in the internet could not inject maliscious packets to the user. L2 > identification helps with none of this. It just has to do ingress filtering in the GGSN which from what I know is default. So you should assume it is default and if anything explicitly state this as an assumption/requirement. > All of these issues are much simpler with something resembling > configured tunneling, which is why it's preferable. STEP > and the like > are just extensions of that model to make the tunnel easier to > configure, but the security properties are still the same. I am not saying work should stop on STEP. What I am saying is that ISATAP is already being used and has good reasons for that. So the draft should be quickly adapted to reflect what is deployed and moved on. That will give us a solution which we can use. Otherwise we will continue with this standstill situation. /Karim This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Fri Mar 26 08:35: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 IAA19315 for ; Fri, 26 Mar 2004 08:35:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6rSs-000Dj3-U5 for v6ops-data@psg.com; Fri, 26 Mar 2004 13:33:38 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6rSr-000Die-PE for v6ops@ops.ietf.org; Fri, 26 Mar 2004 13:33:37 +0000 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2QDXaYG015055 for ; Fri, 26 Mar 2004 14:33:36 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 14:33:36 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Mar 2004 14:33:36 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B20@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: comments on draft-ietf-v6ops-3gpp-analysis-09.txt Date: Fri, 26 Mar 2004 14:33:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Mar 2004 13:33:36.0682 (UTC) FILETIME=[F11148A0:01C41336] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Fri, 26 Mar 2004, Pekka Savola wrote: > > (co-chair hat on) > > This document is on the IESG agenda next week. Unless they raise > > issues about this, it's likely that it will be changed. > > Oops.. I meant the other way around -- "unlikely that is will be > changed". > > Sorry for too fast typing. This is not the first time that these same comments are brought up. I would assume that, even if they are not repeated every time, the IESG does take them into consideration. /Karim This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Fri Mar 26 10:54: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 KAA27235 for ; Fri, 26 Mar 2004 10:54:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6tcB-00095y-4Q for v6ops-data@psg.com; Fri, 26 Mar 2004 15:51:23 +0000 Received: from [66.218.79.73] (helo=web80503.mail.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B6tc9-00095g-Cv for v6ops@ops.ietf.org; Fri, 26 Mar 2004 15:51:21 +0000 Message-ID: <20040326155120.96841.qmail@web80503.mail.yahoo.com> Received: from [63.197.18.101] by web80503.mail.yahoo.com via HTTP; Fri, 26 Mar 2004 07:51:20 PST Date: Fri, 26 Mar 2004 07:51:20 -0800 (PST) From: Fred Templin Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] To: "Karim El-Malki \(HF/EAB\)" , "'Pekka Savola'" Cc: v6ops@ops.ietf.org In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B1F@ESEALNT442.al.sw.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1856160081-1080316280=:95226" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1856160081-1080316280=:95226 Content-Type: text/plain; charset=us-ascii I won't respond to this thread in detail other than to say that a clear sense seems to be emerging from the community in terms of desired scope for the ISATAP spec, and have received similar feedback from other sources as well. About the 6to4 issue, others have already correctly answered that ISATAP and 6to4 would not occur on the same IPv4 interface such that there would be no ambiguity. The only way this could happen is if we had an unrestricted "multihomed IPv4 interface", e.g., a wireless interface that could connect to multiple sites at the same time w/o encapsulation. But, in practice, we either use overlay pseudo interfaces (e.g., PDP contexts, PPP, configured tunnels, ISATAP interfaces, etc.) to keep the sites separate, or link-layer abstractions like the IEEE 802.11 (I)BSS to restrict access to a single site at a time. About interoperability testing, this is certainly high on the agenda but, as others have commented, ISATAP is already seen in wide deployment. I believe there were ISATAP implementations shown in the IPv6 demo exhibits at IETF59 as well; I'll send a request to the 'isatap.com' site administrator asking to have the links there updated. Fred Templin osprey67@yahoo.com "Karim El-Malki (HF/EAB)" wrote: > On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote: > > This stems from the STEP vs. ISATAP competition which I don't quite > > understand. There is not such a big difference between simplified > > host-to-router ISATAP implementations that are deployed > today and the > > functions specified in STEP. > > OK, let's have a few. > > ISATAP uses a pseudo-interface (this is especially problematic if the > implementation also has a 6to4 pseudo-interface, and one big reason > why ISATAP should be avoided). ISATAP accepts proto-41 packets from > anyone. Just like an IPv6 host accepts IPv6 packets from anyone right? By using appropriate security (incl. ingress filtering) you limit the risks. But this is not a problem of ISATAP. > ISATAP does direct tunneling between the nodes (even if they > aren't in the same admin domain, if deployed as you propose). ISATAP > relies that the site has made appropriate protections at its > perimeter, or else its security properties fall apart. ISATAP was > devised to be used inside a site, not across the sites. And that's exactly what is proposed, it is always inside a site from the IP viewpoint. > > I do not know which specific simplified subset of ISATAP you have in > mind, but these are fundamental issues with ISATAP as it is > (and as it > always has been). Some of these have been made worse (or new ones > introduced) along the lifetime of ISATAP, so depending on what's > implemented, it could be worse as well. It has been implemented and used widely. You may claim that only a subset was used and I would be happy to agree. Still that is a reason for the ISATAP document to be modified to reflect what is deployed and any limitations but not a reason to discard it. I am certainly in favour of this and had already sent come comments to Fred Templin about this to share with the authors. > > > So to start with IMO the above paragraph > > should mention the existence of these implementations and their > > interoperability since it is important for mobile > operators/vendors to > > know that there is something they can use. Now it > basically says the > > opposite i.e. no interoperability and wait for further work. > > I do not think that is appropriate at all. If the WG has not made up > its mind, WG document should not be pushing toward a solution which > has known problems. Better not nudge towards any particular > direction. By ignoring the reality of what is out there this will make it harder for IPv6 to be deployed. Also you are just turning the tables since the text you wanted in that spec is specifically pushing for STEP. So if there is someone pushing for their solution which the WG has not adopted yet it's not me unlike what you seem to be hinting. I would like ISATAP to be given fair consideration, since it is anyway used today and a likely candidate for more deployment in the short run. Creating an ISATAP vs. STEP competiton as you are doing will just leave us with nothing to deploy since STEP is too new. > > Read closer about non-interoperability: it says basically that if we > wanted to "simplify" or secure ISATAP considerably, that would likely > require non-interoperable changes to the spec. It is not trying to > say that current ISATAP implementations are non-interoperable. Since current interoperable ISATAP implementations are already a "simplified" version your logic doesn't make sense. > > > The paragraph above also talks about ISATAP complexity and > this does > > not match the experience with the deployed base. We're > talking about > > supporting RA/RS over a tunnel interface and that doesn't seem like > > something complex. > > It has much more to it than just RA/RS over a tunnel interface. Again, it says deployed base. > > > Also there is no need for the sort of security across > > administrative domains mentioned above in 3gpp networks, > since it is > > handled at layer 2. > > I don't think you understand the issues that come into play when you > deploy something to be used across administrative domains. The > interface between domains must be carefully analyzed. It > helps a lot > if the interface is simple and easy to understand (IMHO which ISATAP > isn't). Actually I think your logic does not reflect at all how a 3gpp mobile network works. Once again, there is no crossing of administrative domains in the way you mean it. > > It is one thing to say that the 3GPP operator has identified the user > (whether using regular or pre-paid SIM or whatever) -- and > consequently everything any user does to the operator, the > Internet or > the user would be magically trusted -- and another to consider what > the user is able to believe. > That is, 1) can the user trust > the other > 3GPP users who are doing direct tunneling to it, possibly injecting > malicious packets (which they wouldn't be able to do, unless > there was > ISATAP), This has nothing to do with ISATAP. With native IPv6 or IPv4 users can just send each other packets and these packets are in no way less likely to be malicious than tunnelled packets. or 2) can the user trust that the 3GPP operator has secured > *all* of its borders properly, so that either other users, or anyone > in the internet could not inject maliscious packets to the user. L2 > identification helps with none of this. It just has to do ingress filtering in the GGSN which from what I know is default. So you should assume it is default and if anything explicitly state this as an assumption/requirement. > All of these issues are much simpler with something resembling > configured tunneling, which is why it's preferable. STEP > and the like > are just extensions of that model to make the tunnel easier to > configure, but the security properties are still the same. I am not saying work should stop on STEP. What I am saying is that ISATAP is already being used and has good reasons for that. So the draft should be quickly adapted to reflect what is deployed and moved on. That will give us a solution which we can use. Otherwise we will continue with this standstill situation. /Karim This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --0-1856160081-1080316280=:95226 Content-Type: text/html; charset=us-ascii
I won't respond to this thread in detail other than to say that a clear sense
seems to be emerging from the community in terms of desired scope for the
ISATAP spec, and have received similar feedback from other sources as well.
 
About the 6to4 issue, others have already correctly answered that ISATAP
and 6to4 would not occur on the same IPv4 interface such that there would
be no ambiguity. The only way this could happen is if we had an unrestricted
"multihomed IPv4 interface", e.g., a wireless interface that could connect to
multiple sites at the same time w/o encapsulation. But, in practice, we
either use overlay pseudo interfaces (e.g., PDP contexts, PPP, configured
tunnels, ISATAP interfaces, etc.) to keep the sites separate, or link-layer
abstractions like the IEEE 802.11 (I)BSS to restrict access to a single
site at a time.
 
About interoperability testing, this is certainly high on the agenda but,
as others have commented, ISATAP is already seen in wide deployment.
I believe there were ISATAP implementations shown in the IPv6 demo
exhibits at IETF59 as well; I'll send a request to the 'isatap.com' site
administrator asking to have the links there updated.
 
Fred Templin
 

"Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com> wrote:
> On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote:
> > This stems from the STEP vs. ISATAP competition which I don't quite
> > understand. There is not such a big difference between simplified
> > host-to-router ISATAP implementations that are deployed
> today and the
> > functions specified in STEP.
>
> OK, let's have a few.
>
> ISATAP uses a pseudo-interface (this is especially problematic if the
> implementation also has a 6to4 pseudo-interface, and one big reason
> why ISATAP should be avoided). ISATAP accepts proto-41 packets from
> anyone.

Just like an IPv6 host accepts IPv6 packets from anyone right?
By using appropriate security (incl. ingress filtering) you limit
the risks. But this is not a problem of ISATAP.

> ISATAP does direct tunneling between the nodes (even if they
> aren't in the same admin domain, if deployed as you propose). ISATAP
> relies that the site has made appropriate protections at its
> perimeter, or else its security properties fall apart. ISATAP was
> devised to be used inside a site, not across the sites.

And that's exactly what is proposed, it is always inside a site
from the IP viewpoint.

>
> I do not know which specific simplified subset of ISATAP you have in
> mind, but these are fundamental issues with ISATAP as it is
> (and as it
> always has been). Some of these have been made worse (or new ones
> introduced) along the lifetime of ISATAP, so depending on what's
> implemented, it could be worse as well.

It has been implemented and used widely. You may claim that only a
subset was used and I would be happy to agree. Still that is a reason
for the ISATAP document to be modified to reflect what is deployed and
any limitations but not a reason to discard it. I am certainly in favour
of this and had already sent come comments to Fred Templin about this
to share with the authors.

>
> > So to start with IMO the above paragraph
> > should mention the existence of these implementations and their
> > interoperability since it is important for mobile
> operators/vendors to
> > know that there is something they can use. Now it
> basically says the
> > opposite i.e. no interoperability and wait for further work.
>
> I do not think that is appropriate at all. If the WG has not made up
> its mind, WG document should not be pushing toward a solution which
> has known problems. Better not nudge towards any particular
> direction.

By ignoring the reality of what is out there this will make it harder
for IPv6 to be deployed. Also you are just turning the tables since the
text you wanted in that spec is specifically pushing for STEP. So if there
is someone pushing for their solution which the WG has not adopted yet it's
not me unlike what you seem to be hinting. I would like ISATAP to be
given fair consideration, since it is anyway used today and a likely candidate
for more deployment in the short run. Creating an ISATAP vs. STEP competiton
as you are doing will just leave us with nothing to deploy since STEP is
too new.

>
> Read closer about non-interoperability: it says basically that if we
> wanted to "simplify" or secure ISATAP considerably, that would likely
> require non-interoperable changes to the spec. It is not trying to
> say that current ISATAP implementations are non-interoperable.

Since current interoperable ISATAP implementations are already a
"simplified" version your logic doesn't make sense.

>
> > The paragraph above also talks about ISATAP complexity and
> this does
> > not match the experience with the deployed base. We're
> talking about
> > supporting RA/RS over a tunnel interface and that doesn't seem like
> > something complex.
>
> It has much more to it than just RA/RS over a tunnel interface.

Again, it says deployed base.

>
> > Also there is no need for the sort of security across
> > administrative domains mentioned above in 3gpp networks,
> since it is
> > handled at layer 2.
>
> I don't think you understand the issues that come into play when you
> deploy something to be used across administrative domains. The
> interface between domains must be carefully analyzed. It
> helps a lot
> if the interface is simple and easy to understand (IMHO which ISATAP
> isn't).

Actually I think your logic does not reflect at all how a 3gpp mobile
network works. Once again, there is no crossing of administrative domains
in the way you mean it.

>
> It is one thing to say that the 3GPP operator has identified the user
> (whether using regular or pre-paid SIM or whatever) -- and
> consequently everything any user does to the operator, the
> Internet or
> the user would be magically trusted -- and another to consider what
> the user is able to believe.
> That is, 1) can the user trust
> the other
> 3GPP users who are doing direct tunneling to it, possibly injecting
> malicious packets (which they wouldn't be able to do, unless
> there was
> ISATAP),

This has nothing to do with ISATAP. With native IPv6 or IPv4 users can
just send each other packets and these packets are in no way less likely
to be malicious than tunnelled packets.

or 2) can the user trust that the 3GPP operator has secured
> *all* of its borders properly, so that either other users, or anyone
> in the internet could not inject maliscious packets to the user. L2
> identification helps with none of this.

It just has to do ingress filtering in the GGSN which from what I know
is default. So you should assume it is default and if anything explicitly
state this as an assumption/requirement.

> All of these issues are much simpler with something resembling
> configured tunneling, which is why it's preferable. STEP
> and the like
> are just extensions of that model to make the tunnel easier to
> configure, but the security properties are still the same.

I am not saying work should stop on STEP. What I am saying is that
ISATAP is already being used and has good reasons for that. So the
draft should be quickly adapted to reflect what is deployed and
moved on. That will give us a solution which we can use. Otherwise
we will continue with this standstill situation.

/Karim

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--0-1856160081-1080316280=:95226-- From owner-v6ops@ops.ietf.org Fri Mar 26 12:17: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 MAA02127 for ; Fri, 26 Mar 2004 12:17:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6uuI-000LhV-NB for v6ops-data@psg.com; Fri, 26 Mar 2004 17:14:10 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6uuD-000LfU-5p for v6ops@ops.ietf.org; Fri, 26 Mar 2004 17:14:05 +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 41-md50000000011.tmp for ; Fri, 26 Mar 2004 18:19:42 +0100 Message-ID: <033401c41356$7a6bd920$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <200403082022.PAA26928@ietf.org> <4063E741.474C2E0D@zurich.ibm.com> Subject: Re: I-D ACTION:draft-palet-v6ops-ipv6security-00.txt Date: Fri, 26 Mar 2004 18:19:09 +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, 26 Mar 2004 18:19:42 +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.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 Brian, Thanks a lot for your inputs. My comments below, in-line. Regards, Jordi ----- Original Message -----=20 From: "Brian E Carpenter" To: "IPv6 Operations" Sent: Friday, March 26, 2004 9:18 AM Subject: Re: I-D ACTION:draft-palet-v6ops-ipv6security-00.txt A few comments (not including nits; this is in the spirit of an early review): I will make the next version with XML, so a lot of this issues will be = ok by default ;-) > 1.=20 > Introduction=20 >=20 > The today=C6s Internet paradigms for security need a revision with = the=20 > deployment of IPv6, offering end-to-end security capabilities.=20 >=20 > Current security policies based on a centric approach with unique=20 > border devices don=C6t longer apply. Often they are based in a = firewall=20 > or security gateway and statically configured rules.=20 And they don't work either, due to the "crunchy outside, soft inside" phenomenon (i.e. half of the enemies are inside the firewall). = Additionally, note that the firewall model is deeply incompatible with the model of virtual organizations that is fundamental to Grid computing - virtual organizations cross all traditional security boundaries. [Jordi] Very good input. I will include those aspects in the next = release. > Keeping today=C6s static security model is a wrong approach, which=20 > disables the end-to-end features and advantages of IPv6.=20 "disables" is too strong - "interferes with" is more accurate. [Jordi] Ok. > Enforcing the nomadic users and devices to connect to Internet by=20 > means of the security device, is almost equivalent to disable the=20 > IPsec stack on each node, thus invalidating one of the key IPv6=20 > advantages.=20 I don't think this is really true, with current solutions for IPSEC to traverse NAT, and future solutions from Midcom for firewall traversal. [Jordi] I will reword it. The main idea is that not all the host, or = even NATs or firewalls support this or yes ? This is the same trouble we = have with the IPv6 transition ... > On the other hand, is also true and perfectly understandable that=20 > there is a need to enforce security in the networks, in such way = that=20 > the network administrator has always the control over it.=20 It's the security administrator who wants control; she is often = different from the network administrator. [Jordi] I will use "security administrator (or even the network = administrator)", as some times is the same (medium and small networks). Missing argument here: the current enterprise network security model prevents innovation. [Jordi] again very good input. > 2.=20 > Distributed security model=20 Please credit Steve Bellovin and his colleagues, who first proposed a "distributed firewall" model a few years ago.=20 http://www.research.att.com/~smb/papers/distfw.pdf http://www.research.att.com/~smb/papers/ccs-df.ps=20 [Jordi] Will do so. We are already working in some more drafts on this = topic, so there will be concrete references to this work and some others = with similar views. > The distributed security model implies the use of node or personal=20 > firewalls.=20 >=20 Not only that. It also implies the use of end-to-end applications level security (for example the Web Services security standards). [Jordi] Will include this. > These node or personal firewalls must respect the security policy = of=20 > the network where they are attached.=20 It's more subtle than that. If the "home" security policy of a roaming = system is *different* from the local policy where the system is connected, = there may be actual conflict between the policies. To take a trivial case, local policy might prohibit ICMP messages, but the home policy might require = ICMP probes for some checking purpose. So the solution must allow for = resolution of conflict between security policies. [Jordi] My point of view is that if the security administrator of the = visited network don't allow ICMP we need to respect it, otherwise they = will not accept this distributed security model. If they allow using a = tunnel, then it might be an option to respect the "wishes" of both = policies. > This is possible in most of the situations because, even if IPsec = and=20 > encryption are enforced for most of the communications, nodes often = > have powerful CPUs with unused cycles that will easily accommodate=20 > the extra required workload.=20 Sorry but that's nonsense. Particularly in the case of small roaming = devices, they *don't* have spare capacity. You can argue that capacity for = security should be provided by design, but you can't simply assume there will be = such capacity. [Jordi] Will reconsider this, may be the text is confusing. The point = was not considering roaming devices, but nodes in the infrastructure of = the network that could be configured by the security policy/manager to = share resources for non IPsec capable sensors or roaming devices (just = examples). This could be the case if the firewall doesn't exist (SOHO = networks, SMEs), or the firewall capability is exceed by whatever = reason. Anyway, when I check my laptop CPU and LAN card usage, usually = they are at a very low level of utilization. I guess this is becoming = more and more frequent. > On the other hand, the central firewalls will be able to dedicate = CPU=20 > cycles to new functions, or be able to protect bigger networks.=20 Should intrusion detection be centralized or distributed? Also note that the central firewalls will need to support Midcom-style firewall traversal in future. [Jordi] I believe they should be also distributed, if we can create a = trusted model. Yes, we are already checking the Midcom work. > 4.=20 > The visiting node=20 >=20 ... >=20 > Different visited networks have different security requirements.=20 > Consequently is required that those nomadic nodes dynamically=20 > accommodate their own security policy to the one defined in the=20 > visited network.=20 As noted above, this is subject to the need for conflict resolution when the policies are incompatible. [Jordi] Right, but I'm still not convinced, in the sense that the = priority must be always the "more strict" policy, otherwise, you can be = banned to access that network or even Internet from that network ? > 6.=20 > The security policy server and protocol=20 ... >=20 > When a node is attached to a visited network and receives the = visited=20 > network security policy, basically there are two possible = situations:=20 >=20 > a) The network security policy is less or same restrictive than the = > node configuration. In this case, the node will not change its=20 > security policy configuration.=20 >=20 > b) The network security policy is more restrictive than the node=20 > configuration. In this case, the node will adapt its security=20 > configuration to at least match the one indicated by the security=20 > policy.=20 >=20 > Until the node performs and acknowledge the required security = policy=20 > configuration update, it will not be allowed to transfer/receive = data=20 > to/from other nodes either in the network or other connected=20 > networks.=20 Again the same point. If my employer's corporate security policy has requirement A and I visit a network whose policy has requirement Z, it is *not* true in general that A is either more or less restrictive than Z. It may be that they are simply incompatible. My employer would require that A wins and the host network would require that Z wins. So who wins?=20 [Jordi] That's the point. The more strict one ? ... > A possible approach is to align this with the existing COPS [iii] = and=20 > COPS-PR [iv] standards.=20 It's very unclear that COPS will be widely implemented. [Jordi] COPS was considered as a good option, but we are already = considering other options. Obviously the goal is not developing = something new if there is anything that can be used "as is" or extended = for this mission. > 7.=20 > Single versus multiple point of attack=20 ... > The failure of the central firewall could completely disconnect the = > network from Internet or other networks. In the case of a central=20 > policy server fail, the nodes can be configured by the security=20 > policy in such way that continue working, keeping the same security = > restrictions imposed by the policy server.=20 Instead of "same" I think you mean "most recent." [Jordi] Right. On the other hand, during such a failure, there is a risk of incorrectly or partially configured hosts being wide open. [Jordi] One option could be a "default" network security policy for this = situations, but just a quick thought. Will work on this. How about a compromised host that pretends to conform to the central policy but is actually a hacker haven? [Jordi] Yes, this could happen, even when the central firewall is still = working. We are already working on some options here. > 8.=20 > Non-security-capable nodes and security workload distribution=20 >=20 > Increase in security often means increase in processing power.=20 >=20 > Some nodes could not have the required CPU cycles to afford the=20 > complete required security policy.=20 >=20 > The firewalls or even other security-capable nodes with free=20 > resources, could act as trusted security gateways for the non- > security-capable nodes.=20 >=20 > This seems only possible if minimum security verification can be = done=20 > by those nodes, i.e. digital signature verification.=20 Why? They don't today. All you need is that if a host fails to say "yes, I installed your central security policy", then you treat it as a non-security-capable host. [Jordi] Right. It was a too quick thought. We need to reconsider this. I = will like this feature, but I'm not really convinced is feasible, or = even useful. We need to think in a concrete scenario to see if it makes = sense. > 10.=20 > Virus and spam=20 >=20 > As part of the services offered by the distributed security model, = it=20 > should be considered means to alleviate the effects of virus and=20 > spam.=20 It seems to me that this is far to complex and expensive to distribute. Spam/virus filters require contnuous updating of very sophisticated and large signature files. Since all email flows through mail servers = anyway, I can't see any argument for distributing this complexity. In any case, it's not an IPv6 issue. [Jordi] May be you're right for spam, but virus can also come from a = device attached to the node (disk drive, CD-ROM, USB stick, ....). We = need to evaluate this. What about instant messaging, IRC, file sharing = ... I think we need to work on the feasibility of doing this and balance = pros/cons. Brian ********************************** 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 Mar 26 12:43: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 MAA03954 for ; Fri, 26 Mar 2004 12:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6vKt-000Px2-Hk for v6ops-data@psg.com; Fri, 26 Mar 2004 17:41:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6vKr-000PwY-MV for v6ops@ops.ietf.org; Fri, 26 Mar 2004 17:41:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2QHfNV13480; Fri, 26 Mar 2004 19:41:23 +0200 Date: Fri, 26 Mar 2004 19:41:23 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B1F@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 26 Mar 2004, Karim El-Malki (HF/EAB) wrote: > > ISATAP uses a pseudo-interface (this is especially problematic if the > > implementation also has a 6to4 pseudo-interface, and one big reason > > why ISATAP should be avoided). ISATAP accepts proto-41 packets from > > anyone. > > Just like an IPv6 host accepts IPv6 packets from anyone right? > By using appropriate security (incl. ingress filtering) you limit > the risks. But this is not a problem of ISATAP. No, ISATAP opens a (semi-)trusted conduit, a virtual link, to everyone in the Internet (or everyone in the ISATAP site, if the border security is done properly). Specifically, the ISATAP pseudo-interface, with its link local addresses and functionality using link-local addresses is placed at risk. This is not possible with just any IPv6 host. This is completely different from any IPv6 host accepting IPv6 packets. To say it differently, a regular IPv6 host cannot receive packets with a link-local source address and TTL=255 from practically anyone out there, from completely untrusted source. ISATAP allows -- no, even stronger, requires! -- this. (There are other problems with the ISATAP router spoofing as well, but they are probably not as relevant compared to this.) > > ISATAP does direct tunneling between the nodes (even if they > > aren't in the same admin domain, if deployed as you propose). ISATAP > > relies that the site has made appropriate protections at its > > perimeter, or else its security properties fall apart. ISATAP was > > devised to be used inside a site, not across the sites. > > And that's exactly what is proposed, it is always inside a site > from the IP viewpoint. You do not understand the the concept of "administrative domain". UEs do not belong to the same AD as the 3GPP operator. > > I do not know which specific simplified subset of ISATAP you have in > > mind, but these are fundamental issues with ISATAP as it is > > (and as it > > always has been). Some of these have been made worse (or new ones > > introduced) along the lifetime of ISATAP, so depending on what's > > implemented, it could be worse as well. > > It has been implemented and used widely. You may claim that only a > subset was used and I would be happy to agree. Still that is a reason > for the ISATAP document to be modified to reflect what is deployed and > any limitations but not a reason to discard it. I am certainly in favour > of this and had already sent come comments to Fred Templin about this > to share with the authors. It would help in this discussion if the specific features (and security protections) implemented and used was explicitly spelled out. > By ignoring the reality of what is out there this will make it harder > for IPv6 to be deployed. Also you are just turning the tables since the > text you wanted in that spec is specifically pushing for STEP. So if there > is someone pushing for their solution which the WG has not adopted yet it's > not me unlike what you seem to be hinting. I would like ISATAP to be > given fair consideration, since it is anyway used today and a likely candidate > for more deployment in the short run. I fail to see what's unfair about the current text. Moreover, no objections were raised. It just lists ISATAP as a proposal, mentions a few problems which have been raised about it, and describes a few alternatives in case these problems are considered to be a problem -- and says more work is needed. > Creating an ISATAP vs. STEP competiton > as you are doing will just leave us with nothing to deploy since STEP is > too new. So, are you saying, "we must get ISATAP, otherwise there is nothing we can deploy"? FWIW, I certainly don't want to push for STEP. There's work in progress to create a more unified tunnel server solution. But IMHO ISATAP seems to have way too many drawbacks to go for it blindfolded. And don't say this comes as a late surprise. I think I've been complaining about this at least a year or two now, but folks don't seem to care or don't seem to have sufficient security expertise to even understand the problems. > > Read closer about non-interoperability: it says basically that if we > > wanted to "simplify" or secure ISATAP considerably, that would likely > > require non-interoperable changes to the spec. It is not trying to > > say that current ISATAP implementations are non-interoperable. > > Since current interoperable ISATAP implementations are already a > "simplified" version your logic doesn't make sense. Then they quite likely aren't yet what was referred to with the "simplified" reference in draft-ietf-v6ops-3gpp-analysis-09. I.e., such simplified version could be e.g. a variant which would not include direct tunneling between ISATAP nodes at all. This would not be suitable in some other contexts, though. > > > The paragraph above also talks about ISATAP complexity and > > this does > > > not match the experience with the deployed base. We're > > talking about > > > supporting RA/RS over a tunnel interface and that doesn't seem like > > > something complex. > > > > It has much more to it than just RA/RS over a tunnel interface. > > Again, it says deployed base. Direct tunneling between ISATAP nodes in the same ISATAP site is in the deployed base, right? Thought so. > > I don't think you understand the issues that come into play when you > > deploy something to be used across administrative domains. The > > interface between domains must be carefully analyzed. It > > helps a lot > > if the interface is simple and easy to understand (IMHO which ISATAP > > isn't). > > Actually I think your logic does not reflect at all how a 3gpp mobile > network works. Once again, there is no crossing of administrative domains > in the way you mean it. Administrative domain as a concept has very little to do with the technique used in the network. I.e., it still holds. > > It is one thing to say that the 3GPP operator has identified the user > > (whether using regular or pre-paid SIM or whatever) -- and > > consequently everything any user does to the operator, the > > Internet or > > the user would be magically trusted -- and another to consider what > > the user is able to believe. > > That is, 1) can the user trust > > the other > > 3GPP users who are doing direct tunneling to it, possibly injecting > > malicious packets (which they wouldn't be able to do, unless > > there was > > ISATAP), > > This has nothing to do with ISATAP. With native IPv6 or IPv4 users can > just send each other packets and these packets are in no way less likely > to be malicious than tunnelled packets. Wrong. See the link-local threat. > or 2) can the user trust that the 3GPP operator has secured > > *all* of its borders properly, so that either other users, or anyone > > in the internet could not inject maliscious packets to the user. L2 > > identification helps with none of this. > > It just has to do ingress filtering in the GGSN which from what I know > is default. So you should assume it is default and if anything explicitly > state this as an assumption/requirement. Again, this doesn't help against the link-local threat. > > All of these issues are much simpler with something resembling > > configured tunneling, which is why it's preferable. STEP > > and the like > > are just extensions of that model to make the tunnel easier to > > configure, but the security properties are still the same. > > I am not saying work should stop on STEP. What I am saying is that > ISATAP is already being used and has good reasons for that. And a large number of reasons why this is an incredibly bad idea. Tell me why again the IETF should be advocating bad practice, just because someone didn't understand the consequences and needed something to deploy -- and the first solution that came across seemed to fit? > So the > draft should be quickly adapted to reflect what is deployed and > moved on. That will give us a solution which we can use. Otherwise > we will continue with this standstill situation. Standstill may be better than bad solution. It might help us to get to a good solution. -- 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 Mar 26 12:59: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 MAA04791 for ; Fri, 26 Mar 2004 12:59:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6vaV-0003Ek-Qd for v6ops-data@psg.com; Fri, 26 Mar 2004 17:57:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6vaU-0003EQ-BY for v6ops@ops.ietf.org; Fri, 26 Mar 2004 17:57:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2QHviR13718; Fri, 26 Mar 2004 19:57:44 +0200 Date: Fri, 26 Mar 2004 19:57:44 +0200 (EET) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: IPv6 Operations Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote: > > Yes. This is very real if they use the same address. But from the > > implementation point of view, this is a huge problem. How do they > > ensure that this won't happen? Seems like a very difficult thing to > > do. > > Well, I don't think that I understand why it is such a problem form > the implementation point of view (I certainly wasn't for us, but > then they may be some autoconfiguration issues that are escaping > me). If you enforce this in the implementation strongly enough, i.e., with a MUST, then this is doable. Could be in the spec. The same actually happens with ISATAP and configured tunneling as well. Luckily enough, there should be relatively little overlap with them as well. > > > Well a proto-41 packet will be discarded by an > > > Isatap interface/daemon unless it meets a few very specific > > criteria's.... > > > > Depending on which specification you're looking at, this ranges from > > "check that v4 and the isatap address match for certain packets, but > > don't check for the rest" to "practically nothing". Depends on which > > spec you're looking at... > > May be, but let choose the most solid spec in this sense then. > I assume we are allowed to improve the mechs and perhaps tune them according > to the applicable scenarios. Yes, they could naturally be improved. Such improvement does not help, however, if the core functionality of the mechanism is which would have to be changed. (And such changes might alter its applicability in other scenarios.) > > But regardless of that, the fact stands that unless the site operator > > blocks proto-41 at the edge, they can be injected to all the ISATAP > > nodes. Even if there are checks for such packets, they can cause a > > lot of harm. Checking that v4 and isatap address match does not help > > that much in that regard, as the addresses are spoofable. > > > > Well typically I think that the Isatap router will be located > within the site or at the site edge, > therefore proto-41 will not be a problem on the site edge. You probably mean that they're in the 3GPP network, yes? It's not really in the same "site" with the ISATAP nodes, then, though. Even if so, this would address the external proto-41 threats only when the 3GPP operator would perform proto-41 filtering at its Internet-facing borders. And that would not yet even protect against attacks from the other users in the same 3GPP network. > > No, I mean that if the 3GPP operator provides the ISATAP endpoint, > > it's in the different administrative domain as the UE. UE is managed > > by the user, not the 3GPP operator. > > I don't get this - typically the tunnel endpoint will be managed by > some else than the user - right ? Sorry if I was confusing here -- by "ISATAP endpoint" I was referring to ISATAP router from the ISATAP host's point of view. The scenario is like this: ======================||===========+ ||3GPP user 1| admin domain 1 3GPP operator's ||ISATAP node| network ||===========+ ||3GPP user N| admin domain N (ISATAP router) ||ISATAP node| ||===========+ ======================|| administrative domain A All the users and the 3GPP network are in different administrative domains. Compare this to e.g. a possible enterprise where ISATAP was originally designed for: =============================| user 1 | Enterprise network | | (ISATAP router) user N | | =============================| The router and the hosts are in the same administrative domain. Actually nowadays, when the internal security is much more important, the trend has been to start compartmentalizing the enterprise internal networks as well, and then ISATAP domains would probably have to be smaller, but again, this is an entirely different ballgame than using ISATAP between 3GPP operator (or an ISP) and its users (and between users as well). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Mar 26 12:59: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 MAA04815 for ; Fri, 26 Mar 2004 12:59:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6va5-00034R-6J for v6ops-data@psg.com; Fri, 26 Mar 2004 17:57:21 +0000 Received: from [66.218.79.78] (helo=web80508.mail.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B6va4-00034D-4B for v6ops@ops.ietf.org; Fri, 26 Mar 2004 17:57:20 +0000 Message-ID: <20040326175714.48290.qmail@web80508.mail.yahoo.com> Received: from [205.226.2.67] by web80508.mail.yahoo.com via HTTP; Fri, 26 Mar 2004 09:57:14 PST Date: Fri, 26 Mar 2004 09:57:14 -0800 (PST) From: Fred Templin Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] To: Pekka Savola , "Karim El-Malki \(HF/EAB\)" Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I couldn't quite tell from your mesasge since you didn't state it; was this a "WG chair hat on" message or a "bozo on the bus" message? Fred osprey67@yahoo.com --- Pekka Savola wrote: > On Fri, 26 Mar 2004, Karim El-Malki (HF/EAB) wrote: > > > ISATAP uses a pseudo-interface (this is especially problematic if the > > > implementation also has a 6to4 pseudo-interface, and one big reason > > > why ISATAP should be avoided). ISATAP accepts proto-41 packets from > > > anyone. > > > > Just like an IPv6 host accepts IPv6 packets from anyone right? > > By using appropriate security (incl. ingress filtering) you limit > > the risks. But this is not a problem of ISATAP. > > No, ISATAP opens a (semi-)trusted conduit, a virtual link, to everyone > in the Internet (or everyone in the ISATAP site, if the border > security is done properly). Specifically, the ISATAP > pseudo-interface, with its link local addresses and functionality > using link-local addresses is placed at risk. This is not possible > with just any IPv6 host. > > This is completely different from any IPv6 host accepting IPv6 > packets. To say it differently, a regular IPv6 host cannot receive > packets with a link-local source address and TTL=255 from practically > anyone out there, from completely untrusted source. ISATAP allows -- > no, even stronger, requires! -- this. > > (There are other problems with the ISATAP router spoofing as well, but > they are probably not as relevant compared to this.) > > > > ISATAP does direct tunneling between the nodes (even if they > > > aren't in the same admin domain, if deployed as you propose). ISATAP > > > relies that the site has made appropriate protections at its > > > perimeter, or else its security properties fall apart. ISATAP was > > > devised to be used inside a site, not across the sites. > > > > And that's exactly what is proposed, it is always inside a site > > from the IP viewpoint. > > You do not understand the the concept of "administrative domain". UEs > do not belong to the same AD as the 3GPP operator. > > > > I do not know which specific simplified subset of ISATAP you have in > > > mind, but these are fundamental issues with ISATAP as it is > > > (and as it > > > always has been). Some of these have been made worse (or new ones > > > introduced) along the lifetime of ISATAP, so depending on what's > > > implemented, it could be worse as well. > > > > It has been implemented and used widely. You may claim that only a > > subset was used and I would be happy to agree. Still that is a reason > > for the ISATAP document to be modified to reflect what is deployed and > > any limitations but not a reason to discard it. I am certainly in favour > > of this and had already sent come comments to Fred Templin about this > > to share with the authors. > > It would help in this discussion if the specific features (and > security protections) implemented and used was explicitly spelled out. > > > By ignoring the reality of what is out there this will make it harder > > for IPv6 to be deployed. Also you are just turning the tables since the > > text you wanted in that spec is specifically pushing for STEP. So if there > > is someone pushing for their solution which the WG has not adopted yet it's > > not me unlike what you seem to be hinting. I would like ISATAP to be > > given fair consideration, since it is anyway used today and a likely candidate > > for more deployment in the short run. > > I fail to see what's unfair about the current text. Moreover, no > objections were raised. > > It just lists ISATAP as a proposal, mentions a few problems which have > been raised about it, and describes a few alternatives in case these > problems are considered to be a problem -- and says more work is > needed. > > > Creating an ISATAP vs. STEP competiton > > as you are doing will just leave us with nothing to deploy since STEP is > > too new. > > So, are you saying, "we must get ISATAP, otherwise there is nothing we > can deploy"? > > FWIW, I certainly don't want to push for STEP. There's work in > progress to create a more unified tunnel server solution. But IMHO > ISATAP seems to have way too many drawbacks to go for it blindfolded. > And don't say this comes as a late surprise. I think I've been > complaining about this at least a year or two now, but folks don't > seem to care or don't seem to have sufficient security expertise to > even understand the problems. > > > > Read closer about non-interoperability: it says basically that if we > > > wanted to "simplify" or secure ISATAP considerably, that would likely > > > require non-interoperable changes to the spec. It is not trying to > > > say that current ISATAP implementations are non-interoperable. > > > > Since current interoperable ISATAP implementations are already a > > "simplified" version your logic doesn't make sense. > > Then they quite likely aren't yet what was referred to with the > "simplified" reference in draft-ietf-v6ops-3gpp-analysis-09. > > I.e., such simplified version could be e.g. a variant which would not > include direct tunneling between ISATAP nodes at all. This would not > be suitable in some other contexts, though. > > > > > The paragraph above also talks about ISATAP complexity and > > > this does > > > > not match the experience with the deployed base. We're > > > talking about > > > > supporting RA/RS over a tunnel interface and that doesn't seem like > > > > something complex. > > > > > > It has much more to it than just RA/RS over a tunnel interface. > > > > Again, it says deployed base. > > Direct tunneling between ISATAP nodes in the same ISATAP site is in > the deployed base, right? Thought so. > > > > I don't think you understand the issues that come into play when you > > > deploy something to be used across administrative domains. The > > > interface between domains must be carefully analyzed. It > > > helps a lot > > > if the interface is simple and easy to understand (IMHO which ISATAP > > > isn't). > > > > Actually I think your logic does not reflect at all how a 3gpp mobile > > network works. Once again, there is no crossing of administrative domains > > in the way you mean it. > > Administrative domain as a concept has very little to do with the > technique used in the network. I.e., it still holds. > > > > It is one thing to say that the 3GPP operator has identified the user > > > (whether using regular or pre-paid SIM or whatever) -- and > > > consequently everything any user does to the operator, the > > > Internet or > > > the user would be magically trusted -- and another to consider what > > > the user is able to believe. > > > That is, 1) can the user trust > > > the other > > > 3GPP users who are doing direct tunneling to it, possibly injecting > > > malicious packets (which they wouldn't be able to do, unless > > > there was > > > ISATAP), > > > > This has nothing to do with ISATAP. With native IPv6 or IPv4 users can > > just send each other packets and these packets are in no way less likely > > to be malicious than tunnelled packets. > > Wrong. See the link-local threat. > > > or 2) can the user trust that the 3GPP operator has secured > > > *all* of its borders properly, so that either other users, or anyone > > > in the internet could not inject maliscious packets to the user. L2 > > > identification helps with none of this. > > > > It just has to do ingress filtering in the GGSN which from what I know > > is default. So you should assume it is default and if anything explicitly > > state this as an assumption/requirement. > > Again, this doesn't help against the link-local threat. > > > > All of these issues are much simpler with something resembling > > > configured tunneling, which is why it's preferable. STEP > > > and the like > > > are just extensions of that model to make the tunnel easier to > > > configure, but the security properties are still the same. > > > > I am not saying work should stop on STEP. What I am saying is that > > ISATAP is already being used and has good reasons for that. > > And a large number of reasons why this is an incredibly bad idea. > > Tell me why again the IETF should be advocating bad practice, just > because someone didn't understand the consequences and needed > something to deploy -- and the first solution that came across seemed > to fit? > > > So the > > draft should be quickly adapted to reflect what is deployed and > > moved on. That will give us a solution which we can use. Otherwise > > we will continue with this standstill situation. > > Standstill may be better than bad solution. It might help us to get > to a good solution. > > -- > 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 Mar 26 13:06: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 NAA05193 for ; Fri, 26 Mar 2004 13:06:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6vhS-0004io-K3 for v6ops-data@psg.com; Fri, 26 Mar 2004 18:04:58 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6vhQ-0004iB-KB for v6ops@ops.ietf.org; Fri, 26 Mar 2004 18:04:56 +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 i2QI4mvI029230; Fri, 26 Mar 2004 13:04:49 -0500 (EST) Date: Fri, 26 Mar 2004 13:04:09 -0500 From: Marc Blanchet To: "Bound, Jim" , v6ops@ops.ietf.org Subject: RE: Enterprise scenario text proposal Message-ID: <73100000.1080324249@classic.viagenie.qc.ca> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B05DC0A04@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B05DC0A04@tayexc13.americas.cpqc orp.net> X-Mailer: Mulberry/3.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.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 I have to confirm what Jim is saying. customers are asking for v6-only native deployment with some level of v4 legacy support (i.e. tunnelling). Marc. -- Friday, March 19, 2004 07:03:00 -0500 "Bound, Jim" wrote/a ecrit: > Dave, > > Will respond later traveling and cannot right this moment. But your > missing DSTM and you entered the analysis for enterprise scenarios and > we do not want to go there until after the scenarios are done. So will > not respond to that later. Also we have enterprises moving directly to > IPv6 Native as a strategy as soon as possilbe using dual stack so legacy > v4 can be supported if required. > > thanks > /jim > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dave Thaler >> Sent: Thursday, March 18, 2004 7:34 PM >> To: v6ops@ops.ietf.org >> Subject: Enterprise scenario text proposal >> >> From the minutes: >> > Dave Thaler: As the slide says, enterprise scenarios >> document doesn't >> yet >> > give much help in what's required. But Enterprises want v6 with >> little >> > overhead in any case. >> > Jonne: not discussing enterprise today, Dave should contribute to >> > Enterprise work. >> >> To start following up on my action item, here's text I'll >> propose for possible addition to the >> draft-savola-v6ops-tunneling-00.txt draft. >> For now, I only consider "Scenario 1" (as defined in >> draft-ietf-v6ops-ent-scenarios-01.txt), which is making IPv6 >> equivalent to IPv4. Personally I don't consider scenario 2 >> (supporting only a particular set of apps) as significantly >> unique to the enterprise scenarios and as it's not in any of >> the other non-enterprise scenarios, I will ignore it. I >> leave scenario 3 (essentially IPv4 over native >> IPv6) to others, as I don't have data on that scenario and >> it's not clear to me whether it's really enterprise specific >> (could this arise in 3GPP? I don't know). >> >> +'s indicate proposed additions to the existing draft. >> >> --- >> 3.3 Enterprise Scenarios >> >> The only scenario which is obvious at the moment is when the >> enterprise wishes to deploy IPv6 without changing the gear to be >> dual-stack, without injecting IPv6 into existing VLANs, or without >> adding additional IPv6 routers in the VLANs. >> >> + There are three subcases of this scenario: >> + >> + 1. When the enterprise does not NAT between different parts >> + of the internal network. This case is useful to separate >> + from case 2 merely because it is generally the common case, >> + where simplicity is the most highly valued. >> + >> + 2. When NATs exist within the enterprise network, e.g., to connect >> + branch offices to the corporate network. >> + >> + 3. When the enterprise internally uses multicast >> applications/protocols >> + that they want to transition to IPv6. Here the enterprise has >> + already deployed intra-domain IPv4 multicast to support this >> usage. >> + As with case 1, there are no internal NATs in this case >> since IPv4 >> >> + multicast itself does not cross NATs. >> + >> + NAT traversal must be supported in case 2, and IPv6 >> multicast must >> + be supported in case 3. >> + >> + The need for direct connectivity in all cases is strong due to two >> + factors: >> + * the high end-to-end bandwidth requirements for enterprise >> + applications, e.g., many clients accessing various servers, >> + such that bottlenecks occur if all traffic must be funneled >> + through one or a few tunnel endpoints; >> + * the use of collaborative applications, possibly including >> + high-bandwidth streams such as audio/video. >> + >> + Finally, most enterprise networks currently lack IPv6 >> expertise, and >> + have a great need to keep costs low. Hence simplicity and low >> + infrastructure costs are also required. >> >> --- >> >> 4.1 Scenarios Evaluation >> >> +++++++++ >> NAT-T Direct ISP Secure Simple Low Multicast >> Overhead >> Unman 1.1 * * N - - - - >> Unman 1.2 * N * -/* - - - >> Unman 2 * - * - * - - >> 3GPP 1 N -/* * - * * - >> 3GPP 2 N -/* * - * * - >> + Enterprise 1 N -/* * * * - - >> + Enterprise 2 * -/* * - * - - >> + Enterprise 3 N -/* * - * - * >> >> Legend: * = MUST; - = Nice to have; N = No >> >> + Multicast support indicates whether the mechanism must be able to >> + support multicast traffic. >> >> >> --- >> 4.2 Mechanisms Evaluation >> >> One should note that we are not evaluating the specific version of >> the specification, but rather the mechanism in a more generic sense >> ("which features could this mechanism easily be made to >> work with?"). >> >> >> +++++ >> NAT-T Direct ISP Secure Simple Low Impl. >> Depl. Mcast >> Overhead >> Teredo Y Y N Y N N R Y N >> ISATAP N Y@ Y N/R R Y Y R? N >> TSP Y N Y? Y R N R R? Y? >> STEP Y N Y Y Y/R Y N N Y? >> + L2TP Y N Y Y N N Y Y Y >> + 6to4 N Y N N Y Y Y Y N >> + 6over4 N Y Y R Y Y Y R Y >> >> @: intra-site, no NATs in the path >> >> Legend: Y = Yes; R = Relatively good; N = No >> >> + Multicast indicates whether the mechanism is able to support >> + multicast traffic. >> >> --- >> >> -Dave >> >> >> >> > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Fri Mar 26 13:22: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 NAA06130 for ; Fri, 26 Mar 2004 13:22:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6vvW-0006yI-7j for v6ops-data@psg.com; Fri, 26 Mar 2004 18:19:30 +0000 Received: from [66.163.170.84] (helo=smtp814.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B6vvU-0006xu-E0 for v6ops@ops.ietf.org; Fri, 26 Mar 2004 18:19:28 +0000 Received: from unknown (HELO VALUED847D7605) (carl?e?williams@sbcglobal.net@209.137.156.6 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 26 Mar 2004 18:19:21 -0000 Reply-To: From: "Carl Williams" To: Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] Date: Fri, 26 Mar 2004 10:21:59 -0800 Organization: KDDI Labs USA Message-ID: <000001c4135f$3b085840$7101a8c0@VALUED847D7605> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a bit of operator input that I can provide. We are currently investigating the use of ISATAP with respect to 3GPP2 deployments (cdma2000 networks). The ISATAP router can be placed behind the PDSNs and minimal changes are required. We can gradually transition the 3G network to IPv6 for simple IPv6 service. We will not use 6to4 for this specific deployment. We have tested ISATAP implementations from Cisco, MSFT and public domain versions (usagi Linux). Carl Original Message: ----------------- From: Fred Templin osprey67@yahoo.com Date: Fri, 26 Mar 2004 07:51:20 -0800 (PST) To: karim.el-malki@ericsson.com, pekkas@netcore.fi, v6ops@ops.ietf.org Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] I won't respond to this thread in detail other than to say that a clear sense seems to be emerging from the community in terms of desired scope for the ISATAP spec, and have received similar feedback from other sources as well. About the 6to4 issue, others have already correctly answered that ISATAP and 6to4 would not occur on the same IPv4 interface such that there would be no ambiguity. The only way this could happen is if we had an unrestricted "multihomed IPv4 interface", e.g., a wireless interface that could connect to multiple sites at the same time w/o encapsulation. But, in practice, we either use overlay pseudo interfaces (e.g., PDP contexts, PPP, configured tunnels, ISATAP interfaces, etc.) to keep the sites separate, or link-layer abstractions like the IEEE 802.11 (I)BSS to restrict access to a single site at a time. About interoperability testing, this is certainly high on the agenda but, as others have commented, ISATAP is already seen in wide deployment. I believe there were ISATAP implementations shown in the IPv6 demo exhibits at IETF59 as well; I'll send a request to the 'isatap.com' site administrator asking to have the links there updated. Fred Templin osprey67@yahoo.com "Karim El-Malki (HF/EAB)" wrote: > On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote: > > This stems from the STEP vs. ISATAP competition which I don't quite > > understand. There is not such a big difference between simplified > > host-to-router ISATAP implementations that are deployed > today and the > > functions specified in STEP. > > OK, let's have a few. > > ISATAP uses a pseudo-interface (this is especially problematic if the > implementation also has a 6to4 pseudo-interface, and one big reason > why ISATAP should be avoided). ISATAP accepts proto-41 packets from > anyone. Just like an IPv6 host accepts IPv6 packets from anyone right? By using appropriate security (incl. ingress filtering) you limit the risks. But this is not a problem of ISATAP. > ISATAP does direct tunneling between the nodes (even if they > aren't in the same admin domain, if deployed as you propose). ISATAP > relies that the site has made appropriate protections at its > perimeter, or else its security properties fall apart. ISATAP was > devised to be used inside a site, not across the sites. And that's exactly what is proposed, it is always inside a site from the IP viewpoint. > > I do not know which specific simplified subset of ISATAP you have in > mind, but these are fundamental issues with ISATAP as it is > (and as it > always has been). Some of these have been made worse (or new ones > introduced) along the lifetime of ISATAP, so depending on what's > implemented, it could be worse as well. It has been implemented and used widely. You may claim that only a subset was used and I would be happy to agree. Still that is a reason for the ISATAP document to be modified to reflect what is deployed and any limitations but not a reason to discard it. I am certainly in favour of this and had already sent come comments to Fred Templin about this to share with the authors. > > > So to start with IMO the above paragraph > > should mention the existence of these implementations and their > > interoperability since it is important for mobile > operators/vendors to > > know that there is something they can use. Now it > basically says the > > opposite i.e. no interoperability and wait for further work. > > I do not think that is appropriate at all. If the WG has not made up > its mind, WG document should not be pushing toward a solution which > has known problems. Better not nudge towards any particular > direction. By ignoring the reality of what is out there this will make it harder for IPv6 to be deployed. Also you are just turning the tables since the text you wanted in that spec is specifically pushing for STEP. So if there is someone pushing for their solution which the WG has not adopted yet it's not me unlike what you seem to be hinting. I would like ISATAP to be given fair consideration, since it is anyway used today and a likely candidate for more deployment in the short run. Creating an ISATAP vs. STEP competiton as you are doing will just leave us with nothing to deploy since STEP is too new. > > Read closer about non-interoperability: it says basically that if we > wanted to "simplify" or secure ISATAP considerably, that would likely > require non-interoperable changes to the spec. It is not trying to > say that current ISATAP implementations are non-interoperable. Since current interoperable ISATAP implementations are already a "simplified" version your logic doesn't make sense. > > > The paragraph above also talks about ISATAP complexity and > this does > > not match the experience with the deployed base. We're > talking about > > supporting RA/RS over a tunnel interface and that doesn't seem like > > something complex. > > It has much more to it than just RA/RS over a tunnel interface. Again, it says deployed base. > > > Also there is no need for the sort of security across > > administrative domains mentioned above in 3gpp networks, > since it is > > handled at layer 2. > > I don't think you understand the issues that come into play when you > deploy something to be used across administrative domains. The > interface between domains must be carefully analyzed. It > helps a lot > if the interface is simple and easy to understand (IMHO which ISATAP > isn't). Actually I think your logic does not reflect at all how a 3gpp mobile network works. Once again, there is no crossing of administrative domains in the way you mean it. > > It is one thing to say that the 3GPP operator has identified the user > (whether using regular or pre-paid SIM or whatever) -- and > consequently everything any user does to the operator, the > Internet or > the user would be magically trusted -- and another to consider what > the user is able to believe. > That is, 1) can the user trust > the other > 3GPP users who are doing direct tunneling to it, possibly injecting > malicious packets (which they wouldn't be able to do, unless > there was > ISATAP), This has nothing to do with ISATAP. With native IPv6 or IPv4 users can just send each other packets and these packets are in no way less likely to be malicious than tunnelled packets. or 2) can the user trust that the 3GPP operator has secured > *all* of its borders properly, so that either other users, or anyone > in the internet could not inject maliscious packets to the user. L2 > identification helps with none of this. It just has to do ingress filtering in the GGSN which from what I know is default. So you should assume it is default and if anything explicitly state this as an assumption/requirement. > All of these issues are much simpler with something resembling > configured tunneling, which is why it's preferable. STEP > and the like > are just extensions of that model to make the tunnel easier to > configure, but the security properties are still the same. I am not saying work should stop on STEP. What I am saying is that ISATAP is already being used and has good reasons for that. So the draft should be quickly adapted to reflect what is deployed and moved on. That will give us a solution which we can use. Otherwise we will continue with this standstill situation. /Karim This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Fri Mar 26 14:45: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 OAA10578 for ; Fri, 26 Mar 2004 14:45:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6xEa-000Ipf-Gk for v6ops-data@psg.com; Fri, 26 Mar 2004 19:43:16 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6xEU-000Ioo-IT for v6ops@ops.ietf.org; Fri, 26 Mar 2004 19:43:10 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2QJh9YG014240 for ; Fri, 26 Mar 2004 20:43:09 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 20:43:09 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Mar 2004 20:43:09 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B27@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] Date: Fri, 26 Mar 2004 20:43:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Mar 2004 19:43:09.0365 (UTC) FILETIME=[91043650:01C4136A] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Just like an IPv6 host accepts IPv6 packets from anyone right? > > By using appropriate security (incl. ingress filtering) you limit > > the risks. But this is not a problem of ISATAP. > > No, ISATAP opens a (semi-)trusted conduit, a virtual link, > to everyone > in the Internet (or everyone in the ISATAP site, if the border > security is done properly). Specifically, the ISATAP > pseudo-interface, with its link local addresses and functionality > using link-local addresses is placed at risk. This is not possible > with just any IPv6 host. > > This is completely different from any IPv6 host accepting IPv6 > packets. To say it differently, a regular IPv6 host cannot receive > packets with a link-local source address and TTL=255 from practically > anyone out there, from completely untrusted source. ISATAP allows -- > no, even stronger, requires! -- this. It is good that you bring this up. The host-to-router model is the only one we have ever talked about using. It is not difficult to have only a default route to the ISATAP router and only accept tunnelled packets from it. I am in favour of the spec being updated in this sense as from previous discussions. Host-to-router is what is used in the deployments I know about. > > > ISATAP does direct tunneling between the nodes (even if they > > > aren't in the same admin domain, if deployed as you > propose). ISATAP > > > relies that the site has made appropriate protections at its > > > perimeter, or else its security properties fall apart. > ISATAP was > > > devised to be used inside a site, not across the sites. > > > > And that's exactly what is proposed, it is always inside a site > > from the IP viewpoint. > > You do not understand the the concept of "administrative > domain". UEs > do not belong to the same AD as the 3GPP operator. I don't think we should be wasting much time on this point since we should focus on how things work today. When a terminal is authenticated it is allowed access to a certain basic set of services and this can be one of them. > > > > I do not know which specific simplified subset of > ISATAP you have in > > > mind, but these are fundamental issues with ISATAP as it is > > > (and as it > > > always has been). Some of these have been made worse > (or new ones > > > introduced) along the lifetime of ISATAP, so depending on what's > > > implemented, it could be worse as well. > > > > It has been implemented and used widely. You may claim that only a > > subset was used and I would be happy to agree. Still that > is a reason > > for the ISATAP document to be modified to reflect what is > deployed and > > any limitations but not a reason to discard it. I am > certainly in favour > > of this and had already sent come comments to Fred Templin > about this > > to share with the authors. > > It would help in this discussion if the specific features (and > security protections) implemented and used was explicitly > spelled out. This is mostly something for the ISATAP authors IMO. We can then discuss based on a new version of the draft that addresses those features. > > > By ignoring the reality of what is out there this will > make it harder > > for IPv6 to be deployed. Also you are just turning the > tables since the > > text you wanted in that spec is specifically pushing for > STEP. So if there > > is someone pushing for their solution which the WG has not > adopted yet it's > > not me unlike what you seem to be hinting. I would like > ISATAP to be > > given fair consideration, since it is anyway used today > and a likely candidate > > for more deployment in the short run. > > I fail to see what's unfair about the current text. Moreover, no > objections were raised. I remember objecting several times on the admin boundary crossing issue and the protocol's complexity. I may have missed the last time but these issues aren't new. > > It just lists ISATAP as a proposal, mentions a few problems > which have > been raised about it, and describes a few alternatives in case these > problems are considered to be a problem -- and says more work is > needed. It says that ISATAP has some problems (in 3ggp nets which is what this doc is about) which we don't seem to have an agreement on. It also says that STEP is an alternative and doesn't mention issues with it. So I read it as saying that STEP is the way to go. > > Creating an ISATAP vs. STEP competiton > > as you are doing will just leave us with nothing to deploy > since STEP is > > too new. > > So, are you saying, "we must get ISATAP, otherwise there is > nothing we > can deploy"? It's already out there anyway. So yes I do say that, given that I do not see the great problems you see. If the spec is modified according to what we talked about above, and Fred's message seems to hint that this may be the direction, then it would certainly help deployment IMO. And I'm not thinking only about the mobile field of course. > > FWIW, I certainly don't want to push for STEP. There's work in > progress to create a more unified tunnel server solution. But IMHO > ISATAP seems to have way too many drawbacks to go for it blindfolded. > And don't say this comes as a late surprise. I think I've been > complaining about this at least a year or two now, but folks don't > seem to care or don't seem to have sufficient security expertise to > even understand the problems. Maybe people don't care because you expect them to agree with you all the time since you understand the problems? > > > Read closer about non-interoperability: it says > basically that if we > > > wanted to "simplify" or secure ISATAP considerably, > that would likely > > > require non-interoperable changes to the spec. It is > not trying to > > > say that current ISATAP implementations are non-interoperable. > > > > Since current interoperable ISATAP implementations are already a > > "simplified" version your logic doesn't make sense. > > Then they quite likely aren't yet what was referred to with the > "simplified" reference in draft-ietf-v6ops-3gpp-analysis-09. > > I.e., such simplified version could be e.g. a variant which would not > include direct tunneling between ISATAP nodes at all. This > would not > be suitable in some other contexts, though. The text just says simplified, and we can take that to mean anything. The implemented version is suitable for some important v6ops scenarios so it is worth spending time on it IMO. > > > > > The paragraph above also talks about ISATAP complexity and > > > this does > > > > not match the experience with the deployed base. We're > > > talking about > > > > supporting RA/RS over a tunnel interface and that > doesn't seem like > > > > something complex. > > > > > > It has much more to it than just RA/RS over a tunnel interface. > > > > Again, it says deployed base. > > Direct tunneling between ISATAP nodes in the same ISATAP site is in > the deployed base, right? Thought so. I already commented on that above. > > > > I don't think you understand the issues that come into > play when you > > > deploy something to be used across administrative domains. The > > > interface between domains must be carefully analyzed. It > > > helps a lot > > > if the interface is simple and easy to understand (IMHO > which ISATAP > > > isn't). > > > > Actually I think your logic does not reflect at all how a > 3gpp mobile > > network works. Once again, there is no crossing of > administrative domains > > in the way you mean it. > > Administrative domain as a concept has very little to do with the > technique used in the network. I.e., it still holds. I am talking about how a mobile network works and don't know what to answer when you reply with a concept. > > > > It is one thing to say that the 3GPP operator has > identified the user > > > (whether using regular or pre-paid SIM or whatever) -- and > > > consequently everything any user does to the operator, the > > > Internet or > > > the user would be magically trusted -- and another to > consider what > > > the user is able to believe. > > > That is, 1) can the user trust > > > the other > > > 3GPP users who are doing direct tunneling to it, > possibly injecting > > > malicious packets (which they wouldn't be able to do, unless > > > there was > > > ISATAP), > > > > This has nothing to do with ISATAP. With native IPv6 or > IPv4 users can > > just send each other packets and these packets are in no > way less likely > > to be malicious than tunnelled packets. > > Wrong. See the link-local threat. See the host-to-router discussion that we've been having over and over again. I fully agree that building only on the host-to-router model (i.e. default route and only accept packets from the router) is the right way ahead. Ingress filtering is assumed as default as I said before. > > > or 2) can the user trust that the 3GPP operator has secured > > > *all* of its borders properly, so that either other > users, or anyone > > > in the internet could not inject maliscious packets to > the user. L2 > > > identification helps with none of this. > > > > It just has to do ingress filtering in the GGSN which from > what I know > > is default. So you should assume it is default and if > anything explicitly > > state this as an assumption/requirement. > > Again, this doesn't help against the link-local threat. It does if we ensure that the host-to-router model is used. Other general threats would be in the SEND area. > > > > All of these issues are much simpler with something resembling > > > configured tunneling, which is why it's preferable. STEP > > > and the like > > > are just extensions of that model to make the tunnel easier to > > > configure, but the security properties are still the same. > > > > I am not saying work should stop on STEP. What I am saying is that > > ISATAP is already being used and has good reasons for that. > > And a large number of reasons why this is an incredibly bad idea. > > Tell me why again the IETF should be advocating bad practice, just > because someone didn't understand the consequences and needed > something to deploy -- and the first solution that came across seemed > to fit? I guess I would be that someone you talk about, well enlighten us ignorants then! Seriously, I don't think you have grounds to claim what I wrote above is bad practice. > > > So the > > draft should be quickly adapted to reflect what is deployed and > > moved on. That will give us a solution which we can use. Otherwise > > we will continue with this standstill situation. > > Standstill may be better than bad solution. It might help us to get > to a good solution. This attitude is what has helped get v6ops to a standstill. It's true that we could just keep on following your recommendation to push back on everything and wait for something good to happen...but obviously I strongly disagree with this approach. I'd actually like to see IPv6 deployed. /Karim This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Fri Mar 26 16:03:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14777 for ; Fri, 26 Mar 2004 16:03:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6yPv-0004Eb-PY for v6ops-data@psg.com; Fri, 26 Mar 2004 20:59:03 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6yPu-0004EC-EB for v6ops@ops.ietf.org; Fri, 26 Mar 2004 20:59:02 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2QKwih09446; Fri, 26 Mar 2004 12:58:44 -0800 X-mProtect: <200403262058> 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 smtpdvc4lVf; Fri, 26 Mar 2004 12:58:42 PST Message-ID: <40649995.6060904@iprg.nokia.com> Date: Fri, 26 Mar 2004 12:59:01 -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: "Karen E. Nielsen (AH/TED)" , IPv6 Operations Subject: Re: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, This note seems more suitable for legitimate follow-up; see below: Pekka Savola wrote: >On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote: > > >>>Yes. This is very real if they use the same address. But from the >>>implementation point of view, this is a huge problem. How do they >>>ensure that this won't happen? Seems like a very difficult thing to >>>do. >>> >>> >>Well, I don't think that I understand why it is such a problem form >>the implementation point of view (I certainly wasn't for us, but >>then they may be some autoconfiguration issues that are escaping >>me). >> >> > >If you enforce this in the implementation strongly enough, i.e., with >a MUST, then this is doable. Could be in the spec. > I can take this up with the co-authors. Something along the lines of "must not mix sites over the same IPv4 interface"? There might also be some text from older versions of the spec that could help. >The same actually happens with ISATAP and configured tunneling as >well. Luckily enough, there should be relatively little overlap with >them as well. > Here, it would seem normal and natural to find both ISATAP and configured tunnels configured over the same IPv4 interface. >>>>Well a proto-41 packet will be discarded by an >>>>Isatap interface/daemon unless it meets a few very specific >>>> >>>> >>>criteria's.... >>> >>>Depending on which specification you're looking at, this ranges from >>>"check that v4 and the isatap address match for certain packets, but >>>don't check for the rest" to "practically nothing". Depends on which >>>spec you're looking at... >>> >>> >>May be, but let choose the most solid spec in this sense then. >>I assume we are allowed to improve the mechs and perhaps tune them according >>to the applicable scenarios. >> >> > >Yes, they could naturally be improved. Such improvement does not >help, however, if the core functionality of the mechanism is which >would have to be changed. (And such changes might alter its >applicability in other scenarios.) > > > >>>But regardless of that, the fact stands that unless the site operator >>>blocks proto-41 at the edge, they can be injected to all the ISATAP >>>nodes. Even if there are checks for such packets, they can cause a >>>lot of harm. Checking that v4 and isatap address match does not help >>>that much in that regard, as the addresses are spoofable. >>> >>> >>> >>Well typically I think that the Isatap router will be located >>within the site or at the site edge, >>therefore proto-41 will not be a problem on the site edge. >> >> > >You probably mean that they're in the 3GPP network, yes? It's not >really in the same "site" with the ISATAP nodes, then, though. > >Even if so, this would address the external proto-41 threats only when >the 3GPP operator would perform proto-41 filtering at its >Internet-facing borders. And that would not yet even protect against >attacks from the other users in the same 3GPP network. > But, wouldn't this depend on whether the ISATAP router sits on the edge of the 3GPP operator network vs. somewhere inside the network? See more on this below: >>>No, I mean that if the 3GPP operator provides the ISATAP endpoint, >>>it's in the different administrative domain as the UE. UE is managed >>>by the user, not the 3GPP operator. >>> >>> >>I don't get this - typically the tunnel endpoint will be managed by >>some else than the user - right ? >> >> > >Sorry if I was confusing here -- by "ISATAP endpoint" I was referring >to ISATAP router from the ISATAP host's point of view. > >The scenario is like this: > >======================||===========+ > ||3GPP user 1| admin domain 1 > 3GPP operator's ||ISATAP node| > network ||===========+ > ||3GPP user N| admin domain N > (ISATAP router) ||ISATAP node| > ||===========+ >======================|| >administrative domain A > >All the users and the 3GPP network are in different administrative >domains. > Yes, but if we limit the ISATAP router to occur at the edge of the 3GPP operator network (and not somewhere inside the network), then we have a natural point of demarcation for site boundaries. E.g., if 3GPP user 1 in your example opens up an IPv4 PDP context, and the 3GPP operator's equipment acts as an ISATAP router on an interface at the outward-facing edge of administrative domain A, then the PDP context would extend admin domain 1 only to the edge of the operator's network and not allow it to penetrate into admin domain A, i.e., there would be no site-overlap. This would make the interface(s) at the outward-facing edge of admin domain A appear to be ISATAP router interfaces, and the 3GPP operator's network would appear as a gigantic ISATAP router with multiple ISATAP interfaces - one per 3GPP user, i.e., one per customer site. Would this go toward addressing your concern? And, is there anything more needed in the spec to support this? Fred ftemplin@iprg.nokia.com P.S. I recall posting a note proposing an "inside-out isatap model" a long time ago, but it was quickly swept aside for some reason. From owner-v6ops@ops.ietf.org Fri Mar 26 16:07: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 QAA15015 for ; Fri, 26 Mar 2004 16:07:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6yWF-0005dG-3l for v6ops-data@psg.com; Fri, 26 Mar 2004 21:05:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6yWA-0005cP-Jq for v6ops@ops.ietf.org; Fri, 26 Mar 2004 21:05:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2QL5Rt17118; Fri, 26 Mar 2004 23:05:27 +0200 Date: Fri, 26 Mar 2004 23:05:27 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639B27@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 26 Mar 2004, Karim El-Malki (HF/EAB) wrote: > > > Just like an IPv6 host accepts IPv6 packets from anyone right? > > > By using appropriate security (incl. ingress filtering) you limit > > > the risks. But this is not a problem of ISATAP. > > > > No, ISATAP opens a (semi-)trusted conduit, a virtual link, > > to everyone > > in the Internet (or everyone in the ISATAP site, if the border > > security is done properly). Specifically, the ISATAP > > pseudo-interface, with its link local addresses and functionality > > using link-local addresses is placed at risk. This is not possible > > with just any IPv6 host. > > > > This is completely different from any IPv6 host accepting IPv6 > > packets. To say it differently, a regular IPv6 host cannot receive > > packets with a link-local source address and TTL=255 from practically > > anyone out there, from completely untrusted source. ISATAP allows -- > > no, even stronger, requires! -- this. > > It is good that you bring this up. The host-to-router model is the only > one we have ever talked about using. It is not difficult to have only > a default route to the ISATAP router and only accept tunnelled packets from > it. I am in favour of the spec being updated in this sense as from > previous discussions. Host-to-router is what is used in the deployments > I know about. Note that this is in conflict with a lot of deployments in (non-3GPP) cases, e.g., inside certain enterprises. There may be a lot of pushback for making that change. (Which is why I've taken this to be an integral feature of ISATAP.) [cutting down some quotes which didn't seem relevant anymore] > > It would help in this discussion if the specific features (and > > security protections) implemented and used was explicitly > > spelled out. > > This is mostly something for the ISATAP authors IMO. > We can then discuss based on a new version of the draft that > addresses those features. Obviously. However, as noted above, I see an inevitably conflict of interests down the road if one removes host-to-host part of ISATAP. So, the question is whether one could get consensus for such a change. I mean, as this is a non-trivial change, I don't think one can go around asking for, "do we want to go ahead with ISATAP?" and then modify it like this. We have to have a stronger strawman proposal (and some form of acceptance) in the table. Like, "this is ISATAP-DirectTunneling [draft1], this is ISATAP-HostToRouterOnly [draft2] .. is one of these the way we want to go?" To be frank, if you look at the minimized ISATAP protocol (only host-to-router part), it's practically quite similar to what STEP (in Ad-hoc) is doing, except instead of the router being able to give you a /64 (or more), the client calculates a /128 for itself (simplifying one part of the process). So, I'm not sure whether it's worth taking ISATAP that road (though it may be an interesting exercise to see how it'd look like), as it seems to be fundamentally different from the original ISATAP design. > > I fail to see what's unfair about the current text. Moreover, no > > objections were raised. > > I remember objecting several times on the admin boundary crossing > issue and the protocol's complexity. I may have missed the last > time but these issues aren't new. Right. You among others objected to previous text proposals, so a new one was coined up, trying to find a balance between different proposals. > > It just lists ISATAP as a proposal, mentions a few problems > > which have > > been raised about it, and describes a few alternatives in case these > > problems are considered to be a problem -- and says more work is > > needed. > > It says that ISATAP has some problems (in 3ggp nets which is what > this doc is about) which we don't seem to have an agreement on. It does not say ISATAP has problems; it says "issues have been raised about it". It leaves the interpretation whether those issues are relevant or not to the reader. It specifically didn't say "we have consensus that ISATAP has these and these problems..". > It also says that STEP is an alternative and doesn't mention issues > with it. So I read it as saying that STEP is the way to go. No significant issues have been raised about it, so it'd be difficult to mention those :-). > > FWIW, I certainly don't want to push for STEP. There's work in > > progress to create a more unified tunnel server solution. But IMHO > > ISATAP seems to have way too many drawbacks to go for it blindfolded. > > And don't say this comes as a late surprise. I think I've been > > complaining about this at least a year or two now, but folks don't > > seem to care or don't seem to have sufficient security expertise to > > even understand the problems. > > Maybe people don't care because you expect them to agree with you > all the time since you understand the problems? Agreeing doesn't hurt of course ;-) .. but it isn't necessary. I'm trying to get to the point where people voicing opinions are making *informed* decisions. Without sharing understanding of the issues (which apparently hasn't been too succesful, probably partially due to my fault for not documenting them more precisely, e.g. in an Internet-Draft) it's difficult to argue whether there is agreement whether they are significant issues or not (which hasn't really happened so far). Read: I'm personally strongly against making uninformed decisions. > > Then they quite likely aren't yet what was referred to with the > > "simplified" reference in draft-ietf-v6ops-3gpp-analysis-09. > > > > I.e., such simplified version could be e.g. a variant which would not > > include direct tunneling between ISATAP nodes at all. This > > would not > > be suitable in some other contexts, though. > > The text just says simplified, and we can take that to mean anything. Which is why it also said, "probably non-interoperable". :) > The implemented version is suitable for some important v6ops scenarios > so it is worth spending time on it IMO. The implemented version(s), at least about three of them which I'm aware of, contain the host-to-host interactions as well. > > > I am not saying work should stop on STEP. What I am saying is that > > > ISATAP is already being used and has good reasons for that. > > > > And a large number of reasons why this is an incredibly bad idea. > > > > Tell me why again the IETF should be advocating bad practice, just > > because someone didn't understand the consequences and needed > > something to deploy -- and the first solution that came across seemed > > to fit? > > I guess I would be that someone you talk about, well enlighten us > ignorants then! Seriously, I don't think you have grounds to claim > what I wrote above is bad practice. I've been trying... ;-) Why do you think I've been trying to preach against this for a long time, wasting a lot of time in the process? Hint: I don't derive pleasure from disagreeing with people ;-). It's because I *do* think it *is* a bad idea, and could be harmful thing to recommend. It's unfortunate that some have taken it and deployed it (in scenarios where it's not IMHO suitable) already, and some others are considering it: I'd hope these discussions would have taken place 3 years ago. But even more unfortunate would be saying "OK, now that a couple of players have deployed it or piloted that, because they went there on their own not knowing (or believing) the dangers, we should follow suit and dive in the shallow water ourselves as well." That does not seem like a good idea at all. It might be that in the end we could decide that, OK, with sufficiently strong warnings, good text in the document, added security checks, or whatever, the protocol might go forward in some form and be recommended ... but THAT should have to be done in an informed fashion, documenting/being aware of the concerned issues, not like it seems to have been pushed until now. > It's true that we could just keep on following your recommendation to push > back on everything and wait for something good to happen...but obviously > I strongly disagree with this approach. I'd actually like to see IPv6 > deployed. If you note, I'd rather not wait for something good to happen. Some alternatives have been proposed (just as a proof-of-concept) when I got furstrated when it wasn't apparent that alternative solutions could provide the same features with less pain. Some new proposals/integrated protocols are being worked. This is more of a question of the will to go forward with eyes open or not. .... Even if this thread may not have been the most productive one at start, based on this exchange I'm hoping that we're moving towards better understanding .. and will likely be able to solve (or at least gain understanding) of these very difficult issues easier in the short term. -- 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 Mar 29 07:05: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 HAA28174 for ; Mon, 29 Mar 2004 07:05:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B7vRQ-000Kuk-27 for v6ops-data@psg.com; Mon, 29 Mar 2004 12:00:32 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7vRM-000KsL-Bx for v6ops@ops.ietf.org; Mon, 29 Mar 2004 13:00:28 +0100 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2TC0RqY000590 for ; Mon, 29 Mar 2004 14:00:27 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Mar 2004 14:00:27 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H7DJC6X1; Mon, 29 Mar 2004 12:03:39 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Mar 2004 12:01:47 +0200 Message-ID: X-Sybari-Trust: 58f26722 272a6e05 bf9f9d61 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , "'Fred Templin'" Cc: IPv6 Operations Subject: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] Date: Mon, 29 Mar 2004 12:01:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 29 Mar 2004 12:00:27.0082 (UTC) FILETIME=[6CA542A0:01C41585] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Fred, All > On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote: > > > Yes. This is very real if they use the same address. > But from the > > > implementation point of view, this is a huge problem. How do they > > > ensure that this won't happen? Seems like a very > difficult thing to > > > do. > > > > Well, I don't think that I understand why it is such a problem form > > the implementation point of view (I certainly wasn't for us, but > > then they may be some autoconfiguration issues that are escaping > > me). > > If you enforce this in the implementation strongly enough, i.e., with > a MUST, then this is doable. Could be in the spec. You don't need at MUST only support one kind of tunnels here, however the implementation must be able to prioritise the tunnel interfaces and rules for how the prioritisation is done should be included in the spec. For outbound traffic there isn't a problem, the appropriate tunnnel interface should be selected from the forwarding table/destination cache. For inbound traffic there is an issue if the tunnel interfaces, lets say an Isatap pseudo tunnel interface and a configured v6inv4 tunnel interface, are anchored on the same (source) address of an Ipv4 interface. The implementation must here be able to determine which protocol processing module (Isatap or configured tunnel respectively) that an incomming packet should be subject to. One possibility here (which we have used in one implementation) it to apply the following inbound processing rules in prioritised order: R1. If the outer IPv4 header of the encapsulated packet matches a configured v6inv4 tunnel (if any) the packet is processed by this tunnel interface. R2. If the prefix of the source address in the inner IPv6 header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel interface. R3. If the prefix of either the source or destination address in the inner IPv6 header is a 6to4 prefix, the packet is processed by the (if any) 6to4 tunnel interface. I do consider it unlikely to have both 6to4 and Isatap used on the same Ipv4 interface so a more strict version of the above could be: An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on the same IPv4 interface (address of an IPv4 interface, strictly speaking, the problems only arise if the tunnels are anchored on the samme addresses). An Isatap tunnel interface and a configured v6inv4 tunnel interface may be anchored on the same Ipv4 interface (address of Ipv4 interface). In this case the implementation must comply with the following inbound processing rules in prioritized order: R1. If the outer IPv4 header of the encapsulated packet matches a configured v6inv4 tunnel (if any) the packet is processed by this tunnel interface. R2. If the prefix of the source address in the inner IPv6 header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel interface. (Obviously the same prioritization can be enforced in between v6inv4 configured tunnels and 6to4 pseudo interfaces, but lets leave that out here.) > > The same actually happens with ISATAP and configured tunneling as > well. Luckily enough, there should be relatively little overlap with > them as well. As Fred has pointed out then coexistence in between Isatap tunnels and configured tunnel interfaces anchored on the same Ipv4 address/interface would be nice to have. BR, Karen This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Mon Mar 29 18: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 SAA02950 for ; Mon, 29 Mar 2004 18:14:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B85tD-0005C7-P3 for v6ops-data@psg.com; Mon, 29 Mar 2004 23:09:55 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B85tC-0005Bp-7i for v6ops@ops.ietf.org; Tue, 30 Mar 2004 00:09:54 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2TN9fw01667; Mon, 29 Mar 2004 15:09:41 -0800 X-mProtect: <200403292309> 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 smtpdOd14H5; Mon, 29 Mar 2004 15:09:39 PST Message-ID: <4068ACB1.6010609@iprg.nokia.com> Date: Mon, 29 Mar 2004 15:09:37 -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: "Karen E. Nielsen (AH/TED)" CC: "'Pekka Savola'" , IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen, The points you raise warrant careful consideration; see below: Karen E. Nielsen (AH/TED) wrote: >Hi Pekka, Fred, All > > > >>On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote: >> >> >>>>Yes. This is very real if they use the same address. >>>> >>>> >>But from the >> >> >>>>implementation point of view, this is a huge problem. How do they >>>>ensure that this won't happen? Seems like a very >>>> >>>> >>difficult thing to >> >> >>>>do. >>>> >>>> >>>Well, I don't think that I understand why it is such a problem form >>>the implementation point of view (I certainly wasn't for us, but >>>then they may be some autoconfiguration issues that are escaping >>>me). >>> >>> >>If you enforce this in the implementation strongly enough, i.e., with >>a MUST, then this is doable. Could be in the spec. >> >> > >You don't need at MUST only support one kind of tunnels here, > I don't think "MUST only support one kind of tunnels" was exactly what Pekka was implying, but see more below: >however the implementation must be able to >prioritise the tunnel interfaces and rules for >how the prioritisation is done should >be included in the spec. > Agree that an implementation must be able to prioritise the tunnel interfaces. Not quite as clear on what should be included in "the spec", and not entirely sure exactly which document you are referring to when you say: "the spec", but see more below: >For outbound traffic there isn't a problem, >the appropriate tunnnel interface should >be selected from the forwarding table/destination cache. > Agreed; longest-prefix match will select the appropriate tunnel interface for outbound traffic. >For inbound traffic there is an issue if the tunnel interfaces, >lets say an Isatap pseudo tunnel interface and a configured >v6inv4 tunnel interface, are anchored on the same >(source) address of an Ipv4 interface. >The implementation must here be able to determine which protocol processing module >(Isatap or configured tunnel respectively) that an incomming >packet should be subject to. > Agree with the above assertions regarding inbound traffic. >One possibility here (which we have used in one implementation) >it to apply the following inbound processing rules in prioritised order: >R1. If the outer IPv4 header of the encapsulated packet matches a configured v6inv4 tunnel (if any) the packet is processed by this tunnel interface. > IP-proto-41 packets are first checked to determine whether they belong to a configured tunnel by checking the (source/destination addresses) in the IPv4 header, yes. This much seems consistent with the current ISATAP draft version, but thanks for reminding of this. >R2. If the prefix of the source address in the inner IPv6 header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel interface. >R3. If the prefix of either the source or destination address in the inner IPv6 header is a 6to4 prefix, the packet is processed by the (if any) 6to4 tunnel interface. > >I do consider it unlikely to have both 6to4 and Isatap used on the same Ipv4 interface so a more strict version of the above could be: > >An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on the same IPv4 interface >(address of an IPv4 interface, strictly speaking, the problems only arise if the tunnels are anchored on the samme addresses). > (Retracting a bit from some comments in an earlier message on this subject.) According to RFC 3056, 6to4 can only occur over global unicast IPv4 addresses. ISATAP interfaces can also occur over global unicast IPv4 addresses, in which case the ISATAP link would span the entire global IPv4 Internet. If we allowed both a 6to4 interface and an ISATAP interface to be anchored to the *same* global unicast IPv4 address (e.g., "V4ADDR"), it should be OK as long as no prefixes derived from "2002:V4ADDR::/48" (i.e., the /48 prefix itself, or any finer-grained derivative prefix) are configured as on-link prefixes on the ISATAP interface. This would keep the "6to4-prefixed IPv6 Internet" from overlapping with the "everything-else-prefixed IPv6 Internet", where "everything-else" is a candidate prefix for ISATAP. I think there may be several possible ways of expressing this, ranging from "least restrictive" to: "most restrictive"; below are two possible examples that lie at the extremities of the range of alternatives: Least restrictive: ************** "An ISATAP and a 6to4 tunnel interface MAY coexist on the same global unicast IPv4 address ("V4ADDR"), but in this case the ISATAP interface MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as an on-link prefix." Most restrictive: ************** "An ISATAP interface configured over a global unicast IPv4 address MUST NOT configure a prefix derived from "2002::/16" as an on-link prefix." (Note that both of these examples still allow for ISATAP interfaces configured over private IPv4 addresses to configure 6to4 prefixes, but the ISATAP tunneling would be strictly intra-site in that case.) Any comments on this? >An Isatap tunnel interface and a configured v6inv4 tunnel interface may be anchored on >the same Ipv4 interface (address of Ipv4 interface). In this case the implementation must comply with the following inbound processing rules in prioritized order: >R1. If the outer IPv4 header of the encapsulated packet matches a configured v6inv4 tunnel (if any) the packet is processed by this tunnel interface. > Agreed, as above. >R2. If the prefix of the source address in the inner IPv6 header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel interface. > I have to say that I have thought hard about this rule and am not entirely sure what to make of it, since it seems to simplistic. But, I will try: 1) What we have considered for this space to-date is that an ISATAP interface would match a specific IPv4 destination address and a wild-card source address in the IPv4 header of an ip-proto-41 packet. 2) Multiple ISATAP interfaces might be matched by this criteria, and so we require a means for identifying the correct one. 3) An ISATAP interface that configures a prefix that matches the IPv6 source of the packet (if found) is clearly the best first-choice to receive the packet. 4) If no ISATAP interface with a matching prefix is found, this could be a packet from an off-link source that is being forwarded to (or, through this decapsulator by a member of the Potential Router List. But, stopping now for a closer look at item 4), there seems to be no way to determine which ISATAP interface (among possibly many) might be the correct one to receive and decapsulate the packet - if any. It could be that the IPv6 destination address is a foreign address also, making for a router<->router transaction which is a non-goal for ISATAP. This says that, in order to disambiguate the search, we really need to treat all possible IPv6 source addresses as on-link for the purpose of receiving packets, but off-link for the purpose of sending return packets. In other words, we would need an ISATAP interface with a distinct /128 prefix for each destination we are actively communicating with that uses the same IPv6 next-hop address for return addresses. In other words, from a host's viewpoint the sources of IPv6 packets for which a matching ISATAP interface exists would all appear to be on-link, but the destinations would all appear to be off-link and reachable through a particular IPv6 next-hop address. There is a (somewhat) subtle implication here for decapsulation validity checks of the IPv4 source address, but should be very simple to express. If what I am saying makes sense, and if we can agree that ISATAP support for router<->router tunneling is a non-goal, then I believe your R2 above could provide a useful simplification for the spec. >(Obviously the same prioritization can be enforced in between v6inv4 configured tunnels and >6to4 pseudo interfaces, but lets leave that out here.) > Agree with let's leave it out. >>The same actually happens with ISATAP and configured tunneling as >>well. Luckily enough, there should be relatively little overlap with >>them as well. >> >> > >As Fred has pointed out then coexistence in between Isatap tunnels and >configured tunnel interfaces anchored on the same Ipv4 address/interface >would be nice to have. > Already allowed in the current draft, and will make sure it stays that way. Fred ftemplin@iprg.nokia.com >BR, Karen > >This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > > > From owner-v6ops@ops.ietf.org Mon Mar 29 18:39: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 SAA04158 for ; Mon, 29 Mar 2004 18:39:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B86Kk-000AI9-08 for v6ops-data@psg.com; Mon, 29 Mar 2004 23:38:22 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B86Ki-000AHt-Fg for v6ops@ops.ietf.org; Tue, 30 Mar 2004 00:38:20 +0100 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HVD00M0A2ZV82@mailout1.samsung.com> for v6ops@ops.ietf.org; Tue, 30 Mar 2004 08:38:19 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HVD00KVV2ZUSA@mailout1.samsung.com> for v6ops@ops.ietf.org; Tue, 30 Mar 2004 08:38:18 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HVD0006F2ZUVK@mmp1.samsung.com> for v6ops@ops.ietf.org; Tue, 30 Mar 2004 08:38:18 +0900 (KST) Date: Tue, 30 Mar 2004 08:38:34 +0900 From: "S. Daniel Park" Subject: RE:[DHCP and IPv6over4 Tunnels]automatic tunnel mechanism selection In-reply-to: To: Alain.Durand@Sun.COM Cc: "'Pekka Savola'" , "'JORDI PALET MARTINEZ'" , v6ops@ops.ietf.org Message-id: <003101c415e6$f3cc9970$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_/uJs/TYjxC9nc1mv5Si0og)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_/uJs/TYjxC9nc1mv5Si0og) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT A revised draft is now available as below: http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-02.txt Any comments are most welcome ! Regards - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. --Boundary_(ID_/uJs/TYjxC9nc1mv5Si0og) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT 메시지
 
 
A revised draft is now available as below:
 
 
Any comments are most welcome !
 
 
 
Regards

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics.

--Boundary_(ID_/uJs/TYjxC9nc1mv5Si0og)-- From owner-v6ops@ops.ietf.org Tue Mar 30 00:10: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 AAA16480 for ; Tue, 30 Mar 2004 00:10:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8BTA-000OMI-JS for v6ops-data@psg.com; Tue, 30 Mar 2004 05:07:24 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8BT8-000OLu-Uy for v6ops@ops.ietf.org; Tue, 30 Mar 2004 06:07:23 +0100 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2U57Mwr019334 for ; Mon, 29 Mar 2004 22:07:22 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVD00KFCI8863@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 29 Mar 2004 22:07:22 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HVD00KG8I873Q@mail.sun.net> for v6ops@ops.ietf.org; Mon, 29 Mar 2004 22:07:20 -0700 (MST) Date: Mon, 29 Mar 2004 21:07:18 -0800 From: Alain Durand Subject: Multiple tunneling protocols on the same Ipv4 address )Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] In-reply-to: <4068ACB1.6010609@iprg.nokia.com> To: Fred Templin Cc: IPv6 Operations , "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Message-id: <1E6811C5-8208-11D8-A9F8-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4068ACB1.6010609@iprg.nokia.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT The issue raised here is not limited to 6to4 & isatap but in fact it arises anytime you will have two or more tunneling protocols over IPvx anchored on the same IPvx address. For example, we saw that issue while implementing 6to4 and IPv4 compatible addresses. Our implementation choice at the time was to say we do not support both at the same time on the IPv4 address. So if you want do set rules, they will have to include configured tunnel v6 over v4 (and its many tunnel broker variants), 6to4 6over4 isatap IPv4 compatible Given the fact that all those protocols have been standardized/implemented to (at least) some extend, the only two alternatives IMHO are: - either declare them all mutually exclusive - create that ordered list. Note that it may be more or less difficult for some implementation to actually see both inner and outer address of the packet at the same time. This gets, of course, even trickier if multiple levels of tunneling are in place, e.g. v6 in v6 in v4 in v6 in v4 .... I have not really seen a compelling, practical, case where having two or more of those protocols anchored to the same IPv4 address was necessary, so I would be tempted to favor the 'mutually exclusive' approach. - Alain. On Mar 29, 2004, at 3:09 PM, Fred Templin wrote: > According to RFC 3056, 6to4 can only occur over global unicast IPv4 > addresses. > ISATAP interfaces can also occur over global unicast IPv4 addresses, > in which > case the ISATAP link would span the entire global IPv4 Internet. > > If we allowed both a 6to4 interface and an ISATAP interface to be > anchored > to the *same* global unicast IPv4 address (e.g., "V4ADDR"), it should > be > OK as long as no prefixes derived from "2002:V4ADDR::/48" (i.e., the > /48 > prefix itself, or any finer-grained derivative prefix) are configured > as on-link > prefixes on the ISATAP interface. This would keep the "6to4-prefixed > IPv6 > Internet" from overlapping with the "everything-else-prefixed IPv6 > Internet", > where "everything-else" is a candidate prefix for ISATAP. > > I think there may be several possible ways of expressing this, ranging > from > "least restrictive" to: "most restrictive"; below are two possible > examples > that lie at the extremities of the range of alternatives: > > Least restrictive: > ************** > "An ISATAP and a 6to4 tunnel interface MAY coexist on the same global > unicast IPv4 address ("V4ADDR"), but in this case the ISATAP > interface > MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as > an on-link prefix." > > Most restrictive: > ************** > "An ISATAP interface configured over a global unicast IPv4 address > MUST NOT configure a prefix derived from "2002::/16" as an > on-link prefix." > (Note that both of these examples still allow for ISATAP interfaces > configured over private IPv4 addresses to configure 6to4 prefixes, > but the ISATAP tunneling would be strictly intra-site in that case.) > > Any comments on this? From owner-v6ops@ops.ietf.org Tue Mar 30 06:26: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 GAA13236 for ; Tue, 30 Mar 2004 06:26:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8HJx-000EmW-MV for v6ops-data@psg.com; Tue, 30 Mar 2004 11:22:17 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8HJr-000Elw-Ic for v6ops@ops.ietf.org; Tue, 30 Mar 2004 12:22:11 +0100 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2UBMAYG015082 for ; Tue, 30 Mar 2004 13:22:10 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 30 Mar 2004 13:22:10 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FA1T9D; Tue, 30 Mar 2004 13:22:39 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Mar 2004 13:22:07 +0200 Message-ID: X-Sybari-Trust: d344902e 2c4885b5 07698819 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Fred Templin'" Cc: "'Pekka Savola'" , IPv6 Operations Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09 .txt] ] Date: Tue, 30 Mar 2004 13:21:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 Mar 2004 11:22:10.0212 (UTC) FILETIME=[3E047640:01C41649] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Fred, Please accept my apologies for sending half baked thoughts (previous mail) out on the list. A few comment inline. BR, Karen [snip] > > > > Agree that an implementation must be able to prioritize the > tunnel interfaces. Not quite as clear on what should be included > in "the spec", and not entirely sure exactly which document you > are referring to when you say: "the spec", but see more below: > I simply mean that the prioritization in between different tunnels in the inbound processing path (i.e. exact algorithm behind the location of appropriate inbound tunnel interface) can have implications for the external behavior, wherefore it should be written down in an IETF document. For what concerns Isatap, e.g., in the Isatap "spec". (In regard to the latest Isatap draft, e.g. in Section 7.2.3, but this is of course not for me to say :-)). > >For outbound traffic there isn't a problem, > >the appropriate tunnel interface should > >be selected from the forwarding table/destination cache. > > > > Agreed; longest-prefix match will select the appropriate tunnel > interface for outbound traffic. > > >For inbound traffic there is an issue if the tunnel interfaces, > >lets say an Isatap pseudo tunnel interface and a configured > >v6inv4 tunnel interface, are anchored on the same > >(source) address of an Ipv4 interface. > >The implementation must here be able to determine which > protocol processing module > >(Isatap or configured tunnel respectively) that an incoming > >packet should be subject to. > > > > Agree with the above assertions regarding inbound traffic. > > >One possibility here (which we have used in one implementation) > >it to apply the following inbound processing rules in > prioritized order: > >R1. If the outer IPv4 header of the encapsulated packet > matches a configured v6inv4 tunnel (if any) the packet is > processed by this tunnel interface. > > > > IP-proto-41 packets are first checked to determine whether they belong > to a configured tunnel by checking the (source/destination > addresses) in > the IPv4 header, yes. This much seems consistent with the current > ISATAP draft version, but thanks for reminding of this. I am sorry if that's already spelled out in the current draft. > > >R2. If the prefix of the source address in the inner IPv6 > header of the encapsulated packet matches a prefix of the (if > any) ISATAP interface, the packet is processed by this tunnel > interface. > >R3. If the prefix of either the source or destination > address in the inner IPv6 header is a 6to4 prefix, the packet > is processed by the (if any) 6to4 tunnel interface. > > > >I do consider it unlikely to have both 6to4 and Isatap used > on the same Ipv4 interface so a more strict version of the > above could be: > > > >An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on > the same IPv4 interface > >(address of an IPv4 interface, strictly speaking, the > problems only arise if the tunnels are anchored on the same > addresses). > > > > (Retracting a bit from some comments in an earlier message on > this subject.) > According to RFC 3056, 6to4 can only occur over global unicast IPv4 > addresses. > ISATAP interfaces can also occur over global unicast IPv4 > addresses, in > which > case the ISATAP link would span the entire global IPv4 Internet. > > If we allowed both a 6to4 interface and an ISATAP interface > to be anchored > to the *same* global unicast IPv4 address (e.g., "V4ADDR"), > it should be > OK as long as no prefixes derived from "2002:V4ADDR::/48" > (i.e., the /48 > prefix itself, or any finer-grained derivative prefix) are > configured as > on-link > prefixes on the ISATAP interface. This would keep the > "6to4-prefixed IPv6 > Internet" from overlapping with the "everything-else-prefixed IPv6 > Internet", > where "everything-else" is a candidate prefix for ISATAP. > > I think there may be several possible ways of expressing > this, ranging from > "least restrictive" to: "most restrictive"; below are two > possible examples > that lie at the extremities of the range of alternatives: > > Least restrictive: > ************** > "An ISATAP and a 6to4 tunnel interface MAY coexist on the > same global > unicast IPv4 address ("V4ADDR"), but in this case the > ISATAP interface > MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as > an on-link prefix." > > Most restrictive: > ************** > "An ISATAP interface configured over a global unicast IPv4 address > MUST NOT configure a prefix derived from "2002::/16" as an > on-link prefix." > > (Note that both of these examples still allow for ISATAP interfaces > configured over private IPv4 addresses to configure 6to4 prefixes, > but the ISATAP tunneling would be strictly intra-site in that case.) > > Any comments on this? First I must say, that the rules above were used by us in a Router implementation (not host) in which Isatap communication only was supported to and from the Isatap hosts of the router. (i.e. no support for Isatap router-to-router). I apologies for not making that clear !!!!! Secondly: I assume that the above rules means to imply that a packet should be: processed by the Isatap interface when inner packet is destined to and/or sourced from an address with a prefix of the Isatap interface. I guess that the above rules are sound and lead to unambiguous behavior both in the host and in the Isatap+6to4 border router case (that is, a router with both 6to4 pseudo (border router) and router-to-host Isatap interfaces, the reason for not including router-to-router isatap interfaces is simply that I haven't thought very deeply about those) There may be a problem in the following, very very sick could be discarded ?, situation: Given that a router has a non-6to4 prefixed Isatap interface as well as a 6to4 relay router interface anchored on the same address of an IPv4 interface (not using 6to4 anycast address) then v6inv4 encapsulated packets may arrive on the IPv4 interface in which the inner v6packet is destined for an Isatap address with the mentioned non-6to4 Isatap prefix of the isatap interface but where the encapsulated packet is sourced from a 6to4 border router using 6to4. This packet should be processed by the 6to4 interface and not the Isatap interface. (And yes the hosts should speak Ipv4 instead of Ipv6 given, as it is, that they both have global Ipv4 addresses). On the other hand if the above prefix limitations are combined with a split in a host and a router part, such as: * ROUTER interfaces: If the prefix of the source address in the inner IPv6 header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel interface. * HOST interfaces: If the prefix of the source address in the inner IPv6 header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel interface, then no ambiguity would arise wrt inbound 6to4 and isatap processing. > > >An Isatap tunnel interface and a configured v6inv4 tunnel > interface may be anchored on > >the same Ipv4 interface (address of Ipv4 interface). In this > case the implementation must comply with the following > inbound processing rules in prioritized order: > >R1. If the outer IPv4 header of the encapsulated packet > matches a configured v6inv4 tunnel (if any) the packet is > processed by this tunnel interface. > > > > Agreed, as above. > > >R2. If the prefix of the source address in the inner IPv6 > header of the encapsulated packet matches a prefix of the (if > any) ISATAP interface, the packet is processed by this tunnel > interface. > > > > I have to say that I have thought hard about this rule and am not > entirely sure what to make of it, since it seems to simplistic. > But, I will try: Again, I apologize wildly for not making it clear that this was thought only to cover the router case and only in the router-host situation. > > 1) What we have considered for this space to-date is that an ISATAP > interface would match a specific IPv4 destination address and a > wild-card source address in the IPv4 header of an > ip-proto-41 packet. > 2) Multiple ISATAP interfaces might be matched by this criteria, > and so we require a means for identifying the correct one. > 3) An ISATAP interface that configures a prefix that > matches the IPv6 > source of the packet (if found) is clearly the best > first-choice to > receive > the packet. > 4) If no ISATAP interface with a matching prefix is found, > this could > be a packet from an off-link source that is being > forwarded to (or, > through this decapsulator by a member of the Potential > Router List. > > But, stopping now for a closer look at item 4), there seems to be no > way to determine which ISATAP interface (among possibly many) > might be the correct one to receive and decapsulate the packet - if > any. It could be that the IPv6 destination address is a > foreign address > also, making for a router<->router transaction which is a non-goal > for ISATAP. > > This says that, in order to disambiguate the search, we really need to > treat all possible IPv6 source addresses as on-link for the purpose of > receiving packets, but off-link for the purpose of sending return > packets. In other words, we would need an ISATAP interface > with a distinct /128 prefix for each destination we are actively > communicating with that uses the same IPv6 next-hop address > for return addresses. In other words, from a host's viewpoint the > sources of IPv6 packets for which a matching ISATAP interface > exists would all appear to be on-link, but the destinations would > all appear to be off-link and reachable through a particular IPv6 > next-hop address. There is a (somewhat) subtle implication here > for decapsulation validity checks of the IPv4 source address, > but should be very simple to express. > > If what I am saying makes sense, and if we can agree that ISATAP > support for router<->router tunneling is a non-goal, then I believe > your R2 above could provide a useful simplification for the spec. Wouldn't you need a different R2 for host and for router interfaces (founded on destination address and source address respectively) ? In addition, the source address check could potentially be performed by the isatap host interface implementation - e.g. to rule out direct packets from "non-link" hosts - thus limiting the direct tunnelling function to hosts using the same prefixes - and/or to rule out packets coming form anything else than default router in some scenarios. With the 6to4 prefix limitation on Isatap interfaces this would eliminate conflicts wrt inbound 6to4 and Isatap interfaces processing. In addition you would need to prioritize configured tunnel and Isatap interfaces, but I guess that this is implicitly covered by 1) (in that specific Ipv4 addresses would take precedence over wildcard in Ipv4 source). I hope this at least help to clarify my previous mail. Whether it adds anything useful to the picture, will be for you and others to decide. BR, Karen > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Tue Mar 30 07:37: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 HAA16180 for ; Tue, 30 Mar 2004 07:37:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8IRT-0000sV-1q for v6ops-data@psg.com; Tue, 30 Mar 2004 12:34:07 +0000 Received: from [195.212.14.170] (helo=mail-gw2.hursley.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8IQq-0000jE-Nv for v6ops@ops.ietf.org; Tue, 30 Mar 2004 13:33:29 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B8IQn-0000mP-00; Tue, 30 Mar 2004 13:33:25 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B8IQn-0000mK-00; Tue, 30 Mar 2004 13:33:25 +0100 Received: from zurich.ibm.com (sig-9-145-168-184.de.ibm.com [9.145.168.184]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2UCXNF130392; Tue, 30 Mar 2004 13:33:23 +0100 Message-ID: <40696927.D8A08135@zurich.ibm.com> Date: Tue, 30 Mar 2004 14:33:43 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Alain Durand CC: Fred Templin , IPv6 Operations , "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Subject: Re: Multiple tunneling protocols on the same Ipv4 address )Re: ISATAP,v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re:comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] References: <4068ACB1.6010609@iprg.nokia.com> <1E6811C5-8208-11D8-A9F8-00039358A080@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think this is a case for a SHOULD though; there may be cases we haven't thought of where more than one could rationally be active. Brian Alain Durand wrote: > > The issue raised here is not limited to 6to4 & isatap but in fact it > arises anytime > you will have two or more tunneling protocols over IPvx anchored > on the same IPvx address. > For example, we saw that issue while implementing 6to4 and IPv4 > compatible addresses. > Our implementation choice at the time was to say we do not support both > at the same time > on the IPv4 address. > > So if you want do set rules, they will have to include > configured tunnel v6 over v4 (and its many tunnel broker variants), > 6to4 > 6over4 > isatap > IPv4 compatible > > Given the fact that all those protocols have been > standardized/implemented > to (at least) some extend, the only two alternatives IMHO are: > - either declare them all mutually exclusive > - create that ordered list. > > Note that it may be more or less difficult for some implementation to > actually > see both inner and outer address of the packet at the same time. > This gets, of course, even trickier if multiple levels of tunneling are > in place, > e.g. v6 in v6 in v4 in v6 in v4 .... > > I have not really seen a compelling, practical, case where having two > or more > of those protocols anchored to the same IPv4 address was necessary, so > I would be > tempted to favor the 'mutually exclusive' approach. > > - Alain. > > On Mar 29, 2004, at 3:09 PM, Fred Templin wrote: > > > According to RFC 3056, 6to4 can only occur over global unicast IPv4 > > addresses. > > ISATAP interfaces can also occur over global unicast IPv4 addresses, > > in which > > case the ISATAP link would span the entire global IPv4 Internet. > > > > If we allowed both a 6to4 interface and an ISATAP interface to be > > anchored > > to the *same* global unicast IPv4 address (e.g., "V4ADDR"), it should > > be > > OK as long as no prefixes derived from "2002:V4ADDR::/48" (i.e., the > > /48 > > prefix itself, or any finer-grained derivative prefix) are configured > > as on-link > > prefixes on the ISATAP interface. This would keep the "6to4-prefixed > > IPv6 > > Internet" from overlapping with the "everything-else-prefixed IPv6 > > Internet", > > where "everything-else" is a candidate prefix for ISATAP. > > > > I think there may be several possible ways of expressing this, ranging > > from > > "least restrictive" to: "most restrictive"; below are two possible > > examples > > that lie at the extremities of the range of alternatives: > > > > Least restrictive: > > ************** > > "An ISATAP and a 6to4 tunnel interface MAY coexist on the same global > > unicast IPv4 address ("V4ADDR"), but in this case the ISATAP > > interface > > MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as > > an on-link prefix." > > > > Most restrictive: > > ************** > > "An ISATAP interface configured over a global unicast IPv4 address > > MUST NOT configure a prefix derived from "2002::/16" as an > > on-link prefix." > > (Note that both of these examples still allow for ISATAP interfaces > > configured over private IPv4 addresses to configure 6to4 prefixes, > > but the ISATAP tunneling would be strictly intra-site in that case.) > > > > Any comments on this? -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-v6ops@ops.ietf.org Tue Mar 30 09:21:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20441 for ; Tue, 30 Mar 2004 09:21:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8K41-000Gq2-1x for v6ops-data@psg.com; Tue, 30 Mar 2004 14:18:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8K3w-000GpD-Ky for v6ops@ops.ietf.org; Tue, 30 Mar 2004 15:17:56 +0100 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2UEHp331777; Tue, 30 Mar 2004 17:17:51 +0300 Date: Tue, 30 Mar 2004 17:17:51 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Karen E. Nielsen (AH/TED)" , IPv6 Operations Subject: Re: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] In-Reply-To: <40649995.6060904@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A few responses in-line.. On Fri, 26 Mar 2004, Fred Templin wrote: > >On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote: > >If you enforce this in the implementation strongly enough, i.e., with > >a MUST, then this is doable. Could be in the spec. > > > > I can take this up with the co-authors. Something along the lines of > "must not mix sites over the same IPv4 interface"? There might also > be some text from older versions of the spec that could help. I haven't been able to follow the discussion on this, so I don't know about the current thinking, but when the thred has ceased, maybe someone will summarize the conclusion. I'm not so much concerned about sites getting mixed up (I guess this would assume that different sites the host connects to have different ISATAP domains, and the node could act as a router), but how the implementations could robustly perform their ip-proto-41 decapsulation algorithm so that different tunnels would not get mixed up. (Note: one thing some may be forgetting that the ISATAP interface also includes a link-local prefix, which overlaps with all the other mechanisms (well, except, 6to4 doesn't use them). So, matching the global prefixes is not sufficient..) > >The same actually happens with ISATAP and configured tunneling as > >well. Luckily enough, there should be relatively little overlap with > >them as well. > > > > Here, it would seem normal and natural to find both ISATAP > and configured tunnels configured over the same IPv4 interface. I would not personally find it "normal and natural" -- because if you have the capability for configured tunnels, you should not be needing ISATAP to begin with (except possibly as an optimization methodbetween the ISATAP nodes inside the ISATAP site). But I agree that there may be overlap. > >You probably mean that they're in the 3GPP network, yes? It's not > >really in the same "site" with the ISATAP nodes, then, though. > > > >Even if so, this would address the external proto-41 threats only when > >the 3GPP operator would perform proto-41 filtering at its > >Internet-facing borders. And that would not yet even protect against > >attacks from the other users in the same 3GPP network. > > But, wouldn't this depend on whether the ISATAP router sits on the > edge of the 3GPP operator network vs. somewhere inside the network? > See more on this below: ... > >Sorry if I was confusing here -- by "ISATAP endpoint" I was referring > >to ISATAP router from the ISATAP host's point of view. > > > >The scenario is like this: > > > >======================||===========+ > > ||3GPP user 1| admin domain 1 > > 3GPP operator's ||ISATAP node| > > network ||===========+ > > ||3GPP user N| admin domain N > > (ISATAP router) ||ISATAP node| > > ||===========+ > >======================|| > >administrative domain A > > > >All the users and the 3GPP network are in different administrative > >domains. > > > > Yes, but if we limit the ISATAP router to occur at the edge of the > 3GPP operator network (and not somewhere inside the network), > then we have a natural point of demarcation for site boundaries. > > E.g., if 3GPP user 1 in your example opens up an IPv4 PDP context, > and the 3GPP operator's equipment acts as an ISATAP router on an > interface at the outward-facing edge of administrative domain A, then > the PDP context would extend admin domain 1 only to the edge of the > operator's network and not allow it to penetrate into admin domain A, > i.e., there would be no site-overlap. > > This would make the interface(s) at the outward-facing edge of admin > domain A appear to be ISATAP router interfaces, and the 3GPP operator's > network would appear as a gigantic ISATAP router with multiple ISATAP > interfaces - one per 3GPP user, i.e., one per customer site. Would this go > toward addressing your concern? And, is there anything more needed in > the spec to support this? I think you're describing the model where ISATAP is only used for host-to-router tunneling in some sense -- where the host-to-host part was disabled (using some unspecified methods)? To say it differently, are you proposing the model where a different /64 prefix is advertised to *each* of users, i.e., that each would function as their own ISATAP site (with nobody else in the ISATAP site)? (And the other users would not be "on-link", ISATAP-wise.) If I understand the scenario sufficiently, I think that would fix most of the concerns. But then again, as takes away the direct tunneling benefit of ISATAP, I'm very uncertain why it would make sense to go into that direction in any case -- as this seems fundamentally like what a configured tunnel set-up does (like STEP or simplied TSP). -- 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 Mar 30 13:09: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 NAA03144 for ; Tue, 30 Mar 2004 13:09:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8NcT-0009DZ-TO for v6ops-data@psg.com; Tue, 30 Mar 2004 18:05:49 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8NcO-0009D7-Pk for v6ops@ops.ietf.org; Tue, 30 Mar 2004 19:05:44 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2UI5gF11728; Tue, 30 Mar 2004 10:05:42 -0800 X-mProtect: <200403301805> 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 smtpdNie0k7; Tue, 30 Mar 2004 10:05:39 PST Message-ID: <4069B6F5.7020809@iprg.nokia.com> Date: Tue, 30 Mar 2004 10:05:41 -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: Alain Durand CC: IPv6 Operations , "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Subject: Re: Multiple tunneling protocols on the same Ipv4 address )Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] References: <4068ACB1.6010609@iprg.nokia.com> <1E6811C5-8208-11D8-A9F8-00039358A080@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain, Appreciate the thoughts. As to your assertion of not seeing a compelling, practical case I tend to disagree with that as a sufficiently strong arguement towards disallowing multiple tunneling protocols anchored to the same IPv4 address. So, my leaning is toward your suggestion of a prioritized set of rules, or something similar. Thanks - Fred ftemplin@iprg.noka.com Alain Durand wrote: > > The issue raised here is not limited to 6to4 & isatap but in fact it > arises anytime > you will have two or more tunneling protocols over IPvx anchored > on the same IPvx address. > For example, we saw that issue while implementing 6to4 and IPv4 > compatible addresses. > Our implementation choice at the time was to say we do not support > both at the same time > on the IPv4 address. > > So if you want do set rules, they will have to include > configured tunnel v6 over v4 (and its many tunnel broker variants), > 6to4 > 6over4 > isatap > IPv4 compatible > > Given the fact that all those protocols have been > standardized/implemented > to (at least) some extend, the only two alternatives IMHO are: > - either declare them all mutually exclusive > - create that ordered list. > > Note that it may be more or less difficult for some implementation to > actually > see both inner and outer address of the packet at the same time. > This gets, of course, even trickier if multiple levels of tunneling > are in place, > e.g. v6 in v6 in v4 in v6 in v4 .... > > I have not really seen a compelling, practical, case where having two > or more > of those protocols anchored to the same IPv4 address was necessary, so > I would be > tempted to favor the 'mutually exclusive' approach. > > - Alain. > > > > On Mar 29, 2004, at 3:09 PM, Fred Templin wrote: > >> According to RFC 3056, 6to4 can only occur over global unicast IPv4 >> addresses. >> ISATAP interfaces can also occur over global unicast IPv4 addresses, >> in which >> case the ISATAP link would span the entire global IPv4 Internet. >> >> If we allowed both a 6to4 interface and an ISATAP interface to be >> anchored >> to the *same* global unicast IPv4 address (e.g., "V4ADDR"), it should be >> OK as long as no prefixes derived from "2002:V4ADDR::/48" (i.e., the /48 >> prefix itself, or any finer-grained derivative prefix) are configured >> as on-link >> prefixes on the ISATAP interface. This would keep the "6to4-prefixed >> IPv6 >> Internet" from overlapping with the "everything-else-prefixed IPv6 >> Internet", >> where "everything-else" is a candidate prefix for ISATAP. >> >> I think there may be several possible ways of expressing this, >> ranging from >> "least restrictive" to: "most restrictive"; below are two possible >> examples >> that lie at the extremities of the range of alternatives: >> >> Least restrictive: >> ************** >> "An ISATAP and a 6to4 tunnel interface MAY coexist on the same global >> unicast IPv4 address ("V4ADDR"), but in this case the ISATAP >> interface >> MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as >> an on-link prefix." >> >> Most restrictive: >> ************** >> "An ISATAP interface configured over a global unicast IPv4 address >> MUST NOT configure a prefix derived from "2002::/16" as an >> on-link prefix." >> (Note that both of these examples still allow for ISATAP interfaces >> configured over private IPv4 addresses to configure 6to4 prefixes, >> but the ISATAP tunneling would be strictly intra-site in that case.) >> >> Any comments on this? > > From owner-v6ops@ops.ietf.org Tue Mar 30 13:11:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03332 for ; Tue, 30 Mar 2004 13:11:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8NgD-0009er-IY for v6ops-data@psg.com; Tue, 30 Mar 2004 18:09:41 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8Ng3-0009cC-VZ for v6ops@ops.ietf.org; Tue, 30 Mar 2004 19:09:35 +0100 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2UI9Vwr003606 for ; Tue, 30 Mar 2004 11:09:31 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVE00KDRIFU63@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 30 Mar 2004 11:09:31 -0700 (MST) Received: from [192.168.1.102] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HVE00I9MIFS2D@mail.sun.net> for v6ops@ops.ietf.org; Tue, 30 Mar 2004 11:09:30 -0700 (MST) Date: Tue, 30 Mar 2004 10:09:27 -0800 From: Alain Durand Subject: Re: Multiple tunneling protocols on the same Ipv4 address )Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] In-reply-to: <4069B6F5.7020809@iprg.nokia.com> To: Fred Templin Cc: IPv6 Operations , "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Message-id: <61DBCF68-8275-11D8-BA59-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4068ACB1.6010609@iprg.nokia.com> <1E6811C5-8208-11D8-A9F8-00039358A080@sun.com> <4069B6F5.7020809@iprg.nokia.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 30, 2004, at 10:05 AM, Fred Templin wrote: > Alain, > > Appreciate the thoughts. As to your assertion of not seeing a > compelling, > practical case I tend to disagree with that as a sufficiently strong > arguement > towards disallowing multiple tunneling protocols anchored to the same > IPv4 address. So, my leaning is toward your suggestion of a > prioritized > set of rules, or something similar. Fred, Could you provide an example where anchoring two or more tunneling protocols on the same IPv4 interface makes real sense and cannot be done differently? - Alain. From owner-v6ops@ops.ietf.org Tue Mar 30 13:28:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04110 for ; Tue, 30 Mar 2004 13:28:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8Nx3-000D19-3Q for v6ops-data@psg.com; Tue, 30 Mar 2004 18:27:05 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8Nwt-000Cza-Rm for v6ops@ops.ietf.org; Tue, 30 Mar 2004 19:26:55 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2UIQsq22179; Tue, 30 Mar 2004 10:26:54 -0800 X-mProtect: <200403301826> 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 smtpd70dpLX; Tue, 30 Mar 2004 10:26:52 PST Message-ID: <4069BBEE.40305@iprg.nokia.com> Date: Tue, 30 Mar 2004 10:26:54 -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: Alain Durand CC: IPv6 Operations , "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Subject: Re: Multiple tunneling protocols on the same Ipv4 address )Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] References: <4068ACB1.6010609@iprg.nokia.com> <1E6811C5-8208-11D8-A9F8-00039358A080@sun.com> <4069B6F5.7020809@iprg.nokia.com> <61DBCF68-8275-11D8-BA59-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain Durand wrote: > Could you provide an example where anchoring two or more tunneling > protocols > on the same IPv4 interface makes real sense and cannot be done > differently? Yes, but probably not without sending the list into the same sort tailspin we've seen in the past whenever this subject comes up. I think there are plenty of messages in the archives to draw on on this subject, but the main point is that I don't see how a: "MUST NOT configure multiple tunneling types over the same IPv4 address" can be justified in the face of reasonable doubt that such configurations will be required in near term or future operational deployments. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Mar 30 13:37:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04308 for ; Tue, 30 Mar 2004 13:37:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8O5R-000FJD-Es for v6ops-data@psg.com; Tue, 30 Mar 2004 18:35:45 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8O5O-000FIe-TQ for v6ops@ops.ietf.org; Tue, 30 Mar 2004 19:35:42 +0100 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2UIZgwr018184 for ; Tue, 30 Mar 2004 11:35:42 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVE0070KJNHWD@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 30 Mar 2004 11:35:42 -0700 (MST) Received: from [192.168.1.102] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HVE00IHDJNG2D@mail.sun.net> for v6ops@ops.ietf.org; Tue, 30 Mar 2004 11:35:41 -0700 (MST) Date: Tue, 30 Mar 2004 10:35:38 -0800 From: Alain Durand Subject: Re: Multiple tunneling protocols on the same Ipv4 address )Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] In-reply-to: <4069BBEE.40305@iprg.nokia.com> To: Fred Templin Cc: IPv6 Operations , "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Message-id: <0A370E96-8279-11D8-BA59-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4068ACB1.6010609@iprg.nokia.com> <1E6811C5-8208-11D8-A9F8-00039358A080@sun.com> <4069B6F5.7020809@iprg.nokia.com> <61DBCF68-8275-11D8-BA59-00039376A6AA@sun.com> <4069BBEE.40305@iprg.nokia.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Mar 30, 2004, at 10:26 AM, Fred Templin wrote: > > > Alain Durand wrote: > >> Could you provide an example where anchoring two or more tunneling >> protocols >> on the same IPv4 interface makes real sense and cannot be done >> differently? > > > Yes, but probably not without sending the list into the same sort > tailspin > we've seen in the past whenever this subject comes up. Well, one could take this as a sign that the case is not that solid... > I think there are plenty of messages in the archives to draw on on this > subject, but the main point is that I don't see how a: "MUST NOT > configure > multiple tunneling types over the same IPv4 address" can be justified > in the > face of reasonable doubt that such configurations will be required in > near > term or future operational deployments. I'm not looking at a MUST. Brian pointed earlier that a SHOUD rather than a MUST was more suitable. Actually the discussion is more between a MAY and a SHOULD. Essentially, the text I would like to see is something like "Implementations MAY decide not to support multiple tunneling types over the same IPv4 address" - Alain. From owner-v6ops@ops.ietf.org Tue Mar 30 14:07: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 OAA05102 for ; Tue, 30 Mar 2004 14:07:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8OYc-000Nwn-Eo for v6ops-data@psg.com; Tue, 30 Mar 2004 19:05:54 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8OYX-000Nvd-30 for v6ops@ops.ietf.org; Tue, 30 Mar 2004 20:05:49 +0100 Received: from consulintel02 ([206.99.50.39]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 30-md50000000109.tmp for ; Tue, 30 Mar 2004 21:10:11 +0200 Message-ID: <040001c4168a$85b64770$273263ce@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <4068ACB1.6010609@iprg.nokia.com> <1E6811C5-8208-11D8-A9F8-00039358A080@sun.com> <4069B6F5.7020809@iprg.nokia.com> Subject: Re: Multiple tunneling protocols on the same Ipv4 address )Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ] Date: Tue, 30 Mar 2004 16:09:23 -0300 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, 30 Mar 2004 21:10:11 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 206.99.50.39 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.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, In the I-D that we are preparing "auto-trans" that Pekka already = mentioned some days ago, we are taking in consideration this priorized = set of rules. Regards, Jordi ----- Original Message -----=20 From: "Fred Templin" To: "Alain Durand" Cc: "IPv6 Operations" ; "Karen E. Nielsen (AH/TED)" = ; "'Pekka Savola'" Sent: Tuesday, March 30, 2004 3:05 PM Subject: Re: Multiple tunneling protocols on the same Ipv4 address )Re: = ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter = natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] = ] > Alain, >=20 > Appreciate the thoughts. As to your assertion of not seeing a = compelling, > practical case I tend to disagree with that as a sufficiently strong=20 > arguement > towards disallowing multiple tunneling protocols anchored to the same > IPv4 address. So, my leaning is toward your suggestion of a = prioritized > set of rules, or something similar. >=20 > Thanks - Fred > ftemplin@iprg.noka.com >=20 > Alain Durand wrote: >=20 > > > > The issue raised here is not limited to 6to4 & isatap but in fact = it=20 > > arises anytime > > you will have two or more tunneling protocols over IPvx anchored > > on the same IPvx address. > > For example, we saw that issue while implementing 6to4 and IPv4=20 > > compatible addresses. > > Our implementation choice at the time was to say we do not support=20 > > both at the same time > > on the IPv4 address. > > > > So if you want do set rules, they will have to include > > configured tunnel v6 over v4 (and its many tunnel broker variants), > > 6to4 > > 6over4 > > isatap > > IPv4 compatible > > > > Given the fact that all those protocols have been=20 > > standardized/implemented > > to (at least) some extend, the only two alternatives IMHO are: > > - either declare them all mutually exclusive > > - create that ordered list. > > > > Note that it may be more or less difficult for some implementation = to=20 > > actually > > see both inner and outer address of the packet at the same time. > > This gets, of course, even trickier if multiple levels of tunneling=20 > > are in place, > > e.g. v6 in v6 in v4 in v6 in v4 .... > > > > I have not really seen a compelling, practical, case where having = two=20 > > or more > > of those protocols anchored to the same IPv4 address was necessary, = so=20 > > I would be > > tempted to favor the 'mutually exclusive' approach. > > > > - Alain. > > > > > > > > On Mar 29, 2004, at 3:09 PM, Fred Templin wrote: > > > >> According to RFC 3056, 6to4 can only occur over global unicast IPv4 = > >> addresses. > >> ISATAP interfaces can also occur over global unicast IPv4 = addresses,=20 > >> in which > >> case the ISATAP link would span the entire global IPv4 Internet. > >> > >> If we allowed both a 6to4 interface and an ISATAP interface to be=20 > >> anchored > >> to the *same* global unicast IPv4 address (e.g., "V4ADDR"), it = should be > >> OK as long as no prefixes derived from "2002:V4ADDR::/48" (i.e., = the /48 > >> prefix itself, or any finer-grained derivative prefix) are = configured=20 > >> as on-link > >> prefixes on the ISATAP interface. This would keep the = "6to4-prefixed=20 > >> IPv6 > >> Internet" from overlapping with the "everything-else-prefixed IPv6=20 > >> Internet", > >> where "everything-else" is a candidate prefix for ISATAP. > >> > >> I think there may be several possible ways of expressing this,=20 > >> ranging from > >> "least restrictive" to: "most restrictive"; below are two possible=20 > >> examples > >> that lie at the extremities of the range of alternatives: > >> > >> Least restrictive: > >> ************** > >> "An ISATAP and a 6to4 tunnel interface MAY coexist on the same = global > >> unicast IPv4 address ("V4ADDR"), but in this case the ISATAP=20 > >> interface > >> MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as > >> an on-link prefix." > >> > >> Most restrictive: > >> ************** > >> "An ISATAP interface configured over a global unicast IPv4 = address > >> MUST NOT configure a prefix derived from "2002::/16" as an > >> on-link prefix." > >> (Note that both of these examples still allow for ISATAP interfaces > >> configured over private IPv4 addresses to configure 6to4 prefixes, > >> but the ISATAP tunneling would be strictly intra-site in that = case.) > >> > >> Any comments on this? > > > > > ********************************** 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 Mar 30 20:22: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 UAA15064 for ; Tue, 30 Mar 2004 20:22:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8UMj-0004un-0N for v6ops-data@psg.com; Wed, 31 Mar 2004 01:18:01 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8UMf-0004uD-OF for v6ops@ops.ietf.org; Wed, 31 Mar 2004 02:17:57 +0100 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2004 17:25:26 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2V1Hsn2025069; Tue, 30 Mar 2004 17:17:55 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-39.cisco.com [10.86.240.39]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHF89666; Tue, 30 Mar 2004 20:17:52 -0500 (EST) Message-Id: <4.3.2.7.2.20040325084437.027e9520@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Mar 2004 17:28:21 -0500 To: Pekka Savola From: Ralph Droms Subject: Re: DHCP auth in unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt] Cc: v6ops@ops.ietf.org In-Reply-To: References: <4.3.2.7.2.20040324164856.02993b18@flask.cisco.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.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 At 12:53 PM 3/25/2004 +0200, Pekka Savola wrote: >On Wed, 24 Mar 2004, Ralph Droms wrote: > > > > The statement "To be useful in such environment in practice, the > practical > > > > details of managing the DHCP authentication need to be analyzed." > needs to > > > > be explained. How is the authentication specified in RFC3315 and > > > > recommended for DHCPv6 PD in RFC3396 not adequate? > > > > > >(Operational) key management seems problematic, even though DHCP > > >provides support for that. > > > > How is operational key management for the authentication mechanism > described > > in RFC3315 more problematic than for other mechanisms that use shared keys? > >Those protocols are not often used 1) between administrative domains >[where key management is arguably simpler] and I can walk into a WiFi hotspot today, establish a new trust relationship that I haven't used before, and establish a secure link to the Internet that uses a DHCP-delegated IPv4 address. Delegating a prefix with DHCPv6 is essentially the same problem as obtaining an IPv4 address with DHCPv4. What is the problem we need to solve with DHCPv6? > 2) before getting IP >addresses in the first place (that is, if you don't have an address >yet, you cannot run mechanisms which help in making the key sharing >simpler). Whether or not an IP address has been obtained is irrelevant to the problem and especially to DHCPv6 prefix delegation. > > >Maybe reword: > > > > > > The basic use of DHCP is insecure. This may be a problem if the link > > > between gateway and ISP is shared by multiple subscribers. DHCP > > > specification includes authentication options, but does not describe > > > the task of managing the keys, and how the information would be > > > shared between the customer and the ISP. To be useful in such > > > environment in practice, the practical details of managing the DHCP > > > authentication need to be analyzed. > > > > > >to: > > > > > > DHCP is insecure unless authentication is used. This may be a > > > particular problem if the link between gateway and ISP is shared by > > > multiple subscribers. DHCP specification includes authentication > > > options, but the operational procedures for managing the keys and > > > methods for sharing the required information between the customer > > > and the ISP are unclear. To be secure in such environment in > > > practice, the practical details of managing the DHCP authentication > > > need to be analyzed. > > > > > >Perhaps that is a bit more fair statement of the issue(s) involved. > > > > No, I honestly don't think it's any more fair. Most service providers > > provide complete isolation of customer traffic through filtering even > if the > > link appears to be shared among multiple customers. > >But then it no longer is a shared link, and the above does not apply. > >But you raise a good point: I think we should spell out the obvious, >that rather than trying to operate with *really* shared links, the >operators should strongly consider mechanisms (any pointers?) which >achieve the isolation, making the issues more complex. OK, and I think that secured, non-shared links really are the norm. As security issues are explicitly described in more detail in the DHCPv6 and PD RFCs, I suggest the text about security be replaced with pointers to the discussions of security in those two documents: 4.1.2 Explicit prefix delegation Several networks have already started using an explicit prefix delegation mechanism using DHCPv6 [RFC3633]. In this mechanism, the gateway uses a DHCP request to obtain a prefix from a DHCP server managed by the ISP. The DHCP server identifies the gateway, for example, through identification information provided by the gateway in the DHCP request message or by the port or circuit through which the DHCP request message is received. The server can implement prefix delegation policies based on the identity of the requesting gateway. According to the recommendations in RFCxxxx the ISP assigns a /48 to the customer. The gateway then automatically assign /64s out of this /48 to its internal links. (Editorial notes: * I don't think the acronym "ISP" is defined anywhere in the document * There doesn't seem to be a citation of RFC 3315 anywhere in the document * There should be citations of RFC 2131 and RFC 2132 for DHCPv4) Security issues associated with DHCP and prefix delegation are addressed in the "Security Considerations" section of RFC 3315 and RFC 3633, respectively. 4.1.3 Recommendation The ND proxy and DHCP methods appear to have different domains of application. ND proxy is a simple method that corresponds well to "informal sharing" of a link, while explicit delegation provides strong administrative control. The ND proxy mechanism has not yet been accepted as an Internet Standard and the interaction between neighbor discovery and ND proxy needs to be specified. > > If customers do truly > > share a link, there are *many* other attacks available and pointing out > DHCP > > as a specific problem is only telling part of the story. > >Yep, but that's the only story being covered in that section of the >document... It's also the only place in the document where specific security issues are raised beyond the level of "Specific security issues should be studied and addressed during the development of the specific mechanisms." > > Finally, I still > > haven't heard an explanation of the requirement that "the practical details > > of managing the DHCP authentication need to be analyzed." DHCP can use a > > password provided by the service provider to the customer. What additional > > analysis do we need to perform? > >If they provide a password, that's fine. As long as it's clear how >they provide it, and how it would end up being configured in the >router. (Trivial if the ISP ships the box to the user, possibly >non-trivial otherwise.) > >I think the shared key model also requires that the key stays as it >forever (providing for better brute-force attacks against it), unless >you do re-keying or the like somehow. But that would probably be >equally problematic. Which is exactly the model employed in the equivalent problem of address assignment today. Why are the requirements for prefix delegation stricter than for what is deployed today? > > The issue of DHCPv6 security is adequately addressed in RFC3315 and need > > not be rehashed here. Anyone who reads RFC3315 (btw, the reference > > [DNSDHCPV6] is never cited anywhere in the body of the document) will > > see the security analysis for DHCPv6. > >The security analysis in there is restricted to the scenario which >may not be directly applicable here: > > This protocol is focused on solving the intradomain problem where the > out-of-band exchange of a shared key is feasible. > >This is inter-domain, and whether sharing keys is feasible is an open >question. (In some cases, with some constraints, it certainly seems to >be possible, but...) The common model today is to establish a separate security relationship with different administrative domains and select the appropriate relationship as needed. The same strategy can be applied to prefix delegation - if, indeed, any ISP actually deploys a network in which customers really see each others traffic on a shared link. > > > > What are the security implications of ND proxy? > > > > > >Roughly equal or slightly worse, but then again, it would probably not > > >be applicable in this specific ("multiple subscribers in one big LAN") > > >environment in any case. > > > > So ND proxy doesn't represent a security problem and requires no > > authentication because its scaling properties preclude its use in what you > > consider to be a typical deployment scenario? > >Yep. > > > Whatever the situation, > > the security issues for ND proxy should be mentioned as well as those > > for DHCPv6. > >Agreed. > >-- >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 Mar 30 21:02: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 VAA16945 for ; Tue, 30 Mar 2004 21:02:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8V1j-000E8b-Ru for v6ops-data@psg.com; Wed, 31 Mar 2004 02:00:23 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8V1i-000E8G-DT for v6ops@ops.ietf.org; Wed, 31 Mar 2004 03:00:22 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2V20BD07435; Tue, 30 Mar 2004 18:00:11 -0800 X-mProtect: <200403310200> 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 smtpdBG8GDJ; Tue, 30 Mar 2004 18:00:08 PST Message-ID: <406A262C.7060009@iprg.nokia.com> Date: Tue, 30 Mar 2004 18:00:12 -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: "Karen E. Nielsen (AH/TED)" , IPv6 Operations Subject: Re: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: >A few responses in-line.. > >On Fri, 26 Mar 2004, Fred Templin wrote: > > >>>On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote: >>>If you enforce this in the implementation strongly enough, i.e., with >>>a MUST, then this is doable. Could be in the spec. >>> >>> >>> >>I can take this up with the co-authors. Something along the lines of >>"must not mix sites over the same IPv4 interface"? There might also >>be some text from older versions of the spec that could help. >> >> > >I haven't been able to follow the discussion on this, so I don't know >about the current thinking, but when the thred has ceased, maybe >someone will summarize the conclusion. > I agree that this thread should be wrapped up with a concise summary; see below. >I'm not so much concerned about sites getting mixed up (I guess this >would assume that different sites the host connects to have different >ISATAP domains, and the node could act as a router), but how the >implementations could robustly perform their ip-proto-41 decapsulation >algorithm so that different tunnels would not get mixed up. > As far as I can tell, configured tunnels will have a specific match on both the source and destination IPv4 addresses in the outer headers of ip-proto-41 packets, while automatic tunnels will have a specific match on the destination but wildcard match on the source - that much seems unambiguous. >(Note: one thing some may be forgetting that the ISATAP interface also >includes a link-local prefix, which overlaps with all the other >mechanisms (well, except, 6to4 doesn't use them). So, matching the >global prefixes is not sufficient..) > I havn't forgotten. >>>The same actually happens with ISATAP and configured tunneling as >>>well. Luckily enough, there should be relatively little overlap with >>>them as well. >>> >>> >>> >>Here, it would seem normal and natural to find both ISATAP >>and configured tunnels configured over the same IPv4 interface. >> >> > >I would not personally find it "normal and natural" -- because if you >have the capability for configured tunnels, you should not be needing >ISATAP to begin with (except possibly as an optimization methodbetween >the ISATAP nodes inside the ISATAP site). > >But I agree that there may be overlap. > ISATAP specifies mechanisms for auto-discovery (and has for a long time now) that add value for the host-router case. It can even be combined with a tunnel broker capability to dynamically create configured tunnels if you'd like, but that is getting beyond the scope of simple mechanisms. >>>You probably mean that they're in the 3GPP network, yes? It's not >>>really in the same "site" with the ISATAP nodes, then, though. >>> >>>Even if so, this would address the external proto-41 threats only when >>>the 3GPP operator would perform proto-41 filtering at its >>>Internet-facing borders. And that would not yet even protect against >>>attacks from the other users in the same 3GPP network. >>> >>> >>But, wouldn't this depend on whether the ISATAP router sits on the >>edge of the 3GPP operator network vs. somewhere inside the network? >>See more on this below: >> >> > >... > > > >>>Sorry if I was confusing here -- by "ISATAP endpoint" I was referring >>>to ISATAP router from the ISATAP host's point of view. >>> >>>The scenario is like this: >>> >>>======================||===========+ >>> ||3GPP user 1| admin domain 1 >>>3GPP operator's ||ISATAP node| >>> network ||===========+ >>> ||3GPP user N| admin domain N >>>(ISATAP router) ||ISATAP node| >>> ||===========+ >>>======================|| >>>administrative domain A >>> >>>All the users and the 3GPP network are in different administrative >>>domains. >>> >>> >>> >>Yes, but if we limit the ISATAP router to occur at the edge of the >>3GPP operator network (and not somewhere inside the network), >>then we have a natural point of demarcation for site boundaries. >> >>E.g., if 3GPP user 1 in your example opens up an IPv4 PDP context, >>and the 3GPP operator's equipment acts as an ISATAP router on an >>interface at the outward-facing edge of administrative domain A, then >>the PDP context would extend admin domain 1 only to the edge of the >>operator's network and not allow it to penetrate into admin domain A, >>i.e., there would be no site-overlap. >> >>This would make the interface(s) at the outward-facing edge of admin >>domain A appear to be ISATAP router interfaces, and the 3GPP operator's >>network would appear as a gigantic ISATAP router with multiple ISATAP >>interfaces - one per 3GPP user, i.e., one per customer site. Would this go >>toward addressing your concern? And, is there anything more needed in >>the spec to support this? >> >> > >I think you're describing the model where ISATAP is only used for >host-to-router tunneling in some sense -- where the host-to-host part >was disabled (using some unspecified methods)? > >To say it differently, are you proposing the model where a different >/64 prefix is advertised to *each* of users, i.e., that each would >function as their own ISATAP site (with nobody else in the ISATAP >site)? (And the other users would not be "on-link", ISATAP-wise.) > >If I understand the scenario sufficiently, I think that would fix most >of the concerns. But then again, as takes away the direct tunneling >benefit of ISATAP, I'm very uncertain why it would make sense to go >into that direction in any case -- as this seems fundamentally like >what a configured tunnel set-up does (like STEP or simplied TSP). > I am not claiming that the above is the only way to go in the 3GPP space; it's just one possibility. I agree that it might appear to be converging toward what a configured tunnel set-up does in this scenario, but the mechanism is lightweight and simple. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Mar 30 21:12: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 VAA17449 for ; Tue, 30 Mar 2004 21:12:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8VCE-000FPm-9Z for v6ops-data@psg.com; Wed, 31 Mar 2004 02:11:14 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8VCC-000FPT-WE for v6ops@ops.ietf.org; Wed, 31 Mar 2004 03:11:13 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2V2AwK26445; Tue, 30 Mar 2004 18:10:58 -0800 X-mProtect: <200403310210> 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 smtpdbUhDYm; Tue, 30 Mar 2004 18:10:55 PST Message-ID: <406A28B2.80001@iprg.nokia.com> Date: Tue, 30 Mar 2004 18:10:58 -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: "Karen E. Nielsen (AH/TED)" CC: "'Pekka Savola'" , IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09 .txt] ] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen, Thanks for the additional thoughts. On the non-use of 6to4 prefixes as on-link prefixes for ISATAP interfaces, I'd like to back-track on this yet again. I don't see a problem with an ISATAP interface and a 6to4 interface anchored to the same (global unicast) IPv4 address and having the same 6to4 prefix as an on-link prefix - just as IP addresses and prefixes may be assigned to multiple ordinary interfaces. There is a slight difference in that ISATAP and 6to4 use slightly different checks on decapsulation, but it seems sufficient to leave as implementor's choice how to resolve the ambiguity, e.g., some might choose to always use the 6to4 decapsulation rules (and receive interface) in this case. Fred ftemplin@iprg.nokia.com Karen E. Nielsen (AH/TED) wrote: >Hi Fred, > >Please accept my apologies for sending >half baked thoughts (previous mail) out on the list. > >A few comment inline. > >BR, Karen > >[snip] > > > >>Agree that an implementation must be able to prioritize the >>tunnel interfaces. Not quite as clear on what should be included >>in "the spec", and not entirely sure exactly which document you >>are referring to when you say: "the spec", but see more below: >> >> >> > >I simply mean that the prioritization in >between different tunnels in the inbound processing path >(i.e. exact algorithm behind the location of appropriate inbound tunnel interface) can have implications for >the external behavior, wherefore it should be written down in >an IETF document. For what concerns Isatap, e.g., in the Isatap "spec". >(In regard to the latest Isatap draft, e.g. in Section 7.2.3, but this is of course not for me to say :-)). > > > >>>For outbound traffic there isn't a problem, >>>the appropriate tunnel interface should >>>be selected from the forwarding table/destination cache. >>> >>> >>> >>Agreed; longest-prefix match will select the appropriate tunnel >>interface for outbound traffic. >> >> >> >>>For inbound traffic there is an issue if the tunnel interfaces, >>>lets say an Isatap pseudo tunnel interface and a configured >>>v6inv4 tunnel interface, are anchored on the same >>>(source) address of an Ipv4 interface. >>>The implementation must here be able to determine which >>> >>> >>protocol processing module >> >> >>>(Isatap or configured tunnel respectively) that an incoming >>>packet should be subject to. >>> >>> >>> >>Agree with the above assertions regarding inbound traffic. >> >> >> >>>One possibility here (which we have used in one implementation) >>>it to apply the following inbound processing rules in >>> >>> >>prioritized order: >> >> >>>R1. If the outer IPv4 header of the encapsulated packet >>> >>> >>matches a configured v6inv4 tunnel (if any) the packet is >>processed by this tunnel interface. >> >> >>IP-proto-41 packets are first checked to determine whether they belong >>to a configured tunnel by checking the (source/destination >>addresses) in >>the IPv4 header, yes. This much seems consistent with the current >>ISATAP draft version, but thanks for reminding of this. >> >> > >I am sorry if that's already spelled out in the current draft. > > > >>>R2. If the prefix of the source address in the inner IPv6 >>> >>> >>header of the encapsulated packet matches a prefix of the (if >>any) ISATAP interface, the packet is processed by this tunnel >>interface. >> >> >>>R3. If the prefix of either the source or destination >>> >>> >>address in the inner IPv6 header is a 6to4 prefix, the packet >>is processed by the (if any) 6to4 tunnel interface. >> >> >>>I do consider it unlikely to have both 6to4 and Isatap used >>> >>> >>on the same Ipv4 interface so a more strict version of the >>above could be: >> >> >>>An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on >>> >>> >>the same IPv4 interface >> >> >>>(address of an IPv4 interface, strictly speaking, the >>> >>> >>problems only arise if the tunnels are anchored on the same >>addresses). >> >> >>(Retracting a bit from some comments in an earlier message on >>this subject.) >>According to RFC 3056, 6to4 can only occur over global unicast IPv4 >>addresses. >>ISATAP interfaces can also occur over global unicast IPv4 >>addresses, in >>which >>case the ISATAP link would span the entire global IPv4 Internet. >> >>If we allowed both a 6to4 interface and an ISATAP interface >>to be anchored >>to the *same* global unicast IPv4 address (e.g., "V4ADDR"), >>it should be >>OK as long as no prefixes derived from "2002:V4ADDR::/48" >>(i.e., the /48 >>prefix itself, or any finer-grained derivative prefix) are >>configured as >>on-link >>prefixes on the ISATAP interface. This would keep the >>"6to4-prefixed IPv6 >>Internet" from overlapping with the "everything-else-prefixed IPv6 >>Internet", >>where "everything-else" is a candidate prefix for ISATAP. >> >>I think there may be several possible ways of expressing >>this, ranging from >>"least restrictive" to: "most restrictive"; below are two >>possible examples >>that lie at the extremities of the range of alternatives: >> >>Least restrictive: >>************** >> "An ISATAP and a 6to4 tunnel interface MAY coexist on the >>same global >> unicast IPv4 address ("V4ADDR"), but in this case the >>ISATAP interface >> MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as >> an on-link prefix." >> >>Most restrictive: >>************** >> "An ISATAP interface configured over a global unicast IPv4 address >> MUST NOT configure a prefix derived from "2002::/16" as an >> on-link prefix." >> >>(Note that both of these examples still allow for ISATAP interfaces >>configured over private IPv4 addresses to configure 6to4 prefixes, >>but the ISATAP tunneling would be strictly intra-site in that case.) >> >>Any comments on this? >> >> > >First I must say, that the rules above were used by us >in a Router implementation (not host) in which Isatap communication only >was supported to and from the Isatap hosts of the router. >(i.e. no support for Isatap router-to-router). > >I apologies for not making that clear !!!!! > >Secondly: > >I assume that the above rules means to imply that a packet should be: >processed by the Isatap interface when inner packet is destined to and/or sourced from an address with a prefix of the Isatap interface. > >I guess that the above rules are sound and lead to unambiguous behavior >both in the host and in the Isatap+6to4 border router case (that is, a router with both 6to4 pseudo (border router) and router-to-host Isatap interfaces, the reason for not including router-to-router isatap interfaces is simply that I haven't thought very deeply about those) > >There may be a problem in the following, very very sick could be discarded ?, situation: >Given that a router has a non-6to4 prefixed Isatap interface >as well as a 6to4 relay router interface >anchored on the same address of an IPv4 interface (not using 6to4 anycast address) then v6inv4 encapsulated packets may arrive on the IPv4 interface in which the inner v6packet is destined for an Isatap address with >the mentioned non-6to4 Isatap prefix of the isatap interface but where >the encapsulated packet is sourced from a 6to4 border router using 6to4. > >This packet should be processed by the 6to4 interface and not the Isatap interface. > >(And yes the hosts should speak Ipv4 instead of Ipv6 given, as it is, that they >both have global Ipv4 addresses). > >On the other hand if the above prefix limitations are combined with a split > in a host and a router part, such as: >* ROUTER interfaces: If the prefix of the source address in the inner IPv6 >header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel >interface. >* HOST interfaces: If the prefix of the source address in the inner IPv6 >header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel >interface, >then no ambiguity would arise wrt inbound 6to4 and isatap processing. > > > > >>>An Isatap tunnel interface and a configured v6inv4 tunnel >>> >>> >>interface may be anchored on >> >> >>>the same Ipv4 interface (address of Ipv4 interface). In this >>> >>> >>case the implementation must comply with the following >>inbound processing rules in prioritized order: >> >> >>>R1. If the outer IPv4 header of the encapsulated packet >>> >>> >>matches a configured v6inv4 tunnel (if any) the packet is >>processed by this tunnel interface. >> >> >>Agreed, as above. >> >> >> >>>R2. If the prefix of the source address in the inner IPv6 >>> >>> >>header of the encapsulated packet matches a prefix of the (if >>any) ISATAP interface, the packet is processed by this tunnel >>interface. >> >> >>I have to say that I have thought hard about this rule and am not >>entirely sure what to make of it, since it seems to simplistic. >>But, I will try: >> >> > >Again, I apologize wildly for not making it clear that this was >thought only to cover the >router case and only in the router-host situation. > > > >> 1) What we have considered for this space to-date is that an ISATAP >> interface would match a specific IPv4 destination address and a >> wild-card source address in the IPv4 header of an >>ip-proto-41 packet. >> 2) Multiple ISATAP interfaces might be matched by this criteria, >> and so we require a means for identifying the correct one. >> 3) An ISATAP interface that configures a prefix that >>matches the IPv6 >> source of the packet (if found) is clearly the best >>first-choice to >>receive >> the packet. >> 4) If no ISATAP interface with a matching prefix is found, >>this could >> be a packet from an off-link source that is being >>forwarded to (or, >> through this decapsulator by a member of the Potential >>Router List. >> >>But, stopping now for a closer look at item 4), there seems to be no >>way to determine which ISATAP interface (among possibly many) >>might be the correct one to receive and decapsulate the packet - if >>any. It could be that the IPv6 destination address is a >>foreign address >>also, making for a router<->router transaction which is a non-goal >>for ISATAP. >> >>This says that, in order to disambiguate the search, we really need to >>treat all possible IPv6 source addresses as on-link for the purpose of >>receiving packets, but off-link for the purpose of sending return >>packets. In other words, we would need an ISATAP interface >>with a distinct /128 prefix for each destination we are actively >>communicating with that uses the same IPv6 next-hop address >>for return addresses. In other words, from a host's viewpoint the >>sources of IPv6 packets for which a matching ISATAP interface >>exists would all appear to be on-link, but the destinations would >>all appear to be off-link and reachable through a particular IPv6 >>next-hop address. There is a (somewhat) subtle implication here >>for decapsulation validity checks of the IPv4 source address, >>but should be very simple to express. >> >>If what I am saying makes sense, and if we can agree that ISATAP >>support for router<->router tunneling is a non-goal, then I believe >>your R2 above could provide a useful simplification for the spec. >> >> > >Wouldn't you need >a different R2 for host and for router interfaces >(founded on destination address and source address respectively) ? > >In addition, the source address check could potentially be performed by the isatap host interface implementation - e.g. to rule out direct packets from >"non-link" hosts - thus limiting the direct tunnelling function to hosts >using the same prefixes - and/or to rule out packets coming form anything else >than default router in some scenarios. > >With the 6to4 prefix limitation on Isatap interfaces this would >eliminate conflicts wrt inbound 6to4 and Isatap interfaces processing. > >In addition you would need to prioritize configured tunnel and Isatap >interfaces, but I guess that this is implicitly covered by 1) (in that >specific Ipv4 addresses would take precedence over wildcard in Ipv4 source). > >I hope this at least help to clarify my previous mail. >Whether it adds anything useful to the picture, will be for you and >others to decide. > >BR, Karen > > > >This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > > From owner-v6ops@ops.ietf.org Wed Mar 31 03:20: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 DAA05218 for ; Wed, 31 Mar 2004 03:20:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8au3-000Cbp-W9 for v6ops-data@psg.com; Wed, 31 Mar 2004 08:16:51 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8atx-000CZx-Ci for v6ops@ops.ietf.org; Wed, 31 Mar 2004 09:16:45 +0100 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2V8GiqY012643 for ; Wed, 31 Mar 2004 10:16:44 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 10:16:43 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2AA7QJ0Z; Wed, 31 Mar 2004 10:16:43 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Mar 2004 10:16:40 +0200 Message-ID: X-Sybari-Trust: 384b906c 2c4885b5 4dbf37a1 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Fred Templin'" Cc: "'Pekka Savola'" , IPv6 Operations , "'JORDI PALET MARTINEZ'" Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] Date: Wed, 31 Mar 2004 10:16:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 31 Mar 2004 08:16:43.0828 (UTC) FILETIME=[8096BF40:01C416F8] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Fred, I think that the problem is very real, both implementation and external behavior wise, every time you want to implement more than one tunneling mechs. Leaving it up to the implementation to resolve ambiguities is for me the same as to say coexistence not in scope of specification (which is fine). Specification of such coexistence may then of course appear at a later stage. However if we actually wish at this stage to enable coexistence of certain specific combinations of tunneling mechs then IMO we should say MAY coexist under the following unambiguous guidelines/rules. Jordi et al.'s list may of course solve this once and for all. Karen. > > Karen, > > Thanks for the additional thoughts. On the non-use of 6to4 prefixes as > on-link prefixes for ISATAP interfaces, I'd like to > back-track on this yet > again. I don't see a problem with an ISATAP interface and a 6to4 > interface anchored to the same (global unicast) IPv4 address and > having the same 6to4 prefix as an on-link prefix - just as IP > addresses > and prefixes may be assigned to multiple ordinary interfaces. > > There is a slight difference in that ISATAP and 6to4 use slightly > different checks on decapsulation, but it seems sufficient to leave > as implementor's choice how to resolve the ambiguity, e.g., some > might choose to always use the 6to4 decapsulation rules (and > receive interface) in this case. > > Fred > ftemplin@iprg.nokia.com > > Karen E. Nielsen (AH/TED) wrote: > > >Hi Fred, > > > >Please accept my apologies for sending > >half baked thoughts (previous mail) out on the list. > > > >A few comment inline. > > > >BR, Karen > > > >[snip] > > > > > > > >>Agree that an implementation must be able to prioritize the > >>tunnel interfaces. Not quite as clear on what should be included > >>in "the spec", and not entirely sure exactly which document you > >>are referring to when you say: "the spec", but see more below: > >> > >> > >> > > > >I simply mean that the prioritization in > >between different tunnels in the inbound processing path > >(i.e. exact algorithm behind the location of appropriate > inbound tunnel interface) can have implications for > >the external behavior, wherefore it should be written down in > >an IETF document. For what concerns Isatap, e.g., in the > Isatap "spec". > >(In regard to the latest Isatap draft, e.g. in Section > 7.2.3, but this is of course not for me to say :-)). > > > > > > > >>>For outbound traffic there isn't a problem, > >>>the appropriate tunnel interface should > >>>be selected from the forwarding table/destination cache. > >>> > >>> > >>> > >>Agreed; longest-prefix match will select the appropriate tunnel > >>interface for outbound traffic. > >> > >> > >> > >>>For inbound traffic there is an issue if the tunnel interfaces, > >>>lets say an Isatap pseudo tunnel interface and a configured > >>>v6inv4 tunnel interface, are anchored on the same > >>>(source) address of an Ipv4 interface. > >>>The implementation must here be able to determine which > >>> > >>> > >>protocol processing module > >> > >> > >>>(Isatap or configured tunnel respectively) that an incoming > >>>packet should be subject to. > >>> > >>> > >>> > >>Agree with the above assertions regarding inbound traffic. > >> > >> > >> > >>>One possibility here (which we have used in one implementation) > >>>it to apply the following inbound processing rules in > >>> > >>> > >>prioritized order: > >> > >> > >>>R1. If the outer IPv4 header of the encapsulated packet > >>> > >>> > >>matches a configured v6inv4 tunnel (if any) the packet is > >>processed by this tunnel interface. > >> > >> > >>IP-proto-41 packets are first checked to determine whether > they belong > >>to a configured tunnel by checking the (source/destination > >>addresses) in > >>the IPv4 header, yes. This much seems consistent with the current > >>ISATAP draft version, but thanks for reminding of this. > >> > >> > > > >I am sorry if that's already spelled out in the current draft. > > > > > > > >>>R2. If the prefix of the source address in the inner IPv6 > >>> > >>> > >>header of the encapsulated packet matches a prefix of the (if > >>any) ISATAP interface, the packet is processed by this tunnel > >>interface. > >> > >> > >>>R3. If the prefix of either the source or destination > >>> > >>> > >>address in the inner IPv6 header is a 6to4 prefix, the packet > >>is processed by the (if any) 6to4 tunnel interface. > >> > >> > >>>I do consider it unlikely to have both 6to4 and Isatap used > >>> > >>> > >>on the same Ipv4 interface so a more strict version of the > >>above could be: > >> > >> > >>>An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on > >>> > >>> > >>the same IPv4 interface > >> > >> > >>>(address of an IPv4 interface, strictly speaking, the > >>> > >>> > >>problems only arise if the tunnels are anchored on the same > >>addresses). > >> > >> > >>(Retracting a bit from some comments in an earlier message on > >>this subject.) > >>According to RFC 3056, 6to4 can only occur over global unicast IPv4 > >>addresses. > >>ISATAP interfaces can also occur over global unicast IPv4 > >>addresses, in > >>which > >>case the ISATAP link would span the entire global IPv4 Internet. > >> > >>If we allowed both a 6to4 interface and an ISATAP interface > >>to be anchored > >>to the *same* global unicast IPv4 address (e.g., "V4ADDR"), > >>it should be > >>OK as long as no prefixes derived from "2002:V4ADDR::/48" > >>(i.e., the /48 > >>prefix itself, or any finer-grained derivative prefix) are > >>configured as > >>on-link > >>prefixes on the ISATAP interface. This would keep the > >>"6to4-prefixed IPv6 > >>Internet" from overlapping with the "everything-else-prefixed IPv6 > >>Internet", > >>where "everything-else" is a candidate prefix for ISATAP. > >> > >>I think there may be several possible ways of expressing > >>this, ranging from > >>"least restrictive" to: "most restrictive"; below are two > >>possible examples > >>that lie at the extremities of the range of alternatives: > >> > >>Least restrictive: > >>************** > >> "An ISATAP and a 6to4 tunnel interface MAY coexist on the > >>same global > >> unicast IPv4 address ("V4ADDR"), but in this case the > >>ISATAP interface > >> MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as > >> an on-link prefix." > >> > >>Most restrictive: > >>************** > >> "An ISATAP interface configured over a global unicast > IPv4 address > >> MUST NOT configure a prefix derived from "2002::/16" as an > >> on-link prefix." > >> > >>(Note that both of these examples still allow for ISATAP interfaces > >>configured over private IPv4 addresses to configure 6to4 prefixes, > >>but the ISATAP tunneling would be strictly intra-site in that case.) > >> > >>Any comments on this? > >> > >> > > > >First I must say, that the rules above were used by us > >in a Router implementation (not host) in which Isatap > communication only > >was supported to and from the Isatap hosts of the router. > >(i.e. no support for Isatap router-to-router). > > > >I apologies for not making that clear !!!!! > > > >Secondly: > > > >I assume that the above rules means to imply that a packet should be: > >processed by the Isatap interface when inner packet is > destined to and/or sourced from an address with a prefix of > the Isatap interface. > > > >I guess that the above rules are sound and lead to > unambiguous behavior > >both in the host and in the Isatap+6to4 border router case > (that is, a router with both 6to4 pseudo (border router) and > router-to-host Isatap interfaces, the reason for not > including router-to-router isatap interfaces is simply that I > haven't thought very deeply about those) > > > >There may be a problem in the following, very very sick > could be discarded ?, situation: > >Given that a router has a non-6to4 prefixed Isatap interface > >as well as a 6to4 relay router interface > >anchored on the same address of an IPv4 interface (not using > 6to4 anycast address) then v6inv4 encapsulated packets may > arrive on the IPv4 interface in which the inner v6packet is > destined for an Isatap address with > >the mentioned non-6to4 Isatap prefix of the isatap interface > but where > >the encapsulated packet is sourced from a 6to4 border router > using 6to4. > > > >This packet should be processed by the 6to4 interface and > not the Isatap interface. > > > >(And yes the hosts should speak Ipv4 instead of Ipv6 given, > as it is, that they > >both have global Ipv4 addresses). > > > >On the other hand if the above prefix limitations are > combined with a split > > in a host and a router part, such as: > >* ROUTER interfaces: If the prefix of the source address in > the inner IPv6 > >header of the encapsulated packet matches a prefix of the > (if any) ISATAP interface, the packet is processed by this tunnel > >interface. > >* HOST interfaces: If the prefix of the source address in > the inner IPv6 > >header of the encapsulated packet matches a prefix of the > (if any) ISATAP interface, the packet is processed by this tunnel > >interface, > >then no ambiguity would arise wrt inbound 6to4 and isatap processing. > > > > > > > > > >>>An Isatap tunnel interface and a configured v6inv4 tunnel > >>> > >>> > >>interface may be anchored on > >> > >> > >>>the same Ipv4 interface (address of Ipv4 interface). In this > >>> > >>> > >>case the implementation must comply with the following > >>inbound processing rules in prioritized order: > >> > >> > >>>R1. If the outer IPv4 header of the encapsulated packet > >>> > >>> > >>matches a configured v6inv4 tunnel (if any) the packet is > >>processed by this tunnel interface. > >> > >> > >>Agreed, as above. > >> > >> > >> > >>>R2. If the prefix of the source address in the inner IPv6 > >>> > >>> > >>header of the encapsulated packet matches a prefix of the (if > >>any) ISATAP interface, the packet is processed by this tunnel > >>interface. > >> > >> > >>I have to say that I have thought hard about this rule and am not > >>entirely sure what to make of it, since it seems to simplistic. > >>But, I will try: > >> > >> > > > >Again, I apologize wildly for not making it clear that this was > >thought only to cover the > >router case and only in the router-host situation. > > > > > > > >> 1) What we have considered for this space to-date is that > an ISATAP > >> interface would match a specific IPv4 destination address and a > >> wild-card source address in the IPv4 header of an > >>ip-proto-41 packet. > >> 2) Multiple ISATAP interfaces might be matched by this criteria, > >> and so we require a means for identifying the correct one. > >> 3) An ISATAP interface that configures a prefix that > >>matches the IPv6 > >> source of the packet (if found) is clearly the best > >>first-choice to > >>receive > >> the packet. > >> 4) If no ISATAP interface with a matching prefix is found, > >>this could > >> be a packet from an off-link source that is being > >>forwarded to (or, > >> through this decapsulator by a member of the Potential > >>Router List. > >> > >>But, stopping now for a closer look at item 4), there seems to be no > >>way to determine which ISATAP interface (among possibly many) > >>might be the correct one to receive and decapsulate the packet - if > >>any. It could be that the IPv6 destination address is a > >>foreign address > >>also, making for a router<->router transaction which is a non-goal > >>for ISATAP. > >> > >>This says that, in order to disambiguate the search, we > really need to > >>treat all possible IPv6 source addresses as on-link for the > purpose of > >>receiving packets, but off-link for the purpose of sending return > >>packets. In other words, we would need an ISATAP interface > >>with a distinct /128 prefix for each destination we are actively > >>communicating with that uses the same IPv6 next-hop address > >>for return addresses. In other words, from a host's viewpoint the > >>sources of IPv6 packets for which a matching ISATAP interface > >>exists would all appear to be on-link, but the destinations would > >>all appear to be off-link and reachable through a particular IPv6 > >>next-hop address. There is a (somewhat) subtle implication here > >>for decapsulation validity checks of the IPv4 source address, > >>but should be very simple to express. > >> > >>If what I am saying makes sense, and if we can agree that ISATAP > >>support for router<->router tunneling is a non-goal, then I believe > >>your R2 above could provide a useful simplification for the spec. > >> > >> > > > >Wouldn't you need > >a different R2 for host and for router interfaces > >(founded on destination address and source address respectively) ? > > > >In addition, the source address check could potentially be > performed by the isatap host interface implementation - e.g. > to rule out direct packets from > >"non-link" hosts - thus limiting the direct tunnelling > function to hosts > >using the same prefixes - and/or to rule out packets coming > form anything else > >than default router in some scenarios. > > > >With the 6to4 prefix limitation on Isatap interfaces this would > >eliminate conflicts wrt inbound 6to4 and Isatap interfaces > processing. > > > >In addition you would need to prioritize configured tunnel and Isatap > >interfaces, but I guess that this is implicitly covered by > 1) (in that > >specific Ipv4 addresses would take precedence over wildcard > in Ipv4 source). > > > >I hope this at least help to clarify my previous mail. > >Whether it adds anything useful to the picture, will be for you and > >others to decide. > > > >BR, Karen > > > > > > > >This communication is confidential and intended solely for > the addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has > been sent to you in error, please notify the sender by > replying to this transmission and delete the message without > disclosing it. Thank you. > > > >E-mail including attachments is susceptible to data > corruption, interruption, unauthorized amendment, tampering > and viruses, and we only send and receive e-mails on the > basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any > consequences thereof. > > > > > > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From owner-v6ops@ops.ietf.org Wed Mar 31 09:54: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 JAA25028 for ; Wed, 31 Mar 2004 09:54:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8h0x-0008T1-T0 for v6ops-data@psg.com; Wed, 31 Mar 2004 14:48:23 +0000 Received: from [66.218.79.80] (helo=web80510.mail.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B8h0Z-0008Qa-LC for v6ops@ops.ietf.org; Wed, 31 Mar 2004 15:47:59 +0100 Message-ID: <20040331144759.5257.qmail@web80510.mail.yahoo.com> Received: from [63.197.18.101] by web80510.mail.yahoo.com via HTTP; Wed, 31 Mar 2004 06:47:59 PST Date: Wed, 31 Mar 2004 06:47:59 -0800 (PST) From: Fred Templin Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] To: "Karen E. Nielsen \(AH/TED\)" , "'Fred Templin'" Cc: "'Pekka Savola'" , IPv6 Operations , "'JORDI PALET MARTINEZ'" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-220158286-1080744479=:2731" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-220158286-1080744479=:2731 Content-Type: text/plain; charset=us-ascii Karen, OK, if you must know it then I believe it is possible to run both 6to4 and ISATAP from a single interface. Let's say a node wants to send a packet to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting for the moment that 192.1.2.3 is non-global and used only as example). If the node has, e.g., a route in its routing table such as: 2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0) then the packet will go out the isatap0 interface using ISATAP encapsulation based on the link-local ISATAP address from the routing table as the next-hop toward the 6to4 router, and the 6to4 router will be unable to tell whether the encapsulator used 6to4 or ISATAP. In other words, if we view each 6to4 router as also an ISATAP router with a link-local address on the "site" that includes the global IPv4 Internet, then it really makes no difference whether we use a 6to4 interface or an ISATAP interface for sending the packet. In terms of receiving packets, if we view every global IPv4 address as a "Potential Router", then the ISATAP decapsulation checks amount to exactly the same (optional) checks suggested for 6to4 and, again, either interface could be used to receive the packet with no differences. The difference comes when operational deployments will begin to use non-6to4 global IPv6 prefixes, in which case sending nodes will need to, e.g., add routes such as: 3FFE:EXAMPLE::/48 -> fe80::0200:5EFE:C001:0203 (isatap0) Then, the ISATAP router at 192.1.2.3 will appear the same as if it were a 6to4 relay router that relays from the 6to4 domain to the 3FFE:EXAMPLE::/48 prefix space. Sending nodes will most likely use the DNS to discover the IPv6 prefix to global IPv4 address mappings for destinations of interest, and so there really would be no need for running a BGP-style routing protocol between the ISATAP routers (that are really acting as 6to4 relay router equivalents). In this case, however, the only choice would be to use an ISATAP interface, since 6to4 interfaces only encapsulate packets sent to a 2002:EXAMPLE::48 prefix. So, I guess that would make the ISATAP interface as the LCD that needs to be there in any case, and configuring a 6to4 interface also on the same node (and over the same IPv4 address) could be viewed as optional. This is not by way of saying that ISATAP is in any way obsoleting 6to4, but rather the 6to4 and non-6to4 prefix space can be consolidated into a single automatic tunnel interface footprint (instead of two) if desired. Fred osprey67@yahoo.com "Karen E. Nielsen (AH/TED)" wrote: Fred, I think that the problem is very real, both implementation and external behavior wise, every time you want to implement more than one tunneling mechs. Leaving it up to the implementation to resolve ambiguities is for me the same as to say coexistence not in scope of specification (which is fine). Specification of such coexistence may then of course appear at a later stage. However if we actually wish at this stage to enable coexistence of certain specific combinations of tunneling mechs then IMO we should say MAY coexist under the following unambiguous guidelines/rules. Jordi et al.'s list may of course solve this once and for all. Karen. > > Karen, > > Thanks for the additional thoughts. On the non-use of 6to4 prefixes as > on-link prefixes for ISATAP interfaces, I'd like to > back-track on this yet > again. I don't see a problem with an ISATAP interface and a 6to4 > interface anchored to the same (global unicast) IPv4 address and > having the same 6to4 prefix as an on-link prefix - just as IP > addresses > and prefixes may be assigned to multiple ordinary interfaces. > > There is a slight difference in that ISATAP and 6to4 use slightly > different checks on decapsulation, but it seems sufficient to leave > as implementor's choice how to resolve the ambiguity, e.g., some > might choose to always use the 6to4 decapsulation rules (and > receive interface) in this case. > > Fred > ftemplin@iprg.nokia.com > > Karen E. Nielsen (AH/TED) wrote: > > >Hi Fred, > > > >Please accept my apologies for sending > >half baked thoughts (previous mail) out on the list. > > > >A few comment inline. > > > >BR, Karen > > > >[snip] > > > > > > > >>Agree that an implementation must be able to prioritize the > >>tunnel interfaces. Not quite as clear on what should be included > >>in "the spec", and not entirely sure exactly which document you > >>are referring to when you say: "the spec", but see more below: > >> > >> > >> > > > >I simply mean that the prioritization in > >between different tunnels in the inbound processing path > >(i.e. exact algorithm behind the location of appropriate > inbound tunnel interface) can have implications for > >the external behavior, wherefore it should be written down in > >an IETF document. For what concerns Isatap, e.g., in the > Isatap "spec". > >(In regard to the latest Isatap draft, e.g. in Section > 7.2.3, but this is of course not for me to say :-)). > > > > > > > >>>For outbound traffic there isn't a problem, > >>>the appropriate tunnel interface should > >>>be selected from the forwarding table/destination cache. > >>> > >>> > >>> > >>Agreed; longest-prefix match will select the appropriate tunnel > >>interface for outbound traffic. > >> > >> > >> > >>>For inbound traffic there is an issue if the tunnel interfaces, > >>>lets say an Isatap pseudo tunnel interface and a configured > >>>v6inv4 tunnel interface, are anchored on the same > >>>(source) address of an Ipv4 interface. > >>>The implementation must here be able to determine which > >>> > >>> > >>protocol processing module > >> > >> > >>>(Isatap or configured tunnel respectively) that an incoming > >>>packet should be subject to. > >>> > >>> > >>> > >>Agree with the above assertions regarding inbound traffic. > >> > >> > >> > >>>One possibility here (which we have used in one implementation) > >>>it to apply the following inbound processing rules in > >>> > >>> > >>prioritized order: > >> > >> > >>>R1. If the outer IPv4 header of the encapsulated packet > >>> > >>> > >>matches a configured v6inv4 tunnel (if any) the packet is > >>processed by this tunnel interface. > >> > >> > >>IP-proto-41 packets are first checked to determine whether > they belong > >>to a configured tunnel by checking the (source/destination > >>addresses) in > >>the IPv4 header, yes. This much seems consistent with the current > >>ISATAP draft version, but thanks for reminding of this. > >> > >> > > > >I am sorry if that's already spelled out in the current draft. > > > > > > > >>>R2. If the prefix of the source address in the inner IPv6 > >>> > >>> > >>header of the encapsulated packet matches a prefix of the (if > >>any) ISATAP interface, the packet is processed by this tunnel > >>interface. > >> > >> > >>>R3. If the prefix of either the source or destination > >>> > >>> > >>address in the inner IPv6 header is a 6to4 prefix, the packet > >>is processed by the (if any) 6to4 tunnel interface. > >> > >> > >>>I do consider it unlikely to have both 6to4 and Isatap used > >>> > >>> > >>on the same Ipv4 interface so a more strict version of the > >>above could be: > >> > >> > >>>An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on > >>> > >>> > >>the same IPv4 interface > >> > >> > >>>(address of an IPv4 interface, strictly speaking, the > >>> > >>> > >>problems only arise if the tunnels are anchored on the same > >>addresses). > >> > >> > >>(Retracting a bit from some comments in an earlier message on > >>this subject.) > >>According to RFC 3056, 6to4 can only occur over global unicast IPv4 > >>addresses. > >>ISATAP interfaces can also occur over global unicast IPv4 > >>addresses, in > >>which > >>case the ISATAP link would span the entire global IPv4 Internet. > >> > >>If we allowed both a 6to4 interface and an ISATAP interface > >>to be anchored > >>to the *same* global unicast IPv4 address (e.g., "V4ADDR"), > >>it should be > >>OK as long as no prefixes derived from "2002:V4ADDR::/48" > >>(i.e., the /48 > >>prefix itself, or any finer-grained derivative prefix) are > >>configured as > >>on-link > >>prefixes on the ISATAP interface. This would keep the > >>"6to4-prefixed IPv6 > >>Internet" from overlapping with the "everything-else-prefixed IPv6 > >>Internet", > >>where "everything-else" is a candidate prefix for ISATAP. > >> > >>I think there may be several possible ways of expressing > >>this, ranging from > >>"least restrictive" to: "most restrictive"; below are two > >>possible examples > >>that lie at the extremities of the range of alternatives: > >> > >>Least restrictive: > >>************** > >> "An ISATAP and a 6to4 tunnel interface MAY coexist on the > >>same global > >> unicast IPv4 address ("V4ADDR"), but in this case the > >>ISATAP interface > >> MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as > >> an on-link prefix." > >> > >>Most restrictive: > >>************** > >> "An ISATAP interface configured over a global unicast > IPv4 address > >> MUST NOT configure a prefix derived from "2002::/16" as an > >> on-link prefix." > >> > >>(Note that both of these examples still allow for ISATAP interfaces > >>configured over private IPv4 addresses to configure 6to4 prefixes, > >>but the ISATAP tunneling would be strictly intra-site in that case.) > >> > >>Any comments on this? > >> > >> > > > >First I must say, that the rules above were used by us > >in a Router implementation (not host) in which Isatap > communication only > >was supported to and from the Isatap hosts of the router. > >(i.e. no support for Isatap router-to-router). > > > >I apologies for not making that clear !!!!! > > > >Secondly: > > > >I assume that the above rules means to imply that a packet should be: > >processed by the Isatap interface when inner packet is > destined to and/or sourced from an address with a prefix of > the Isatap interface. > > > >I guess that the above rules are sound and lead to > unambiguous behavior > >both in the host and in the Isatap+6to4 border router case > (that is, a router with both 6to4 pseudo (border router) and > router-to-host Isatap interfaces, the reason for not > including router-to-router isatap interfaces is simply that I > haven't thought very deeply about those) > > > >There may be a problem in the following, very very sick > could be discarded ?, situation: > >Given that a router has a non-6to4 prefixed Isatap interface > >as well as a 6to4 relay router interface > >anchored on the same address of an IPv4 interface (not using > 6to4 anycast address) then v6inv4 encapsulated packets may > arrive on the IPv4 interface in which the inner v6packet is > destined for an Isatap address with > >the mentioned non-6to4 Isatap prefix of the isatap interface > but where > >the encapsulated packet is sourced from a 6to4 border router > using 6to4. > > > >This packet should be processed by the 6to4 interface and > not the Isatap interface. > > > >(And yes the hosts should speak Ipv4 instead of Ipv6 given, > as it is, that they > >both have global Ipv4 addresses). > > > >On the other hand if the above prefix limitations are > combined with a split > > in a host and a router part, such as: > >* ROUTER interfaces: If the prefix of the source address in > the inner IPv6 > >header of the encapsulated packet matches a prefix of the > (if any) ISATAP interface, the packet is processed by this tunnel > >interface. > >* HOST interfaces: If the prefix of the source address in > the inner IPv6 > >header of the encapsulated packet matches a prefix of the > (if any) ISATAP interface, the packet is processed by this tunnel > >interface, > >then no ambiguity would arise wrt inbound 6to4 and isatap processing. > > > > > > > > > >>>An Isatap tunnel interface and a configured v6inv4 tunnel > >>> > >>> > >>interface may be anchored on > >> > >> > >>>the same Ipv4 interface (address of Ipv4 interface). In this > >>> > >>> > >>case the implementation must comply with the following > >>inbound processing rules in prioritized order: > >> > >> > >>>R1. If the outer IPv4 header of the encapsulated packet > >>> > >>> > >>matches a configured v6inv4 tunnel (if any) the packet is > >>processed by this tunnel interface. > >> > >> > >>Agreed, as above. > >> > >> > >> > >>>R2. If the prefix of the source address in the inner IPv6 > >>> > >>> > >>header of the encapsulated packet matches a prefix of the (if > >>any) ISATAP interface, the packet is processed by this tunnel > >>interface. > >> > >> > >>I have to say that I have thought hard about this rule and am not > >>entirely sure what to make of it, since it seems to simplistic. > >>But, I will try: > >> > >> > > > >Again, I apologize wildly for not making it clear that this was > >thought only to cover the > >router case and only in the router-host situation. > > > > > > > >> 1) What we have considered for this space to-date is that > an ISATAP > >> interface would match a specific IPv4 destination address and a > >> wild-card source address in the IPv4 header of an > >>ip-proto-41 packet. > >> 2) Multiple ISATAP interfaces might be matched by this criteria, > >> and so we require a means for identifying the correct one. > >> 3) An ISATAP interface that configures a prefix that > >>matches the IPv6 > >> source of the packet (if found) is clearly the best > >>first-choice to > >>receive > >> the packet. > >> 4) If no ISATAP interface with a matching prefix is found, > >>this could > >> be a packet from an off-link source that is being > >>forwarded to (or, > >> through this decapsulator by a member of the Potential > >>Router List. > >> > >>But, stopping now for a closer look at item 4), there seems to be no > >>way to determine which ISATAP interface (among possibly many) > >>might be the correct one to receive and decapsulate the packet - if > >>any. It could be that the IPv6 destination address is a > >>foreign address > >>also, making for a router<->router transaction which is a non-goal > >>for ISATAP. > >> > >>This says that, in order to disambiguate the search, we > really need to > >>treat all possible IPv6 source addresses as on-link for the > purpose of > >>receiving packets, but off-link for the purpose of sending return > >>packets. In other words, we would need an ISATAP interface > >>with a distinct /128 prefix for each destination we are actively > >>communicating with that uses the same IPv6 next-hop address > >>for return addresses. In other words, from a host's viewpoint the > >>sources of IPv6 packets for which a matching ISATAP interface > >>exists would all appear to be on-link, but the destinations would > >>all appear to be off-link and reachable through a particular IPv6 > >>next-hop address. There is a (somewhat) subtle implication here > >>for decapsulation validity checks of the IPv4 source address, > >>but should be very simple to express. > >> > >>If what I am saying makes sense, and if we can agree that ISATAP > >>support for router<->router tunneling is a non-goal, then I believe > >>your R2 above could provide a useful simplification for the spec. > >> > >> > > > >Wouldn't you need > >a different R2 for host and for router interfaces > >(founded on destination address and source address respectively) ? > > > >In addition, the source address check could potentially be > performed by the isatap host interface implementation - e.g. > to rule out direct packets from > >"non-link" hosts - thus limiting the direct tunnelling > function to hosts > >using the same prefixes - and/or to rule out packets coming > form anything else > >than default router in some scenarios. > > > >With the 6to4 prefix limitation on Isatap interfaces this would > >eliminate conflicts wrt inbound 6to4 and Isatap interfaces > processing. > > > >In addition you would need to prioritize configured tunnel and Isatap > >interfaces, but I guess that this is implicitly covered by > 1) (in that > >specific Ipv4 addresses would take precedence over wildcard > in Ipv4 source). > > > >I hope this at least help to clarify my previous mail. > >Whether it adds anything useful to the picture, will be for you and > >others to decide. > > > >BR, Karen > > > > > > > >This communication is confidential and intended solely for > the addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has > been sent to you in error, please notify the sender by > replying to this transmission and delete the message without > disclosing it. Thank you. > > > >E-mail including attachments is susceptible to data > corruption, interruption, unauthorized amendment, tampering > and viruses, and we only send and receive e-mails on the > basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any > consequences thereof. > > > > > > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --0-220158286-1080744479=:2731 Content-Type: text/html; charset=us-ascii
Karen,
 
OK, if you must know it then I believe it is possible to run both 6to4 and
ISATAP from a single interface. Let's say a node wants to send a packet
to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that
is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting
for the moment that 192.1.2.3 is non-global and used only as example).
If the node has, e.g., a route in its routing table such as:
 
   2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0)
 
then the packet will go out the isatap0 interface using ISATAP encapsulation
based on the link-local ISATAP address from the routing table as the next-hop
toward the 6to4 router, and the 6to4 router will be unable to tell whether the
encapsulator used 6to4 or ISATAP.
 
In other words, if we view each 6to4 router as also an ISATAP router with a
link-local address on the "site" that includes the global IPv4 Internet, then it
really makes no difference whether we use a 6to4 interface or an ISATAP
interface for sending the packet.
 
In terms of receiving packets, if we view every global IPv4 address as a
"Potential Router", then the ISATAP decapsulation checks amount to
exactly the same (optional) checks suggested for 6to4 and, again, either
interface could be used to receive the packet with no differences.
 
The difference comes when operational deployments will begin to use
non-6to4 global IPv6 prefixes, in which case sending nodes will need to,
e.g., add routes such as:
 
   3FFE:EXAMPLE::/48 -> fe80::0200:5EFE:C001:0203 (isatap0)
 
Then, the ISATAP router at 192.1.2.3 will appear the same as
if it were a 6to4 relay router that relays from the 6to4 domain to the
3FFE:EXAMPLE::/48 prefix space. Sending nodes will most likely use
the DNS to discover the IPv6 prefix to global IPv4 address mappings for
destinations of interest, and so there really would be no need for running
a BGP-style routing protocol between the ISATAP routers (that are really
acting as 6to4 relay router equivalents). In this case, however, the only
choice would be to use an ISATAP interface, since 6to4 interfaces only
encapsulate packets sent to a 2002:EXAMPLE::48 prefix.
 
So, I guess that would make the ISATAP interface as the LCD that
needs to be there in any case, and configuring a 6to4 interface also
on the same node (and over the same IPv4 address) could be viewed
as optional. This is not by way of saying that ISATAP is in any way
obsoleting 6to4, but rather the 6to4 and non-6to4 prefix space can
be consolidated into a single automatic tunnel interface footprint
(instead of two) if desired.
 
Fred
osprey67@yahoo.com

"Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com> wrote:
Fred,

I think that the problem is very real, both implementation and
external behavior wise, every time you
want to implement more than one tunneling mechs.

Leaving it up to the implementation to resolve
ambiguities is for me the same as to say
coexistence not in scope of specification (which is fine).

Specification of such coexistence may then of course
appear at a later stage.

However if we actually wish at this stage to enable coexistence of
certain specific combinations of tunneling mechs
then IMO we should say MAY coexist under the following
unambiguous guidelines/rules.

Jordi et al.'s list may of course solve this once and for all.

Karen.

>
> Karen,
>
> Thanks for the additional thoughts. On the non-use of 6to4 prefixes as
> on-link prefixes for ISATAP interfaces, I'd like to
> back-track on this yet
> again. I don't see a problem with an ISATAP interface and a 6to4
> interface anchored to the same (global unicast) IPv4 address and
> having the same 6to4 prefix as an on-link prefix - just as IP
> addresses
> and prefixes may be assigned to multiple ordinary interfaces.
>
> There is a slight difference in that ISATAP and 6to4 use slightly
> different checks on decapsulation, but it seems sufficient to leave
> as implementor's choice how to resolve the ambiguity, e.g., some
> might choose to always use the 6to4 decapsulation rules (and
> receive interface) in this case.
>
> Fred
> ftemplin@iprg.nokia.com
>
> Karen E. Nielsen (AH/TED) wrote:
>
> >Hi Fred,
> >
> >Please accept my apologies for sending
> >half baked thoughts (previous mail) out on the list.
> >
> >A few comment inline.
> >
> >BR, Karen
> >
> >[snip]
> >
> >
> >
> >>Agree that an implementation must be able to prioritize the
> >>tunnel interfaces. Not quite as clear on what should be included
> >>in "the spec", and not entirely sure exactly which document you
> >>are referring to when you say: "the spec", but see more below:
> >>
> >>
> >>
> >
> >I simply mean that the prioritization in
> >between different tunnels in the inbound processing path
> >(i.e. exact algorithm behind the location of appropriate
> inbound tunnel interface) can have implications for
> >the external behavior, wherefore it should be written down in
> >an IETF document. For what concerns Isatap, e.g., in the
> Isatap "spec".
> >(In regard to the latest Isatap draft, e.g. in Section
> 7.2.3, but this is of course not for me to say :-)).
> >
> >
> >
> >>>For outbound traffic there isn't a problem,
> >>>the appropriate tunnel interface should
> >>>be selected from the forwarding table/destination cache.
> >>>
> >>>
> >>>
> >>Agreed; longest-prefix match will select the appropriate tunnel
> >>interface for outbound traffic.
> >>
> >>
> >>
> >>>For inbound traffic there is an issue if the tunnel interfaces,
> >>>lets say an Isatap pseudo tunnel interface and a configured
> >>>v6inv4 tunnel interface, are anchored on the same
> >>>(source) address of an Ipv4 interface.
> >>>The implementation must here be able to determine which
> >>>
> >>>
> >>protocol processing module
> >>
> >>
> >>>(Isatap or configured tunnel respectively) that an incoming
> >>>packet should be subject to.
> >>>
> >>>
> >>>
> >>Agree with the above assertions regarding inbound traffic.
> >>
> >>
> >>
> >>>One possibility here (which we have used in one implementation)
> >>>it to apply the following inbound processing rules in
> >>>
> >>>
> >>prioritized order:
> >>
> >>
> >>>R1. If the outer IPv4 header of the encapsulated packet
> >>>
> >>>
> >>matches a configured v6inv4 tunnel (if any) the packet is
> >>processed by this tunnel interface.
> >>
> >>
> >>IP-proto-41 packets are first checked to determine whether
> they belong
> >>to a configured tunnel by checking the (source/destination
> >>addresses) in
> >>the IPv4 header, yes. This much seems consistent with the current
> >>ISATAP draft version, but thanks for reminding of this.
> >>
> >>
> >
> >I am sorry if that's already spelled out in the current draft.
> >
> >
> >
> >>>R2. If the prefix of the source address in the inner IPv6
> >>>
> >>>
> >>header of the encapsulated packet matches a prefix of the (if
> >>any) ISATAP interface, the packet is processed by this tunnel
> >>interface.
> >>
> >>
> >>>R3. If the prefix of either the source or destination
> >>>
> >>>
> >>address in the inner IPv6 header is a 6to4 prefix, the packet
> >>is processed by the (if any) 6to4 tunnel interface.
> >>
> >>
> >>>I do consider it unlikely to have both 6to4 and Isatap used
> >>>
> >>>
> >>on the same Ipv4 interface so a more strict version of the
> >>above could be:
> >>
> >>
> >>>An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on
> >>>
> >>>
> >>the same IPv4 interface
> >>
> >>
> >>>(address of an IPv4 interface, strictly speaking, the
> >>>
> >>>
> >>problems only arise if the tunnels are anchored on the same
> >>addresses).
> >>
> >>
> >>(Retracting a bit from some comments in an earlier message on
> >>this subject.)
> >>According to RFC 3056, 6to4 can only occur over global unicast IPv4
> >>addresses.
> >>ISATAP interfaces can also occur over global unicast IPv4
> >>addresses, in
> >>which
> >>case the ISATAP link would span the entire global IPv4 Internet.
> >>
> >>If we allowed both a 6to4 interface and an ISATAP interface
> >>to be anchored
> >>to the *same* global unicast IPv4 address (e.g., "V4ADDR"),
> >>it should be
> >>OK as long as no prefixes derived from "2002:V4ADDR::/48"
> >>(i.e., the /48
> >>prefix itself, or any finer-grained derivative prefix) are
> >>configured as
> >>on-link
> >>prefixes on the ISATAP interface. This would keep the
> >>"6to4-prefixed IPv6
> >>Internet" from overlapping with the "everything-else-prefixed IPv6
> >>Internet",
> >>where "everything-else" is a candidate prefix for ISATAP.
> >>
> >>I think there may be several possible ways of expressing
> >>this, ranging from
> >>"least restrictive" to: "most restrictive"; below are two
> >>possible examples
> >>that lie at the extremities of the range of alternatives:
> >>
> >>Least restrictive:
> >>**************
> >> "An ISATAP and a 6to4 tunnel interface MAY coexist on the
> >>same global
> >> unicast IPv4 address ("V4ADDR"), but in this case the
> >>ISATAP interface
> >> MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as
> >> an on-link prefix."
> >>
> >>Most restrictive:
> >>**************
> >> "An ISATAP interface configured over a global unicast
> IPv4 address
> >> MUST NOT configure a prefix derived from "2002::/16" as an
> >> on-link prefix."
> >>
> >>(Note that both of these examples still allow for ISATAP interfaces
> >>configured over private IPv4 addresses to configure 6to4 prefixes,
> >>but the ISATAP tunneling would be strictly intra-site in that case.)
> >>
> >>Any comments on this?
> >>
> >>
> >
> >First I must say, that the rules above were used by us
> >in a Router implementation (not host) in which Isatap
> communication only
> >was supported to and from the Isatap hosts of the router.
> >(i.e. no support for Isatap router-to-router).
> >
> >I apologies for not making that clear !!!!!
> >
> >Secondly:
> >
> >I assume that the above rules means to imply that a packet should be:
> >processed by the Isatap interface when inner packet is
> destined to and/or sourced from an address with a prefix of
> the Isatap interface.
> >
> >I guess that the above rules are sound and lead to
> unambiguous behavior
> >both in the host and in the Isatap+6to4 border router case
> (that is, a router with both 6to4 pseudo (border router) and
> router-to-host Isatap interfaces, the reason for not
> including router-to-router isatap interfaces is simply that I
> haven't thought very deeply about those)
> >
> >There may be a problem in the following, very very sick
> could be discarded ?, situation:
> >Given that a router has a non-6to4 prefixed Isatap interface
> >as well as a 6to4 relay router interface
> >anchored on the same address of an IPv4 interface (not using
> 6to4 anycast address) then v6inv4 encapsulated packets may
> arrive on the IPv4 interface in which the inner v6packet is
> destined for an Isatap address with
> >the mentioned non-6to4 Isatap prefix of the isatap interface
> but where
> >the encapsulated packet is sourced from a 6to4 border router
> using 6to4.
> >
> >This packet should be processed by the 6to4 interface and
> not the Isatap interface.
> >
> >(And yes the hosts should speak Ipv4 instead of Ipv6 given,
> as it is, that they
> >both have global Ipv4 addresses).
> >
> >On the other hand if the above prefix limitations are
> combined with a split
> > in a host and a router part, such as:
> >* ROUTER interfaces: If the prefix of the source address in
> the inner IPv6
> >header of the encapsulated packet matches a prefix of the
> (if any) ISATAP interface, the packet is processed by this tunnel
> >interface.
> >* HOST interfaces: If the prefix of the source address in
> the inner IPv6
> >header of the encapsulated packet matches a prefix of the
> (if any) ISATAP interface, the packet is processed by this tunnel
> >interface,
> >then no ambiguity would arise wrt inbound 6to4 and isatap processing.
> >
> >
> >
> >
> >>>An Isatap tunnel interface and a configured v6inv4 tunnel
> >>>
> >>>
> >>interface may be anchored on
> >>
> >>
> >>>the same Ipv4 interface (address of Ipv4 interface). In this
> >>>
> >>>
> >>case the implementation must comply with the following
> >>inbound processing rules in prioritized order:
> >>
> >>
> >>>R1. If the outer IPv4 header of the encapsulated packet
> >>>
> >>>
> >>matches a configured v6inv4 tunnel (if any) the packet is
> >>processed by this tunnel interface.
> >>
> >>
> >>Agreed, as above.
> >>
> >>
> >>
> >>>R2. If the prefix of the source address in the inner IPv6
> >>>
> >>>
> >>header of the encapsulated packet matches a prefix of the (if
> >>any) ISATAP interface, the packet is processed by this tunnel
> >>interface.
> >>
> >>
> >>I have to say that I have thought hard about this rule and am not
> >>entirely sure what to make of it, since it seems to simplistic.
> >>But, I will try:
> >>
> >>
> >
> >Again, I apologize wildly for not making it clear that this was
> >thought only to cover the
> >router case and only in the router-host situation.
> >
> >
> >
> >> 1) What we have considered for this space to-date is that
> an ISATAP
> >> interface would match a specific IPv4 destination address and a
> >> wild-card source address in the IPv4 header of an
> >>ip-proto-41 packet.
> >> 2) Multiple ISATAP interfaces might be matched by this criteria,
> >> and so we require a means for identifying the correct one.
> >> 3) An ISATAP interface that configures a prefix that
> >>matches the IPv6
> >> source of the packet (if found) is clearly the best
> >>first-choice to
> >>receive
> >> the packet.
> >> 4) If no ISATAP interface with a matching prefix is found,
> >>this could
> >> be a packet from an off-link source that is being
> >>forwarded to (or,
> >> through this decapsulator by a member of the Potential
> >>Router List.
> >>
> >>But, stopping now for a closer look at item 4), there seems to be no
> >>way to determine which ISATAP interface (among possibly many)
> >>might be the correct one to receive and decapsulate the packet - if
> >>any. It could be that the IPv6 destination address is a
> >>foreign address
> >>also, making for a router<->router transaction which is a non-goal
> >>for ISATAP.
> >>
> >>This says that, in order to disambiguate the search, we
> really need to
> >>treat all possible IPv6 source addresses as on-link for the
> purpose of
> >>receiving packets, but off-link for the purpose of sending return
> >>packets. In other words, we would need an ISATAP interface
> >>with a distinct /128 prefix for each destination we are actively
> >>communicating with that uses the same IPv6 next-hop address
> >>for return addresses. In other words, from a host's viewpoint the
> >>sources of IPv6 packets for which a matching ISATAP interface
> >>exists would all appear to be on-link, but the destinations would
> >>all appear to be off-link and reachable through a particular IPv6
> >>next-hop address. There is a (somewhat) subtle implication here
> >>for decapsulation validity checks of the IPv4 source address,
> >>but should be very simple to express.
> >>
> >>If what I am saying makes sense, and if we can agree that ISATAP
> >>support for router<->router tunneling is a non-goal, then I believe
> >>your R2 above could provide a useful simplification for the spec.
> >>
> >>
> >
> >Wouldn't you need
> >a different R2 for host and for router interfaces
> >(founded on destination address and source address respectively) ?
> >
> >In addition, the source address check could potentially be
> performed by the isatap host interface implementation - e.g.
> to rule out direct packets from
> >"non-link" hosts - thus limiting the direct tunnelling
> function to hosts
> >using the same prefixes - and/or to rule out packets coming
> form anything else
> >than default router in some scenarios.
> >
> >With the 6to4 prefix limitation on Isatap interfaces this would
> >eliminate conflicts wrt inbound 6to4 and Isatap interfaces
> processing.
> >
> >In addition you would need to prioritize configured tunnel and Isatap
> >interfaces, but I guess that this is implicitly covered by
> 1) (in that
> >specific Ipv4 addresses would take precedence over wildcard
> in Ipv4 source).
> >
> >I hope this at least help to clarify my previous mail.
> >Whether it adds anything useful to the picture, will be for you and
> >others to decide.
> >
> >BR, Karen
> >
> >
> >
> >This communication is confidential and intended solely for
> the addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has
> been sent to you in error, please notify the sender by
> replying to this transmission and delete the message without
> disclosing it. Thank you.
> >
> >E-mail including attachments is susceptible to data
> corruption, interruption, unauthorized amendment, tampering
> and viruses, and we only send and receive e-mails on the
> basis that we are not liable for any such corruption,
> interception, amendment, tampering or viruses or any
> consequences thereof.
> >
> >
> >
>
>

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--0-220158286-1080744479=:2731-- From owner-v6ops@ops.ietf.org Wed Mar 31 11:00: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 LAA00079 for ; Wed, 31 Mar 2004 11:00:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8i5r-000M1C-7f for v6ops-data@psg.com; Wed, 31 Mar 2004 15:57:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8i5V-000Lwz-9w for v6ops@ops.ietf.org; Wed, 31 Mar 2004 16:57:09 +0100 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2VFv5T21487; Wed, 31 Mar 2004 18:57:05 +0300 Date: Wed, 31 Mar 2004 18:57:05 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: IPv6 Operations Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] In-Reply-To: <20040331144759.5257.qmail@web80510.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I haven't been following the discussion, so I may be missing something -- but a few comments.. On Wed, 31 Mar 2004, Fred Templin wrote: > OK, if you must know it then I believe it is possible to run both 6to4 and > ISATAP from a single interface. Let's say a node wants to send a packet > to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that > is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting > for the moment that 192.1.2.3 is non-global and used only as example). > If the node has, e.g., a route in its routing table such as: > > 2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0) > > then the packet will go out the isatap0 interface using ISATAP encapsulation > based on the link-local ISATAP address from the routing table as the next-hop > toward the 6to4 router, and the 6to4 router will be unable to tell whether the > encapsulator used 6to4 or ISATAP. The encapsulation part should be trivial, as it can be set by the longest-prefix match by the system. If it is set improperly, it's only a problem of the implementation/operator. Decapsulation is the tricky part. > In terms of receiving packets, if we view every global IPv4 address as a > "Potential Router", then the ISATAP decapsulation checks amount to > exactly the same (optional) checks suggested for 6to4 and, again, either > interface could be used to receive the packet with no differences. I don't think that's accurate. For example, you don't use link-locals on top of 6to4. With ISATAP, you'd be accepting link-local traffic from everyone. > The difference comes when operational deployments will begin to use > non-6to4 global IPv6 prefixes, in which case sending nodes will need to, > e.g., add routes such as: > > 3FFE:EXAMPLE::/48 -> fe80::0200:5EFE:C001:0203 (isatap0) > > Then, the ISATAP router at 192.1.2.3 will appear the same as > if it were a 6to4 relay router that relays from the 6to4 domain to the > 3FFE:EXAMPLE::/48 prefix space. Yep, though in 6to4 the relay router is typically reached through the 6to4 pseudo-interface. [...] > In this case, however, the only > choice would be to use an ISATAP interface, since 6to4 interfaces only > encapsulate packets sent to a 2002:EXAMPLE::48 prefix. Uh, no. 6to4 relay routers are also reachable through the 6to4 interface, right? -- 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 Mar 31 12:27: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 MAA02801 for ; Wed, 31 Mar 2004 12:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8jSK-000Aak-Bq for v6ops-data@psg.com; Wed, 31 Mar 2004 17:24:48 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8jS6-000AYc-TM for v6ops@ops.ietf.org; Wed, 31 Mar 2004 18:24:34 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2VHOLS32710; Wed, 31 Mar 2004 09:24:21 -0800 X-mProtect: <200403311724> 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 smtpdH39TBH; Wed, 31 Mar 2004 09:24:19 PST Message-ID: <406AFECA.8010600@iprg.nokia.com> Date: Wed, 31 Mar 2004 09:24:26 -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: Fred Templin , IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, Thanks for the comments - see my responses below: Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >I haven't been following the discussion, so I may be missing something >-- but a few comments.. > >On Wed, 31 Mar 2004, Fred Templin wrote: > > >>OK, if you must know it then I believe it is possible to run both 6to4 and >>ISATAP from a single interface. Let's say a node wants to send a packet >>to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that >>is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting >>for the moment that 192.1.2.3 is non-global and used only as example). >>If the node has, e.g., a route in its routing table such as: >> >> 2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0) >> >>then the packet will go out the isatap0 interface using ISATAP encapsulation >>based on the link-local ISATAP address from the routing table as the next-hop >>toward the 6to4 router, and the 6to4 router will be unable to tell whether the >>encapsulator used 6to4 or ISATAP. >> >> > >The encapsulation part should be trivial, as it can be set by the >longest-prefix match by the system. If it is set improperly, it's >only a problem of the implementation/operator. > Agreed. >Decapsulation is the tricky part. > > > >>In terms of receiving packets, if we view every global IPv4 address as a >>"Potential Router", then the ISATAP decapsulation checks amount to >>exactly the same (optional) checks suggested for 6to4 and, again, either >>interface could be used to receive the packet with no differences. >> >> > >I don't think that's accurate. For example, you don't use link-locals >on top of 6to4. With ISATAP, you'd be accepting link-local traffic >from everyone. > I see your point. In the ISATAP decapsulation checks, we currently say that we accept packets coming from any member of the Potential Router List and (thorough error of omission, perhaps) that could include link-locals. Seems like this should be pretty straightforward to fix - or do you still think there is some tricky aspect of it that I'm not seeing? >>The difference comes when operational deployments will begin to use >>non-6to4 global IPv6 prefixes, in which case sending nodes will need to, >>e.g., add routes such as: >> >> 3FFE:EXAMPLE::/48 -> fe80::0200:5EFE:C001:0203 (isatap0) >> >>Then, the ISATAP router at 192.1.2.3 will appear the same as >>if it were a 6to4 relay router that relays from the 6to4 domain to the >>3FFE:EXAMPLE::/48 prefix space. >> >> > >Yep, though in 6to4 the relay router is typically reached through the >6to4 pseudo-interface. > >[...] > > >>In this case, however, the only >>choice would be to use an ISATAP interface, since 6to4 interfaces only >>encapsulate packets sent to a 2002:EXAMPLE::48 prefix. >> >> > >Uh, no. 6to4 relay routers are also reachable through the 6to4 >interface, right? > Well, yes - I agree with your point, and the ISATAP interface is not the only choice. I don't believe this changes the fact that one possible implementation alternative is to combine both the ISATAP and 6to4 functions over a single interface, however. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Mar 31 13:07: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 NAA05200 for ; Wed, 31 Mar 2004 13:07:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8k4h-000Gyh-40 for v6ops-data@psg.com; Wed, 31 Mar 2004 18:04:27 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8k4T-000Gxv-9R for v6ops@ops.ietf.org; Wed, 31 Mar 2004 19:04:13 +0100 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2VI49C24043; Wed, 31 Mar 2004 21:04:09 +0300 Date: Wed, 31 Mar 2004 21:04:09 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] In-Reply-To: <406AFECA.8010600@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 31 Mar 2004, Fred Templin wrote: > >>In terms of receiving packets, if we view every global IPv4 address as a > >>"Potential Router", then the ISATAP decapsulation checks amount to > >>exactly the same (optional) checks suggested for 6to4 and, again, either > >>interface could be used to receive the packet with no differences. > >> > >> > > > >I don't think that's accurate. For example, you don't use link-locals > >on top of 6to4. With ISATAP, you'd be accepting link-local traffic > >from everyone. > > > > I see your point. In the ISATAP decapsulation checks, we currently > say that we accept packets coming from any member of the Potential > Router List and (thorough error of omission, perhaps) that could > include link-locals. Seems like this should be pretty > straightforward to fix - or do you still think there is some tricky > aspect of it that I'm not seeing? I'm not sure what you're saying: 1) modifying the reception from members of PRL list (in some fashion) 2) modifying the acceptance of link-local messages in general 2.a) for all members of PRL 2.b) for PRL members and ISATAP nodes both I think you were proposing 2.a), but not sure? (Or 2.b?) Disallowing link-locals could have a number of effects depending on which of these methods it's used. E.g., it could prevent running a routing protocol on top of the links (not sure if you'd want that). It might also be confusing to disallow it as you're typically configuring an ISATAP link-local address as your next-hop (and you couldn't ping the next-hop). I.e., if the link-local address would only work as a "pseudo-address", it would be used only as a means to specify "send to node 192.1.2.3 through isatap interface". How would the ISATAP nodes send RS to the router, and the router send RA to the nodes to configure the on-link prefix, btw, if this was disallowed? > >>In this case, however, the only > >>choice would be to use an ISATAP interface, since 6to4 interfaces only > >>encapsulate packets sent to a 2002:EXAMPLE::48 prefix. > >> > >> > > > >Uh, no. 6to4 relay routers are also reachable through the 6to4 > >interface, right? > > > > Well, yes - I agree with your point, and the ISATAP interface is not > the only choice. I don't believe this changes the fact that one possible > implementation alternative is to combine both the ISATAP and 6to4 > functions over a single interface, however. (I haven't gone through the thought exercise of looking through the details, but the prospect leaves me with a fuzzy bad feeling..) -- 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 Mar 31 13:39: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 NAA06821 for ; Wed, 31 Mar 2004 13:39:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8kaL-000Mlx-BP for v6ops-data@psg.com; Wed, 31 Mar 2004 18:37:09 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8ka7-000Mjz-DW for v6ops@ops.ietf.org; Wed, 31 Mar 2004 19:36:55 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2VIalI06215; Wed, 31 Mar 2004 10:36:47 -0800 X-mProtect: <200403311836> 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 smtpdc1GF3V; Wed, 31 Mar 2004 10:36:45 PST Message-ID: <406B0FC5.4040806@iprg.nokia.com> Date: Wed, 31 Mar 2004 10:36:53 -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: IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: >On Wed, 31 Mar 2004, Fred Templin wrote: > > >>>>In terms of receiving packets, if we view every global IPv4 address as a >>>>"Potential Router", then the ISATAP decapsulation checks amount to >>>>exactly the same (optional) checks suggested for 6to4 and, again, either >>>>interface could be used to receive the packet with no differences. >>>> >>>> >>>> >>>> >>>I don't think that's accurate. For example, you don't use link-locals >>>on top of 6to4. With ISATAP, you'd be accepting link-local traffic >>> >>> >>>from everyone. >> >> >>I see your point. In the ISATAP decapsulation checks, we currently >>say that we accept packets coming from any member of the Potential >>Router List and (thorough error of omission, perhaps) that could >>include link-locals. Seems like this should be pretty >>straightforward to fix - or do you still think there is some tricky >>aspect of it that I'm not seeing? >> >> > >I'm not sure what you're saying: > >1) modifying the reception from members of PRL list (in some fashion) > >2) modifying the acceptance of link-local messages in general > 2.a) for all members of PRL > 2.b) for PRL members and ISATAP nodes both > >I think you were proposing 2.a), but not sure? (Or 2.b?) > >Disallowing link-locals could have a number of effects depending on >which of these methods it's used. E.g., it could prevent running a >routing protocol on top of the links (not sure if you'd want that). >It might also be confusing to disallow it as you're typically >configuring an ISATAP link-local address as your next-hop (and you >couldn't ping the next-hop). > >I.e., if the link-local address would only work as a "pseudo-address", >it would be used only as a means to specify "send to node 192.1.2.3 >through isatap interface". > >How would the ISATAP nodes send RS to the router, and the router send >RA to the nodes to configure the on-link prefix, btw, if this was >disallowed? > No; not disallow link-locals, since they are fundamental to ND over ISATAP. The intent of the proposal was only to stop link-locals from coming from incorrect nodes. In the current document (section 8.6), we have the following checks for IPv4 source address verification: For packets received on an ISATAP interface, the IPv4 source address is correct if: - the IPv6 source address is an ISATAP address that embeds the IPv4 source address in its interface identifier, or: - 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: - the IPv4 source address is a member of the Potential Router List (see: section 9.1). Neglecting for the moment the middlemost of the three checks, we see that the first check accepts link local IPv6 source addresses that embed the IPv4 source address in the interface identifier. However, the third check also accepts link local IPv6 source addresses that *do not* embed the IPv4 source address - so long as the IPv4 source address is in the Potential Router List - and this is the part that could cause trouble. The fix suggestion is to modify the third check in the list to exclude packets with IPv6 link-local source addresses from the check, forcing IPv6 link-locals to be either verified or rejected via the first check only. Comments? >>>>In this case, however, the only >>>>choice would be to use an ISATAP interface, since 6to4 interfaces only >>>>encapsulate packets sent to a 2002:EXAMPLE::48 prefix. >>>> >>>> >>>> >>>> >>>Uh, no. 6to4 relay routers are also reachable through the 6to4 >>>interface, right? >>> >>> >>> >>Well, yes - I agree with your point, and the ISATAP interface is not >>the only choice. I don't believe this changes the fact that one possible >>implementation alternative is to combine both the ISATAP and 6to4 >>functions over a single interface, however. >> >> > >(I haven't gone through the thought exercise of looking through the >details, but the prospect leaves me with a fuzzy bad feeling..) > Well, the good news is that this would fall under implementation details, and not anything necessary for protocol specification - right? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Mar 31 15:45: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 PAA12430 for ; Wed, 31 Mar 2004 15:45:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8mXZ-000Lpp-Nj for v6ops-data@psg.com; Wed, 31 Mar 2004 20:42:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8mXM-000Lnb-9A for v6ops@ops.ietf.org; Wed, 31 Mar 2004 21:42:12 +0100 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2VKg8d27013; Wed, 31 Mar 2004 23:42:08 +0300 Date: Wed, 31 Mar 2004 23:42:08 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] In-Reply-To: <406B0FC5.4040806@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 31 Mar 2004, Fred Templin wrote: [...] > - the IPv4 source address is a member of the Potential Router > List (see: section 9.1). > > Neglecting for the moment the middlemost of the three checks, we see that > the first check accepts link local IPv6 source addresses that embed the IPv4 > source address in the interface identifier. However, the third check also > accepts link local IPv6 source addresses that *do not* embed the IPv4 > source address - so long as the IPv4 source address is in the Potential > Router List - and this is the part that could cause trouble. > > The fix suggestion is to modify the third check in the list to exclude > packets with IPv6 link-local source addresses from the check, forcing > IPv6 link-locals to be either verified or rejected via the first check only. > Comments? I see no harm in that. But it should be obvious that this doesn't really provide much of practical mitigation, as v4 addresses can be spoofed, or you could just use a real v4 address. This check is most attractive inside a site, where it's reasonable to assume that ingress filtering is in place .. and the "everyone in PRL list" is definitely not that case. (The only difference, still, with 6to4 is that the similar abuse of 6to4 is limited to global addresses -- not link-locals, even if the v4addr matched.) > >>Well, yes - I agree with your point, and the ISATAP interface is not > >>the only choice. I don't believe this changes the fact that one possible > >>implementation alternative is to combine both the ISATAP and 6to4 > >>functions over a single interface, however. > > > >(I haven't gone through the thought exercise of looking through the > >details, but the prospect leaves me with a fuzzy bad feeling..) > > > > Well, the good news is that this would fall under implementation details, > and not anything necessary for protocol specification - right? I fear I have to disagree.. leaving these unspecified seems like an indication that we never managed to figure them out properly, and leaving them as an "exercise for the reader". This would tempt the implementer to either 1) do them improperly, or 2) not do checks at all. We have already seen examples of both... I.e., I think it would be very useful to try to figure out a way to perform decapsulation processing in a sane fashion. We don't need to normatively *require* the specific processing rules, of course -- but just provide them as an example (or two) for the implementers. -- 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 Mar 31 16:43: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 QAA14272 for ; Wed, 31 Mar 2004 16:43:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8nSa-0008ug-Vh for v6ops-data@psg.com; Wed, 31 Mar 2004 21:41:20 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8nSQ-0008t8-Jt for v6ops@ops.ietf.org; Wed, 31 Mar 2004 22:41:10 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2VLf3l21163; Wed, 31 Mar 2004 13:41:03 -0800 X-mProtect: <200403312141> 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 smtpdtwqDiq; Wed, 31 Mar 2004 13:41:01 PST Message-ID: <406B3AF5.3060209@iprg.nokia.com> Date: Wed, 31 Mar 2004 13:41:09 -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: IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Wed, 31 Mar 2004, Fred Templin wrote: >[...] > > >> - the IPv4 source address is a member of the Potential Router >> List (see: section 9.1). >> >>Neglecting for the moment the middlemost of the three checks, we see that >>the first check accepts link local IPv6 source addresses that embed the IPv4 >>source address in the interface identifier. However, the third check also >>accepts link local IPv6 source addresses that *do not* embed the IPv4 >>source address - so long as the IPv4 source address is in the Potential >>Router List - and this is the part that could cause trouble. >> >>The fix suggestion is to modify the third check in the list to exclude >>packets with IPv6 link-local source addresses from the check, forcing >>IPv6 link-locals to be either verified or rejected via the first check only. >>Comments? >> >> > >I see no harm in that. > OK, but I am still checking my thinking on this. I'm now thinking that my suggestion might foul things up for protocols that require a means for detecting L2 address changes due to, e.g., a NAT in the path. >But it should be obvious that this doesn't really provide much of >practical mitigation, as v4 addresses can be spoofed, or you could >just use a real v4 address. This check is most attractive inside a >site, where it's reasonable to assume that ingress filtering is in >place .. and the "everyone in PRL list" is definitely not that case. > I didn't quite catch what you meant by "a real v4 address"? >(The only difference, still, with 6to4 is that the similar abuse of >6to4 is limited to global addresses -- not link-locals, even if the >v4addr matched.) > In terms of link-locals, the first-pass filtering by the ISATAP decapsulator is only for the purpose of determining whether the IPv4 source address in the encapsulating header is acceptable for the IPv6 source address in the encapsualted packet. Higher layers up the stack will also likely use other mitigations in determining whether/not to accept link-local packets, but this is beyond the scope of our discussion on decapsulation. >>>>Well, yes - I agree with your point, and the ISATAP interface is not >>>>the only choice. I don't believe this changes the fact that one possible >>>>implementation alternative is to combine both the ISATAP and 6to4 >>>>functions over a single interface, however. >>>> >>>> >>>(I haven't gone through the thought exercise of looking through the >>>details, but the prospect leaves me with a fuzzy bad feeling..) >>> >>> >>> >>Well, the good news is that this would fall under implementation details, >>and not anything necessary for protocol specification - right? >> >> > >I fear I have to disagree.. leaving these unspecified seems like an >indication that we never managed to figure them out properly, and >leaving them as an "exercise for the reader". This would tempt the >implementer to either 1) do them improperly, or 2) not do checks at >all. We have already seen examples of both... > >I.e., I think it would be very useful to try to figure out a way to >perform decapsulation processing in a sane fashion. We don't need to >normatively *require* the specific processing rules, of course -- but >just provide them as an example (or two) for the implementers. > I can potentially see your point, depending on exactly which document you think such non-normative text should appear in. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Mar 31 17:10: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 RAA15645 for ; Wed, 31 Mar 2004 17:10:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8nsO-000ELf-8e for v6ops-data@psg.com; Wed, 31 Mar 2004 22:08:00 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8nsD-000EJl-Tg for v6ops@ops.ietf.org; Wed, 31 Mar 2004 23:07:49 +0100 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2VM7gv00436; Wed, 31 Mar 2004 14:07:42 -0800 X-mProtect: <200403312207> 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 smtpdSMsKkh; Wed, 31 Mar 2004 14:07:41 PST Message-ID: <406B4135.9010908@iprg.nokia.com> Date: Wed, 31 Mar 2004 14:07:49 -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: Fred Templin CC: Pekka Savola , IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] References: <406B3AF5.3060209@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred Templin wrote: > > > Pekka Savola wrote: > >> On Wed, 31 Mar 2004, Fred Templin wrote: >> [...] >> >> >>> - the IPv4 source address is a member of the Potential Router >>> List (see: section 9.1). >>> >>> Neglecting for the moment the middlemost of the three checks, we see >>> that >>> the first check accepts link local IPv6 source addresses that embed >>> the IPv4 >>> source address in the interface identifier. However, the third check >>> also >>> accepts link local IPv6 source addresses that *do not* embed the IPv4 >>> source address - so long as the IPv4 source address is in the Potential >>> Router List - and this is the part that could cause trouble. >>> >>> The fix suggestion is to modify the third check in the list to exclude >>> packets with IPv6 link-local source addresses from the check, forcing >>> IPv6 link-locals to be either verified or rejected via the first >>> check only. >>> Comments? >>> >> >> >> I see no harm in that. >> > > OK, but I am still checking my thinking on this. I'm now thinking that > my suggestion might foul things up for protocols that require a means > for detecting L2 address changes due to, e.g., a NAT in the path. Umm - sorry. That would be a Teredo concern (not ISATAP) and outside the scope of 'ip-proto-41' tunneling. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Mar 31 19:03: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 TAA21543 for ; Wed, 31 Mar 2004 19:03:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8pda-000EfV-5B for v6ops-data@psg.com; Thu, 01 Apr 2004 00:00:50 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8pdT-000Eep-MI for v6ops@ops.ietf.org; Thu, 01 Apr 2004 01:00:43 +0100 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3100gwr014152 for ; Wed, 31 Mar 2004 17:00:43 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVG009FJTD638@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 31 Mar 2004 17:00:42 -0700 (MST) Received: from [192.168.1.102] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HVG00KA5TD53Q@mail.sun.net> for v6ops@ops.ietf.org; Wed, 31 Mar 2004 17:00:42 -0700 (MST) Date: Wed, 31 Mar 2004 16:00:39 -0800 From: Alain Durand Subject: tunnel set up protocol requirements To: IPv6 Operations Message-id: <9C83524C-836F-11D8-8C6D-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT At the request of Pekka, co-chair of this wg, Florent Parent & I have put together a draft to discuss the requirements for a tunnel set up protocol. We published draft-durand-v6ops-assisted-tunneling-requirements-00.txt For the impatients, there is a copy at: http://playground.sun.com/ipv6/draft-durand-v6ops-assisted-tunneling- requirements-00.txt Comments more than welcome! - Alain. From owner-v6ops@ops.ietf.org Wed Mar 31 23:58: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 XAA02673 for ; Wed, 31 Mar 2004 23:58:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8uEJ-000PBH-55 for v6ops-data@psg.com; Thu, 01 Apr 2004 04:55:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8uEH-000PA3-E0 for v6ops@ops.ietf.org; Thu, 01 Apr 2004 05:55:01 +0100 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i314svk01775; Thu, 1 Apr 2004 07:54:57 +0300 Date: Thu, 1 Apr 2004 07:54:57 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: IPv6 Operations Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ] In-Reply-To: <406B3AF5.3060209@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 31 Mar 2004, Fred Templin wrote: > >But it should be obvious that this doesn't really provide much of > >practical mitigation, as v4 addresses can be spoofed, or you could > >just use a real v4 address. This check is most attractive inside a > >site, where it's reasonable to assume that ingress filtering is in > >place .. and the "everyone in PRL list" is definitely not that case. > > I didn't quite catch what you meant by "a real v4 address"? The check only protects from someone spoofing their v4 address. If the use of link-locals by strangers (remember that these have TTL=255 and are allowed to do anything Neighbor Discovery -wise) is categorically thought to be harmful (I certainly think so), this doesn't really help. > >(The only difference, still, with 6to4 is that the similar abuse of > >6to4 is limited to global addresses -- not link-locals, even if the > >v4addr matched.) > > In terms of link-locals, the first-pass filtering by the ISATAP decapsulator > is only for the purpose of determining whether the IPv4 source address in > the encapsulating header is acceptable for the IPv6 source address in the > encapsualted packet. Higher layers up the stack will also likely use other > mitigations in determining whether/not to accept link-local packets, but > this is beyond the scope of our discussion on decapsulation. Of course, but as LL's are treated specially e.g. by ND code, this makes the ISATAP decapsulation non-equivalent to 6to4 decapsulation. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings