From owner-v6ops@ops.ietf.org Sat Nov 1 01:04:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04157 for ; Sat, 1 Nov 2003 01:04:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFomR-0004P7-PA for v6ops-data@psg.com; Sat, 01 Nov 2003 05:58:35 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFomM-0004Om-Py for v6ops@ops.ietf.org; Sat, 01 Nov 2003 05:58:30 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3817113B1A for ; Sat, 1 Nov 2003 00:58:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 Nov 2003 00:58:30 -0500 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: Implementation vs. the Standard Date: Sat, 1 Nov 2003 00:58:29 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1E8@tayexc13.americas.cpqcorp.net> Thread-Topic: Implementation vs. the Standard Thread-Index: AcOfHl4rvvuTa3EyTkWQruko39JD0wAlRQpAACEHjZA= From: "Bound, Jim" To: X-OriginalArrivalTime: 01 Nov 2003 05:58:30.0016 (UTC) FILETIME=[2CB73800:01C3A03D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >From: Pekka Savola [mailto:pekkas@netcore.fi]=20 >Subject: Re: Implementation vs. the Standard > >A couple of comments inline. > >On Thu, 30 Oct 2003, Bound, Jim wrote: >> It is important for us to separate implementation choice vs. the=20 >> standard. The onlink and v6bydefault discussions are mostly a focus=20 >> on if you do this with IPv6 and don't think about this other aspect=20 >> you can hurt yourself. > >I'm not sure how to read this. Are you implying that the=20 >specifications could (should) include harmful or dubious=20 >features, which clever implementers could then ignore or work=20 >around locally, as a means for product/vendor differentiation?=20 > Probably not, but that's a way to interpret some of the=20 >comments about why things like these are outside the scope of=20 >the specs. Not at all. I am saying any standard that is implemented can be broken by bad implementation or bad operational management. The trade off as to what the standard does to help alleiviate potential problems is a fine line. For example, it is not the IETF's business to state if an implementation has IPv4 or IPv6 on or not on by default. It is appropriate for example to not build one standard that is not interoperable with another standard if that other standard has not been deprecated. > >> There is nothing wrong with documenting issues for=20 >implementers in an=20 >> RFC and that work should be encouraged. In that context I=20 >agree with=20 >> Pekka S. But, for the IETF to tell vendors how they ship their=20 >> products for customers is simply inappropriate and vendors will not=20 >> listen to the IETF, hence this is not a good use of our=20 >precious mail=20 >> time. In that sense I agree with Tony 100%. >> >> Discussion of operational issues with our standards and how=20 >they work=20 >> with implementation is a good discussion. But should not be a=20 >> priority over the standards work we need to deliver as a working=20 >> group. > >Personally, I disagree with the second paragraph. It is=20 >almost criminally=20 >negligent to just push out standards, one after another,=20 >without fixing or=20 >documenting issues in the existing ones. Not what I said at all your reading into the words subjectively and you don't know me, we are not friends, and this is not the intention of the words. I will give you another example. =20 ND is widely deployed and also highly tested with 3 separate test suites to verify interoperability, in addition to running in many networks I am aware of intimately. None of the issues in the afforementioned specs about v6onbydefault or onlink issues have ever occurred I am aware of except in an analysis lab and that is good. That does not mean those are not important to document. But, we have new specs to get out the door like the scenarios and those documents require a lot of discussion to complete. That should be the WG priority from your view as Co-Chair that is all I am saying. And I am not saying we should not document potential problems in current specs. It's a matter of priority. =20 Regarding being multitasked. We must operate as a multitasking entity not doing so and living in one pipeline is unacceptable to the market and sooner or later they will simply ignore and replace us with a more efficient body. =20 > >Our number one priority to ensure that the standards and the=20 >supporting=20 >advice we generate is accurate, has no known problems and is=20 >interoperable. The supporting "advice" cannot and is not to be in the standard and look at all the trouble putting that advice of a "conceptual" algorithm has caused for ND now (I think the issue is way overrated but that's my view) and is a perfect example of not putting "advice" in a standard. If you want to write down advice put it in Informational or BCPs. Now I am not saying hints and guidelines are not to be in standards, but they need to be minimal and left for other documents, and why we created BCPs in the IETF. Now to finish my argument. If we are producing 8 BCPs and no standards to the IESG we have not done our job as IETF WG. It is the same for many of us here in the IETF. Most of us are not paid to come to the IETF and are paid as engineers and other job codes I am sure, and we can work on IETF stuff. But, if most of us only worked on the IETF work and did not deliver in our others job functions we would be fired. Likewise if we only deliver BCPs or "advice" and no stanards we will be fired by the IESG or the Chairs :--) > >From my point of view, broken standards are worse than no standards at=20 >all, hence the need to focus to addressing the issues in the existing=20 >standards. I don't believe and most of us don't believe here that the standards I think your speaking of are broken at all. Would you like to be specific what standards are broken and first ask yourself a question? Is continuing this discussion a good use of this WG's time? You're a Chair. This is a test.......... > >> I would also add that topics which are standards we are working on=20 >> that are needed and on standards track receive priority mail=20 >> discussion. The Standards Track discussions are the ones=20 >that may help=20 >> improve time-to-market for the IETF to deliver their=20 >product/solutions=20 >> which are networking standards and the point of this body and forum. > >Exactly the reason why I believe these issues are critical. =20 >I'm personally very worried about more than just=20 >time-to-market -- rather, what kind of technology ends up in=20 >the market, and if there are flaws in that technology, how to=20 >fix it quickly that the market won't reject it. All standards from the IETF since inception are subject to that market test. If you believe we permitted specs to go to DS and those specs are broken and have flaws then your saying a lot of bright people were broken in their deliberations and you and a couple of drafts about doing very questionable things on a network that is highly suspect, then you are challenging a rather large set of work and years of analysis, and quite frankly "running code" that has shipped in many products in the market, has not broken in real life, has not failed on Network Pilots all over the world, I can go on and on. And that all should be changed and take up all our time because you believe it is broken? Then please begin to be specific and responding to those who have told you it is guidelines needed not changes to the core protocols. Using technical depth response discourse and not words like "what if", "broken", "criminal".=20 Here is my subjective opinion. Some new people to IPv6 will pick on anything they can just to make themselves a name that they in fact had something to do with the definition of IPv6. If I am correct I ask them please work on the new stuff, review the old stuff based on a real need, and help us do the new stuff.=20 Someone want something to be champion of how about taking the lead on what are all the common application exact same issues across 3GPP, Umanaged, ISP, and Enterprise Scenarios. If someone took on this work and lead it and did it I think they would be an IPv6 hero forever. At the end of the day this is all our opinions on a thread like this and I will not keep responding. As a DI told me once "opinions are like assholes, everybodys got one". And I as one WG member appreciate your high energy and efforts in the WG all I am saying is lets be careful how much we work on stuff that is advice vs. the standards technical work that is required for IPv6. Take Care, /jim > >--=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 Sun Nov 2 19:37:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01034 for ; Sun, 2 Nov 2003 19:37:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGSbm-000O5g-7P for v6ops-data@psg.com; Mon, 03 Nov 2003 00:30:14 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGSbX-000O4A-4o for v6ops@ops.ietf.org; Mon, 03 Nov 2003 00:29:59 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HNR0056P2PW6O@mailout1.samsung.com> for v6ops@ops.ietf.org; Mon, 03 Nov 2003 09:29:56 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HNR00B7V2P6I8@mailout1.samsung.com> for v6ops@ops.ietf.org; Mon, 03 Nov 2003 09:29:30 +0900 (KST) Received: from ep_was25 (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 <0HNR00LTX2P5DW@ms3.samsung.com> for v6ops@ops.ietf.org; Mon, 03 Nov 2003 09:29:30 +0900 (KST) Content-return: prohibited Date: Mon, 03 Nov 2003 09:29:25 +0900 From: =?EUC-KR?B?udq89sir?= Subject: [I-D] DHCPv6 support for IPv6 Transition X-Sender: =?EUC-KR?Q?=BB=EF=BC=BA=C0=FC=C0=DA=A1=E7Mobile_Platform_Lab(DM=BF=AC)?= To: v6ops@ops.ietf.org, vijayak@india.hp.com, soohong.park@samsung.com Reply-to: soohong.park@samsung.com Message-id: <0HNR00LTY2P6DW@ms3.samsung.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_tAryJ7adXMSeHjAiLPCy+A)" X-Priority: 3 Msgkey: 20031103092925@soohong.park X-MTR: 20031103092925@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Boundary_(ID_tAryJ7adXMSeHjAiLPCy+A) Content-type: text/plain; charset=euc-kr Content-Transfer-Encoding: 7BIT Hello (Sorry for the cross-posting. This is because some people who are in the v6ops list may want to join the discussion. I'll restrict my further posting to the dhc list in order to avoid unnecessary noise.) I am attaching a new draft dealing with IPv6 transition issue. " DHCPv6 support for IPv6 Transition" I could not submit the draft to ID queue, as the deadline has crossed. Please go through this draft and let me know your comments. The abstract of this draft is given below Abstract For the newly deployed IPv6 networks to interoperate with vastly deployed IPv4 networks, various transition mechanisms had been proposed. Two such methods are configured tunnels [2] and 6to4 routing [3]. This document provides a mechanism by which the DHCPv6 [1] servers can provide information about the various configured tunnel end points to reach the IPv6 nodes which are separated by IPv4 networks. This documents also explains the mechanism by which the 6to4 hosts are allocated with 6to4 addresses needed for 6to4 tunneling [3]. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics --Boundary_(ID_tAryJ7adXMSeHjAiLPCy+A) Content-type: application/octet-stream; NAME=draft-ietf-dhc-dhcpv6-ipv6trans-00.txt.txt Content-disposition: attachment; filename=draft-ietf-dhc-dhcpv6-ipv6trans-00.txt.txt Content-Transfer-Encoding: base64 DQoNCiAgTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQS5LLiBWaWpheWFiaGFza2FyIA0KICBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBIZXdsZXR0LVBhY2thcmQgDQogIEV4cGlyZXMg OiBNYXkgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBEYW5p ZWwgUGFyayANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBTQU1TVU5HIEVsZWN0cm9uaWNzIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDMgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgIA0KICAgICAgICAgICAgICAgICAgICAgIERIQ1B2NiBzdXBw b3J0IGZvciBJUHY2IFRyYW5zaXRpb24gDQogICAgICAgICAgICAgICAgICAgIGRyYWZ0LWll dGYtZGhjLWRoY3B2Ni1pcHY2dHJhbnMtMDAudHh0IA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICBTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgDQogICAg IFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29u Zm9ybWFuY2Ugd2l0aCANCiAgICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBS RkMyMDI2LiANCiAgIA0KICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyANCiAgICAgVGFzayBGb3JjZSAoSUVU RiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCANCiAg ICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMg YXMgSW50ZXJuZXQtIA0KICAgICBEcmFmdHMuIA0KICAgDQogICAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4ICANCiAg ICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBi eSBvdGhlciBkb2N1bWVudHMgIA0KICAgICBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyAgDQogICAgIHJlZmVyZW5jZSBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i IA0KICAgDQogICAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBi ZSBhY2Nlc3NlZCBhdCANCiAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0 cmFjdHMudHh0LiAgDQogICANCiAgICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hh ZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9zaGFkb3cuaHRtbC4gIA0KICAgDQogIENvcHlyaWdodCBOb3RpY2UgDQogICAN CiAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuICBBbGwg UmlnaHRzIFJlc2VydmVkLiANCiAgIA0KICBBYnN0cmFjdCANCiAgIA0KICAgICBGb3IgdGhl IG5ld2x5IGRlcGxveWVkIElQdjYgbmV0d29ya3MgdG8gaW50ZXJvcGVyYXRlIHdpdGggdmFz dGx5IA0KICAgICBkZXBsb3llZCBJUHY0IG5ldHdvcmtzLCB2YXJpb3VzIHRyYW5zaXRpb24g bWVjaGFuaXNtcyBoYWQgYmVlbiANCiAgICAgcHJvcG9zZWQuICBUd28gc3VjaCBtZXRob2Rz IGFyZSBjb25maWd1cmVkIHR1bm5lbHMgWzJdIGFuZCA2dG80IA0KICAgICByb3V0aW5nIFsz XS4gIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtZWNoYW5pc20gYnkgd2hpY2ggdGhlIERI Q1B2NiANCiAgICAgWzFdIHNlcnZlcnMgY2FuIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIHZhcmlvdXMgY29uZmlndXJlZCANCiAgICAgdHVubmVsIGVuZCBwb2ludHMgdG8gcmVh Y2ggdGhlIElQdjYgbm9kZXMgd2hpY2ggYXJlIHNlcGFyYXRlZCBieSANCiAgICAgSVB2NCBu ZXR3b3Jrcy4gIFRoaXMgZG9jdW1lbnRzIGFsc28gZXhwbGFpbnMgdGhlIG1lY2hhbmlzbSBi eSB3aGljaCANCiAgICAgdGhlIDZ0bzQgaG9zdHMgYXJlIGFsbG9jYXRlZCB3aXRoIDZ0bzQg YWRkcmVzc2VzIG5lZWRlZCBmb3IgNnRvNCANCiAgICAgdHVubmVsaW5nIFszXS4gDQogICAN Cg0KDQogICANCiAgIA0KICBWaWpheSwgUGFyayAgICAgICAgICAgICAgICAgRXhwaXJlcyBN YXkgMjAwNCAgICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0KDCAgIA0KICBJbnRlcm5ldC1E cmFmdCAgICAgREhDUHY2IHN1cHBvcnQgZm9yIElQdjYgVHJhbnNpdGlvbiAgICBOb3ZlbWJl ciAyMDAzIA0KICAgDQogICANCiAgIA0KICAxLiBJbnRyb2R1Y3Rpb24gDQogICANCiAgICAg SW4gdGhlIGluaXRpYWwgZGVwbG95bWVudCBvZiBJUHY2LCB0aGUgSVB2NiBub2RlcyBtYXkg bmVlZCB0byANCiAgICAgY29tbXVuaWNhdGUgd2l0aCB0aGUgb3RoZXIgSVB2NiBub2RlcyB2 aWEgSVB2NCBuZXR3b3Jrcy4gIENvbmZpZ3VyZWQgDQogICAgIHR1bm5lbHMgWzJdIHByb3Zp ZGUgYSB3YXkgdG8gZW5jYXBzdWxhdGUgdGhlIElQdjYgcGFja2V0cyBpbiBJUHY0IA0KICAg ICBwYWNrZXRzIGFuZCB0dW5uZWwgdGhlbSBpbiB0aGUgSVB2NCBuZXR3b3JrLiAgNnRvNCBy b3V0aW5nIFszXSBkb2VzIA0KICAgICB0aGUgc2FtZSBraW5kIG9mIHR1bm5lbGluZywgYnV0 LCB3aXRob3V0IHRoZSBuZWVkIG9mIGNvbmZpZ3VyZWQgDQogICAgIHR1bm5lbHMuICBCdXQs IHRoZSBob3N0cyBhcmUgbmVlZGVkIHRvIGhhdmUgYSBzcGVjaWFsIHR5cGUgb2YgDQogICAg IGFkZHJlc3NlcyBjYWxsZWQgNnRvNCBhZGRyZXNzZXMgb2YgcHJlZml4IDIwMDI6Oi8xNi4g DQogICANCiAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IG9wdGlvbiBjYWxsZWQg Q29uZmlndXJlZCBUdW5uZWwgRW5kICANCiAgICAgUG9pbnQgYnkgd2hpY2ggdGhlIHNlcnZl ciBjYW4gbm90aWZ5IHRoZSBjbGllbnQgd2l0aCB0aGUgbGlzdCBvZiBlbmQgDQogICAgIHBv aW50IG9mIHRoZSBjb25maWd1cmVkIHR1bm5lbHMgdG8gdmFyaW91cyBJUHY2IG5ldHdvcmtz IHNlcGFyYXRlZCANCiAgICAgYnkgdGhlIElQdjQgbmV0d29ya3MuIA0KICAgDQogICAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyBhbm90aGVyIG9wdGlvbiBjYWxsZWQgSWRlbnRpdHkgQXNz b2NpYXRpb24gZm9yIA0KICAgICA2dG80IGFkZHJlc3Nlcy4gIFRoaXMgb3B0aW9uIGlzIHVz ZWQgdG8gY29uZmlndXJlIHRoZSBjbGllbnRzIHdpdGggDQogICAgIDZ0bzQgYWRkcmVzc2Vz IG5lZWRlZCBmb3IgNnRvNCByb3V0aW5nIFszXS4gDQogICANCiAgIA0KICAyLiBSZXF1aXJl bWVudHMgDQogICANCiAgICAgVGhlIGtleXdvcmRzIE1VU1QsIE1VU1QgTk9ULCBSRVFVSVJF RCwgU0hBTEwsIFNIQUxMIE5PVCwgU0hPVUxELCANCiAgICAgU0hPVUxEIE5PVCwgUkVDT01N RU5ERUQsIE1BWSwgYW5kIE9QVElPTkFMLCB3aGVuIHRoZXkgYXBwZWFyIGluIHRoaXMgDQog ICAgIGRvY3VtZW50LCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJG QyAyMTE5IFs0XSANCiAgIA0KICAgDQogIDMuIFRlcm1pbm9sb2d5IA0KICAgDQogICAgIFRo aXMgZG9jdW1lbnQgdXNlcyB0ZXJtaW5vbG9neSBzcGVjaWZpYyB0byBJUHY2IGFuZCBESENQ djYgYXMgIA0KICAgICBkZWZpbmVkIGluICJUZXJtaW5vbG9neSIgc2VjdGlvbiBvZiB0aGUg REhDUHY2IHNwZWNpZmljYXRpb24gWzFdLiANCiAgIA0KICAgDQogIDQuIENvbmZpZ3VyZWQg VHVubmVsIEVuZCBQb2ludCBPcHRpb24gDQogICANCiAgICAgVGhlIENvbmZpZ3VyZWQgVHVu bmVsIEVuZCBQb2ludCBPcHRpb24gZ2l2ZXMgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSANCiAg ICAgY2xpZW50cyBhYm91dCB0aGUgQ29uZmlndXJlZCBUdW5uZWwgRW5kIFBvaW50IFsyXSB0 byBiZSBjb250YWN0ZWQgIA0KICAgICBmb3IgcmVhY2hpbmcgdGhlIG5vZGVzIGluIHRoZSB2 YXJpb3VzIElQdjYgbmV0d29ya3Mgd2hpY2ggYXJlIA0KICAgICBzZXBhcmF0ZWQgYnkgSVB2 NCBuZXR3b3Jrcy4gIFRoZSBjbGllbnRzIGFyZSBleHBlY3RlZCB0byBpbnN0YWxsIA0KICAg ICB0aGVzZSByb3V0ZXMgaW4gdGhlaXIgbWFjaGluZXMuIA0KICAgDQogICAgIFRoZSBmb3Jt YXQgb2YgdGhlIENvbmZpZ3VyZWQgVHVubmVsIEVuZCBQb2ludCBPcHRpb24gaXMgYXMgc2hv d24gDQogICAgIGJlbG93OiANCiAgIA0KDQoNCg0KDQogIFZpamF5LCBQYXJrICAgICAgICAg ICAgICAgICBFeHBpcmVzIE1heSAyMDA0ICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQoM ICAgDQogIEludGVybmV0LURyYWZ0ICAgICBESENQdjYgc3VwcG9ydCBmb3IgSVB2NiBUcmFu c2l0aW9uICAgIE5vdmVtYmVyIDIwMDMgDQogICANCiAgIA0KICAgDQogICANCiAgICAgICAg IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMgDQogICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgDQogICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0K ICAgICAgICB8ICAgICAgICAgICBPUFRJT05fQ1RFUCAgICAgICAgICAgfCAgICAgICAgIG9w dGlvbi1sZW4gICAgICAgICAgfCANCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgIHwg ICAgcHJlZml4LWxlbiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg DQogICAgICAgIHwgICAgICAgICAgICAgICAgIERlc3RpbmF0aW9uIFByZWZpeCAoMTYgYnl0 ZXMpICAgICAgICAgICAgICAgICB8IA0KICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAg KyAgICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsgDQogICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCANCiAgICAgICAgfCAgICAgICAgICAgICAgICBDb25maWd1cmVkIFRFUCBBZGRyZXNzICgx NiBieXRlcykgICAgICAgICAgICAgIHwgDQogICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAg ICB8ICAgICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKyANCiAgICAgICAgfCAgICAgICAgICAgICAgICAgfCBwcmVmaXgtbGVu ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICANCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgIHwgICAgICAgICAgICAg ICAgIERlc3RpbmF0aW9uIFByZWZpeCAoMTYgYnl0ZXMpICAgICAgICAgICAgICAgICB8IA0K ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgDQogICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICB8ICAgICAgICAgICAgICAgIENvbmZpZ3VyZWQgVEVQIEFkZHJlc3Mg KDE2IGJ5dGVzKSAgICAgICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLXwgDQogICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgDQogICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgLiAuIC4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgIA0KICAgDQogICAgIG9wdGlv bi1jb2RlOiAgIE9QVElPTl9DVEVQIChUQkQpIA0KICAgDQogICAgIG9wdGlvbi1sZW46IFRv dGFsIGxlbmd0aCBvZiB0aGUgcHJlZml4LWxlbiwgRGVzdGluYXRpb24gUHJlZml4IGFuZCAg DQogICAgICAgICAgICAgICAgIENvbmZpZ3VyZWQgVHVubmVsIEFkZHJlc3MgbGlzdHMgaW4g b2N0ZXRzOyBJdCBzaG91bGQgIA0KICAgICAgICAgICAgICAgICBiZSBhIG11bHRpcGxlIG9m IDMzLiAgDQogICANCiAgICAgcHJlZml4LWxlbjogcHJlZml4IGxlbmd0aCBvZiB0aGUgRGVz dGluYXRpb24gUHJlZml4IA0KICAgDQogICAgIERlc3RpbmF0aW9uIFByZWZpeDogSVB2NiBQ cmVmaXg7IFRoZSBpbml0aWFsIChNU0IpICdwcmVmaXgtbGVuJyAgDQogICAgICAgICAgICAg ICAgIGJ5dGVzIHNob3VsZCBiZSAxIGFuZCByZW1haW5pbmcgYnl0ZXMgc2hvdWxkIGJlIDAu IA0KDQoNCg0KDQogIFZpamF5LCBQYXJrICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAy MDA0ICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQoMICAgDQogIEludGVybmV0LURyYWZ0 ICAgICBESENQdjYgc3VwcG9ydCBmb3IgSVB2NiBUcmFuc2l0aW9uICAgIE5vdmVtYmVyIDIw MDMgDQogICANCiAgIA0KICAgDQogICAgIENvbmZpZ3VyZWQgVEVQIEFkZHJlc3M6ICBJUHY2 IEFkZHJlc3Mgb2YgdGhlIENvbmZpZ3VyZWQgVEVQLiAgDQogICANCiAgICAgVGhlIGNsaWVu dHMgYXJlIGV4cGVjdGVkIHRvIGluc3RhbGwgdGhlIHJvdXRlcyBpZGVudGlmaWVkIGJ5IHRo ZSANCiAgICAgdHVwbGVzIDxEZXN0aW5hdGlvbiBQcmVmaXgvcHJlZml4LWxlbiwgQ29uZmln dXJlZCBURVAgQWRkcmVzcz4gaW4gDQogICAgIHRoZWlyIG1hY2hpbmVzIG9uY2UgdGhleSBy ZWNlaXZlIHRoaXMgb3B0aW9uIGZyb20gdGhlIHNlcnZlci4gDQogICANCiAgIA0KICA1LiBJ ZGVudGl0eSBBc3NvY2lhdGlvbiBmb3IgNnRvNCBBZGRyZXNzZXMgT3B0aW9uIChJQV82VE80 KSANCiAgIA0KICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW5vdGhlciBvcHRpb24gY2Fs bGVkIElkZW50aXR5IEFzc29jaWF0aW9uIGZvciANCiAgICAgNnRvNCBbM10gYWRkcmVzc2Vz IChJQV82VE80KS4gIFRoaXMgb3B0aW9uIGNhcnJpZXMgcGFyYW1ldGVycyANCiAgICAgYXNz b2NpYXRlZCB3aXRoIElBXzZUTzQgYW5kIDZ0bzQgYWRkcmVzc2VzIGFzc29jaWF0ZWQgd2l0 aCB0aGUgDQogICAgIElBXzZUTzQuIA0KICAgDQogICANCiAgICAgICAgMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyANCiAg ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgIHwgICAgICAg IE9QVElPTl9JQV82VE80ICAgICAgICAgfCAgICAgICAgICBvcHRpb24tbGVuICAgICAgICAg ICB8IA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICBJQUlEICg0IG9jdGV0cykgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rIA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBU MSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r IA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUMiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgIC4gICAgICAgICAgICAgICAgICAgICAgIElBXzZUTzQtb3B0 aW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAuIA0KICAgICAgIC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuIA0K ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rIA0KICAgDQogICAgIG9wdGlvbi1jb2RlICAgICAgIE9QVElP Tl9JQV82VE80ICAoVEJEKSANCiAgIA0KICAgICBvcHRpb24tbGVuICAgICAgICAxMiArIGxl bmd0aCBvZiBJQV82VE80LW9wdGlvbnMgZmllbGQgDQogICANCiAgICAgSUFJRCAgICAgICAg ICAgICAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGlzIElBXzZUTzQ7IHRoZSBJQUlE IA0KICAgICAgICAgICAgICAgICAgICAgICBtdXN0IGJlIHVuaXF1ZSBhbW9uZyB0aGUgaWRl bnRpZmllcnMgZm9yIGFsbCBvZiANCiAgICAgICAgICAgICAgICAgICAgICAgdGhpcyBjbGll bnQncyBJQV82VE80cy4gDQogICANCiAgICAgVDEgICAgICAgICAgICAgICAgVGhlIHRpbWUg YXQgd2hpY2ggdGhlIGNsaWVudCBjb250YWN0cyB0aGUgc2VydmVyICANCiAgICAgICAgICAg ICAgICAgICAgICAgZnJvbSB3aGljaCB0aGUgNnRvNCBhZGRyZXNzZXMgaW4gdGhlIElBXzZU TzQgd2VyZSANCiAgICAgICAgICAgICAgICAgICAgICAgb2J0YWluZWQgdG8gZXh0ZW5kIHRo ZSBsaWZldGltZXMgb2YgdGhlIDZ0bzQgDQogICAgICAgICAgICAgICAgICAgICAgIGFkZHJl c3NlcyBhc3NpZ25lZCB0byB0aGUgSUFfNlRPNDsgVDEgaXMgYSANCiAgICAgICAgICAgICAg ICAgICAgICAgdGltZSBkdXJhdGlvbiByZWxhdGl2ZSB0byB0aGUgY3VycmVudCB0aW1lIA0K DQoNCg0KDQogIFZpamF5LCBQYXJrICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAyMDA0 ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQoMICAgDQogIEludGVybmV0LURyYWZ0ICAg ICBESENQdjYgc3VwcG9ydCBmb3IgSVB2NiBUcmFuc2l0aW9uICAgIE5vdmVtYmVyIDIwMDMg DQogICANCiAgIA0KICAgICAgICAgICAgICAgICAgICAgICBleHByZXNzZWQgaW4gdW5pdHMg b2Ygc2Vjb25kcyANCiAgIA0KICAgICBUMiAgICAgICAgICAgICAgICBUaGUgdGltZSBhdCB3 aGljaCB0aGUgY2xpZW50IGNvbnRhY3RzIGFueSAgDQogICAgICAgICAgICAgICAgICAgICAg IGF2YWlsYWJsZSBzZXJ2ZXIgdG8gZXh0ZW5kIHRoZSBsaWZldGltZXMgb2YgdGhlIA0KICAg ICAgICAgICAgICAgICAgICAgICA2dG80IGFkZHJlc3NlcyBhc3NpZ25lZCB0byB0aGUgSUFf NlRPNDsgVDIgaXMgYSANCiAgICAgICAgICAgICAgICAgICAgICAgdGltZSBkdXJhdGlvbiBy ZWxhdGl2ZSB0byB0aGUgY3VycmVudCB0aW1lIA0KICAgICAgICAgICAgICAgICAgICAgICBl eHByZXNzZWQgaW4gdW5pdHMgb2Ygc2Vjb25kcyANCiAgIA0KICAgICBJQV82VE80LW9wdGlv bnMgICBPcHRpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGlzIElBXzZUTzQuIA0KICAgDQogICAN CiAgIA0KICAgICBUaGUgSUFfNlRPNC1vcHRpb25zIGZpZWxkIGVuY2Fwc3VsYXRlcyB0aG9z ZSBvcHRpb25zIHRoYXQgYXJlIA0KICAgICBzcGVjaWZpYyB0byB0aGlzIElBXzZUTzQuICBG b3IgZXhhbXBsZSwgYWxsIG9mIHRoZSBJQSBBZGRyZXNzIA0KICAgICBPcHRpb25zIGNhcnJ5 aW5nIHRoZSA2dG80IGFkZHJlc3NlcyBhc3NvY2lhdGVkIHdpdGggdGhpcyBJQSBhcmUgaW4g DQogICAgIHRoZSBJQV82VE80LW9wdGlvbnMgZmllbGQuIA0KICAgDQogICAgIFRoZSBjbGll bnRzIGFyZSBleHBlY3RlZCB0byBjb25maWd1cmUgdGhlIGludGVyZmFjZSBmb3Igd2hpY2gg dGhlIA0KICAgICBESENQIFJlcXVlc3Qgd2FzIHNlbnQsIHdpdGggdGhlIDZ0bzQgYWRkcmVz c2VzLiANCiAgIA0KICAgICBBbiBJQV82VE80IG9wdGlvbiBtYXkgb25seSBhcHBlYXIgaW4g dGhlIG9wdGlvbnMgYXJlYSBvZiBhIERIQ1B2NiANCiAgICAgbWVzc2FnZS4gIEEgREhDUHY2 IG1lc3NhZ2UgbWF5IGNvbnRhaW4gbXVsdGlwbGUgSUFfNlRPNCBvcHRpb25zLiANCiAgIA0K ICAgICBUaGUgc3RhdHVzIG9mIGFueSBvcGVyYXRpb25zIGludm9sdmluZyB0aGlzIElBXzZU TzQgaXMgaW5kaWNhdGVkIGluICANCiAgICAgYSBTdGF0dXMgQ29kZSBPcHRpb24gWzFdIGlu IHRoZSBJQV82VE80LW9wdGlvbnMgZmllbGQuIA0KICAgDQogICAgIE5vdGUgdGhhdCBhbiBJ QV82VE80IGhhcyBubyBleHBsaWNpdCAibGlmZXRpbWUiIG9yICJsZWFzZSBsZW5ndGgiIG9m IA0KICAgICBpdHMgb3duLiAgV2hlbiB0aGUgdmFsaWQgbGlmZXRpbWVzIG9mIGFsbCBvZiB0 aGUgNnRvNCBhZGRyZXNzZXMgaW4gDQogICAgIGFuIElBXzZUTzQgaGF2ZSBleHBpcmVkLCB0 aGUgSUFfNlRPNCBjYW4gYmUgY29uc2lkZXJlZCBhcyBoYXZpbmcgDQogICAgIGV4cGlyZWQu ICBUMSBhbmQgVDIgYXJlIGluY2x1ZGVkIHRvIGdpdmUgc2VydmVycyBleHBsaWNpdCBjb250 cm9sIA0KICAgICBvdmVyIHdoZW4gYSBjbGllbnQgcmVjb250YWN0cyB0aGUgc2VydmVyIGFi b3V0IGEgc3BlY2lmaWMgSUFfNlRPNC4gDQogICANCiAgICAgSW4gYSBtZXNzYWdlIHNlbnQg YnkgYSBjbGllbnQgdG8gYSBzZXJ2ZXIsIHZhbHVlcyBpbiB0aGUgVDEgYW5kIFQyIA0KICAg ICBmaWVsZHMgaW5kaWNhdGUgdGhlIGNsaWVudCdzIHByZWZlcmVuY2UgZm9yIHRob3NlIHBh cmFtZXRlcnMuICBUaGUgDQogICAgIGNsaWVudCBzZXRzIFQxIGFuZCBUMiB0byAwIGlmIGl0 IGhhcyBubyBwcmVmZXJlbmNlIGZvciB0aG9zZSB2YWx1ZXMuIA0KICAgICBJbiBhIG1lc3Nh Z2Ugc2VudCBieSBhIHNlcnZlciB0byBhIGNsaWVudCwgdGhlIGNsaWVudCBNVVNUIHVzZSB0 aGUgDQogICAgIHZhbHVlcyBpbiB0aGUgVDEgYW5kIFQyIGZpZWxkcyBmb3IgdGhlIFQxIGFu ZCBUMiBwYXJhbWV0ZXJzLCB1bmxlc3MgDQogICAgIHRob3NlIHZhbHVlcyBpbiB0aG9zZSBm aWVsZHMgYXJlIDAuICBUaGUgdmFsdWVzIGluIHRoZSBUMSBhbmQgVDIgDQogICAgIGZpZWxk cyBhcmUgdGhlIG51bWJlciBvZiBzZWNvbmRzIHVudGlsIFQxIGFuZCBUMi4gDQogICANCiAg ICAgVGhlIHNlcnZlciBzZWxlY3RzIHRoZSBUMSBhbmQgVDIgdGltZXMgdG8gYWxsb3cgdGhl IGNsaWVudCB0byBleHRlbmQgDQogICAgIHRoZSBsaWZldGltZXMgb2YgYW55IDZ0bzQgYWRk cmVzc2VzIGluIHRoZSBJQV82VE80IGJlZm9yZSB0aGUgDQogICAgIGxpZmV0aW1lcyBleHBp cmUsIGV2ZW4gaWYgdGhlIHNlcnZlciBpcyB1bmF2YWlsYWJsZSBmb3Igc29tZSBzaG9ydCAN CiAgICAgcGVyaW9kIG9mIHRpbWUuICBSZWNvbW1lbmRlZCB2YWx1ZXMgZm9yIFQxIGFuZCBU MiBhcmUgLjUgYW5kIC44IA0KICAgICB0aW1lcyB0aGUgc2hvcnRlc3QgcHJlZmVycmVkIGxp ZmV0aW1lIG9mIHRoZSA2dG80IGFkZHJlc3NlcyBpbiB0aGUgDQoNCg0KDQoNCiAgVmlqYXks IFBhcmsgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwMDQgICAgICAgICAgICAgICAg ICBbUGFnZSA1XSANCgwgICANCiAgSW50ZXJuZXQtRHJhZnQgICAgIERIQ1B2NiBzdXBwb3J0 IGZvciBJUHY2IFRyYW5zaXRpb24gICAgTm92ZW1iZXIgMjAwMyANCiAgIA0KICAgDQogICAg IElBLCByZXNwZWN0aXZlbHkuICBJZiB0aGUgdGltZSBhdCB3aGljaCB0aGUgNnRvNCBhZGRy ZXNzZXMgaW4gYW4gDQogICAgIElBXzZUTzQgYXJlIHRvIGJlIHJlbmV3ZWQgaXMgdG8gYmUg bGVmdCB0byB0aGUgZGlzY3JldGlvbiBvZiB0aGUgDQogICAgIGNsaWVudCwgdGhlIHNlcnZl ciBzZXRzIFQxIGFuZCBUMiB0byAwLiANCiAgIA0KICAgDQogIDYuIENsaWVudCBCZWhhdmlv ciANCiAgIA0KICAgICBJZiB0aGUgY2xpZW50J3MgbmV0d29yayBzdXBwb3J0IDZ0bzQgcm91 dGluZyBhbmQgdGhlIGNsaWVudCBpcyANCiAgICAgaW50ZXJlc3RlZCBpbiBjb21tdW5pY2F0 aW5nIHdpdGggdGhlIElQdjYgbm9kZXMgY29ubmVjdGVkIGJ5IDZ0bzQgDQogICAgIHJvdXRl cnMsIGl0IGNhbiBvYnRhaW4gdGhlIDZ0bzQgYWRkcmVzc2VzIGZyb20gdGhlIERIQ1B2NiBz ZXJ2ZXIgDQogICAgIHVzaW5nIElBXzZUTzQgb3B0aW9uLiANCiAgIA0KICAgICBUaGUgSUFf NlRPNCBvcHRpb24gaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBJQV9OQSBbMV0gaW4gYWxsIGFz cGVjdHMgDQogICAgIGV4Y2VwdCBJQV82VE80IGNhcnJ5IDZ0bzQgYWRkcmVzc2VzIGluIGVu Y2Fwc3VsYXRlZCBJQSBhZGRyZXNzIA0KICAgICBvcHRpb24uICBUaGUgcmVxdWVzdCwgcmVu ZXcsIHJlYmluZCwgY29uZmlybSwgcmVsZWFzZSBhbmQgZGVjbGluZSBvZiANCiAgICAgSUFf NlRPNCBpcyBkb25lIGluIHNpbWlsYXIgd2F5IGFzIElBX05BLiAgVGhlIGhhbmRsaW5nIG9m IHRoZSBlcnJvciANCiAgICAgY29kZXMgYXJlIGFsc28gZG9uZSBpbiB0aGUgc2ltaWxhciB3 YXkgYXMgSUFfTkEgWzFdLiANCiAgIA0KICAgDQogIDcuIFNlcnZlciBCZWhhdmlvciANCiAg IA0KICAgICBUaGUgc2VydmVyIFNIT1VMRCBzZWxlY3QgNnRvNCBhZGRyZXNzZXMgZm9yIGFz c2lnbm1lbnQgdG8gSUFfNlRPNCANCiAgICAgYXMgcGVyIHRoZSBtZWNoYW5pc20gc3BlY2lm aWVkIGluIFNlY3Rpb24gMTEgKFNlbGVjdGluZyBBZGRyZXNzZXMgDQogICAgIGZvciBBc3Np Z25tZW50IHRvIGFuIElBKSBzcGVjaWZpZWQgaW4gREhDUHY2IHNwZWNpZmljYXRpb24gWzFd LiANCiAgIA0KICAgICBUaGUgc2VydmVyIFNIT1VMRCBhc3NpZ24gNnRvNCBhZGRyZXNzZXMg dG8gSUFfNlRPNCBvciByZXR1cm4gZXJyb3IgDQogICAgIGNvZGVzIGluIHRoZSB2ZXJ5IHNp bWlsYXIgd2F5IGFzIGZvciBJQV9OQSBbMV0uIA0KICAgDQogICANCiAgOC4gIEFwcGVhcmFu Y2Ugb2YgdGhpcyBvcHRpb24gDQogICANCiAgICAgVGhlIENvbmZpZ3VyZWQgVHVubmVsIEVu ZCBQb2ludCBPcHRpb24gTVVTVCBOT1QgYXBwZWFyIGluIG90aGVyIHRoYW4gDQogICAgIHRo ZSBmb2xsb3dpbmcgbWVzc2FnZXM6IFNvbGljaXQsIEFkdmVydGlzZSwgUmVxdWVzdCwgUmVu ZXcsIFJlYmluZCwgDQogICAgIEluZm9ybWF0aW9uLVJlcXVlc3QgYW5kIFJlcGx5LiANCiAg IA0KICAgICBUaGUgb3B0aW9uIG51bWJlciBvZiBDb25maWd1cmVkIFR1bm5lbCBFbmQgUG9p bnQgb3B0aW9uIE1BWSBhcHBlYXIgDQogICAgIGluIHRoZSBPcHRpb24gUmVxdWVzdCBPcHRp b24gWzFdIGluIHRoZSBmb2xsb3dpbmcgbWVzc2FnZXM6ICBTb2xpY2l0LCANCiAgICAgUmVx dWVzdCwgUmVuZXcsIFJlYmluZCwgSW5mb3JtYXRpb24tUmVxdWVzdCBhbmQgUmVjb25maWd1 cmUuIA0KICAgDQogICAgIFRoZSBJZGVudGl0eSBBc3NvY2lhdGlvbiBmb3IgNnRvNCBhZGRy ZXNzZXMgb3B0aW9uIE1VU1QgTk9UIGFwcGVhciANCiAgICAgaW4gb3RoZXIgdGhhbiB0aGUg Zm9sbG93aW5nIG1lc3NhZ2VzOiAgU29saWNpdCwgQWR2ZXJ0aXNlLCBSZXF1ZXN0LCANCiAg ICAgUmVuZXcsIFJlYmluZCwgQ29uZmlybSBhbmQgUmVwbHkuIA0KICAgDQogICANCiAgOS4g U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQoNCg0KDQoNCiAgVmlqYXksIFBhcmsgICAgICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDIwMDQgICAgICAgICAgICAgICAgICBbUGFnZSA2XSAN CgwgICANCiAgSW50ZXJuZXQtRHJhZnQgICAgIERIQ1B2NiBzdXBwb3J0IGZvciBJUHY2IFRy YW5zaXRpb24gICAgTm92ZW1iZXIgMjAwMyANCiAgIA0KICAgDQogICANCiAgICAgVGhlIENv bmZpZ3VyZWQgVHVubmVsIEVuZCBQb2ludCBPcHRpb24gbWF5IGJlIHVzZWQgYnkgYW4gaW50 cnVkZXIgDQogICAgIERIQ1B2NiBzZXJ2ZXIgdG8gcHJvdmlkZSBpbnZhbGlkIGNvbmZpZ3Vy ZWQgdHVubmVsIGVuZCBwb2ludC4gIFRoaXMgDQogICAgIG1ha2VzIHRoZSBjbGllbnQgdW5h YmxlIHRvIHJlYWNoIGl0cyBkZXN0aW5hdGlvbiBJUHY2IG5vZGUuIA0KICAgDQogICAgIFRo ZSBJZGVudGl0eSBBc3NvY2lhdGlvbiBmb3IgNnRvNCBhZGRyZXNzIG9wdGlvbiBtYXkgYmUg dXNlZCBieSBhbiANCiAgICAgaW50cnVkZXIgREhDUHY2IHNlcnZlciB0byBhbGxvY2F0ZSA2 dG80IGFkZHJlc3NlcyB3aGljaCBtYXkgYmUgDQogICAgIGluY29ycmVjdCBvciBpbmFwcHJv cHJpYXRlIHRvIHRoZSBjbGllbnQncyBsaW5rLiBUaGlzIHdpbGwgcmVzdWx0IA0KICAgICBp biB0aGUgY2xpZW50IHVuYWJsZSB0byBjb21tdW5pY2F0ZSB0byB0aGUgSVB2NiBub2RlcyBj b25uZWN0ZWQgDQogICAgIHRocm91Z2ggNnRvNCByb3V0ZXJzLiANCiAgIA0KICAgICBUbyBh dm9pZCBhdHRhY2tzIHRocm91Z2ggdGhpcyBvcHRpb24sIHRoZSBESENQdjYgY2xpZW50IFNI T1VMRCB1c2UgIA0KICAgICBhdXRoZW50aWNhdGVkIERIQ1AgKHNlZSBzZWN0aW9uICJBdXRo ZW50aWNhdGlvbiBvZiBESENQIG1lc3NhZ2VzIiAgDQogICAgIGluIHRoZSBESENQdjYgc3Bl Y2lmaWNhdGlvbiBbMV0pLiANCiAgIA0KICAgDQogIDEwLiBJQU5BIENvbnNpZGVyYXRpb25z IA0KICAgDQogICAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzc2lnbiBhbiBvcHRpb24gY29k ZSB0byB0aGUgZm9sbG93aW5nIG9wdGlvbnMgDQogICAgIGZyb20gdGhlIG9wdGlvbi1jb2Rl IHNwYWNlIGRlZmluZWQgaW4gIkRIQ1B2NiBPcHRpb25zIiBzZWN0aW9uIG9mIA0KICAgICB0 aGUgREhDUHY2IHNwZWNpZmljYXRpb24gWzFdLiANCiAgIA0KICAgICAgICBPcHRpb24gTmFt ZSAgICAgICAgICAgIFZhbHVlICAgICBEZXNjcmliZWQgaW4gDQogICAgICAgIE9QVElPTl9D VEVQICAgICAgICAgICAgVEJEICAgICAgIFNlY3Rpb24gNCANCiAgICAgICAgT1BUSU9OX0lB XzZUTzQgICAgICAgICBUQkQgICAgICAgU2VjdGlvbiA0IA0KICAgDQogICANCiAgMTEuIE5v cm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgDQogICAgIFsxXSAgQm91bmQsIEouLCBDYXJuZXks IE0uLCBQZXJraW5zLCBDLiwgTGVtb24sIFQuLCBWb2x6LCBCLiBhbmQgUi4gDQogICAgICAg ICAgRHJvbXMgKGVkLiksICJEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBm b3IgSVB2NiANCiAgICAgICAgICAoREhDUHY2KSIsIFJGQyAzMzE1LCBKdWx5IDIwMDMuIA0K ICAgDQogICANCiAgMTIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgDQogICANCiAgICAgWzJd ICBSLiBHaWxsaWdhbiwgRS4gTm9yZG1hcmssICJUcmFuc2l0aW9uIE1lY2hhbmlzbXMgZm9y IElQdjYgSG9zdHMgIA0KICAgICAgICAgIGFuZCBSb3V0ZXJzIiwgUkZDIDI4OTMsICBBdWd1 c3QgMjAwMC4gDQogICANCiAgICAgWzNdICBCLiBDYXJwZW50ZXIsIEsuIE1vb3JlLCAiQ29u bmVjdGlvbiBvZiBJUHY2IERvbWFpbnMgdmlhIElQdjQgIA0KICAgICAgICAgIENsb3VkcyIs IFJGQyAzMDU2LCBGZWJydWFyeSAyMDAxLiAgDQogICANCiAgICAgWzRdICBCcmFkbmVyLCBT LiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQg DQogICAgICAgICAgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4gDQog ICANCg0KDQoNCg0KICBWaWpheSwgUGFyayAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkg MjAwNCAgICAgICAgICAgICAgICAgIFtQYWdlIDddIA0KDCAgIA0KICBJbnRlcm5ldC1EcmFm dCAgICAgREhDUHY2IHN1cHBvcnQgZm9yIElQdjYgVHJhbnNpdGlvbiAgICBOb3ZlbWJlciAy MDAzIA0KICAgDQogICANCiAgIA0KICBBdXRob3JzJyBBZGRyZXNzZXMgDQogICANCiAgICAg VmlqYXlhYmhhc2thciBBIEsgDQogICAgIEhld2xldHQtUGFja2FyZCBTVFNELUkgDQogICAg IDI5LCBDdW5uaW5naGFtIFJvYWQgDQogICAgIEJhbmdhbG9yZSAtIDU2MDA1MiANCiAgICAg SW5kaWEgDQogICANCiAgICAgUGhvbmU6ICs5MS04MC0yMDUzMDg1IA0KICAgICBFLU1haWw6 IHZpamF5YWtAaW5kaWEuaHAuY29tIA0KICAgDQogICAgIFNvb2hvbmcgRGFuaWVsIFBhcmsg DQogICAgIE1vYmlsZSBQbGF0Zm9ybSBMYWJvcmF0b3J5LCBTQU1TVU5HIEVsZWN0cm9uaWNz LiANCiAgICAgNDE2LiBNYWV0YW4tRG9uZywgUGFsZGFsLUd1LCANCiAgICAgU3V3b24sIEd5 ZW9uZ2dpLURvIA0KICAgICBLb3JlYSANCiAgIA0KICAgICBQaG9uZTogKzgxLTMxLTIwMC00 NTA4IA0KICAgICBFLU1haWw6IHNvb2hvbmcucGFya0BzYW1zdW5nLmNvbSANCiAgIA0KICAg DQogIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudCANCiAgIA0KICAgICBDb3B5cmlnaHQgKEMp IFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAzKS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIA0K ICAgDQogICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUg Y29waWVkIGFuZCBmdXJuaXNoZWQgdG8gDQogICAgIG90aGVycywgYW5kIGRlcml2YXRpdmUg d29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBleHBsYWluIGl0IA0KICAgICBv ciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVk LCBwdWJsaXNoZWQgDQogICAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFy dCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkgDQogICAgIGtpbmQsIHByb3ZpZGVkIHRo YXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIA0KICAg ICBhcmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtz LiAgSG93ZXZlciwgdGhpcyANCiAgICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9k aWZpZWQgaW4gYW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZyANCiAgICAgdGhlIGNvcHly aWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBv dGhlciANCiAgICAgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBm b3IgdGhlIHB1cnBvc2Ugb2YgDQogICAgIGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRz IGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIA0KICAgICBjb3B5cmlnaHRzIGRl ZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11c3QgYmUgDQogICAg IGZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFn ZXMgb3RoZXIgdGhhbiANCiAgICAgRW5nbGlzaC4gDQogICANCiAgICAgVGhlIGxpbWl0ZWQg cGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBi ZSANCiAgICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vz c29ycyBvciBhc3NpZ25zLiANCiAgIA0KICAgICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbiANCiAgICAgIkFT IElTIiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBF TkdJTkVFUklORyANCg0KDQoNCg0KICBWaWpheSwgUGFyayAgICAgICAgICAgICAgICAgRXhw aXJlcyBNYXkgMjAwNCAgICAgICAgICAgICAgICAgIFtQYWdlIDhdIA0KDCAgIA0KICBJbnRl cm5ldC1EcmFmdCAgICAgREhDUHY2IHN1cHBvcnQgZm9yIElQdjYgVHJhbnNpdGlvbiAgICBO b3ZlbWJlciAyMDAzIA0KICAgDQogICANCiAgICAgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxM IFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgSU5DTFVESU5HIA0KICAgICBCVVQg Tk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JN QVRJT04gDQogICAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFO WSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQogICAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gDQogICANCiAgQWNrbm93bGVkZ2VtZW50 IA0KICAgDQogICAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1 cnJlbnRseSBwcm92aWRlZCBieSB0aGUgDQogICAgIEludGVybmV0IFNvY2lldHkuIFRoZSBp ZGVhIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBiYXNlZCBvbiANCiAgICAgUkZDIDI5Mzcs IFNlcHRlbWJlciAyMDAwLiANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgVmlqYXksIFBh cmsgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwMDQgICAgICAgICAgICAgICAgICBb UGFnZSA5XSA= --Boundary_(ID_tAryJ7adXMSeHjAiLPCy+A)-- From owner-v6ops@ops.ietf.org Mon Nov 3 08:08:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00458 for ; Mon, 3 Nov 2003 08:08:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGeMo-000Pxw-PU for v6ops-data@psg.com; Mon, 03 Nov 2003 13:03:34 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGeMc-000PxS-3v for v6ops@ops.ietf.org; Mon, 03 Nov 2003 13:03:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA3D3KM31939; Mon, 3 Nov 2003 15:03:20 +0200 Date: Mon, 3 Nov 2003 15:03:20 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: bob@thefinks.com, Subject: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, This is a WG Last Call for comments on sending draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms for IPv6 Hosts and Routers", to the IESG for consideration as Proposed Standard: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt (We're hoping to recycle to Draft Standard soon afterwards.) Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be sent to the IESG. The last call will end in about 3 weeks, on 25th November. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Mon Nov 3 09:45:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03995 for ; Mon, 3 Nov 2003 09:45:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGftz-0004KW-OS for v6ops-data@psg.com; Mon, 03 Nov 2003 14:41:55 +0000 Received: from [160.36.56.50] (helo=klutz.cs.utk.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGftn-0004Jv-2f for v6ops@ops.ietf.org; Mon, 03 Nov 2003 14:41:43 +0000 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B4D35142C0; Mon, 3 Nov 2003 09:41:42 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21296-07; Mon, 3 Nov 2003 09:41:41 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id D7E3B142B4; Mon, 3 Nov 2003 09:41:40 -0500 (EST) Date: Mon, 3 Nov 2003 08:36:50 -0500 From: Keith Moore To: Pekka Savola Cc: moore@cs.utk.edu, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031103083650.67297afd.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Having looked at this again, I'm firmly convinced that: - if address family is set to AF_UNSPEC, getaddrinfo() should by default attempt both IPv4 and IPv6 lookups - even if the local system is not capable of communicating on both IPv4 and IPv6. it can be useful to do A lookups even if the local system doesn't support IPv4, and it can be useful to do AAAA lookups even if the local system doesn't support IPv6. the job of an API is to do what the application tells it to do, not to guess what the application needs. when getaddrinfo() tries to be too clever (as it does on some platforms) it gets in the way and makes it difficult just to do simple DNS lookups. this implies that a feature to avoid A or AAAA lookups on systems that cannot communicate on v4 or v6 (respectively) should be optional, as AI_ADDRCONFIG is. - It's highly desirable to avoid unnecessary DNS queries. DNS is too slow and unreliable for single queries; multiple queries only makes this worse. There are various ways that DNS could be updated to return the same information in fewer round-trips, but none of them would obviate the need for hosts to do multiple concurrent queries in the near term. - AI_ADDRCONFIG is an imperfect heuristic, not a reliable indicator of whether an address can be used. that doesn't mean that it's useless, but it does mean that people need to be aware of its limitations and not rely on it to do magic - in particular, it will not do a perfect job of either avoiding unnecessary lookups and connection attempts, or (due to race conditions) of finding all usable addresses. - getaddrinfo SHOULD ONLY DO DNS QUERIES. LLMNR/mDNS, NIS/NIS+, netinfo, WINS and local file lookups only serve to cause divergence between platforms and problems for apps that need a consistent view of DNS. (Note: I don't expect to get consensus for this view, so I'll offer a less radical view: Apps whose behavior is defined based on "what DNS says", rather than some other name lookup service, need a portable and reliable way to find out "what DNS says" without having to supply their own DNS lookup routines. e.g. maybe there needs to be a AI_DNS_ONLY flag for getaddrinfo?) - if AI_ADDRCONFIG is set, the decision of whether to do DNS lookups for a particular address family should ignore link-local addresses as well as loopback addresses. This is in keeping with the notion that AI_ADDRCONFIG is an imperfect heuristic. The configuration of only link-local addresses for a particular address family is a good (though imperfect) indicator that DNS queries for that address family will not yield usable results. OTOH, if getaddrinfo() is set up (against my better judgement) to do queries from services other than DNS, the choice of whether to query other services might not want to ignore link-local addresses. For example, on a host with only a v4 link-local address configured it might make sense to query LLMNR for A records. - IMHO, getaddrinfo()'s job should be to report what is in DNS, not to try to coerce apps into behaving well. So even though apps shouldn't be using link-local addresses, and even though people shouldn't list link-local addresses in DNS, getaddrinfo() should not try to hide such addresses from apps if they happen to appear in DNS. Keith From owner-v6ops@ops.ietf.org Mon Nov 3 10:21:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06634 for ; Mon, 3 Nov 2003 10:21:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGgSC-00065c-70 for v6ops-data@psg.com; Mon, 03 Nov 2003 15:17:16 +0000 Received: from [2001:700:1:4:202:55ff:fe67:bc18] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGgRz-000650-Fp for v6ops@ops.ietf.org; Mon, 03 Nov 2003 15:17:03 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id hA3FGQpI032667; Mon, 3 Nov 2003 16:16:26 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hA3FGQR7021499; Mon, 3 Nov 2003 16:16:26 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hA3FGQDI021498; Mon, 3 Nov 2003 16:16:26 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 3 Nov 2003 16:16:26 +0100 From: Stig Venaas To: Keith Moore Cc: Pekka Savola , v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031103151626.GB21430@sverresborg.uninett.no> References: <20031103083650.67297afd.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031103083650.67297afd.moore@cs.utk.edu> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [...] > - IMHO, getaddrinfo()'s job should be to report what is in DNS, not to try to > coerce apps into behaving well. So even though apps shouldn't be using > link-local addresses, and even though people shouldn't list link-local > addresses in DNS, getaddrinfo() should not try to hide such addresses from > apps if they happen to appear in DNS. I can sympathize with your opinions. I think two things are needed: o A standard call that most applications can use in a simple way. IMHO it should query DNS, other name services, /etc/hosts etc. o A standard call that applications can use to check what is in DNS The first should IMHO be something like getaddrinfo() where applications simply try the addresses in the order they are returned. I also think it should be possible for an administrator to define which name services should be used, which type of addresses should be returned, and the order. Another matter is what the API should be. Most IPv6 enabled applications today use getaddrinfo(), while specialized DNS applications like "host" use their own resolver routines. So I would say that getaddrinfo() without special arguments would be good for the general applications. For the DNS applications one could use getaddrinfo() with a new option, or a completely new call. It's easier to change the few DNS applications that are out there. Stig From owner-v6ops@ops.ietf.org Mon Nov 3 10:51:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07845 for ; Mon, 3 Nov 2003 10:51:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGgtT-0007Kn-5r for v6ops-data@psg.com; Mon, 03 Nov 2003 15:45:27 +0000 Received: from [160.36.56.50] (helo=klutz.cs.utk.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGgtG-0007JZ-Rw for v6ops@ops.ietf.org; Mon, 03 Nov 2003 15:45:14 +0000 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5F1AF142D6; Mon, 3 Nov 2003 10:45:14 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29204-03; Mon, 3 Nov 2003 10:45:13 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id BF92214240; Mon, 3 Nov 2003 10:45:12 -0500 (EST) Date: Mon, 3 Nov 2003 10:42:02 -0500 From: Keith Moore To: Stig Venaas Cc: moore@cs.utk.edu, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031103104202.08e7a1a3.moore@cs.utk.edu> In-Reply-To: <20031103151626.GB21430@sverresborg.uninett.no> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > [...] > > - IMHO, getaddrinfo()'s job should be to report what is in DNS, not > > to try to > > coerce apps into behaving well. So even though apps shouldn't be > > using link-local addresses, and even though people shouldn't list > > link-local addresses in DNS, getaddrinfo() should not try to hide > > such addresses from apps if they happen to appear in DNS. > > I can sympathize with your opinions. I think two things are needed: > > o A standard call that most applications can use in a simple way. IMHO > it should query DNS, other name services, /etc/hosts etc. > > o A standard call that applications can use to check what is in DNS > > The first should IMHO be something like getaddrinfo() where > applications simply try the addresses in the order they are returned. I don't think that we should be defining getaddrinfo() in terms of "whatever lookup service happens to be around" because it's very difficult to get reliable and repeatable behavior that way. > I also think it > should be possible for an administrator to define which name services > should be used, which type of addresses should be returned, and the > order. I disagree. Different apps have different needs, and no single host-wide or site-wide policy can accomodate the needs of the variety of apps in use. Also, apps often cross administrative boundaries, which creates problems when different nodes of those apps are subjected to the whims of different administrators. > Another matter is what the API should be. Most IPv6 enabled > applications today use getaddrinfo(), while specialized DNS > applications like "host" use their own resolver routines. It's not just specalized DNS applications that need to know what really is in DNS. Many apps need consistent views of DNS without having to second-guess the local host API implementation, brain-damaged sysadmins, etc. Keith From owner-v6ops@ops.ietf.org Mon Nov 3 12:10:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10946 for ; Mon, 3 Nov 2003 12:10:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGiAL-000BKE-Ls for v6ops-data@psg.com; Mon, 03 Nov 2003 17:06:57 +0000 Received: from [2002:d40d:c798::1] (helo=castlerea.stdlib.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGiA7-000BJ4-2h for v6ops@ops.ietf.org; Mon, 03 Nov 2003 17:06:43 +0000 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.20) id 1AGi9V-0006Ns-Mr; Mon, 03 Nov 2003 17:06:05 +0000 Date: Mon, 3 Nov 2003 17:06:05 +0000 From: Colm MacCarthaigh To: Keith Moore Cc: Stig Venaas , pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031103170605.GA24355@castlerea.stdlib.net.> Reply-To: colm@stdlib.net References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20031103104202.08e7a1a3.moore@cs.utk.edu> User-Agent: Mutt/1.3.28i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > I don't think that we should be defining getaddrinfo() in terms of > "whatever lookup service happens to be around" because it's very > difficult to get reliable and repeatable behavior that way. Isn't the DNS a lookup service that happens to be around ? The purpose of getaddrinfo is to perform network address and service translation. Whilst a portable, granular, interface to DNS would be very much welcome - getaddrinfo should not be it. > > I also think it > > should be possible for an administrator to define which name services > > should be used, which type of addresses should be returned, and the > > order. > > I disagree. Different apps have different needs, and no single > host-wide or site-wide policy can accomodate the needs of the variety of > apps in use. A large ammount of apps have common needs; a very common need is to translate network and service names into numbers. The vast majority of these apps should not care whether it comes from lookupd/nscd, a hosts file, dns, WINS or another source. > Also, apps often cross administrative boundaries, which > creates problems when different nodes of those apps are subjected to the > whims of different administrators. Indeed, but to remove responsibility from administrators is to remove power from administrators. Many administrators cherish and understand their ability to define a search-order, over-ride domains, cache lookups. Others misunderstand and abuse these facilities, but the primary fault lies with those administrators - not elsewhere. Resolving only DNS would even hinder an administrators ability to fix these problems. Many sites have RFC1918 bogons in their zones (forward and reverse), some even listed as MX. It can ocasionally be useful to over-ride such sillyness locally. I'm not saying administrators should have to work around other's problems, de-incentivising the need to really fix them, but ocasionally we do. > It's not just specalized DNS applications that need to know what really > is in DNS. I would argue that really only an application with specialised DNS functionality (for instance an SMTP implementation) needs to know what really is in DNS. Certainly more applications than host/dig and so on need to know what's really is in DNS, but I don't think the term "specialised" is unsuited. A the issue of link-locals in DNS, I agree that they should be returned by getaddrinfo, for the same reason I cite below. > Many apps need consistent views of DNS without having to > second-guess the local host API implementation, brain-damaged sysadmins, > etc. Whilst it's extremely desirable that apps not have to deal with API implementation inconsistency, the application writers sense of priorities should come much lower than the local administrators IMO. -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net From owner-v6ops@ops.ietf.org Mon Nov 3 17:49:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00374 for ; Mon, 3 Nov 2003 17:49:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGnS5-0002uu-Kx for v6ops-data@psg.com; Mon, 03 Nov 2003 22:45:37 +0000 Received: from [2002:d40d:c798::1] (helo=castlerea.stdlib.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGnRq-0002u0-It for v6ops@ops.ietf.org; Mon, 03 Nov 2003 22:45:22 +0000 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.20) id 1AGnO7-000733-5s; Mon, 03 Nov 2003 22:41:31 +0000 Date: Mon, 3 Nov 2003 22:41:31 +0000 From: Colm MacCarthaigh To: Keith Moore Cc: Stig.Venaas@uninett.no, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031103224131.GA26982@castlerea.stdlib.net.> Reply-To: colm@stdlib.net References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20031103162255.61563fcb.moore@cs.utk.edu> User-Agent: Mutt/1.3.28i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, Nov 03, 2003 at 04:22:55PM -0500, Keith Moore wrote: > > On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > > > I don't think that we should be defining getaddrinfo() in terms of > > > "whatever lookup service happens to be around" because it's very > > > difficult to get reliable and repeatable behavior that way. > > > > Isn't the DNS a lookup service that happens to be around ? > > DNS is a specific lookup service. not a random one that just might happen > to be around. NIS is a specific lookup service, as is WINS, and well I could go on ... DNS may be more standardised, more widely-deployed and frankly - more tasteful, but it is no more specific. It's not the only show in town :) I don't mean to be facetious here, of course I regard DNS as the "standard" name to number resolver, but I'm a long long way from thinking it should be the only means allowed for applications to resolve names. > > The purpose of getaddrinfo is to perform network address and service > > translation. Whilst a portable, granular, interface to DNS would be > > very much welcome - getaddrinfo should not be it. > > Perhaps. But if getaddrinfo isn't the service that does DNS lookups, > then at least some apps should not be using it. Could you give some specific examples of the type of apps you're talking about? > > A large ammount of apps have common needs; a very common need is to > > translate network and service names into numbers. The vast majority > > of these apps should not care whether it comes from lookupd/nscd, a > > hosts file, dns, WINS or another source. > > That's simply insane. > > Apps (and users) often care if the results from whatever lookup service > getaddrinfo/gethostname happens to use are not consistent with reality. When you say "reality", do you really mean - "DNS"? If so, what makes DNS more authorative than the decisions of the local administrator ? What about site to site inconsistencies in DNS ? I don't think many people would argue that Global DNS names should be broken by local administrators. But is making that slightly harder worth heavily impairing their ability to have site-local name resolution? > Apps sometimes care if the results of those lookups at different points > in the network are not consistent with one another. Certainly, but since this can (and frequently does) happen with DNS on its own, surely the problem should be resolved more generally? I don't see how the problem of distributed applications needing to agree on a network number is solved by only using DNS to resolve network names. > People are often claiming that apps should not use IP addresses for > referrals - that they should use DNS names instead. Indeed, it would > be nice for apps to be able to do that, but that would imply (among > other things) that a name means the same thing from all points of > the application - NOT whatever some random lookup service or stale > host file happens to return to a particular host. I disagree. And there are many examples of when people consider it useful for domains to return inconsistent results. Many end-users wish to blackhole the domains of web-banner advertiser; integral to many testing and staging procedures is the ability to spoof production domains; users of RFC1918 space frequently wish to resolve to different addresses depending on scope. Whilst all of this is possible with control over a resolving name-server (assuming there is one), it very much removes power from the administrator which they find useful. > Every additional oracle that attempts to provide name to address translation > is another potential source of variation and error. Every additional > configuration knob that attempts to choose which source of name lookup should > be used (whether it be an API, a config file, or a DHCP option) is yet > another knob that can be set wrong. All of this garbage makes applications > that ought to be portable from one host to another and one network to another, > overly sensitive to host and site configuration. It causes bugs that are often > difficult to troubleshoot. Agreed, however I view the alternative as worse. I've been involved in the IPv6 development of widely-deployed applications, and have experience dealing with obsure user problems, extremely tenous getaddrinfo bugs and other such madness, and I can't think of many such problems occuring. On the other hand, I've been saved by the ability to quickly over-ride local name resolution more than once. > > > Also, apps often cross administrative boundaries, which > > > creates problems when different nodes of those apps are subjected to the > > > whims of different administrators. > > > > Indeed, but to remove responsibility from administrators is to remove > > power from administrators. > > It removes the power to screw things up. I don't see this as a bad thing. > > Administrators can already set the meanings of DNS names in the zones that > they control. Why do they need multiple ways to screw things up ? Because local administrators arn't always in control of their DNS names. All that would happen is that more local administrators would run local DNS resolvers. It just gets you right back to square one :) > > I would argue that really only an application with specialised DNS > > functionality (for instance an SMTP implementation) needs to know what > > really is in DNS. > > You're wrong, of course. Could you provide an example ? Personally I consider lookup-agnosticism as a good feature of getaddrinfo. It will take a lot to persuade me otherwise. "really in DNS" and "globally consistent" are not equatable statements, because well ... they're not. Unless you're arguing for a global short-list of resolvers ? The problems seen with name-resolsution inconsistency are the result of stupid operators - they arn't going to go away. They're just going to be stupid with DNS instead :) > Quite often local administrators forget that their purpose is to support > users, that those users need to run apps, and that for the apps to run > reliably they need a reliable and predictable environment. Totally, but it is not for an API to dictate to local administrators how best to achieve this. Extra lookup methods can be part of providing a more reliable and predictable environment. -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net From owner-v6ops@ops.ietf.org Mon Nov 3 18:39:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03815 for ; Mon, 3 Nov 2003 18:39:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGoFL-0005Lh-Rj for v6ops-data@psg.com; Mon, 03 Nov 2003 23:36:31 +0000 Received: from [160.36.56.50] (helo=klutz.cs.utk.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGoF8-0005L5-Hc for v6ops@ops.ietf.org; Mon, 03 Nov 2003 23:36:18 +0000 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 28A791417F; Mon, 3 Nov 2003 16:26:10 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11783-09; Mon, 3 Nov 2003 16:26:08 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0B05F1409E; Mon, 3 Nov 2003 16:26:08 -0500 (EST) Date: Mon, 3 Nov 2003 16:22:55 -0500 From: Keith Moore To: colm@stdlib.net Cc: moore@cs.utk.edu, Stig.Venaas@uninett.no, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031103162255.61563fcb.moore@cs.utk.edu> In-Reply-To: <20031103170605.GA24355@castlerea.stdlib.net.> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > > I don't think that we should be defining getaddrinfo() in terms of > > "whatever lookup service happens to be around" because it's very > > difficult to get reliable and repeatable behavior that way. > > Isn't the DNS a lookup service that happens to be around ? DNS is a specific lookup service. not a random one that just might happen to be around. > The purpose of getaddrinfo is to perform network address and service > translation. Whilst a portable, granular, interface to DNS would be > very much welcome - getaddrinfo should not be it. Perhaps. But if getaddrinfo isn't the service that does DNS lookups, then at least some apps should not be using it. > > > I also think it > > > should be possible for an administrator to define which name services > > > should be used, which type of addresses should be returned, and the > > > order. > > > > I disagree. Different apps have different needs, and no single > > host-wide or site-wide policy can accomodate the needs of the variety of > > apps in use. > > A large ammount of apps have common needs; a very common need is to > translate network and service names into numbers. The vast majority > of these apps should not care whether it comes from lookupd/nscd, a > hosts file, dns, WINS or another source. That's simply insane. Apps (and users) often care if the results from whatever lookup service getaddrinfo/gethostname happens to use are not consistent with reality. Apps sometimes care if the results of those lookups at different points in the network are not consistent with one another. People are often claiming that apps should not use IP addresses for referrals - that they should use DNS names instead. Indeed, it would be nice for apps to be able to do that, but that would imply (among other things) that a name means the same thing from all points of the application - NOT whatever some random lookup service or stale host file happens to return to a particular host. Every additional oracle that attempts to provide name to address translation is another potential source of variation and error. Every additional configuration knob that attempts to choose which source of name lookup should be used (whether it be an API, a config file, or a DHCP option) is yet another knob that can be set wrong. All of this garbage makes applications that ought to be portable from one host to another and one network to another, overly sensitive to host and site configuration. It causes bugs that are often difficult to troubleshoot. > > Also, apps often cross administrative boundaries, which > > creates problems when different nodes of those apps are subjected to the > > whims of different administrators. > > Indeed, but to remove responsibility from administrators is to remove > power from administrators. It removes the power to screw things up. I don't see this as a bad thing. Administrators can already set the meanings of DNS names in the zones that they control. Why do they need multiple ways to screw things up ? > Many administrators cherish and understand > their ability to define a search-order, over-ride domains, cache lookups. And many administrators should be terminated with extreme prejudice, too. > Resolving only DNS would even hinder an administrators ability to fix > these problems. Many sites have RFC1918 bogons in their zones (forward > and reverse), some even listed as MX. It can ocasionally be useful to > over-ride such sillyness locally. I'm not saying administrators should > have to work around other's problems, de-incentivising the need to really > fix them, but ocasionally we do. Okay, fine. Maybe admins need a way to work around occasional problems that occur. But we don't need a hodgepodge of different lookup methods and APIs and configuration mechanisms that interact with each other in arbitrary ways that vary from one host or site to another. > > It's not just specalized DNS applications that need to know what really > > is in DNS. > > I would argue that really only an application with specialised DNS > functionality (for instance an SMTP implementation) needs to know what > really is in DNS. You're wrong, of course. > A the issue of link-locals in DNS, I agree that they should be returned > by getaddrinfo, for the same reason I cite below. Well, link-local addresses should never be in DNS in the first place. My argument is not that link-local addresses should be returned by getaddrinfo() , it is that getaddrinfo() should be transparent. It shouldn't be yet another layer (in addition to all of the ones mentioned above) that is getting in the way of the app finding out what the DNS name means. > > Many apps need consistent views of DNS without having to > > second-guess the local host API implementation, brain-damaged sysadmins, > > etc. > > Whilst it's extremely desirable that apps not have to deal with API > implementation inconsistency, the application writers sense of priorities > should come much lower than the local administrators IMO. Quite often local administrators forget that their purpose is to support users, that those users need to run apps, and that for the apps to run reliably they need a reliable and predictable environment. Keith From owner-v6ops@ops.ietf.org Tue Nov 4 02:08:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27165 for ; Tue, 4 Nov 2003 02:08:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGvDt-000Ncr-Pl for v6ops-data@psg.com; Tue, 04 Nov 2003 07:03:29 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGvDf-000Ncb-A0 for v6ops@ops.ietf.org; Tue, 04 Nov 2003 07:03:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA46qPn19249; Tue, 4 Nov 2003 08:52:25 +0200 Date: Tue, 4 Nov 2003 08:52:24 +0200 (EET) From: Pekka Savola To: Colm MacCarthaigh cc: Keith Moore , , , Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031103224131.GA26982@castlerea.stdlib.net.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 3 Nov 2003, Colm MacCarthaigh wrote: > > DNS is a specific lookup service. not a random one that just might happen > > to be around. > > NIS is a specific lookup service, as is WINS, and well I could go on ... > DNS may be more standardised, more widely-deployed and frankly - more > tasteful, but it is no more specific. It's not the only show in town :) > > I don't mean to be facetious here, of course I regard DNS as the "standard" > name to number resolver, but I'm a long long way from thinking it should > be the only means allowed for applications to resolve names. My personal experience is that the lookup mechanisms are rarely fully equivalent/replaceable. They give different kinds of results. /etc/hosts and DNS are (typically) pretty close to each other, but if you pluck in e.g. WINS, the names it'll give you are typically entirely different (starting from the format) from those learned from DNS. I'd expect similar inconsistancies if queries were done using LLMNR or ICMP Node Information Queries. The important point here is who configures the names to be looked up. Looking them up e.g. in LDAP would probably yield similar results than lookup up from the DNS (as they're very probably configured by the same entity) -- but asking from the node itself what it thinks its name is is *very* likely to yield different results than one would get asking his network administrator.. I think typically we have been interested of the latter, that is, what the network administrator of a node thinks a node's name is (and NOT what the node or its user thinks!) -- 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 Nov 4 03:32:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03611 for ; Tue, 4 Nov 2003 03:32:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGwYI-0001Bg-BO for v6ops-data@psg.com; Tue, 04 Nov 2003 08:28:38 +0000 Received: from [193.6.222.240] (helo=mignon.ki.iif.hu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGwY5-0001AH-8g for v6ops@ops.ietf.org; Tue, 04 Nov 2003 08:28:25 +0000 Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id 2655B6DBF; Tue, 4 Nov 2003 09:28:24 +0100 (CET) Received: from mignon.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74217-01-3; Tue, 4 Nov 2003 09:28:18 +0100 (CET) Received: by mignon.ki.iif.hu (Postfix, from userid 1003) id 001CB6E46; Tue, 4 Nov 2003 09:28:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id F20776E06; Tue, 4 Nov 2003 09:28:17 +0100 (CET) Date: Tue, 4 Nov 2003 09:28:17 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Keith Moore Cc: colm@stdlib.net, Stig Venaas , pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031103162255.61563fcb.moore@cs.utk.edu> Message-ID: <20031104085701.X37922@mignon.ki.iif.hu> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 3 Nov 2003, Keith Moore wrote: > > On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > > > I don't think that we should be defining getaddrinfo() in terms of > > > "whatever lookup service happens to be around" because it's very > > > difficult to get reliable and repeatable behavior that way. > > > > Isn't the DNS a lookup service that happens to be around ? > > DNS is a specific lookup service. not a random one that just might happen > to be around. > > > The purpose of getaddrinfo is to perform network address and service > > translation. Whilst a portable, granular, interface to DNS would be > > very much welcome - getaddrinfo should not be it. > > Perhaps. But if getaddrinfo isn't the service that does DNS lookups, > then at least some apps should not be using it. getaddrinfo() and getnameinfo() was developed as a generalisation of gethostbyname() and gethostbyaddr(). Thus, from pragmatic point of view should follow the behaviour of the extended functions (gethostbyname etc.) Basically if you call them you are rely on the several different name service functions controlled by local configuration (e.g nsswitch.conf resolv.conf etc.) > > Well, link-local addresses should never be in DNS in the first place. Yes this is advisable! > My argument is not that link-local addresses should be returned by > getaddrinfo() , it is that getaddrinfo() should be transparent. Completely agree. The getaddrinfo() should be completely transparent from programmers' point of view. The local setup should be system/environment specific. I think the cleanest solution would be to setup the DNS resolution order locally by administrator: IPv6 address-resolution enable, and order of IPv4/IPv6 address-resolution. In my opinion, this should be included the resolver code and configurable from resolv.conf. We already have sortlist: IPv6 should be added, and then we could configure whether we want IPv6 address or IPv4 in the first place. To disable IPv6 DNS query should be configurable one the _res.options e.g RES_NO_INET6_QUERY. The current default is to do IPv6 RR query, so that one could be disabled. I strongly against the idea, to change the current default behavior of IPv6 applications without setting up new things. The compatibility is one of the most important feature that we have to keep! Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Tue Nov 4 04:00:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04566 for ; Tue, 4 Nov 2003 04:00:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGx0x-0002gJ-Rd for v6ops-data@psg.com; Tue, 04 Nov 2003 08:58:15 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGx0k-0002fM-Ga for v6ops@ops.ietf.org; Tue, 04 Nov 2003 08:58:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA48vsw21275; Tue, 4 Nov 2003 10:57:55 +0200 Date: Tue, 4 Nov 2003 10:57:49 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: RE: Implementation vs. the Standard In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1E8@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 1 Nov 2003, Bound, Jim wrote: > Not at all. I am saying any standard that is implemented can be broken > by bad implementation or bad operational management. The trade off as > to what the standard does to help alleiviate potential problems is a > fine line. For example, it is not the IETF's business to state if an > implementation has IPv4 or IPv6 on or not on by default. Totally agree here. But I'm not sure what you consider to be bad implementation (failure to implement additional safeguards, not mentioned in the spec?) or bad operational management (enabling IPv6 on nodes before the network supports IPv6, or enabling IPv6 by default in general, ....)? If we agree that we should work towards being able ensure that vendors and users would feel safe(r) to turn on IPv6 by default (of course, we still wouldn't mandate anything about it in a standard!), we get to these problems we've been discussing here .. and then, it seems to me, they should be addressed somewhere, somehow. But if folks disagree that turning v6 on by default is not a useful goal, or that v6 should only be enabled on nodes which do in fact have full IPv6 connectivity as well, we might end up with a different kind of conclusion. > ND is widely deployed and also highly tested with 3 separate test suites > to verify interoperability, in addition to running in many networks I am > aware of intimately. None of the issues in the afforementioned specs > about v6onbydefault or onlink issues have ever occurred I am aware of > except in an analysis lab and that is good. That may be because when v6 is turned on, you also typically enable the v6 connectivity, and because v6 is used by pretty knowledgeable folks. I'm not sure if they've even tested these transitionary phases. > That does not mean those are > not important to document. But, we have new specs to get out the door > like the scenarios and those documents require a lot of discussion to > complete. That should be the WG priority from your view as Co-Chair > that is all I am saying. And I am not saying we should not document > potential problems in current specs. It's a matter of priority. The scenarios/solutions are our priority item. We're just working on them in parallel. Of course, a good question is how much we can do things in parallel so that the work on our priority items does not slow down. But it seems to me that the work was not much faster years ago when we only had these scenarios and analysis.. > But, if most of us only worked on the IETF work and > did not deliver in our others job functions we would be fired. Likewise > if we only deliver BCPs or "advice" and no stanards we will be fired by > the IESG or the Chairs :--) We're IPv6 Operations WG, and our primary function (as I see it) is certainly *NOT* to produce standards. Actually, the only standards activity (excluding BCPs which are in fact standards track) we've been chartered *at the moment* to do is advancing or deprecating transmech, SIIT, NAT-PT and 6to4 if their usefulness is demonstrated in the scenarios/analysis work. (Charter item #6 also lists a possibility for standardizing transition mechanisms if the problems are demonstrated, cannot be solved otherwise or in some other WG.) > All standards from the IETF since inception are subject to that market > test. If you believe we permitted specs to go to DS and those specs are > broken and have flaws then [...] I'm not sure if you're referring to IETF specs in general or Neighbor Discovery in particular. In general, the IETF has raised the bar for PS so that specs should have fewer problems when they go to DS. That's good. However, it's pretty easy to go to Draft Standard, if you just want to do the paperwork and interop testing -- you just need to have a couple of implementations which interoperate and implement all the features of the spec. In theory, "sufficient operational experience" is also required, but that is subjective. In particular, however, Neighbor Discovery spec had not been extensively deployed in different kinds of environments five years ago that it was published as DS. It would be unnatural to assume it would NOT have any issues, which would be exposed later on, with wider and different kinds of deployments. That is, just because a specification goes to Draft Standard especially before it's very widely deployed doesn't mean it can't have problems :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Nov 4 08:06:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13132 for ; Tue, 4 Nov 2003 08:06:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH0pR-000EIM-K8 for v6ops-data@psg.com; Tue, 04 Nov 2003 13:02:37 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH0pD-000EHc-Cu for v6ops@ops.ietf.org; Tue, 04 Nov 2003 13:02:23 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E87DA7F06; Tue, 4 Nov 2003 08:02:22 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 Nov 2003 08:02:22 -0500 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: Implementation vs. the Standard Date: Tue, 4 Nov 2003 08:02:22 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA20B@tayexc13.americas.cpqcorp.net> Thread-Topic: Implementation vs. the Standard Thread-Index: AcOiscNZmMWlW0lMTIOJwhRc7FXE0AAIP27w From: "Bound, Jim" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 04 Nov 2003 13:02:22.0503 (UTC) FILETIME=[E2E60370:01C3A2D3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, There are over 100,000 nodes that have deployed ND and across every geography in the world and it is shipping from at least 20 well known products that all did QA Testing which often includes interoperability. That is widely deployed enough. I think you are not informed about how widely IPv6 has been deployed for the purposes of banging on our specs. I am not talking about revenue streams. Our views simply are divergent on many many issues. That is why we have a working group and why we have discussion. It is not up to YOU or I but the IETF what the final answers are and I welcome the challenge and battle to defeat most of your ideas in public, that I feel are completely not valid or the IETF's concern regarding what products do or don't do. I choose logic and tehnical depth for this battle :--) Not emotion and what we call in U.S. Legal Court Proceedings as here-say. Mercy does not exists in my character for such battle of technology for such an important matter :--)=20 I would suggest the root of our disagreements time after time for me is your "assumptions". You have just become a focus in my technical life congratulations, as a major problem for IPv6, not a helpful partner. Respectfully, /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Tuesday, November 04, 2003 3:58 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: Implementation vs. the Standard >=20 >=20 > On Sat, 1 Nov 2003, Bound, Jim wrote: > > Not at all. I am saying any standard that is implemented can be=20 > > broken by bad implementation or bad operational management.=20 > The trade=20 > > off as to what the standard does to help alleiviate=20 > potential problems=20 > > is a fine line. For example, it is not the IETF's business=20 > to state=20 > > if an implementation has IPv4 or IPv6 on or not on by default. >=20 > Totally agree here. But I'm not sure what you consider to be bad=20 > implementation (failure to implement additional safeguards, not=20 > mentioned in the spec?) or bad operational management=20 > (enabling IPv6 on=20 > nodes before the network supports IPv6, or enabling IPv6 by=20 > default in=20 > general, ....)? >=20 > If we agree that we should work towards being able ensure=20 > that vendors and users would feel safe(r) to turn on IPv6 by=20 > default (of course, we still wouldn't mandate anything about=20 > it in a standard!), we get to these problems we've been=20 > discussing here .. and then, it seems to me, they should be=20 > addressed somewhere, somehow. >=20 > But if folks disagree that turning v6 on by default is not a=20 > useful goal, or that v6 should only be enabled on nodes which=20 > do in fact have full IPv6 connectivity as well, we might end=20 > up with a different kind of conclusion. >=20 > > ND is widely deployed and also highly tested with 3 separate test=20 > > suites to verify interoperability, in addition to running in many=20 > > networks I am aware of intimately. None of the issues in the=20 > > afforementioned specs about v6onbydefault or onlink issues=20 > have ever=20 > > occurred I am aware of except in an analysis lab and that is good. >=20 > That may be because when v6 is turned on, you also typically=20 > enable the v6 connectivity, and because v6 is used by pretty=20 > knowledgeable folks. I'm not sure if they've even tested=20 > these transitionary phases. >=20 > > That does not mean those are > > not important to document. But, we have new specs to get=20 > out the door=20 > > like the scenarios and those documents require a lot of=20 > discussion to=20 > > complete. That should be the WG priority from your view as=20 > Co-Chair=20 > > that is all I am saying. And I am not saying we should not document=20 > > potential problems in current specs. It's a matter of priority. >=20 > The scenarios/solutions are our priority item. We're just=20 > working on them in parallel. Of course, a good question is=20 > how much we can do things in parallel so that the work on our=20 > priority items does not slow down. But it seems to me that=20 > the work was not much faster years ago when we only had these=20 > scenarios and analysis.. >=20 > > But, if most of us only worked on the=20 > IETF work=20 > > and did not deliver in our others job functions we would be fired. =20 > > Likewise if we only deliver BCPs or "advice" and no=20 > stanards we will=20 > > be fired by the IESG or the Chairs :--) >=20 > We're IPv6 Operations WG, and our primary function (as I see=20 > it) is certainly *NOT* to produce standards. =20 >=20 > Actually, the only standards activity (excluding BCPs which=20 > are in fact standards track) we've been chartered *at the=20 > moment* to do is advancing or deprecating transmech, SIIT,=20 > NAT-PT and 6to4 if their usefulness is demonstrated in the=20 > scenarios/analysis work. (Charter item #6 also lists a=20 > possibility for standardizing transition mechanisms if the=20 > problems are demonstrated, cannot be solved otherwise or in=20 > some other WG.) >=20 > > All standards from the IETF since inception are subject to=20 > that market=20 > > test. If you believe we permitted specs to go to DS and=20 > those specs=20 > > are broken and have flaws then [...] >=20 > I'm not sure if you're referring to IETF specs in general or Neighbor=20 > Discovery in particular. >=20 > In general, the IETF has raised the bar for PS so that specs=20 > should have fewer problems when they go to DS. That's good. =20 > However, it's pretty easy to go to Draft Standard, if you=20 > just want to do the paperwork and interop testing -- you just=20 > need to have a couple of implementations which interoperate=20 > and implement all the features of the spec. In theory,=20 > "sufficient operational experience" is also required, but=20 > that is subjective. >=20 > In particular, however, Neighbor Discovery spec had not been=20 > extensively deployed in different kinds of environments five=20 > years ago that it was published as DS. It would be unnatural=20 > to assume it would NOT have any issues, which would be=20 > exposed later on, with wider and different kinds of deployments. >=20 > That is, just because a specification goes to Draft Standard=20 > especially before it's very widely deployed doesn't mean it=20 > can't have problems :-) >=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 Tue Nov 4 08:44:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14446 for ; Tue, 4 Nov 2003 08:44:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH1RJ-000Gje-DU for v6ops-data@psg.com; Tue, 04 Nov 2003 13:41:45 +0000 Received: from [160.36.56.50] (helo=klutz.cs.utk.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH1Pn-000Gbq-B8 for v6ops@ops.ietf.org; Tue, 04 Nov 2003 13:40:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 27C8914093; Tue, 4 Nov 2003 08:40:10 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26816-07; Tue, 4 Nov 2003 08:40:09 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id D435A14057; Tue, 4 Nov 2003 08:40:08 -0500 (EST) Date: Tue, 4 Nov 2003 07:35:14 -0500 From: Keith Moore To: Mohacsi Janos Cc: moore@cs.utk.edu, colm@stdlib.net, Stig.Venaas@uninett.no, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031104073514.61046c34.moore@cs.utk.edu> In-Reply-To: <20031104085701.X37922@mignon.ki.iif.hu> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > My argument is not that link-local addresses should be returned by > > getaddrinfo() , it is that getaddrinfo() should be transparent. > > Completely agree. The getaddrinfo() should be completely transparent from > programmers' point of view. The local setup should be system/environment > specific. I think the cleanest solution would be to setup the DNS > resolution order locally by administrator: IPv6 address-resolution enable, > and order of IPv4/IPv6 address-resolution. In my opinion, this should be > included the resolver code and configurable from resolv.conf. what you are describing is not transparent to applications that actually need to know what is in DNS. Keith From owner-v6ops@ops.ietf.org Tue Nov 4 10:09:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17364 for ; Tue, 4 Nov 2003 10:09:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH2lU-000Lav-9T for v6ops-data@psg.com; Tue, 04 Nov 2003 15:06:40 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH2lG-000La8-0l for v6ops@ops.ietf.org; Tue, 04 Nov 2003 15:06:26 +0000 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 16:06:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Unicast Reverse Path Forwarding Date: Tue, 4 Nov 2003 16:06:21 +0100 Message-ID: Thread-Topic: Unicast Reverse Path Forwarding Thread-Index: AcOeNhiE23rlJlVDTzmudbzurp8CTgErhk6w From: "ADAM Yann FTRD/DAC/LAN" To: "Hobbes tiger extraordinaire" , X-OriginalArrivalTime: 04 Nov 2003 15:06:22.0373 (UTC) FILETIME=[35681550:01C3A2E5] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, On Cisco, the command is: 'ipv6 verify unicast reverse-path' at the interface level. Regards, Yann Adam -----Original Message----- From: Hobbes tiger extraordinaire [mailto:orly@redbrick.dcu.ie] Sent: mercredi 29 octobre 2003 13:04 To: v6ops@ops.ietf.org Subject: Unicast Reverse Path Forwarding Hi,=20 I was wondering if anyone can tell me if Unicast Reverse Path Forwarding is able to deal with IPv6 addresses on Cisco? JunOS appears to be able to manage both addresses. Thanks in advance Orla --=20 Happiness is a warm puppy From owner-v6ops@ops.ietf.org Tue Nov 4 14:10:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28483 for ; Tue, 4 Nov 2003 14:10:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH6Ur-000C6t-B3 for v6ops-data@psg.com; Tue, 04 Nov 2003 19:05:45 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH6Ua-000C5b-6T for v6ops@ops.ietf.org; Tue, 04 Nov 2003 19:05:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA4J5Ms32407 for ; Tue, 4 Nov 2003 21:05:24 +0200 Date: Tue, 4 Nov 2003 21:05:19 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6ops agenda for Minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops agenda for Minneapolis IETF --------------------------------- (minor changes are still possible, of course..) 2.0h slot, Monday Afternoon 1300-1500 ===================================== Introduction and agenda bashing - 5 mins, Chairs/Pekka Process issues for the working group, 10-15 mins, Chairs/Jonne - Introduce the changes/enhancements to the WG process. - How to move forward with Unmanaged, Enterprise and ISP - GOAL: enable WG to work more effectively Document status - 5-10 mins, Chairs/Pekka - What has happened with WG documents lately - GOAL: show the status of WG documents 3GPP Analysis Issues discussion, 15 mins, J. Wiljakka - draft-ietf-v6ops-3gpp-analysis-07.txt - Go through the open issues raised before and during the last call, try to solicit comments from the WG. - GOAL: try to gain some form of consensus on the issues, to be ready to ship the document to the IESG after revision in Dec 2003. ISP Scenarios/Solutions, 30 mins, M. Lind, V. Ksinant - draft-lind-v6ops-isp-scenarios-01.txt - draft-ksinant-v6ops-isp-analysis-00.txt - present changes, solicit discussion on the ISP scenarios/solutions - try to get meta discussion what the WG actually wants to do in ISP space - GOAL: Show the latest developments in ISP space, get WG to discuss what to do to move forward. Adapt both as WG documents. Unmanaged Connectivity Tradeoffs discussion, 30 mins, T. Chown - draft-chown-v6ops-unmanaged-connectivity-00.txt - 10 mins presentation, 20 mins discussion - describe the connectivity issues currently blocking the unmanaged solutions document, discuss tradeoffs - GOAL: try to get useful discussion on the tradeoffs of connectivity. Get input whether this is the right direction to go to solve these issues. IPv6-on-by-Default/On-link-bydefault tradeoffs - 25 mins, Sebastien Roy - draft-ietf-v6ops-v6onbydefault-00.txt - draft-ietf-v6ops-onlinkassumption-00.txt - 5-10 minutes presentation/changes - 15 minutes discussion - GOAL: discuss changes since the last version, first time as WG document - GOAL: make clear how to proceed with the onlinkassumption document. 2.0h slot, Wednesday Afternoon 1530-1730 ======================================== Transition mechanisms update, 10 mins, Erik Nordmark - draft-ietf-v6ops-mech-v2-01.txt - present the changes, 2 mins; discussion of issues, 8 mins - GOAL: Discuss open issues and comments received during the beginning of WG Last Call (if any). Enterprise Scenarios discussion, 20 mins, Y. Pouffary, J. Bound - draft-ietf-v6ops-ent-scenarios-00.txt - 5-10 mins presentation, the rest discussion - bring up the points where WG input would be useful, discuss those - GOAL: allow the WG to go give input on the document, and help it go forward. SIIT/NAT-PT Applicability Statement - 15 mins, Suresh Satapati - draft-satapati-v6ops-natpt-applicability-00.txt - 5 minutes presentation, 10 minutes discussion especially the major issues where the DT was divided - GOAL: provoke discussion on NAT-PT/SIIT and generic translation, see how the WG likes the document IPv6 Applications Transition - 15 mins, Myung-Ki Shin - draft-shin-v6ops-application-transition-02.txt - 5 minutes presentation, 15 mins discussion - GOAL: adopt as WG document, provoke discussion on application porting guidelines IPv6 Renumbering Procedures, 20 mins, Fred Baker - draft-baker-ipv6-renumber-procedure-01.txt - 5-10 mins presentation, 10 mins discussion of the issues - GOAL: adapt as WG document, discuss how to make renumbering easier. Forwarding Protocol 41 in NAT Boxes - 5-10 mins, Jordi Palet - draft-palet-v6ops-proto41-nat-03.txt - 2-3 minutes changes/presentation - 5 minutes discussion on how to move forward, whether this is the right approach - GOAL: get WG feedback whether this is neutral enough, for documentation purposes. Not being considered as WG item at this point. IPv6 Firewalling Considerations, 10 mins, Pekka Savola - draft-savola-v6ops-firewalling-02.txt - 5 minutes presentation/changes, 5 minutes discussion - GOAL: see whether the WG wants to adapt as WG item for Informational RFC. Experiences with Dual Stack Service - 10-15 mins, Yasuhiro Shirasaki - draft-shirasaki-dualstack-service-02.txt - 5-10 minutes presentation - 5 minutes discussion - GOAL: disseminate how dual-stack access service has been deployed already. (Authors pursue the individual Informational RFC path.) Statistics from a 6to4 Relay - 5 mins, Pekka Savola - (no draft) - quick presentation on the usage statistics from a public 6to4 relay - GOAL: give the WG an impression about the traffic on 6to4 relays From owner-v6ops@ops.ietf.org Wed Nov 5 02:48:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24723 for ; Wed, 5 Nov 2003 02:48:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHIJw-000M4X-9Y for v6ops-data@psg.com; Wed, 05 Nov 2003 07:43:16 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHIJf-000M3j-Vr for v6ops@ops.ietf.org; Wed, 05 Nov 2003 07:43:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA57guv12458 for ; Wed, 5 Nov 2003 09:42:58 +0200 Date: Wed, 5 Nov 2003 09:42:55 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: milestones updated Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, We've finally managed to get the secretariat to update our milestones. If interested, have a look: http://www.ietf.org/html.charters/v6ops-charter.html There are still at least one inaccuracy and a couple of milestones missing for newer WG work items, but those will be fixed after Minneapolis. From owner-v6ops@ops.ietf.org Wed Nov 5 02:49:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24753 for ; Wed, 5 Nov 2003 02:49:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHION-000MIl-4f for v6ops-data@psg.com; Wed, 05 Nov 2003 07:47:51 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHIOB-000MIE-2B for v6ops@ops.ietf.org; Wed, 05 Nov 2003 07:47:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA57lbw12486 for ; Wed, 5 Nov 2003 09:47:37 +0200 Date: Wed, 5 Nov 2003 09:47:37 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: WG Last Call: last two draft-ietf-v6ops-ipv4survey-* documents (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I'd like to remind you that the LC is ending in two days, and we have received zero feedback. The two particular documents were tuned more than the rest, but I still believe there should be at least something worthy of note here! (Or, just sending a note that you've read it would also be nice). We intend to revise (all) the survey documents immediately after Minneapolis to take account the couple of comments received, and send them to the IESG immediately afterwards. Pekka writing as co-chair ---------- Forwarded message ---------- Date: Fri, 24 Oct 2003 19:00:39 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Cc: bob@thefinks.com, jonne.soininen@nokia.com Subject: WG Last Call: last two draft-ietf-v6ops-ipv4survey-* documents Hi all, This is a WG Last Call for comments on sending the following last two "Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents to the IESG for consideration as Informational RFCs: Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-02.txt Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be send to the IESG. The last call will end in 2 weeks, on 7th November. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Thu Nov 6 07:39:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06291 for ; Thu, 6 Nov 2003 07:39:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHjJE-000325-S6 for v6ops-data@psg.com; Thu, 06 Nov 2003 12:32:20 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHjJ0-0002y3-BL for v6ops@ops.ietf.org; Thu, 06 Nov 2003 12:32:06 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA6CTh3K043636 for ; Thu, 6 Nov 2003 12:29:43 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA6CW3qI278130 for ; Thu, 6 Nov 2003 13:32:03 +0100 Received: from zurich.ibm.com ([9.145.246.63]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA38844 for ; Thu, 6 Nov 2003 13:31:59 +0100 Message-ID: <3FAA3F17.4B0645F8@zurich.ibm.com> Date: Thu, 06 Nov 2003 13:31:19 +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-baker-ipv6-renumber-procedure-01.txt References: <200310032029.QAA25670@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, As others have said, this is a very important document. I think it's in pretty good shape, so here are both my substantive comments and my nits. > 2.2.2 Mechanisms for address assignment to interfaces > > IPv6 addresses may be assigned through SLAC, DHCP, and manual > processes. SLAC is defined in the terminology section, but it isn't a standard acronym so I would provide a hint here. > 2.3 Configuring network elements for the new prefix ... > Once the new prefix has been added to the network infrastructure, > access-lists, route-maps and other network configuration options that > use IP addresses should be checked to ensure that hosts and services > that use the new prefix will behave as they did with the old one. I think it is worth adding "including firewalls and other middleboxes" after hosts, to make it clear how broad the scope is. > 3.1 "Find all the places..." ... > o should obtain addresses of other systems or servifces from the > DNS, rather then having those addresses manuall configured, s/servifces/services/ s/manuall/manually/ > o must obtain a new translation if a new session is opened with the > same service after the DNS record's lifetime expires, > > o when addresses are configured rather than translated, should > provide a convenient programmatic method to reconfigure the > addresses that can be executed using a script or its equivalent. I would add o must be capable of handling (and if appropriate, storing) more than one IPv6 address at the same time. I'm assuming that during renumbering, there will be at least two valid addresses, and an application that simply ignores every address after the first one is wrong. There is an interaction here with the address selection rules that should perhaps be discussed, and perhaps some of this belongs in draft-shin-v6ops-application-transition-02.txt too. Brian Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Procedures for Renumbering an IPv6 Network without a Flag Day > Author(s) : F. Baker, et. al. > Filename : draft-baker-ipv6-renumber-procedure-01.txt > Pages : 19 > Date : 2003-10-3 > > This document describes the steps in a procedure that can be used to > transition from the use of an existing prefix to a new prefix in a > network. It uses IPv6's intrinsic ability to assign multiple > addresses to a network interface to provide continuity of network > service through a > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-01.txt From owner-v6ops@ops.ietf.org Thu Nov 6 11:23:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16528 for ; Thu, 6 Nov 2003 11:23:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHmo8-0001uc-OK for v6ops-data@psg.com; Thu, 06 Nov 2003 16:16:28 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHmnw-0001h1-Ac for v6ops@ops.ietf.org; Thu, 06 Nov 2003 16:16: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 CB20BB938; Thu, 6 Nov 2003 11:16:14 -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, 6 Nov 2003 11:16:14 -0500 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: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Thu, 6 Nov 2003 11:16:14 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122559@tayexc13.americas.cpqcorp.net> Thread-Topic: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Thread-Index: AcOiHdjBSqgK0WcKS2q96wR3xJq+mACY1r1A From: "Bound, Jim" To: "Stig Venaas" , "Keith Moore" Cc: "Pekka Savola" , , X-OriginalArrivalTime: 06 Nov 2003 16:16:14.0918 (UTC) FILETIME=[4D2F2E60:01C3A481] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable There is nothing in getaddrinfo that precludes its use with any name service. If customized extesions are needed for that then extended specs can be suggested. /jim > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Stig Venaas > Sent: Monday, November 03, 2003 10:16 AM > To: Keith Moore > Cc: Pekka Savola; v6ops@ops.ietf.org; ipv6@ietf.org > Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG >=20 >=20 > [...] > > - IMHO, getaddrinfo()'s job should be to report what is in=20 > DNS, not to try to > > coerce apps into behaving well. So even though apps=20 > shouldn't be using > > link-local addresses, and even though people shouldn't=20 > list link-local > > addresses in DNS, getaddrinfo() should not try to hide=20 > such addresses from > > apps if they happen to appear in DNS. >=20 > I can sympathize with your opinions. I think two things are needed: >=20 > o A standard call that most applications can use in a simple=20 > way. IMHO it > should query DNS, other name services, /etc/hosts etc. >=20 > o A standard call that applications can use to check what is in DNS >=20 > The first should IMHO be something like getaddrinfo() where=20 > applications simply try the addresses in the order they are=20 > returned. I also think it should be possible for an=20 > administrator to define which name services should be used,=20 > which type of addresses should be returned, and the order. >=20 > Another matter is what the API should be. Most IPv6 enabled=20 > applications today use getaddrinfo(), while specialized DNS=20 > applications like "host" use their own resolver routines. So=20 > I would say that getaddrinfo() without special arguments=20 > would be good for the general applications. For the DNS=20 > applications one could use getaddrinfo() with a new option,=20 > or a completely new call. It's easier to change the few DNS=20 > applications that are out there. >=20 > Stig >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From owner-v6ops@ops.ietf.org Thu Nov 6 11:26:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16631 for ; Thu, 6 Nov 2003 11:26:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHmmF-000PvD-Rt for v6ops-data@psg.com; Thu, 06 Nov 2003 16:14:31 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHmlL-000P1i-2Q for v6ops@ops.ietf.org; Thu, 06 Nov 2003 16:13:35 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 074A31121F; Thu, 6 Nov 2003 11:13:34 -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, 6 Nov 2003 11:13:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Thu, 6 Nov 2003 11:13:21 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122558@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Thread-Index: AcOiC7msyaKL8ymCQ92VXBQE85N5twCdR/IQ From: "Bound, Jim" To: "Pekka Savola" , Cc: , X-OriginalArrivalTime: 06 Nov 2003 16:13:21.0670 (UTC) FILETIME=[E5EBA260:01C3A480] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I do not support this going to PS only DS. I will appeal most likely. regards, /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Monday, November 03, 2003 8:03 AM > To: v6ops@ops.ietf.org > Cc: bob@thefinks.com; jonne.soininen@nokia.com > Subject: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt >=20 >=20 > Hi all, >=20 > This is a WG Last Call for comments on sending=20 > draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms=20 > for IPv6 Hosts and Routers", to the IESG for consideration as=20 > Proposed Standard: >=20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt (We're hoping to recycle to Draft Standard soon afterwards.) Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be sent to the IESG. The last call will end in about 3 weeks, on 25th November. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Thu Nov 6 12:28:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19396 for ; Thu, 6 Nov 2003 12:28:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHnsQ-000ANb-PN for v6ops-data@psg.com; Thu, 06 Nov 2003 17:24:58 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHnsO-000AMi-5r for v6ops@ops.ietf.org; Thu, 06 Nov 2003 17:24:56 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A96641381B; Thu, 6 Nov 2003 12:24:55 -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, 6 Nov 2003 12:24:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Thu, 6 Nov 2003 12:24:55 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122560@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Thread-Index: AcOiC7msyaKL8ymCQ92VXBQE85N5twCfkVAQ From: "Bound, Jim" To: "Pekka Savola" , Cc: , X-OriginalArrivalTime: 06 Nov 2003 17:24:55.0495 (UTC) FILETIME=[E53D5570:01C3A48A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Folks, To make it very clear and sorry about that on why I think it should stay DS. My appeal would be based on Section 9 changes since RFC 2893 as overview. There is no architectural change to the specification for implementations. The changes that remove features were not used widely in the wide implementation of this mechanism in the deployment market sector at all. The changes do not affect current deployment at all. A6, Automatic Tunnels, et al are not widely deployed by any environment that tested them. So the deployment operational community in the market was ahead of this spec and I would argue directly caused these clarifcations. This is IPv6 core base transition spec for operators and widely understood and used. Nothing in this update adds any value to the mechanism as far as new features. Given that we have so much work to do and given the IETF does agree we have a time-to-market or get the spec done problem it is a backward step to go to PS and we should remain DS. I also think the working group should first go for DS and if the IESG wants to push back lets have that discussion then and let the IESG do there job. Lets not jump the fence here if we can just open a gate. =20 There is nothing technically complex changed or even required to change in implementation. /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Monday, November 03, 2003 8:03 AM > To: v6ops@ops.ietf.org > Cc: bob@thefinks.com; jonne.soininen@nokia.com > Subject: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt >=20 >=20 > Hi all, >=20 > This is a WG Last Call for comments on sending=20 > draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms=20 > for IPv6 Hosts and Routers", to the IESG for consideration as=20 > Proposed Standard: >=20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt (We're hoping to recycle to Draft Standard soon afterwards.) Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be sent to the IESG. The last call will end in about 3 weeks, on 25th November. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Thu Nov 6 12:28:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19419 for ; Thu, 6 Nov 2003 12:28:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHnuL-000AZj-9B for v6ops-data@psg.com; Thu, 06 Nov 2003 17:26:57 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHnuJ-000AXr-4y for v6ops@ops.ietf.org; Thu, 06 Nov 2003 17:26:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA6HQiV10973; Thu, 6 Nov 2003 19:26:45 +0200 Date: Thu, 6 Nov 2003 19:26:35 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org, , Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B05122558@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 6 Nov 2003, Bound, Jim wrote: > I do not support this going to PS only DS. I will appeal most likely. First, it would be nice if you explained why only DS is acceptable. Note that there have been a large number of updates since the original transmech. I'd find it difficult to justify that we could go to DS straight away. I'd personally really like to go to DS straight away, but it doesn't seem like a possibility with the revisions the document has undergone. But if e.g. our AD/IESG says DS is fine, then it's fine with me as well. But if you do appeal, please try to be as clear about the grounds for appeal as possible, and what action you seek (as stated in section 6.5 of RFC 2026). -- 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 Nov 6 13:00:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20566 for ; Thu, 6 Nov 2003 13:00:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHoOO-000Ef0-99 for v6ops-data@psg.com; Thu, 06 Nov 2003 17:58:00 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHoOI-000Ebv-Pv for v6ops@ops.ietf.org; Thu, 06 Nov 2003 17:57:54 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 4772113AA1; Thu, 6 Nov 2003 12:57:54 -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, 6 Nov 2003 12:57:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Thu, 6 Nov 2003 12:57:53 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122565@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Thread-Index: AcOkiy0fgKF/Qew4S6iUxGYY3q7JHAABDsrA From: "Bound, Jim" To: "Pekka Savola" Cc: , , X-OriginalArrivalTime: 06 Nov 2003 17:57:54.0057 (UTC) FILETIME=[808DEF90:01C3A48F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I just sent it. The number of changes is not the issue but the content of those changes is my point. Nothing was changed that should preclude DS is my position. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Thursday, November 06, 2003 12:27 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org; bob@thefinks.com; jonne.soininen@nokia.com > Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt >=20 >=20 > On Thu, 6 Nov 2003, Bound, Jim wrote: > > I do not support this going to PS only DS. I will appeal=20 > most likely. >=20 > First, it would be nice if you explained why only DS is acceptable. >=20 > Note that there have been a large number of updates since the=20 > original transmech. I'd find it difficult to justify that we=20 > could go to DS straight away. I'd personally really like to=20 > go to DS straight away, but it doesn't seem like a=20 > possibility with the revisions the document has undergone. =20 > But if e.g. our AD/IESG says DS is fine, then it's fine with=20 > me as well. >=20 > But if you do appeal, please try to be as clear about the=20 > grounds for appeal as possible, and what action you seek (as=20 > stated in section 6.5 of RFC 2026). >=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 Nov 6 13:08:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20936 for ; Thu, 6 Nov 2003 13:08:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHoVo-000GXq-EC for v6ops-data@psg.com; Thu, 06 Nov 2003 18:05:40 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHoVk-000GX6-5s for v6ops@ops.ietf.org; Thu, 06 Nov 2003 18:05:36 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1AHoVh-0005M8-P5; Thu, 06 Nov 2003 10:05:33 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Nov 2003 10:05:33 -0800 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt References: <9C422444DE99BC46B3AD3C6EAFC9711B05122558@tayexc13.americas.cpqcorp.net> Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Note that there have been a large number of updates since the original > transmech. perhaps a small enumeration of the technical changes of substance would help us decide if this needs to recycle at ps. randy From owner-v6ops@ops.ietf.org Thu Nov 6 13:37:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22138 for ; Thu, 6 Nov 2003 13:37:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHows-0002d9-L0 for v6ops-data@psg.com; Thu, 06 Nov 2003 18:33:38 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHown-0002cM-28; Thu, 06 Nov 2003 18:33:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA6IXT612530; Thu, 6 Nov 2003 20:33:30 +0200 Date: Thu, 6 Nov 2003 20:33:24 +0200 (EET) From: Pekka Savola To: Randy Bush cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 6 Nov 2003, Randy Bush wrote: > > Note that there have been a large number of updates since the original > > transmech. > > perhaps a small enumeration of the technical changes of substance > would help us decide if this needs to recycle at ps. These are available in the draft, in "Changes from RFC 2893" section. I think the most major ones, in addition to removing automatic tunneling, have been the changes in the MTU parts of the spec. I believe that ingress-filtering has also changed. I don't think many (or close to any) implementations conform to the spec out of the box, which is why I was edging towards PS myself. But I'd be happy to be convinced otherwise! I'll copy it below (minus the ones that seem mostly only editorial): - Removed automatic tunneling and use of IPv4-compatible addresses. - Removed default Configured Tunnel using IPv4 "Anycast Address" - Dropped "or equal" in if (IPv4 path MTU - 20) is less than or equal to 1280 - Clarified that the dynamic path MTU mechanism in section 3.2 is OPTIONAL but if it is implemented it should follow the rules in section 3.2. - Stated that when the dynamic PMTU is not implemented the sender MUST NOT by default send IPv6 packets larger than 1280 into the tunnel. - Stated that implementations MAY have a knob by which the MTU can be set to larger values on a tunnel by tunnel basis, but that the default MUST be 1280 and that decapsulators need to be configured to match the encapsulator's MTU. - Clarified text about ingress filtering e.g. that it applies to packet delivered to transport protocols on the decapsulator as well as packets being forwarded by the decapsulator, and how the decapsulator's checks help when IPv4 and IPv6 ingress filtering is in place. -- 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 Nov 6 13:43:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22513 for ; Thu, 6 Nov 2003 13:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHp4R-0003ox-GJ for v6ops-data@psg.com; Thu, 06 Nov 2003 18:41:27 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHp4O-0003oi-UT for v6ops@ops.ietf.org; Thu, 06 Nov 2003 18:41:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA6Iefx12649; Thu, 6 Nov 2003 20:41:00 +0200 Date: Thu, 6 Nov 2003 20:40:30 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org, , Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B05122560@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 6 Nov 2003, Bound, Jim wrote: > Given that we have so much work to do and given the IETF does agree we > have a time-to-market or get the spec done problem it is a backward step > to go to PS and we should remain DS. I'm not sure what you mean with "remain DS". Do you mean, "go from PS to DS, as planned previously" ? Or, "remain at the DS level" (taken literally) -- which would be factually incorrect, because RFC2893 is only PS. (If RFC2893 was DS, I'd certainly agree.) > There is nothing technically complex changed or even required to change > in implementation. I think the MTU sections, at least, have seen some rather extensive changes. (Of course, the amount of editorial corrections and clarifications is also large.) I'm not sure if we could find many conformant implementations out of the box (not sure if that'd be required, of course). Some further modifications based on LC comments are also very likely. What is the amount (and scope) of those changes is of course still a question mark. -- 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 Nov 6 14:52:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25783 for ; Thu, 6 Nov 2003 14:52:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHq8V-000Moz-D2 for v6ops-data@psg.com; Thu, 06 Nov 2003 19:49:43 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHq8S-000Moj-IV for v6ops@ops.ietf.org; Thu, 06 Nov 2003 19:49:40 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 117FFFDDB; Thu, 6 Nov 2003 14:49: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); Thu, 6 Nov 2003 14:49:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Thu, 6 Nov 2003 14:49:39 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA221@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Thread-Index: AcOklaOlbCCMu/xzRTKqzUYRDxMZVAACMXcg From: "Bound, Jim" To: "Pekka Savola" Cc: , , X-OriginalArrivalTime: 06 Nov 2003 19:49:39.0876 (UTC) FILETIME=[1D88B640:01C3A49F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Nevermind I was sure it was DS for some reason. My issue is irrelevant. My mistake. Not sure why I thought that though???????????? But none of these are major. Is it worth me going thru that still? I don't mind? For example we all killed the auto tunnels and compatible addreses long ago. What we did as this spec is so key to base transition is implemented as the changes took place. None of them were any large code or architecture changes to the code base. Not saying all were done but the important ones. And running now. =20 I was sure we did implementor reports and all of that for 2893 ?????????????? Yes it should move to DS when this completes. I think you can get implementor reports too. This took too long to recycle for what was changed is other input to you as chair. Perfect example of how ineffective we are with our process. =20 My mistake, /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Thursday, November 06, 2003 1:41 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org; bob@thefinks.com; jonne.soininen@nokia.com > Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt >=20 >=20 > On Thu, 6 Nov 2003, Bound, Jim wrote: > > Given that we have so much work to do and given the IETF=20 > does agree we=20 > > have a time-to-market or get the spec done problem it is a backward=20 > > step to go to PS and we should remain DS. >=20 > I'm not sure what you mean with "remain DS". >=20 > Do you mean, "go from PS to DS, as planned previously" ? >=20 > Or, "remain at the DS level" (taken literally) -- which would=20 > be factually incorrect, because RFC2893 is only PS. (If=20 > RFC2893 was DS, I'd certainly > agree.) >=20 > > There is nothing technically complex changed or even required to=20 > > change in implementation. >=20 > I think the MTU sections, at least, have seen some rather=20 > extensive changes. (Of course, the amount of editorial=20 > corrections and clarifications is also large.) I'm not sure=20 > if we could find many conformant implementations out of the=20 > box (not sure if that'd be required, of course). >=20 > Some further modifications based on LC comments are also very=20 > likely. =20 > What is the amount (and scope) of those changes is of course still a=20 > question mark. >=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 Nov 6 15:08:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26774 for ; Thu, 6 Nov 2003 15:08:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHqOP-0001vi-7o for v6ops-data@psg.com; Thu, 06 Nov 2003 20:06:09 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHqOM-0001ua-5H for v6ops@ops.ietf.org; Thu, 06 Nov 2003 20:06:06 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id CA1A896; Fri, 7 Nov 2003 05:06:03 +0900 (JST) To: jim.bound@hp.com Cc: pekkas@netcore.fi, v6ops@ops.ietf.org, bob@thefinks.com, jonne.soininen@nokia.com Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Thu, 6 Nov 2003 11:13:21 -0500" <9C422444DE99BC46B3AD3C6EAFC9711B05122558@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B05122558@tayexc13.americas.cpqcorp.net> X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031106200603.CA1A896@coconut.itojun.org> Date: Fri, 7 Nov 2003 05:06:03 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> (We're hoping to recycle to Draft Standard soon afterwards.) > I do not support this going to PS only DS. I will appeal most likely. we are not going to DS this time, am i right? itojun From owner-v6ops@ops.ietf.org Thu Nov 6 15:22:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28282 for ; Thu, 6 Nov 2003 15:22:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHqcQ-0008PU-Vu for v6ops-data@psg.com; Thu, 06 Nov 2003 20:20:38 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHqcL-0008MW-M9 for v6ops@ops.ietf.org; Thu, 06 Nov 2003 20:20:33 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6KKHh19286; Thu, 6 Nov 2003 12:20:17 -0800 X-mProtect: <200311062020> 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 smtpd9KRTKa; Thu, 06 Nov 2003 12:20:15 PST Message-ID: <3FAAAE71.3090504@iprg.nokia.com> Date: Thu, 06 Nov 2003 12:26:25 -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: Jun-ichiro itojun Hagino CC: jim.bound@hp.com, pekkas@netcore.fi, v6ops@ops.ietf.org, bob@thefinks.com, jonne.soininen@nokia.com Subject: Re: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt References: <9C422444DE99BC46B3AD3C6EAFC9711B05122558@tayexc13.americas.cpqcorp.net> <20031106200603.CA1A896@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Maybe I'm missing something obvious, but perhaps one (or more) of you could explain why the disposition of DS vs. PS even matters in this case? Thanks - Fred ftemplin@iprg.nokia.com Jun-ichiro itojun Hagino wrote: >>>(We're hoping to recycle to Draft Standard soon afterwards.) >>> >>> >>I do not support this going to PS only DS. I will appeal most likely. >> >> > > we are not going to DS this time, am i right? > >itojun > > > From owner-v6ops@ops.ietf.org Thu Nov 6 19:03:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09311 for ; Thu, 6 Nov 2003 19:03:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHu23-0001TT-Vt for v6ops-data@psg.com; Thu, 06 Nov 2003 23:59:19 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHu1x-0001Sw-V5 for v6ops@ops.ietf.org; Thu, 06 Nov 2003 23:59:16 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA6NxBPh023260 for ; Thu, 6 Nov 2003 16:59: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 <0HNY00CSAFYMXH@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 06 Nov 2003 16:59:11 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNY009MBFYL3C@mail.sun.net> for v6ops@ops.ietf.org; Thu, 06 Nov 2003 16:59:10 -0700 (MST) Date: Thu, 06 Nov 2003 16:02:00 -0800 From: Alain Durand Subject: Re: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-reply-to: To: Pekka Savola Cc: Randy Bush , v6ops@ops.ietf.org Message-id: <9C664650-10B5-11D8-8D51-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I do not see anything here that is fundamentally incompatible with the previous version that will create interoperability issues. I support this going to DS. - Alain. > > - Removed automatic tunneling and use of IPv4-compatible > addresses. > > - Removed default Configured Tunnel using IPv4 "Anycast Address" > > - Dropped "or equal" in if (IPv4 path MTU - 20) is less than or > equal to 1280 > > - Clarified that the dynamic path MTU mechanism in section 3.2 is > OPTIONAL but if it is implemented it should follow the rules in > section 3.2. > > - Stated that when the dynamic PMTU is not implemented the sender > MUST NOT by default send IPv6 packets larger than 1280 into the > tunnel. > > - Stated that implementations MAY have a knob by which the MTU > can > be set to larger values on a tunnel by tunnel basis, but that > the default MUST be 1280 and that decapsulators need to be > configured to match the encapsulator's MTU. > > - Clarified text about ingress filtering e.g. that it applies to > packet delivered to transport protocols on the decapsulator as > well as packets being forwarded by the decapsulator, and how > the > decapsulator's checks help when IPv4 and IPv6 ingress filtering > is in place. From owner-v6ops@ops.ietf.org Thu Nov 6 20:20:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11343 for ; Thu, 6 Nov 2003 20:20:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHvEc-000A4r-DS for v6ops-data@psg.com; Fri, 07 Nov 2003 01:16:22 +0000 Received: from [148.88.16.231] (helo=zooty.lancs.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHvEZ-000A4e-2q for v6ops@ops.ietf.org; Fri, 07 Nov 2003 01:16:19 +0000 Received: from wing1.lancs.ac.uk ([148.88.1.13]) by zooty.lancs.ac.uk with esmtp (Exim 4.22) id 1AHvEY-0006yd-7y for v6ops@ops.ietf.org; Fri, 07 Nov 2003 01:16:18 +0000 Received: from apache by wing1.lancs.ac.uk with local (Exim 3.22 #1) id 1AHvEX-0003yE-00 for v6ops@ops.ietf.org; Fri, 07 Nov 2003 01:16:17 +0000 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) From: m.mackay@lancaster.ac.uk Date: Fri, 07 Nov 2003 01:16:17 +0100 Subject: RE: Comments: draft-savola-v6ops-transarch-01.txt To: v6ops@ops.ietf.org Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: binary Hi, Also see general comments at end... Specific Comments ----------------- However, the big picture of the transition seems not to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process. >> >> might it be useful to discuss these assumptions before moving on to >> the architecture... >> 2.1. General Principles General principles which should be carefully considered when architecturing the transition include at least: o security o simplicity o robustness >> >> How about introducing the idea of service provisioning here, >> not sure if it would count as a general principle >> Services to be deployed >> Behaviour/performance expected >> 2.2.1. Mechanisms, Deployment Models, and Services When forming a transition architecture, there are typically different building blocks to be used, from different classes, including: Mechanisms: o Providing IPv6 connectivity o Protocol translation o Application-specific protocol interoperability (ie. ALG or proxy) Deployment models for IP nodes: o IPv4-only o Dual-stack with only IPv4 connectivity o Dual-stack w/ IPv4/6 connectivity o Dual-stack with only IPv6 connectivity o IPv6-only And services: o IPv4-only o Separate IPv4 and IPv6 o IPv4/6 o IPv6-only >> >> Might be good to include some more discussion of the 'starting point' of >> the transitioning, e.g. IPv4 w/wo NAT, dual stack (various flavours) or >> new (IPv6 only?) >> 2.3. Transition Mechanism Deployment Considerations There are a few very important questions which must be addressed in the cases where a transition mechanism deployment is deemed necessary. For example: o if I deploy IPv6-only service, whose burden is it to enable its use by all clients I wish to make it accessible to? o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6 connectivity, whose burden is it to enable them to access all the services they want? o how much easier would it be to go for dual-stack approach instead? >> >> Definitely, I think the idea of discussing responsibility for the >> provisioning of transitioning is important... >> I think this is a good draft and something that should be discussed here sooner rather than later, however it’s perhaps a bit too general at this stage and doesn't actually specify an architecture as much as put forward some useful guidelines. It would be great to get more discussion of the 'assumptions' at the start of the document highlighting the main points of contention/discussion to help provide some clarification. Another point is that while now it is probably best to deploy dual stack with limited IPv6, it might be an idea to outline how this is likely to change in the future. Just some thoughts I had, hope this helps. Michael From owner-v6ops@ops.ietf.org Fri Nov 7 00:50:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18070 for ; Fri, 7 Nov 2003 00:50:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHzT5-000Cx7-TW for v6ops-data@psg.com; Fri, 07 Nov 2003 05:47:35 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHzT3-000Cwr-J4 for v6ops@ops.ietf.org; Fri, 07 Nov 2003 05:47:33 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 0D698FD09; Fri, 7 Nov 2003 00:47:33 -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, 7 Nov 2003 00:47:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Fri, 7 Nov 2003 00:47:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0512259C@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Thread-Index: AcOkwtlaTEz46BL1Q9S76FTxTh5uOwAL5FKg From: "Bound, Jim" To: "Alain Durand" , "Pekka Savola" Cc: "Randy Bush" , X-OriginalArrivalTime: 07 Nov 2003 05:47:32.0835 (UTC) FILETIME=[A37BDB30:01C3A4F2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable good point I agree. so I want to restate my view. why not go to DS? Ask for implementation reports too. I think we can support our ADs at the IESG layer too this is valid. It also would be great for v6ops morale :--) /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Alain Durand > Sent: Thursday, November 06, 2003 7:02 PM > To: Pekka Savola > Cc: Randy Bush; v6ops@ops.ietf.org > Subject: Re: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt >=20 >=20 > I do not see anything here that is fundamentally incompatible=20 > with the=20 > previous version > that will create interoperability issues. >=20 > I support this going to DS. >=20 > - Alain. >=20 >=20 >=20 > > > > - Removed automatic tunneling and use of IPv4-compatible > > addresses. > > > > - Removed default Configured Tunnel using IPv4=20 > "Anycast Address" > > > > - Dropped "or equal" in if (IPv4 path MTU - 20) is=20 > less than or > > equal to 1280 > > > > - Clarified that the dynamic path MTU mechanism in=20 > section 3.2 is > > OPTIONAL but if it is implemented it should follow=20 > the rules in > > section 3.2. > > > > - Stated that when the dynamic PMTU is not=20 > implemented the sender > > MUST NOT by default send IPv6 packets larger than=20 > 1280 into the > > tunnel. > > > > - Stated that implementations MAY have a knob by=20 > which the MTU=20 > > can > > be set to larger values on a tunnel by tunnel=20 > basis, but that > > the default MUST be 1280 and that decapsulators need to be > > configured to match the encapsulator's MTU. > > > > - Clarified text about ingress filtering e.g. that it=20 > applies to > > packet delivered to transport protocols on the=20 > decapsulator as > > well as packets being forwarded by the decapsulator, and how > > the > > decapsulator's checks help when IPv4 and IPv6=20 > ingress filtering > > is in place. >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Nov 7 07:37:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12715 for ; Fri, 7 Nov 2003 07:37:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AI5hj-000KeZ-NU for v6ops-data@psg.com; Fri, 07 Nov 2003 12:27:07 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AI5ha-000Ke2-Jd for v6ops@ops.ietf.org; Fri, 07 Nov 2003 12:26:58 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA7CQslC046050 for ; Fri, 7 Nov 2003 12:26:56 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA7CQra8214124 for ; Fri, 7 Nov 2003 13:26:53 +0100 Received: from zurich.ibm.com ([9.145.173.118]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA31560 for ; Fri, 7 Nov 2003 13:26:50 +0100 Message-ID: <3FAB8F65.D313543@zurich.ibm.com> Date: Fri, 07 Nov 2003 13:26:13 +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: draft-satapati-v6ops-natpt-applicability-00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think this is very useful draft and it's in good shape. I'd like to see the section on 3GPP2 completed, but otherwise the sooner we get this analysis published, the better. Brian From owner-v6ops@ops.ietf.org Fri Nov 7 10:21:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18278 for ; Fri, 7 Nov 2003 10:21:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AI8K8-0009lO-As for v6ops-data@psg.com; Fri, 07 Nov 2003 15:14:56 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AI8K6-0009lC-CR for v6ops@ops.ietf.org; Fri, 07 Nov 2003 15:14:54 +0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7FEp4t004242; Fri, 7 Nov 2003 07:14:51 -0800 (PST) Received: from naexfe02.na.qualcomm.com (naexfe02.qualcomm.com [129.46.51.214]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7FEm0N015471; Fri, 7 Nov 2003 07:14:49 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.61]) by naexfe02.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 7 Nov 2003 07:14:48 -0800 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.6470.0 Subject: RE: draft-satapati-v6ops-natpt-applicability-00 Date: Fri, 7 Nov 2003 07:14:47 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327C5F@NAEX01.na.qualcomm.com> Thread-Topic: draft-satapati-v6ops-natpt-applicability-00 Thread-Index: AcOlLrOWltq7pmkRSIKH+uyfDmXLHQAEvv3g From: "Barany, Pete" To: "Brian E Carpenter" , "IPv6 Operations" X-OriginalArrivalTime: 07 Nov 2003 15:14:48.0833 (UTC) FILETIME=[E284FF10:01C3A541] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable We are working on the 3GPP2 material. If the WG agrees to move forward with this I-D, we will get consensus and incorporate this material into the next version of the I-D. Thanks. Pete -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, November 07, 2003 4:26 AM To: IPv6 Operations Subject: draft-satapati-v6ops-natpt-applicability-00 I think this is very useful draft and it's in good shape. I'd like to see the section on 3GPP2 completed, but otherwise the sooner we get this analysis published, the better. Brian From owner-v6ops@ops.ietf.org Fri Nov 7 10:36:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18926 for ; Fri, 7 Nov 2003 10:36:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AI8b7-000BXg-LT for v6ops-data@psg.com; Fri, 07 Nov 2003 15:32:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AI8b2-000BXM-Rt for v6ops@ops.ietf.org; Fri, 07 Nov 2003 15:32:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA7FT3v30638; Fri, 7 Nov 2003 17:29:03 +0200 Date: Fri, 7 Nov 2003 17:29:03 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: IPv6 Operations Subject: Re: draft-satapati-v6ops-natpt-applicability-00 In-Reply-To: <3FAB8F65.D313543@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, 7 Nov 2003, Brian E Carpenter wrote: > I think this is very useful draft and it's in good shape. > I'd like to see the section on 3GPP2 completed, but otherwise > the sooner we get this analysis published, the better. Thanks Brian. Just in case, did you have a look at the "NAT-PT applicability considerations" thread, at: http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html .. which tried to provoke thoughts on several subjects relating to the document which might be unanimous. Do you have any further comments to make based on these? -- 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 Nov 7 10:36:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18973 for ; Fri, 7 Nov 2003 10:36:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AI8bd-000BZY-2y for v6ops-data@psg.com; Fri, 07 Nov 2003 15:33:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AI8ba-000BZE-SW for v6ops@ops.ietf.org; Fri, 07 Nov 2003 15:32:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA7FWsZ30707; Fri, 7 Nov 2003 17:32:54 +0200 Date: Fri, 7 Nov 2003 17:32:53 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: bob@thefinks.com, Subject: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, ADDITONAL NOTE: due to the WG feedback, we'll be investigating whether to go to DS directly. If you have preferences about this, please indicate that when sending feedback on the draft in WG LC. In any case, if we can't get to DS immediately, we'll do it soon afterwards, so a lot review for the document would be appreciated! Pekka writing as co-chair On Mon, 3 Nov 2003, Pekka Savola wrote: > This is a WG Last Call for comments on sending > draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms for IPv6 > Hosts and Routers", to the IESG for consideration as Proposed Standard: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt > > (We're hoping to recycle to Draft Standard soon afterwards.) > > Please review these documents carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this document > is ready to go to the IESG. Silence does NOT indicate consent. Unless > sufficient support is demonstrated on the list, the documents will not be > sent to the IESG. > > The last call will end in about 3 weeks, on 25th November. > > Pekka, Jonne & Bob > > > > > > -- 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 Nov 7 12:17:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24831 for ; Fri, 7 Nov 2003 12:17:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIA9u-000Mvm-MY for v6ops-data@psg.com; Fri, 07 Nov 2003 17:12:30 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIA9s-000Mva-UP for v6ops@ops.ietf.org; Fri, 07 Nov 2003 17:12:29 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1AIA9s-000KjB-JQ for v6ops@ops.ietf.org; Fri, 07 Nov 2003 09:12:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 7 Nov 2003 08:14:07 -0800 From: Randy Bush To: Jim Bound Cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA221@tayexc13.americas.cpqcorp.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit > Yes it should move to DS when this completes. I think you can get > implementor reports too. process-nazi nit: it is not 'implementor reports' we need for ds. it is 'interoperability reports'. what we are doing is testing the spec to see if it is sufficiently clear that multiple implementors get the same semantics for each bit of the spec. so, for example, we don't care if implementors I0 and I1 don't fully interoperate. heck, formally, we don't even care if there are no two interoperable implementations. we do care that, for each feature/aspect of the spec, F0 through FN, some set of implementations consisting of more than one member interoperate for that feature. randy From owner-v6ops@ops.ietf.org Fri Nov 7 13:33:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28133 for ; Fri, 7 Nov 2003 13:33:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIBM4-0004ao-UZ for v6ops-data@psg.com; Fri, 07 Nov 2003 18:29:08 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIBM2-0004aV-Jt for v6ops@ops.ietf.org; Fri, 07 Nov 2003 18:29:06 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2003 10:31:29 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA7IT4mU029417 for ; Fri, 7 Nov 2003 10:29:05 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANI77833; Fri, 7 Nov 2003 10:29:02 -0800 (PST) Date: Fri, 7 Nov 2003 10:29:02 -0800 (PST) From: Suresh K Satapati To: v6ops@ops.ietf.org Subject: Re: draft-satapati-v6ops-natpt-applicability-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, Lets not mislead the WG here. From the thread: http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html I disagree with: 2 b) only a more limited set of IPv6-only networks in the applicability statement. These scenarios, may be counterproductive in the face of dual-stack deployment. 3. The recommendation of the specific scenarios. In the body of the text, some applicability was identified in two kinds of networks: the legacy IPv4 equipment and 3GPP. There was no full consensus that going down that deployment path (the point above) would necessarily make sense. As I see it, there was infact a consensus among the DT on the scenarios. The above are more of your opinions on the draft. Pls do not represent the DT on the above. I did not see a major disagreement on the applicable scenarios, except from you (as in 2b and 3) . The slight opposition was on the IMS media translation in 3GPP scenario. Others can speak for themselves on this. -- Suresh On Fri, 7 Nov 2003, Pekka Savola wrote: > Hi, > > On Fri, 7 Nov 2003, Brian E Carpenter wrote: > > I think this is very useful draft and it's in good shape. > > I'd like to see the section on 3GPP2 completed, but otherwise > > the sooner we get this analysis published, the better. > > Thanks Brian. Just in case, did you have a look at the "NAT-PT > applicability considerations" thread, at: > > http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html > > .. which tried to provoke thoughts on several subjects relating to the > document which might be unanimous. > > Do you have any further comments to make based on these? > > -- > 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 Nov 7 14:50:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03849 for ; Fri, 7 Nov 2003 14:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AICX0-000BPv-Cp for v6ops-data@psg.com; Fri, 07 Nov 2003 19:44:30 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AICWq-000BOX-02 for v6ops@ops.ietf.org; Fri, 07 Nov 2003 19:44:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA7Ji1u03528; Fri, 7 Nov 2003 21:44:01 +0200 Date: Fri, 7 Nov 2003 21:44:01 +0200 (EET) From: Pekka Savola To: Suresh Satapati cc: Brian E Carpenter , IPv6 Operations Subject: Re: draft-satapati-v6ops-natpt-applicability-00 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 7 Nov 2003, Suresh Satapati wrote: [...] > As I see it, there was infact a consensus among the DT on the scenarios. > The above are more of your opinions on the draft. Pls do not represent the > DT on the above. > > I did not see a major disagreement on the applicable scenarios, except > from you (as in 2b and 3) . The slight opposition was on the IMS media > translation in 3GPP scenario. Others can speak for themselves on this. FWIW, I believe Rob Austein was not in full agreement with these scenarios, at least, hence the DT was not animous. -- 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 Nov 7 15:37:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06672 for ; Fri, 7 Nov 2003 15:37:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIDHH-000FcU-UR for v6ops-data@psg.com; Fri, 07 Nov 2003 20:32:19 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIDHD-000FbM-KG for v6ops@ops.ietf.org; Fri, 07 Nov 2003 20:32:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA7KWE304433; Fri, 7 Nov 2003 22:32:14 +0200 Date: Fri, 7 Nov 2003 22:32:13 +0200 (EET) From: Pekka Savola Reply-To: v6ops@ops.ietf.org To: v6ops@ops.ietf.org cc: ipv6@ietf.org Subject: SUMMARY: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I'll try to summarize this thread, or at least try to find the most important points from it, because it went on for long and I doubt many had energy enough to keep up with it. (more accurately, I'll just summarize the first part of the thread that was integral to the original topic, see the last point) I believe we should try to avoid crossposting about this subject to both v6ops and ipv6 WG in the future :-). - this seems like a problem that would merit from further investigation - it was not sufficiently clear that this mechanism is about optimizing away unnecessary DNS lookups and making them more robust (e.g. in the face of DNS/load-balancer misbehaviour); default address selection does not help in this case (however, if destination address selection is not implemented, this method would give an additional benefit as well) - currently defined AI_ADDRCONFIG is rather vague, and it should be clarified in any case (e.g., "is address without route OK?") if it's intended to be usable ("too ambiguous to implement") - the problem description (by yours truly) was not sufficiently clear, so it wasn't clear what problems the proposed modifications were trying to address - some application writers are moving away / staying away from getaddrinfo because of the side-effects of e.g. DNS resolvers/load-balancers, also for the majority installed base of IPv4-only and dual-stack (but without v6 connectivity) systems; this option would help a bit there. - a system-level global knob, in addition to an application getaddrinfo hint, could be useful, but this should probably default to off at least (the point below) - the default application behaviour should not be changed, that is, AI_ADDRCONFIG should remain optional; the getaddrinfo/system should not try to second-guess what an application wants, nor hide information that exists in the DNS unless the application indicates it wants the information filtered - if sufficiently many people think link-locals w/ getaddrinfo would be a useful feature, a tradeoffs document instead of a purely recommendations document would be in order - this does not change the situation in the case where a route exists, but an ICMP DU is received (v6onbydefault-00 section 3.2 discusses this), or the case when the packets are silently dropped (e.g. by a discarding firewall) - the latter parts of the thread went into an area ("getaddrinfo should use DNS-only vs not") beyond the main scope of the original topic, and are not included in this thread summary; suffice to say that opinions differ on whether getaddrinfo should be agnostic of the lookup mechanism or not. However, this does have a connection to the original debate: the addition of the link-locals to AI_ADDRCONFIG would cause problems if getaddrinfo was used with local lookup services (or similar) other than the DNS. So, for the purposes of AI_ADDRCONFIG and link-locals, the link local exclusion should probably be limited to DNS or other similar naming services, if done. ---------- Forwarded message ---------- Date: Tue, 28 Oct 2003 14:30:05 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Cc: ipv6@ietf.org Subject: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Hi, (Cc:'ed to ipv6@ietf.org as well, because this seems to have significant impact with the IPv6 APIs as well..) When revising my "transarch" document, I noticed another issue v6 on-by-default might cause. If v6 is enabled by default, all the implementations I know generate the link-local addresses for all the interfaces automatically, unless explicitly configured otherwise (some don't have this knob). This seems to cause an unintended consequence with getaddrinfo and its AI_ADDRCONFIG hint (as specified in the basic socket API RFC). That is, AI_ADDRCONFIG hint causes AAAA DNS queries to be made only if an IPv6 address is configured on the node (similar with v4). Loopback addresses are excluded from this. However, these typically autoconfigured link-local addresses are *not* excluded. In consequence, AI_ADDRCONFIG seems to be of less utility than at least I had hoped. The only reason I could think of for AI_ADDRCONFIG *not* excluding the link-locals as well could be that if a node is expected to be able to communicate using regular, getaddrinfo() -using apps, using the link-local addresses (this would eliminate this possibility). IMHO, using link-local addresses for anything except well-specified purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really counter-productive -- as you'll have to make those apps be able to distinguish the zone identifiers as well, and that's probably something we DON'T want to do. But your mileage may vary. So, I'll conclude by a few questions to give food for thought: - does this seem like a problem, that is, should getaddrinfo() + AI_ADDRCONFIG perform AAAA DNS queries etc. if the node only has v6 link-local/loopback addresses? - is getaddrinfo() + link-local addresses something we should support? - should this be fixed by e.g.: a) recommending that the implementations filter out link-locals as well when doing AI_ADDRCONFIG (a BCP/Info document) b) specifying additional semantics for AI_ADDRCONFIG c) specifying a new hint which would perform this Note: if we go select any of these (especially the latter two), it might make sense to bring this discussion up in the relevant API forums like POSIX as well, because the IETF API documents are just Informational RFCs. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Fri Nov 7 17:07:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10249 for ; Fri, 7 Nov 2003 17:07:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIEgW-000NOY-MZ for v6ops-data@psg.com; Fri, 07 Nov 2003 22:02:28 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIEgS-000NOC-Em for v6ops@ops.ietf.org; Fri, 07 Nov 2003 22:02:24 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id A55C993; Sat, 8 Nov 2003 07:02:22 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org, bob@thefinks.com, jonne.soininen@nokia.com Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Fri, 7 Nov 2003 17:32:53 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031107220222.A55C993@coconut.itojun.org> Date: Sat, 8 Nov 2003 07:02:22 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Mon, 3 Nov 2003, Pekka Savola wrote: > > This is a WG Last Call for comments on sending > > draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms for IPv6 > > Hosts and Routers", to the IESG for consideration as Proposed Standard: suggestion in section 3.7 (quoted below) is unneecessary, or seems too strong. could we remove it, or make it MAY instead of SHOULD at least? reasons: - coupling link-local address with tunnel endpoint IPv4 address makes it harder to switch tunnel endpoint IPv4 address - reconfiguration of IPv6 link-local address (usually used for nexthop) is needed. therefore i prefer them to be separate. it is from my long operational experience. - RFC2472 section 4.1 has better way to generate interface ID. - SHOULD is too strong as the use of different selection algorithm of link-local address here does not impose any interoperability issue. btw, RFC1933 did not have such requirement (SHOULD). RFC2893 introduced this. i did voiced my concern but was not integrated into RFC2893. itojun > The Interface Identifier [RFC2373] for such an Interface SHOULD be > the 32-bit IPv4 address of that interface, with the bytes in the same > order in which they would appear in the header of an IPv4 packet, > padded at the left with zeros to a total of 64 bits. Note that the > "Universal/Local" bit is zero, indicating that the Interface > Identifier is not globally unique. When the host has more than one > IPv4 address in use on the physical interface concerned, an > administrative choice of one of these IPv4 addresses is made when > forming the link-local address. From owner-v6ops@ops.ietf.org Fri Nov 7 17:11:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10483 for ; Fri, 7 Nov 2003 17:11:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIElP-000NoL-FM for v6ops-data@psg.com; Fri, 07 Nov 2003 22:07:31 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIElH-000Nny-QW for v6ops@ops.ietf.org; Fri, 07 Nov 2003 22:07:23 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id D3FAF96; Sat, 8 Nov 2003 07:07:22 +0900 (JST) To: v6ops@ops.ietf.org Subject: phone device References: <3FAB8F65.D313543@zurich.ibm.com> X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 From: itojun@iijlab.net Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031107220722.D3FAF96@coconut.itojun.org> Date: Sat, 8 Nov 2003 07:07:22 +0900 (JST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk i have been told that 3GPP/3GPP2 network will be IPv6 only, and we need twists to support connection from 3GPP/3GPP2 handset to IPv4 server (such as yahoo). http://press.nokia.com/PR/200311/923684_5.html introduces CDMA phone with dual-stack support. i'm wondering what is the difference in 3GPP/3GPP2 statement i saw in the mailing list, and the nokia phone. itojun From owner-v6ops@ops.ietf.org Fri Nov 7 17:56:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12072 for ; Fri, 7 Nov 2003 17:56:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIFSl-000147-B0 for v6ops-data@psg.com; Fri, 07 Nov 2003 22:52:19 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIFSi-00013l-0L for v6ops@ops.ietf.org; Fri, 07 Nov 2003 22:52:16 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA7MqEe12695 for ; Sat, 8 Nov 2003 00:52:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 8 Nov 2003 00:52:14 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 8 Nov 2003 00:52:14 +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: phone device Date: Sat, 8 Nov 2003 00:52:13 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE000@esebe005.ntc.nokia.com> Thread-Topic: phone device Thread-Index: AcOlfDXvnMT5rMPqQoKelOOaNMhOoAAAaGxQ From: To: , X-OriginalArrivalTime: 07 Nov 2003 22:52:14.0644 (UTC) FILETIME=[C97F6740:01C3A581] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, itojun! I try to clarify this a little bit: - 3GPP2 CDMA2000 standards currently support Simple IPv4, Mobile IPv4 = and Simple IPv6 modes. Both Mobile IPv4 and Simple IPv4 modes are = currently deployed in commercial networks. Mobile IPv6 mode will (most = probably) be specified by the end of 2004, so commercial deployments are = expected (probably) in ~2005. There is a PPP link between a 3GPP2 mobile = and its "default router" PDSN (Packet Data Serving Node); all modes can = in theory be (simultaneously) run on that PPP link. So IPv4 mode can be = used when communicating with v4 peer nodes, and IPv6 mode can be used = when communicating with IPv6 peer nodes (of course, depending on network = support). If the network only supports IPv4 (which is the case today), = IPv6-in-IPv4 tunneling (e.g. ISATAP) in the mobile is one alternative. - 3GPP networks support both IPv4 and IPv6 by supporting IPv4 and IPv6 = type of PDP contexts, starting from 3GPP Rel99 networks. IPv4 is = deployed in current GPRS networks and IPv6 deployment is coming in the = networks. I'm not making any advertisements, but this is an example of a = 3GPP phone that supports both IPv6 and IPv4 types of PDP contexts = http://www.nokia.com/nokia/0,,47550,00.html . A good basic principle is = to use IPv4 PDP contexts when talking to IPv4 peer nodes and IPv6 PDP = contexts when talking to IPv6 peer nodes. So that environment is a dual = stack environment. For further information, see RFC 3314, RFC 3574 and = draft-ietf-v6ops-3gpp-analysis-07.txt - What comes to *IMS specifications*, 3GPP Release 5 (/ Release 6) IMS = is a SIP-based *IPv6-only network domain* and its transition scenarios = are analysed in RFC3574 / draft-ietf-v6ops-3gpp-analysis-07.txt / IMS = scenario 1&2. In the IMS case, communications with (external) = IPv4(-only) SIP nodes need a translator solution. Did that clarify or cause more confusion? BR, -Juha W.- -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext itojun@iijlab.net Sent: 08 November, 2003 00:07 To: v6ops@ops.ietf.org Subject: phone device i have been told that 3GPP/3GPP2 network will be IPv6 only, and we need twists to support connection from 3GPP/3GPP2 handset to IPv4 server (such as yahoo). http://press.nokia.com/PR/200311/923684_5.html introduces CDMA phone with dual-stack support. i'm wondering what is the difference in 3GPP/3GPP2 statement i saw in the mailing list, and the nokia phone. itojun From owner-v6ops@ops.ietf.org Sun Nov 9 12:16:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04174 for ; Sun, 9 Nov 2003 12:16:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIt0I-0002Cs-MN for v6ops-data@psg.com; Sun, 09 Nov 2003 17:05:34 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIt0B-0002Cg-Fa for v6ops@ops.ietf.org; Sun, 09 Nov 2003 17:05:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA9H5PX13492 for ; Sun, 9 Nov 2003 19:05:26 +0200 Date: Sun, 9 Nov 2003 19:05:25 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: baker-ipv6-renumbering comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, IMHO the work is important. It is not clear whether this belongs to multi6 or v6ops, but the current charter of multi6 doesn't allow it while v6ops does (by being awfully generic).. To summarize, the document is in a pretty good shape. I think there are several applications-related problems that need to be spelled out and discussed quite a bit more like: * what to do about network settings (like firewall rules, NTP/DNS server configs, etc.) which, if even looked up from the DNS, are typically never refreshed or refreshed only at reboots etc., making the renumbering a real PITA. We need to raise awareness of this issue to facilitate better "service reconfiguration" capabilities * what to do about the process of apps looking up and address and storing the result basically foreverm a very difficult problem.. substantial ----------- 1) 2.2, preparation for renumbering, has: Prior to renumbering, various processes will need to be reconfigured to confirm bindings between names and addresses more frequently. In normal operation, DNS name translations and DHCP bindings are often given relatively long lifetimes to limit server load. In order to reduce transition time from old to new prefix it may be necessary to reduce the time to live (TTL) associated with DNS records and increase the frequency with which DHCP clients contact the DHCP server. ==> I'd also add here something like: It's also required to plan the procedure how to ensure that the configuration parameters will be updated during the period of stably using both the prefixes. ... The biggest problem in section 2.6.2 on transition to the use of ne addresses is ensuring that the users also have a means to start using the new prfix; DNS update may not be quick enough (e.g., if NTP servers are only looked up at boot if they're configured as names in the config, etc.) ... Once all sessions are deemed to have completed, there will be no dependence on the old prefix. It may be removed from the configuration of the routing system, and from any static configurations that depend on it. ==> The same is also in section 2.7 in particular; one could note that there could still be *new* sessions even if the DNS has been updated and the TTL has expired, because the apps don't store the TTL, as has been noticed later in this document. ... in section 3.1: Application designers frequently take short-cuts to save memory or increase responsiveness, and a common short-cut is to use static configuration of IP addresses rather than DNS translation to obtain the same. [...] ==> I think the application aspects deserves a subsection of its own, starting from the sentence above. ==> not looking up something is easy to fix, because the lookups are *easy* and *simple*. The more difficult problem is storing the result.. ... o must obtain a new translation if a new session is opened with the same service after the DNS record's lifetime expires, ==> this is the critical point. As it's *really, really* difficult to do, it needs to be pointed out as such.. these are non-trivial problems to fix (except for the first bullet, in most circumstances..) 2) Clarifying the DNS update problems: 4.1 Dynamic updates to DNS across administrative domains When a DNS server at the start of a zone transitions to the use of a new address, the associated information in the database of the parent DNS server must be updated. If the parent DNS server is in a different administrative domain, the renumbering organization must contact the administration of the parent DNS server, typically through a manual procedure. There is an opportunity to automate this update process through the development of an appropriate protocol. ==> based on this, it's not clear why DynDNS or an appropriate sub-delegation does not cut it? Maybe needs more elaboration. (Note: "DNS server at the start of a zone" -- a bit unclear, maybe reword?) 4.2 Management of the inverse zone In networks where hosts obtain IPv6 addresses through SLAC, updates of reverse zone are problematic because of lack of trust relationship between administrative domain owning the prefix and the host assigning the the low 64 bits using SLAC. For example, suppose a host, H, from organization A roams to a network owned by organization B. If H obtains an address through SLAC, a DNS server from B will own the reverse zone for that address. For H to update its reverse entry, B must accept a DDNS request from H, requiring that an inter-administrative domain trust relationship exist between H and B. The IETF should develop a BCP recommendation for addressing this problem. ==> I'm not sure if I understand the relation of this problem to the renumbering properly. Maybe should be elaborated a bit? It seems that this is a problem in two renumbering-related events: - a mobile node is attached to a site undergoing renumbering for long enough so that it will be affected by the transitions (not sure if this is typical), or - a "visiting" node (e.g., from a different department or a branch office) is connected for a longer period of time to a local network, and only the local network is renumbered -- and the visited node isn't adapted to use the hostname/domainname etc. from the local network. 3) appendix A on latecy management in DNS. This probably needs to be reworked a bit, a few points: - the formulas could be simplified if we conclude that DNS update time to secondaries (TU) is so much smaller than the rest (with the NOTIFY/XFR this is in the order or seconds or minutes at most).. we can simplify the analysis. - I believe the current formulations are only accurate if TTLNEW is smaller than a half of TTLOLD. This is typical, of course..? - Maybe we should change time model a bit, to be something like: TC - (TTLOLD + TTLNEW + ADMIN_UPDATE_TIME) .. where ADMIN_UPDATE_TIME is the time that the administrators want to reserve for making the DNS changes to the zones etc (the update window length..) - (one typo: s/corrse/corres/) semi-substantial ---------------- ==> add "network element" to the terminology, as it's used quite a bit.. DHCP prefix delegation: An extension to DHCP [16] to automate the assignment of a prefix from an ISP to a customer[17] ==> PD doesn't have to be done between the ISP and the customer so reword: DHCP prefix delegation: An extension to DHCP [16] to automate the assignment of a prefix, e.g. from an ISP to a customer [17] ... SLAC: StateLess Address Autoconfiguration [10] ==> I'd use the term SLAAC rather than SLAC, the former is used more. Also note that in the text, you often use "stateless address configuration", which need to be reworded. 1.3 Summary of what must be changed ==> some of these are more verbose than the others.. I'd suggest trying to summarize the steps similarly in each case.. The new link prefixes may be advertised by the network elements, but the router advertisements should not cause hosts to perform SLAC on the new link prefixes. ==> I think it would be important to spell out how to do that. Network elements may have IPv6 addresses from the new link prefixes assigned to interfaces, taking care that this assignment does not interfere with the use of IPv6 addresses from the old prefix and does not cause the new link prefix to be advertised to hosts. ==> note that one has to be careful (I'm not as a matter of fact sure how to ensure this) that the network elements won't prefer the new addresses prematurely, especially for outbound connectivity.. (unless one has been prepared for that, of course..) 2.6.1 Transition of DNS service to the new prefix The DNS service is configured to use the new prefix by removing any IPv6 addresses for internal communications from the DNS server configuration. External references to the DNS servers, such as in the DNS service from which this DNS domain was delegated, are updated to use the IPv6 addresses from the new prefix. ==> I had difficulty understanding the point of the first sentence, maybe reword like: The DNS service is configured to use only the new prefix by removing any IPv6 addresses from the DNS server configuration. (what does internal communications signify here.. isn't it rather irrelevant?) Prefixes from the old prefix in router advertisements and addresses from the old prefix provided through DHCP should have their preferred lifetimes set to zero at this point. ==> continue at the end with like: , to avoid being used for new communications. 5. Security Considerations ==> part of this section should probably go to a conclusions section or something like that, needs to be organized better, and the meat should be in the body of the draft? (At least the paragraph starting with "A subtle" could be integrated with the rest..) editorial --------- This document also contains recommendations for application design and network management which, if taken seriously, may avoid or minimize the impact of the issues. ==> this is at the end of section 1 twice, remove the other records will be updated and PTR records are added to the ipv6.arpa ... removed from the ipv6.arpa domain. ==> s/ipv6/ip6/ o The DHCP Reconfigure message can be sent from the server to the hosts to cause the hosts to contact the server immediately ==> add the period at the end For example, addresses assigned from the new prefix are added to any addresses from the old prefix assigned to interfaces on the network elements. ==> s/added to/configured in addition to/ ? ==> I'd also remove the "assigned ...", seems pretty redundant.. The new prefix is added to the routing infrastructure, firewall filters, ingress/egress lists and other forwarding and filtering ==> s/lists/access lists/ (or "filters") Once the new prefix has been added to the network infrastructure, access-lists, route-maps and other network configuration options that ==> add "then" after the first line, the the period-separated list is easier to read then.. defenses in place before advertising the prefix, if only because the prefix may come under immediate attack. ==> s/immediate/an immediate/ interface (apart from interfaces that use only the link local address), and two addresses are available for the use of any host, one in the old prefix and one in the new. This is a stable configuration. ==> s/link local/link-local/ ==> s/two/two non-link-local/ (just being pedantic :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Nov 9 12:48:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04816 for ; Sun, 9 Nov 2003 12:48:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AItZd-00049S-JU for v6ops-data@psg.com; Sun, 09 Nov 2003 17:42:05 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AItYI-00045E-VD for v6ops@ops.ietf.org; Sun, 09 Nov 2003 17:40:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA9HeW713970; Sun, 9 Nov 2003 19:40:34 +0200 Date: Sun, 9 Nov 2003 19:40:32 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org, , Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: <20031107220222.A55C993@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Sat, 8 Nov 2003, Jun-ichiro itojun Hagino wrote: > > On Mon, 3 Nov 2003, Pekka Savola wrote: > > > This is a WG Last Call for comments on sending > > > draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms for IPv6 > > > Hosts and Routers", to the IESG for consideration as Proposed Standard: > > suggestion in section 3.7 (quoted below) is unneecessary, or seems > too strong. could we remove it, or make it MAY instead of SHOULD > at least? FWIW¸ I don't have a strong opinion either way. RFC2472 can't be listed as normative reference, and the algorithm is too long to describe. MAY could be OK here, with a caveat that this is indeed for bidirectional tunneling only. (For example, some mechanisms may want to re-use the encoding to embed the tunnel address to the low-end address. With bi-dir configured tunneling, this should not really be an issue.) > reasons: > - coupling link-local address with tunnel endpoint IPv4 address makes > it harder to switch tunnel endpoint IPv4 address - reconfiguration > of IPv6 link-local address (usually used for nexthop) is needed. > therefore i prefer them to be separate. it is from my long > operational experience. Inheriting it from a physical device has its own problems, e.g. if the hardware fails on the tunnel peer. A setting independent of MAC address has some uses. Note: the document should be clearer that configured tunnels are typically point-to-point, and then you typically don't even need the link-local addresses, so this becomes practically rather irrelevant.. [...] > - SHOULD is too strong as the use of different selection algorithm > of link-local address here does not impose any interoperability issue. True, I don't really see that w/ configured tunneling how the address is configured really matters at all.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Nov 9 12:51:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04882 for ; Sun, 9 Nov 2003 12:51:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AItcu-0004Jr-HO for v6ops-data@psg.com; Sun, 09 Nov 2003 17:45:28 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AItcs-0004JP-LL for v6ops@ops.ietf.org; Sun, 09 Nov 2003 17:45:26 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id BF4D793; Mon, 10 Nov 2003 02:45:25 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org, bob@thefinks.com, jonne.soininen@nokia.com Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Sun, 9 Nov 2003 19:40:32 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031109174525.BF4D793@coconut.itojun.org> Date: Mon, 10 Nov 2003 02:45:25 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Note: the document should be clearer that configured tunnels are typically > point-to-point, and then you typically don't even need the link-local > addresses, so this becomes practically rather irrelevant.. RFC2373/3513: All interfaces are required to have at least one link-local unicast address. i guess what you are trying to mean is "don't even need to USE the link-local address of the peer, or the node itself". itojun From owner-v6ops@ops.ietf.org Sun Nov 9 12:57:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04946 for ; Sun, 9 Nov 2003 12:57:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AItiv-0004gm-V7 for v6ops-data@psg.com; Sun, 09 Nov 2003 17:51:41 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AItit-0004gZ-UZ for v6ops@ops.ietf.org; Sun, 09 Nov 2003 17:51:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA9HpW214119; Sun, 9 Nov 2003 19:51:32 +0200 Date: Sun, 9 Nov 2003 19:51:32 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: <20031109174525.BF4D793@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 10 Nov 2003, Jun-ichiro itojun Hagino wrote: > > Note: the document should be clearer that configured tunnels are typically > > point-to-point, and then you typically don't even need the link-local > > addresses, so this becomes practically rather irrelevant.. > > RFC2373/3513: > All interfaces are required to have at least one link-local unicast > address. > > i guess what you are trying to mean is "don't even need to USE the > link-local address of the peer, or the node itself". Yep, of course. The address is needed, but there's no use sweating too much what it is if it shouldn't need to be used anyway (by users at least).. :-) Note: another thing to say is that if you have N v4 addresses, you don't have to generate a N link-local addresses.. should be obvious 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 Sun Nov 9 12:59:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04992 for ; Sun, 9 Nov 2003 12:59:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AItl1-0004rr-Rh for v6ops-data@psg.com; Sun, 09 Nov 2003 17:53:51 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AItl0-0004rf-HI for v6ops@ops.ietf.org; Sun, 09 Nov 2003 17:53:50 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id A7D9396; Mon, 10 Nov 2003 02:53:49 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Sun, 9 Nov 2003 19:51:32 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031109175349.A7D9396@coconut.itojun.org> Date: Mon, 10 Nov 2003 02:53:49 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > i guess what you are trying to mean is "don't even need to USE the > > link-local address of the peer, or the node itself". > Yep, of course. The address is needed, but there's no use sweating too > much what it is if it shouldn't need to be used anyway (by users at > least).. :-) for implementers it matters a lot :-) itojun From owner-v6ops@ops.ietf.org Sun Nov 9 13:51:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06406 for ; Sun, 9 Nov 2003 13:51:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIuXM-000815-Jq for v6ops-data@psg.com; Sun, 09 Nov 2003 18:43:48 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIuXI-00080t-Ih for v6ops@ops.ietf.org; Sun, 09 Nov 2003 18:43:44 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 9 Nov 2003 10:43:47 -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); Sun, 9 Nov 2003 10:44:09 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 09 Nov 2003 10:43:42 -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); Sun, 9 Nov 2003 10:43:41 -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); Sun, 9 Nov 2003 10:43:42 -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); Sun, 9 Nov 2003 10:42:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.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: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Sun, 9 Nov 2003 10:43:41 -0800 Message-ID: Thread-Topic: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Thread-Index: AcOm7CAUG5GBsVPhQLOk31x0bmrs2QABNdsA From: "Christian Huitema" To: "Jun-ichiro itojun Hagino" , Cc: X-OriginalArrivalTime: 09 Nov 2003 18:42:57.0398 (UTC) FILETIME=[4B1C4960:01C3A6F1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > > i guess what you are trying to mean is "don't even need to USE the > > > link-local address of the peer, or the node itself". > > Yep, of course. The address is needed, but there's no use sweating too > > much what it is if it shouldn't need to be used anyway (by users at > > least).. :-) >=20 > for implementers it matters a lot :-) I am not so sure that implementation details belong in a standard track RFC. The IETF is about interoperability, i.e. wire formats, protocol state machines, and timers. If those are well specified, then two teams can take the spec, develop their implementation, and interoperate. -- Christian Huitema From owner-v6ops@ops.ietf.org Sun Nov 9 18:09:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17508 for ; Sun, 9 Nov 2003 18:09:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIyZA-000JEd-V1 for v6ops-data@psg.com; Sun, 09 Nov 2003 23:01:56 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIyZ8-000JDo-37 for v6ops@ops.ietf.org; Sun, 09 Nov 2003 23:01:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA9N1lF18875; Mon, 10 Nov 2003 01:01:47 +0200 Date: Mon, 10 Nov 2003 01:01:47 +0200 (EET) From: Pekka Savola To: m.mackay@lancaster.ac.uk cc: v6ops@ops.ietf.org Subject: RE: Comments: draft-savola-v6ops-transarch-01.txt 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, Thanks for comments. Sorry for the delay in responding; I'll revise the doc based on this (and a couple of other documents) to -03 after the meeting. (Btw, a different quoting style might be easier to follow-up.. :-) On Fri, 7 Nov 2003 m.mackay@lancaster.ac.uk wrote: >> However, the big picture of the transition seems not to have been >> discussed sufficiently. Therefore, different people have different >> assumptions on the process, which makes planning the transition >> architecture very difficult: indeed, it seems that there is a lack of >> architecture in the transition process. > > might it be useful to discuss these assumptions before moving on to > the architecture... I think this has improved; a new section has been added before 2.1 already in -02 version. > How about introducing the idea of service provisioning here, > not sure if it would count as a general principle > Services to be deployed > Behaviour/performance expected Hmm.. could you elaborate a bit more? did you have specific ideas in mind how to integrate it to the rest of the document? That is, what level of services you're referring to? The expected performance etc. in realistic terms might also be difficult to estimate.. > Might be good to include some more discussion of the 'starting point' of > the transitioning, e.g. IPv4 w/wo NAT, dual stack (various flavours) or > new (IPv6 only?) Could you elaborate a bit (please check -02 version btw, this has improved as well!)? There *maybe* could be some brief description without starting scenarios, like v4 w/ NAT or v4 w/o NAT, but otherwise I think it has been covered.. > Definitely, I think the idea of discussing responsibility for the > provisioning of transitioning is important... Yep.. I'm not sure how to proceed from there, though. If you have thoughts how to make these issues more concrete (not just questions here and there, and discussed a bit here and there) I'm all ears :-) > I think this is a good draft and something that should be discussed here > sooner rather than later, however it’s perhaps a bit too general at this > stage and doesn't actually specify an architecture as much as put > forward some useful guidelines. I'm trying to avoid preaching "gospel", giving folks thoughts is more important :-) > It would be great to get more discussion of the 'assumptions' at the > start of the document highlighting the main points of > contention/discussion to help provide some clarification. Yep, already there a bit .. see if you agree if it's sufficient or not? > Another point is that while now it is probably best to deploy dual stack > with limited IPv6, it might be an idea to outline how this is likely to > change in the future. True.. Thanks, -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Nov 10 00:18:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25921 for ; Mon, 10 Nov 2003 00:18:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJ4Nb-000KDB-AS for v6ops-data@psg.com; Mon, 10 Nov 2003 05:14:23 +0000 Received: from [66.218.79.74] (helo=web80504.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJ4NY-000KCf-3k for v6ops@ops.ietf.org; Mon, 10 Nov 2003 05:14:20 +0000 Message-ID: <20031110051419.98144.qmail@web80504.mail.yahoo.com> Received: from [130.129.72.244] by web80504.mail.yahoo.com via HTTP; Sun, 09 Nov 2003 21:14:19 PST Date: Sun, 9 Nov 2003 21:14:19 -0800 (PST) From: Fred Templin Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1817518015-1068441259=:94772" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_01,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1817518015-1068441259=:94772 Content-Type: text/plain; charset=us-ascii As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-1817518015-1068441259=:94772 Content-Type: text/html; charset=us-ascii
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-1817518015-1068441259=:94772-- From owner-v6ops@ops.ietf.org Mon Nov 10 08:12:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18512 for ; Mon, 10 Nov 2003 08:12:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJBlB-000DBH-H6 for v6ops-data@psg.com; Mon, 10 Nov 2003 13:07:13 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJBl6-000DAk-KS for v6ops@ops.ietf.org; Mon, 10 Nov 2003 13:07:08 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 6065E3ECDAF for ; Mon, 10 Nov 2003 08:07:06 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 917D75EDFA; Mon, 10 Nov 2003 08:07:05 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Mon, 10 Nov 2003 18:37:05 +0530 X-Sasl-Enc: 9DA4YxUhCqPg3CbQD0unuw 1068469625 Subject: comments on mech-v2-01 Message-Id: <20031110130705.917D75EDFA@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, Few comments on the draft. 1) A race is triggered when an IPv6 router that has a configured tunnel with another router is doing dynamic mtu detection. The outcome of the race is that one or more ICMPv6 "packet too big" message might not be sent out to an host. Assume an IPv6 network like: [H1]-------->[R1]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>[R2]--------->[H2] H1, and H2 are IPv6 hosts R1, and R2 are IPv6 routers with a configured tunnel between them. and the message flow is: 1. H1->R1 TCP packet of size 1400. 2. R1->R2 encapsulated packet of size 1400+20. (R1 is doing PMTU here) (Assume 1500 is the link MTU). 3. Assume one of the IPv4 routers between R1, and R2 send an ICMPv4 "fragmentation needed" with only 8 bytes of payload. 4. R1 records the new MTU for the tunnel but does *not* send an ICMPv6 "packet too big" message with MTU as 1300. 5. H1->R1 TCP packet of size 1400 (this is a retry) 6. R1->H1 ICMPv6 "packet too big" with size 1300 7. H1->R1 TCP packet of size 1400 (this is a retry) 8. ... (the above cycle might repeat if there are more IPv4 routers that send ICMPv4 "fragmentation needed" with 8 bytes of payload) IMHO, this one can be clarified in the draft so that it does not become a puzzle for implementors. 9) Link-layer address (which is an IPv4 address) is not meant to be used with ND. Is there any reason that the sending (of link-layer address) is a "SHOULD NOT", and the receiving is a =93MUST ignore=94. The sending, and the receiving parts should be made consistent with respect to link- layer address. i.e. sending should be a "SHOULD NOT", and receiving should be a "SHOULD ignore=94, or sending should be a "MUST NOT", and receiving should be a "MUST ignore=94. Btw, "NOT" is not a keyword. Hence "s/NOT/not". "For the purposes of Neighbor Discovery the configured tunnels specified in this document are assumed to NOT have a link-layer address, even though the link-layer (IPv4) does have address. This means that: - the sender of Neighbor Discovery packets SHOULD NOT include Source Link Layer Address options or Target Link Layer Address options on the tunnel link. - the receiver MUST, while otherwise processing the neighbor discovery packet, silently ignore the content of any Source Link" Editorial --------- 1) s/For that reason/For that reason,/ From owner-v6ops@ops.ietf.org Mon Nov 10 08:26:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18771 for ; Mon, 10 Nov 2003 08:26:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJC1X-000Ed1-0a for v6ops-data@psg.com; Mon, 10 Nov 2003 13:24:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJC1U-000EcS-ED for v6ops@ops.ietf.org; Mon, 10 Nov 2003 13:24:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAADNwt04335; Mon, 10 Nov 2003 15:23:58 +0200 Date: Mon, 10 Nov 2003 15:23:56 +0200 (EET) From: Pekka Savola To: Chirayu Patel cc: v6ops@ops.ietf.org Subject: Re: comments on mech-v2-01 In-Reply-To: <20031110130705.917D75EDFA@server2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Mon, 10 Nov 2003, Chirayu Patel wrote: > 9) Link-layer address (which is an IPv4 address) is not meant to be used > with ND. Is there any reason that the sending (of link-layer address) > is a "SHOULD NOT", and the receiving is a “MUST ignore”. The sending, > and the receiving parts should be made consistent with respect to > link- > layer address. i.e. sending should be a "SHOULD NOT", and receiving > should be a "SHOULD ignore”, or sending should be a "MUST NOT", and > receiving should be a "MUST ignore”. Btw, "NOT" is not a keyword. > Hence "s/NOT/not". I had made a note about the same thing in my comments (to-be-written-up). IMHO, as RFC2461 doesn't even specify the format for an IPv4 Link-layer address, there is little need for go into this much text here. I guess this is a remnant of 6over4 spec which had that definition. The question is, do we want to care about the fact that 6over4 unfortunately defined the link-layer option, or do we want to spell out the obvious requirement here with "MUST NOT include" and "MUST ignore". In practice, this has of little relevance if 6over4 is not implemented.. So, maybe we could find a wording that wouldn't require using a lot of text and upper-case keywords? -- 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 Nov 10 10:08:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22628 for ; Mon, 10 Nov 2003 10:08:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJDbI-00011Q-JF for v6ops-data@psg.com; Mon, 10 Nov 2003 15:05:08 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJDbF-000100-SH for v6ops@ops.ietf.org; Mon, 10 Nov 2003 15:05:05 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAAF4rPh010065; Mon, 10 Nov 2003 08:04:54 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAAF4bQ11458; Mon, 10 Nov 2003 16:04:42 +0100 (MET) Date: Mon, 10 Nov 2003 16:03:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Pekka Savola Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org, bob@thefinks.com, jonne.soininen@nokia.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Note: the document should be clearer that configured tunnels are typically > point-to-point, and then you typically don't even need the link-local > addresses, so this becomes practically rather irrelevant.. There are some cases when link-locals would be required. For instance, for a host-router tunnel it might make sense for the router to send router advertisements and those must be sourced with link-local addresses. For a router-router tunnel I think the link-locals can be omitted, unless they are used as next-hops across the tunnel. Given this we need to specify one way to pick link-local addresses by default for configured tunnels so that the two ends don't pick the same address. Either using the IPv4 address (with "local") or an EUI-64 derived address (with "local" not set) would work. Erik From owner-v6ops@ops.ietf.org Mon Nov 10 10:08:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22761 for ; Mon, 10 Nov 2003 10:08:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJDay-0000ui-G7 for v6ops-data@psg.com; Mon, 10 Nov 2003 15:04:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJDat-0000uS-Nb for v6ops@ops.ietf.org; Mon, 10 Nov 2003 15:04:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAAF4gp05968 for ; Mon, 10 Nov 2003 17:04:42 +0200 Date: Mon, 10 Nov 2003 17:04:41 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: transmech substantial comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, I believe there are some aspects of the spec to clarify & iron out yet. I've only written up the substantial part of my review comments. Most importantly, I think we'll have to consider whether we want to make ingress filtering and tunnel source address selection/verification more explicit (this may be a problem with a few special cases of current implementations, not sure) becuase the current model is rather vague and too insecure (issues 2, 5, 6). 1) section 2.3 on advertising addresses in the DNS is a bit out of place in this document. If there was some other doc describing how to provision services with addresses in the DNS, the discussion would be best placed there. Can anyone think of such a document? In any case, I believe we need an additional recommendation, that a node should not be added in the DNS before all the externally visible services are supported (e.g., there should not be an AAAA record for foo.example.com, until foo (an IMAP/SMTP server) supports both IMAP and SMTP over v6). Alternatively, service names instead of node names can be used. so, I'd suggest rewording the list and the paragraph to something like: The recommendation is that AAAA records for a node should not be added to the DNS until all of these are true: 1) The address is assigned to the interface on the node. 2) The address is configured on the interface. 3) The interface is on a link which is connected to the IPv6 infrastructure. 4) All the services, which are looked up from the DNS, provided by that node have been IPv6-enabled. [add:] The last one practically implies that unless all the services of a node are transitioned simultaneously, one should configure service names instead of host names in the DNS -- for example, use "smtp.example.com" for SMTP only, and "imap.example.com" for IMAP only, even though they might point to the same node. Using service naming allows one to decouple the services from the nodes providing services, also implying more fine-grained control in the process of enabling IPv6-enabled services. also move the paragraph starting with "A possible implication" up before the previous paragraph, as "A possible..." as it seems like a more logic place for it. 2) I believe unidirectional tunneling should be removed. Note that it seems it has been used in three different meanings in the document: - "point-to-point link", can run neighbor discovery over the tunnel (this obviously doesn't work with NBMA-type tunneling which has been removed from the spec.) - the v4 source address of the other tunnel end-point may be on the same node than the v4 tunnel end-point that was configured on this node, so unidirectional tunnels can be used to avoid this "tunnel source address selection" -problem. - "ingress filtering and routing is bidirectional", that when you send an IPv6 packet to global address X, the reply will come back using the same interface. So, because the first definition is obviously closer to the mark: - unidirectional tunnels with the first definition are a remnant of automatic tunneling, and can be removed. - the bidirectionality rules need to be reworded and described better, and we may have to beef up the source address selection part of a tunnel a bit. 3) do we need to add the following kind of clarification to section 3.2.1 as a caveat on fixed MTU use? One should note that even though MTU of a tunnel on a node is limited to e.g. 1280 bytes, the nodes still must be able to process larger received packets, in case that the peer has configured a higher MTU or if the peer is using dynamic MTU detection. .. just to clarify that people don't too eagerly jump to conclude that MTU=MRU here (or maybe that needs to spelled out in the decapsulation section).. 4) We specify the that the ToS byte for the v4 header is 0 unless otherwise specified, and refer to a couple of documents for that. A problem with this is that I'm not sure if those documents actually tackle the problem of *different* protocol-version tunnels -- rather, they (AFAIR) discuss the issues of ToS byte in v4-over-v4, where mapping (or not mapping) the ToS byte from the inner IP header is a trivial excercise. I fear that we may have to specify the rules for setting the ToS byte ourselves, or at least give more guidance on that. 5) As a consequence from the move to bidirectional tunnels (I hope..), I think we will need stronger text than what's in 3.5: Source Address: IPv4 address of outgoing interface of the encapsulator. The source address MAY alternatively be administratively specified to be a specific IPv4 address assigned to the encapsulator. This is often necessary on encapsulators with multiple IPv4 addresses to ensure that the IPv4 source address is acceptable to the decapsulator. Reword this to e.g.: Source Address: IPv4 address of outgoing interface of the encapsulator or an administraively specified address as described below. And at to the end, after the header field listings: When encapsulating the packets, the nodes must ensure that they will use the source address that the tunnel peer has configured, so that the source addresses are acceptable to the decapsulator. This may be a problem with multi-addressed, and in particular, multi-interface nodes, especially when the routing is changed from a stable condition, as the source address selection may be adversely affected. Therefore, it SHOULD be possible to administratively specify the source address of a tunnel. 6) the ingress filtering sections in 3.6 need beefing up a bit, reword: [...] Packets for which the IPv4 source address does not match SHOULD be silently dropped. A side effect of this source address verification is that the node will silently discard packets with an invalid IPv4 source address such as a multicast address, a broadcast address (255.255.255.255 and the broadcast addresses configured on the node), 0.0.0.0/8, and 127.0.0.1/8. In general, it SHOULD apply the rules for martian filtering in [RFC1812] and ingress filtering [RFC2827] on the IPv4 source address. Packets caught by these checks SHOULD be silently dropped. with (remove the last sentence from the previous paragraph due to duplication and): A side effect of this address verification is that the node will silently discard packets with a wrong source address, and packets which were received by the node but not directly addressed to it (e.g., broadcast addresses). Packets caught by these checks MUST be silently discarded. In addition, the node MAY perform ingress filtering [RFC2827] on the IPv4 source address, i.e., check that the packet is arriving from the interface in the direction of the route towards the tunnel end-point. If done, it is RECOMMENDED that this check is disabled by default. The packets caught by this check SHOULD be silently discarded. (Note there that I elevated a "SHOULD check the source address" to a MUST, because, well, the other scenario is just plain too insecure.) And later, at the end of the section: After the decapsulation the node SHOULD silently discard a packet with an invalid IPv6 source address. This includes IPv6 multicast addresses, the IPv6 unspecified address, and the loopback address but also IPv4-compatible IPv6 source addresses where the IPv4 part of the address is an IPv4 multicast address, broadcast address (255.255.255.255 and the broadcast addresses configured on the node), 0.0.0.0/8, or 127.0.0.1/8. In general it SHOULD apply the rules for martian filtering in [RFC1812] and ingress filtering [RFC2827] on the IPv4 address embedded in IPv4-compatible source addresses. .. this also needs to change, at least to a list of checks, e.g., like: After the decapsulation the node MUST silently discard a packet with an invalid IPv6 source address. The list of invalid source addresses SHOULD include at least: o all multicast addresses (FF00::/8) o the unspecified address (::) o the loopback address (::1) o all the IPv4-compatible IPv6 addresses (::/96) o all the IPv4-mapped IPv6 addresses (::ffff:0:0/96) In addition, the node should perform ingress filtering [RFC2827] on the IPv6 source address, as on any of its interfaces, e.g.: o if the tunnel is towards the Internet, check that the site's IPv6 prefixes are not used as the source addresses, or o if the tunnel is towards an edge network, check that the source address belongs to that edge network. (Section 4 on source address spoofing threats needs a bit beefing up as well, but nothing major..) 7) Security considerations should be better in two aspects: * the first sentence states: Tunneling is not known to introduce any security holes except for the possibility to circumvent ingress filtering [RFC2827]. .. this is not correct, as noted later in this section on the attacks against the pseudo-interface. * there should be text what to do if the current tradeoffs of configured tunneling are not considered to be OK, in: An implementation of tunneling needs to be aware that while a tunnel is a link (as defined in [RFC2460]), the threat model for a tunnel might be rather different than for other links, since the tunnel potentially includes all of the Internet. The recommendations to verify that the IPv4 addresses in the encapsulated packet matches what has been configured for the tunnel, coupled with use of ingress filtering in IPv4, ameliorate some of this. .. e.g., add something like this: If the remainder threats of tunnel source verification are considered to be significant, a tunneling scheme with authentication should be used instead, for example Generic Routing Encapsulation (GRE) [GRE] with a pre-configured secret key. -- 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 Nov 10 10:17:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23848 for ; Mon, 10 Nov 2003 10:17:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJDkZ-0001wZ-3h for v6ops-data@psg.com; Mon, 10 Nov 2003 15:14:43 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJDkU-0001wA-J3 for v6ops@ops.ietf.org; Mon, 10 Nov 2003 15:14:38 +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 hAAFEZ5u009552; Mon, 10 Nov 2003 08:14:36 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAAFEVQ12048; Mon, 10 Nov 2003 16:14:32 +0100 (MET) Date: Mon, 10 Nov 2003 16:13:28 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on mech-v2-01 To: Chirayu Patel Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20031110130705.917D75EDFA@server2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: QUOTED-PRINTABLE > 1) A race is triggered when an IPv6 router that has a configured tunnel > with another router is doing dynamic mtu detection. The outcome of the > race is that one or more ICMPv6 "packet too big" message might not be > sent out to an host. >=20 > Assume an IPv6 network like: >=20 > [H1]-------->[R1]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>[R2]--------->[H2] > 5. H1->R1 TCP packet of size 1400 (this is a retry) > 6. R1->H1 ICMPv6 "packet too big" with size 1300 > 7. H1->R1 TCP packet of size 1400 (this is a retry) > 8. ... (the above cycle might repeat if there are more IPv4 routers > that send ICMPv4 "fragmentation needed" with 8 bytes of payload) I don't understand how it can repeat. Do you think it can repeat forever? When the 8-byte payload ICMP errors are sent then R1 will effectively compute the minimum received (per IPv4 path MTU discovery). It is true that in the case of 8-byte payload ICMP errors you get at least two packet drops instead of at least one in the case of a single laye= r of MTU discovery (R1 needs to learn the tunnel MTU which causes at least on= e packet loss, and then H1 needs to learn the MTU from R1 which causes at least one packet loss. (And in all cases there can be more than one packet = loss if there are multiple large packets in flight at the same time.) > 9) Link-layer address (which is an IPv4 address) is not meant to be used > with ND. Is there any reason that the sending (of link-layer address) > is a "SHOULD NOT", and the receiving is a =93MUST ignore=94. The sendi= ng, > and the receiving parts should be made consistent with respect to > link- > layer address. i.e. sending should be a "SHOULD NOT", and receiving > should be a "SHOULD ignore=94, or sending should be a "MUST NOT", and > receiving should be a "MUST ignore=94. The reason it was written like this was to not immediately invalidate any older implementations that might have sent the link-layer address options. I don't know if there ever were any such implementations. > Btw, "NOT" is not a keyword. > Hence "s/NOT/not". It's upper case for emphasis, since I can't use bold face. I don't think this use of upper case voilates any rules. > Editorial > --------- >=20 > 1) s/For that reason/For that reason,/ Noted. Erik From owner-v6ops@ops.ietf.org Mon Nov 10 10:34:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24748 for ; Mon, 10 Nov 2003 10:34:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJE0t-0003fe-DZ for v6ops-data@psg.com; Mon, 10 Nov 2003 15:31:35 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJE0r-0003fR-Si for v6ops@ops.ietf.org; Mon, 10 Nov 2003 15:31:33 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAAFVVw5002656; Mon, 10 Nov 2003 07:31:31 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn3-260.cisco.com [10.21.65.4]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK29007; Mon, 10 Nov 2003 07:31:30 -0800 (PST) Message-Id: <6.0.0.22.2.20031110092652.04786450@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 10 Nov 2003 09:27:28 -0600 To: Pekka Savola From: Fred Baker Subject: Re: baker-ipv6-renumbering comments Cc: v6ops@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.6 required=5.0 tests=BAYES_00,FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 11:05 AM 11/9/2003, Pekka Savola wrote... Thanks. We'll take a gander at those. From owner-v6ops@ops.ietf.org Mon Nov 10 10:49:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25801 for ; Mon, 10 Nov 2003 10:49:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJEFW-0005E7-O0 for v6ops-data@psg.com; Mon, 10 Nov 2003 15:46:42 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJEFS-0005Do-Oy for v6ops@ops.ietf.org; Mon, 10 Nov 2003 15:46:38 +0000 Received: from ocean.jinmei.org (unknown [2001:468:19ff:80:b8a5:4393:64b5:c5a4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E4AB815210; Tue, 11 Nov 2003 00:46:36 +0900 (JST) Date: Tue, 11 Nov 2003 00:46:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Mon, 10 Nov 2003 16:03:48 +0100 (CET), >>>>> Erik Nordmark said: >> Note: the document should be clearer that configured tunnels are typically >> point-to-point, and then you typically don't even need the link-local >> addresses, so this becomes practically rather irrelevant.. > There are some cases when link-locals would be required. For instance, > for a host-router tunnel it might make sense for the router to send router > advertisements and those must be sourced with link-local addresses. > For a router-router tunnel I think the link-locals can be omitted, unless they > are used as next-hops across the tunnel. I think link-locals are often "used", particularly when we run an IGP (RIPng, OSPFv3, or ISIS) across the tunnel. (But this is so obvious that I'm not sure if this discussion really missed this point in the first place...) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Mon Nov 10 10:55:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26126 for ; Mon, 10 Nov 2003 10:55:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJELv-00063s-QH for v6ops-data@psg.com; Mon, 10 Nov 2003 15:53:19 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJELu-00063M-1j for v6ops@ops.ietf.org; Mon, 10 Nov 2003 15:53:18 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAFrFAt014910; Mon, 10 Nov 2003 07:53:16 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn3-260.cisco.com [10.21.65.4]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK30696; Mon, 10 Nov 2003 07:53:13 -0800 (PST) Message-Id: <6.0.0.22.2.20031110095058.058f9cb8@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 10 Nov 2003 09:53:07 -0600 To: v6ops@ops.ietf.org From: Fred Baker Subject: IETF 58 v6ops meeting baker-ipv6-renumbering slides Cc: proceedings@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.6 required=5.0 tests=BAYES_00,FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I sent a note earlier and for some reason it has not arrived back at my machine. Hmmm. Permit a resend... My slides for v6ops this week are at: ftp://ftpeng.cisco.com/fred/v6ops/Renumbering_Networks.ppt ftp://ftpeng.cisco.com/fred/v6ops/Renumbering_Networks.pdf From owner-v6ops@ops.ietf.org Mon Nov 10 11:03:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26926 for ; Mon, 10 Nov 2003 11:03:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJETA-00072f-Bd for v6ops-data@psg.com; Mon, 10 Nov 2003 16:00:48 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJET9-00072R-2k; Mon, 10 Nov 2003 16:00:47 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJET7-0000lV-Uw; Mon, 10 Nov 2003 10:00:46 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 10 Nov 2003 10:00:45 -0600 To: Fred Baker Cc: v6ops@ops.ietf.org Subject: Re: IETF 58 v6ops meeting baker-ipv6-renumbering slides References: <6.0.0.22.2.20031110095058.058f9cb8@mira-sjc5-b.cisco.com > Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I sent a note earlier and for some reason it has not arrived back at my > machine. Hmmm. perhaps it was this entry in the mail log here? 2003-11-10 14:47:10 H=(sj-iport-3.cisco.com) [171.71.176.72] F= rejected RCPT : Unknown local part ^ From owner-v6ops@ops.ietf.org Mon Nov 10 11:12:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27310 for ; Mon, 10 Nov 2003 11:12:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJEbq-00087b-IR for v6ops-data@psg.com; Mon, 10 Nov 2003 16:09:46 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJEbo-00087E-Mm for v6ops@ops.ietf.org; Mon, 10 Nov 2003 16:09:44 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2003 08:11:26 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAAG9ew7007382; Mon, 10 Nov 2003 08:09:42 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn3-260.cisco.com [10.21.65.4]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK31940; Mon, 10 Nov 2003 08:09:40 -0800 (PST) Message-Id: <6.0.0.22.2.20031110100512.044c3150@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 10 Nov 2003 10:05:57 -0600 To: Randy Bush From: Fred Baker Subject: Re: IETF 58 v6ops meeting baker-ipv6-renumbering slides Cc: v6ops@ops.ietf.org In-Reply-To: References: <6.0.0.22.2.20031110095058.058f9cb8@mira-sjc5-b.cisco.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.6 required=5.0 tests=BAYES_00,FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 10:00 AM 11/10/2003, Randy Bush wrote: > > I sent a note earlier and for some reason it has not arrived back at my > > machine. Hmmm. > >perhaps it was this entry in the mail log here? > >2003-11-10 14:47:10 H=(sj-iport-3.cisco.com) [171.71.176.72] >F= rejected RCPT : Unknown local part You're saying I fat-fingered the address? Sounds like a reasonable explanation... From owner-v6ops@ops.ietf.org Mon Nov 10 11:15:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27504 for ; Mon, 10 Nov 2003 11:15:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJEfS-0008Vr-Tj for v6ops-data@psg.com; Mon, 10 Nov 2003 16:13:30 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJEfQ-0008VH-3r; Mon, 10 Nov 2003 16:13:28 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJEfO-0000ml-Va; Mon, 10 Nov 2003 10:13:27 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 10 Nov 2003 10:13:26 -0600 To: Fred Baker Cc: v6ops@ops.ietf.org Subject: Re: IETF 58 v6ops meeting baker-ipv6-renumbering slides References: <6.0.0.22.2.20031110095058.058f9cb8@mira-sjc5-b.cisco.com > <6.0.0.22.2.20031110100512.044c3150@mira-sjc5-b.cisco.com > Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> perhaps it was this entry in the mail log here? >> 2003-11-10 14:47:10 H=(sj-iport-3.cisco.com) [171.71.176.72] >> F= rejected RCPT : Unknown local part > You're saying I fat-fingered the address? close. i am asking if this was possible. you could/should have received a bounce for that. and, if you did, you might have resent. but perhaps this is not the best forum for smtp debugging :-) randy, a cautious debugger From owner-v6ops@ops.ietf.org Mon Nov 10 11:31:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28440 for ; Mon, 10 Nov 2003 11:31:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJEuY-000AJw-8p for v6ops-data@psg.com; Mon, 10 Nov 2003 16:29:06 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJEuU-000AJI-CP for v6ops@ops.ietf.org; Mon, 10 Nov 2003 16:29:02 +0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 08:35:14 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAGSuAv017132; Mon, 10 Nov 2003 08:29:00 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn3-260.cisco.com [10.21.65.4]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK33503; Mon, 10 Nov 2003 08:28:56 -0800 (PST) Message-Id: <6.0.0.22.2.20031110101645.05967150@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 10 Nov 2003 10:28:23 -0600 To: Randy Bush From: Fred Baker Subject: Re: IETF 58 v6ops meeting baker-ipv6-renumbering slides Cc: v6ops@ops.ietf.org In-Reply-To: References: <6.0.0.22.2.20031110095058.058f9cb8@mira-sjc5-b.cisco.com > <6.0.0.22.2.20031110100512.044c3150@mira-sjc5-b.cisco.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.6 required=5.0 tests=BAYES_00,FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>At 10:13 AM 11/10/2003, Randy Bush wrote: >>>perhaps it was this entry in the mail log here? >>>2003-11-10 14:47:10 H=(sj-iport-3.cisco.com) [171.71.176.72] >>>F=> >>You're saying I fat-fingered the address? > >close. i am asking if this was possible. you could/should have >received a bounce for that. and, if you did, you might have resent. > >but perhaps this is not the best forum for smtp debugging :-) It's probably not the right forum, but a symptom here may be of interest to some operational forum, perhaps asrg. Yes, as it turns out I did get such a bounce. I have a problem. - The email address "fred@cisco.com" is in everybody-and-their-dog's outlook address book. - Everybody-and-their-dog gets viruses (pithy comment on people that click on things that say "click me, I dare you" elided) - viruses send messages *from* every address in the outlook address book *to* every address in the outlook address book. - half of those addresses are no longer valid, or are the addresses of mailing lists that are inadequately maintained. - hence, a significant subset of my spam load is email bounces - My spam filter helpfully detected the bounce from ops.ietf.org and put the message into a file I only occasionally look at. I'm of the opinion that there is an operational issue here. One technique a spammer can use to validate his email alias is to send messages to random addresses. If he gets a bounce, it was an invalid address. If he doesn't get a bounce, there was in fact a target there, although the target may be using antispam measures. Hence, the bounce is an attack avenue for spoofed senders and a security hole for private networks. Um, maybe there is some form of policy that should be recommended for bounces, such as "only send them to some specified set of correspondents" such as a local alias comprised of the or of all local aliases. Let's see; that had something to do with IPv6 operations, right? I now return you to your regularly scheduled mailing list topic... From owner-v6ops@ops.ietf.org Mon Nov 10 12:19:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01393 for ; Mon, 10 Nov 2003 12:19:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJFcj-000FjM-7c for v6ops-data@psg.com; Mon, 10 Nov 2003 17:14:45 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJFch-000Fis-7M for v6ops@ops.ietf.org; Mon, 10 Nov 2003 17:14:43 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAAHEfJ12500 for ; Mon, 10 Nov 2003 19:14:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 19:14:41 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 19:14:40 +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: Issue tracker introduced for the v6ops WG Date: Mon, 10 Nov 2003 19:14:40 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D019549AEFE@esebe024.ntc.nokia.com> Thread-Topic: Proposed changes to the working group processes Thread-Index: AcOIWUFUb3fUdR9CQYOY6JQ8K4E91g== From: To: Cc: , X-OriginalArrivalTime: 10 Nov 2003 17:14:40.0914 (UTC) FILETIME=[2092B720:01C3A7AE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello v6ops, we (the chairs) have been discussing changes for the process of the = working group. The idea is to change the processes to enable open, = traceable, and more efficient process for the WG. This is to speed up, = facilitate better the work of the document editors, and to make sure all = comments are addressed in the group. To achieve this we are proposing to = introduce the issue tracker for all WG drafts. We are going to use the = issue tracker from psg.com (http://rt.psg.com/).=20 Issue tracker is going to be used for all documents when they get to the = WG draft status. The comments to the documents are sent as issues and = the issues are registered to the issue tracker. For submitting issues a = simple template is used. To make sure that every issue is registered, = only the issues submitted using the template are registered. The = template has also space for proposing text to solve the issue. It is = encouraged to use this section when submitting an issue...=20 The issues are registered to the issue tracker for your convenience by = one of the chairs. The editor of the document will be responsible to = propose action to the individual issues. The action is accept, accept = with modification, and reject. The submission of issues and the = discussion about the issues is, of course, done on the list. So, the = issue tracker is mostly a documentation tool for the discussion and = facilitating the work of the editor. We have had good experiences with the initial trial on the 3GPP analysis = draft(will stay at = http://danforsberg.info:8080/draft-ietf-v6ops-3gpp-analysis/index). I = hope this will also revive and focus the discussion on other items as = well. Let's try this out and see how it works! And we'll discuss this in the = meeting today as well. The chairs (Bob, Jonne, Pekka) PS. The template is the following. Thanks for AAA WG letting us use = theirs: [Document]=20 Submitter name: =20 Submitter email address: =20 Date first submitted: =20 Reference: Comment type: ['T'echnical | 'E'ditorial]=20 Priority: ['MUST' Must fix | 'SHOULD' Should fix | 'MAY' Nice to have ]=20 Section: =20 Rationale/Explanation of issue:=20 =20 Requested change:=20 =20 -------- Jonne Soininen Nokia Tel. +358 40 527 4634 Email: jonne.soininen@nokia.com=20 From owner-v6ops@ops.ietf.org Mon Nov 10 12:26:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01833 for ; Mon, 10 Nov 2003 12:26:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJFly-000GbN-0t for v6ops-data@psg.com; Mon, 10 Nov 2003 17:24:18 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJFlv-000GbB-Kz for v6ops@ops.ietf.org; Mon, 10 Nov 2003 17:24:15 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id A27AE9C; Tue, 11 Nov 2003 02:24:14 +0900 (JST) To: Jonne.Soininen@nokia.com Cc: v6ops@ops.ietf.org, pekkas@netcore.fi, bob@thefinks.com Subject: Re: Issue tracker introduced for the v6ops WG In-Reply-To: Your message of "Mon, 10 Nov 2003 19:14:40 +0200" <2D3EB51EAED985419D54AB340A9D019549AEFE@esebe024.ntc.nokia.com> References: <2D3EB51EAED985419D54AB340A9D019549AEFE@esebe024.ntc.nokia.com> X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031110172414.A27AE9C@coconut.itojun.org> Date: Tue, 11 Nov 2003 02:24:14 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Hello v6ops, > > we (the chairs) have been discussing changes for the process of > the working group. The idea is to change the processes to enable > open, traceable, and more efficient process for the WG. This is to > speed up, facilitate better the work of the document editors, and > to make sure all comments are addressed in the group. To achieve > this we are proposing to introduce the issue tracker for all WG > drafts. We are going to use the issue tracker from psg.com > (http://rt.psg.com/). what is the username/password to browse the list of issues? at least we need to be able to browse it anonymously (i.e. without creating user/password pair) otherwise lots of lots of user will be registered just to browse the list of issues. secondly, how can i register username/password? in other words, where is the user manual (for v6ops people)? itojun From owner-v6ops@ops.ietf.org Mon Nov 10 12:28:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01947 for ; Mon, 10 Nov 2003 12:28:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJFo9-000Gt7-Et for v6ops-data@psg.com; Mon, 10 Nov 2003 17:26:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJFo6-000Gs4-KM for v6ops@ops.ietf.org; Mon, 10 Nov 2003 17:26:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAAHQLH09040; Mon, 10 Nov 2003 19:26:21 +0200 Date: Mon, 10 Nov 2003 19:26:21 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: Jonne.Soininen@nokia.com, , Subject: Re: Issue tracker introduced for the v6ops WG In-Reply-To: <20031110172414.A27AE9C@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 11 Nov 2003, Jun-ichiro itojun Hagino wrote: > what is the username/password to browse the list of issues? > at least we need to be able to browse it anonymously (i.e. without > creating user/password pair) otherwise lots of lots of user will be > registered just to browse the list of issues. > > secondly, how can i register username/password? > > in other words, where is the user manual (for v6ops people)? ietf/ietf, as stated at the bottom of the page :-) registering a user name is not needed. -- 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 Nov 10 12:35:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02421 for ; Mon, 10 Nov 2003 12:35:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJFug-000Hic-MD for v6ops-data@psg.com; Mon, 10 Nov 2003 17:33:18 +0000 Received: from [66.218.79.80] (helo=web80510.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJFud-000Hhg-Dl for v6ops@ops.ietf.org; Mon, 10 Nov 2003 17:33:15 +0000 Message-ID: <20031110173314.23014.qmail@web80510.mail.yahoo.com> Received: from [130.129.65.242] by web80510.mail.yahoo.com via HTTP; Mon, 10 Nov 2003 09:33:14 PST Date: Mon, 10 Nov 2003 09:33:14 -0800 (PST) From: Fred Templin Subject: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031110051419.98144.qmail@web80504.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-865920420-1068485594=:22385" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-865920420-1068485594=:22385 Content-Type: text/plain; charset=us-ascii I would like to add some qualifying remarks to my previous message. Many of my earlier messages on this subject were preliminary, but this message and my current document are not. See: www.geocities.com/osprey67/tunnelmtu-03.txt This document offers the following important conclusion: "It is impossible for the network to anticipate the packet transmission strategy of the application." This result is perhaps not surprising and certainly not new, as it is accurately predicted by the End-to-End Principle. Some additional notes: - For the past several months, I have worked under the premise that a robust, secure, efficient, and generalized Path MTU discovery mechanism for IPv6-in-IPv4 tunnels was needed that operated autonomously and without direction from the application. I struggled for many months to come up with a solution that satisfied this design point and failed - as have many others over the past 15 years. - After finally accepting the above conclusion and recognizing the means by which the application could provide guidance to the network, the solution was immediately obvious and I was able to write the entire document on the 4.5 hr flight into Minneapolis. All those interested in path MTU discovery (and the more general subject of application<->network interactions) should read this document along with the normative references it cites (even reading just the Introduction should be sufficient if time is short). The document probably has a few bugs, and I would appreciate comments. But, the conclusions will not go away and are indeed inescapable. Thanks - Fred ftemplin@iprg.nokia.com P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version. Fred Templin wrote: As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-865920420-1068485594=:22385 Content-Type: text/html; charset=us-ascii
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 
 
  

Fred Templin <osprey67@yahoo.com> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-865920420-1068485594=:22385-- From owner-v6ops@ops.ietf.org Mon Nov 10 12:55:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03135 for ; Mon, 10 Nov 2003 12:55:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJGDb-000KK5-VA for v6ops-data@psg.com; Mon, 10 Nov 2003 17:52:51 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJGDZ-000KJr-En for v6ops@ops.ietf.org; Mon, 10 Nov 2003 17:52:49 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA08365 for ; Mon, 10 Nov 2003 17:52:45 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 RAA03314 for ; Mon, 10 Nov 2003 17:52:44 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAAHqiX00900 for v6ops@ops.ietf.org; Mon, 10 Nov 2003 17:52:44 GMT Date: Mon, 10 Nov 2003 17:52:44 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-chown-v6ops-unmanaged-connectivity-00.txt Message-ID: <20031110175244.GC548@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <200310222236.SAA02410@ietf.org> <1dd001c39c01$61301fb0$9402a8c0@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1dd001c39c01$61301fb0$9402a8c0@consulintel.es> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, Oct 26, 2003 at 09:40:21PM +0100, JORDI PALET MARTINEZ wrote: > > I think 1st p. of section 2. needs some clarification. Indeed: "Mechanisms only passing the NAT ... is replaced by an IPv6-aware > box." > Is wrong, in my point of view, or I'm misinterpreting it. We'll reword that text, thanks. > 2.2 typo: Protocol 41 forwarding > > 3.1 Not sure to understand what do you mean with "Tunnels can be either unidirectional or bi-directional" So something like the file delivery mechanism (flute) in mboned might be an example, but I agree it is a rare case. > I think one missing part on the document is to reinforce the unmanaged vs. managed protocols, pros-cons, billing/AAA, from the > perspective of the ISP. If I'm an ISP willing to offer some kind of IPv6 services, this document could be a tool to look for the > different alternatives. We have the ISP management and also accountability. Your suggestion could be worked into one of those or be a new desirable property. Cheers, Tim From owner-v6ops@ops.ietf.org Mon Nov 10 14:33:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07690 for ; Mon, 10 Nov 2003 14:33:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJHk2-00046B-HH for v6ops-data@psg.com; Mon, 10 Nov 2003 19:30:26 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJHjx-00045P-TX for v6ops@ops.ietf.org; Mon, 10 Nov 2003 19:30:22 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8BA9293 for ; Tue, 11 Nov 2003 04:30:20 +0900 (JST) To: v6ops@ops.ietf.org X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: draft-ietf-v6ops-mech-v2-01.txt (first use of template!) From: itojun@iijlab.net Date: Tue, 11 Nov 2003 04:30:20 +0900 Message-Id: <20031110193020.8BA9293@coconut.itojun.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [Document] draft-ietf-v6ops-mech-v2-01.txt Submitter name: itojun Submitter email address: itojun@iijlab.net Date first submitted: Sat, 8 Nov 2003 07:02:22 +0900 (JST) Reference: <20031107220222.A55C993@coconut.itojun.org> Comment type: T Priority: SHOULD Section: 3.7 Rationale/Explanation of issue: suggestion in section 3.7 (quoted below) is unneecessary, or seems too strong. reasons: - coupling link-local address with tunnel endpoint IPv4 address makes it harder to switch tunnel endpoint IPv4 address - reconfiguration of IPv6 link-local address (usually used for nexthop) is needed. therefore i prefer them to be separate. it is from my long operational experience. - RFC2472 section 4.1 has better way to generate interface ID. - SHOULD is too strong as the use of different selection algorithm of link-local address here does not impose any interoperability issue. RFC1933 did not have such requirement (SHOULD). RFC2893 introduced this. i did voiced my concern but was not integrated into RFC2893. > The Interface Identifier [RFC2373] for such an Interface SHOULD be > the 32-bit IPv4 address of that interface, with the bytes in the same > order in which they would appear in the header of an IPv4 packet, > padded at the left with zeros to a total of 64 bits. Note that the > "Universal/Local" bit is zero, indicating that the Interface > Identifier is not globally unique. When the host has more than one > IPv4 address in use on the physical interface concerned, an > administrative choice of one of these IPv4 addresses is made when > forming the link-local address. Requested change: resolution 1: remove the 3.7 paragraph 2, paragraph 3, and figure. resoltion 2: change SHOULD on 1st line of paragraph 2 line to MAY. resolution 3: change SHOULD on 1st line of paragraph 2 line to MAY. add reference to RFC2472 section 4.1 as an alternative. From owner-v6ops@ops.ietf.org Mon Nov 10 14:44:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08360 for ; Mon, 10 Nov 2003 14:44:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJHvi-0005W8-0I for v6ops-data@psg.com; Mon, 10 Nov 2003 19:42:30 +0000 Received: from [66.218.79.72] (helo=web80502.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJHvf-0005Vm-4k for v6ops@ops.ietf.org; Mon, 10 Nov 2003 19:42:27 +0000 Message-ID: <20031110194226.40843.qmail@web80502.mail.yahoo.com> Received: from [130.129.140.51] by web80502.mail.yahoo.com via HTTP; Mon, 10 Nov 2003 11:42:26 PST Date: Mon, 10 Nov 2003 11:42:26 -0800 (PST) From: Fred Templin Subject: Re: Issue tracker introduced for the v6ops WG To: Pekka Savola , Jun-ichiro itojun Hagino Cc: Jonne.Soininen@nokia.com, v6ops@ops.ietf.org, bob@thefinks.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1724454741-1068493346=:40013" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1724454741-1068493346=:40013 Content-Type: text/plain; charset=us-ascii Hi, The question I was intending to ask on this subject before Randy shut down the discussion is how do you propose to mitigate abuse of the mechanism, i.e., so that document authors aren't spammed? (The two examples Jonne provided were prime examples of what I would consider "issue spamming". :^} ) Any thoughts on this? Fred osprey67@yahoo.com Pekka Savola wrote: On Tue, 11 Nov 2003, Jun-ichiro itojun Hagino wrote: > what is the username/password to browse the list of issues? > at least we need to be able to browse it anonymously (i.e. without > creating user/password pair) otherwise lots of lots of user will be > registered just to browse the list of issues. > > secondly, how can i register username/password? > > in other words, where is the user manual (for v6ops people)? ietf/ietf, as stated at the bottom of the page :-) registering a user name is not needed. -- 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-1724454741-1068493346=:40013 Content-Type: text/html; charset=us-ascii
Hi,
 
The question I was intending to ask on this subject before Randy
shut down  the discussion is how do you propose to mitigate abuse
of the mechanism, i.e., so that document authors aren't spammed?
(The two examples Jonne provided were prime examples of what
I would consider "issue spamming". :^} )
 
Any thoughts on this?
 
Fred
osprey67@yahoo.com

Pekka Savola <pekkas@netcore.fi> wrote:
On Tue, 11 Nov 2003, Jun-ichiro itojun Hagino wrote:
> what is the username/password to browse the list of issues?
> at least we need to be able to browse it anonymously (i.e. without
> creating user/password pair) otherwise lots of lots of user will be
> registered just to browse the list of issues.
>
> secondly, how can i register username/password?
>
> in other words, where is the user manual (for v6ops people)?

ietf/ietf, as stated at the bottom of the page :-)

registering a user name is not needed.

--
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-1724454741-1068493346=:40013-- From owner-v6ops@ops.ietf.org Mon Nov 10 15:01:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09240 for ; Mon, 10 Nov 2003 15:01:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJIBc-0007gd-Kz for v6ops-data@psg.com; Mon, 10 Nov 2003 19:58:56 +0000 Received: from [200.196.233.36] (helo=200.196.233.36) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJIBZ-0007gJ-NB for v6ops@ops.ietf.org; Mon, 10 Nov 2003 19:58:53 +0000 Received: (qmail 8892 invoked by uid 89); 10 Nov 2003 18:05:16 -0200 Received: from unknown (HELO ipv6brspw2k) (robson.oliveira@ipv6dobrasil.com.br@200.158.204.84) by 0 with SMTP; 10 Nov 2003 18:05:16 -0200 From: "Robson Oliveira" To: "Fred Baker" Cc: Subject: RE: IETF 58 v6ops meeting baker-ipv6-renumbering slides Date: Mon, 10 Nov 2003 17:56:41 -0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <6.0.0.22.2.20031110095058.058f9cb8@mira-sjc5-b.cisco.com > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,RCVD_NUMERIC_HELO autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred, I would suggest the recommendation add "View the syslog or debug before link removal, requests still be doing to this link. Some TOOLS can help you". -robson -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Fred Baker Sent: Monday, November 10, 2003 1:53 PM To: v6ops@ops.ietf.org Cc: proceedings@ietf.org Subject: IETF 58 v6ops meeting baker-ipv6-renumbering slides I sent a note earlier and for some reason it has not arrived back at my machine. Hmmm. Permit a resend... My slides for v6ops this week are at: ftp://ftpeng.cisco.com/fred/v6ops/Renumbering_Networks.ppt ftp://ftpeng.cisco.com/fred/v6ops/Renumbering_Networks.pdf From owner-v6ops@ops.ietf.org Mon Nov 10 15:26:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11561 for ; Mon, 10 Nov 2003 15:26:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJIa6-000A9x-VM for v6ops-data@psg.com; Mon, 10 Nov 2003 20:24:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJIa4-000A9c-Gz for v6ops@ops.ietf.org; Mon, 10 Nov 2003 20:24:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAAKNu612358; Mon, 10 Nov 2003 22:23:56 +0200 Date: Mon, 10 Nov 2003 22:23:55 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Jun-ichiro itojun Hagino , , , Subject: Re: Issue tracker introduced for the v6ops WG In-Reply-To: <20031110194226.40843.qmail@web80502.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 10 Nov 2003, Fred Templin wrote: > The question I was intending to ask on this subject before Randy > shut down the discussion is how do you propose to mitigate abuse > of the mechanism, i.e., so that document authors aren't spammed? > (The two examples Jonne provided were prime examples of what > I would consider "issue spamming". :^} ) > > Any thoughts on this? We'll deal with it if it becomes a problem :-) The chairs are responsible for recording issues. They could also be edited to fit, or rejected outright if there seems to be abuse in progress.. -- 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 Nov 10 15:30:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11762 for ; Mon, 10 Nov 2003 15:30:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJIdi-000AdD-EO for v6ops-data@psg.com; Mon, 10 Nov 2003 20:27:58 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJIdg-000Acx-LR for v6ops@ops.ietf.org; Mon, 10 Nov 2003 20:27:56 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAKRrAt015674; Mon, 10 Nov 2003 12:27:54 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn1-154.cisco.com [10.21.96.154]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK66341; Mon, 10 Nov 2003 12:27:52 -0800 (PST) Message-Id: <6.0.0.22.2.20031110140258.03f75dd0@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 10 Nov 2003 14:04:38 -0600 To: "Robson Oliveira" From: Fred Baker Subject: RE: IETF 58 v6ops meeting baker-ipv6-renumbering slides Cc: In-Reply-To: References: <6.0.0.22.2.20031110095058.058f9cb8@mira-sjc5-b.cisco.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.6 required=5.0 tests=BAYES_00,FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 01:56 PM 11/10/2003, Robson Oliveira wrote: >I would suggest the recommendation add "View the syslog or debug before link >removal, requests still be doing to this link. Some TOOLS can help you". Thanks. Specifically what tools would you recommend? I'm personally all in favor of tools. I'd like to be a little more specific than that, though. From owner-v6ops@ops.ietf.org Mon Nov 10 15:58:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13270 for ; Mon, 10 Nov 2003 15:58:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJJ4W-000EPX-PR for v6ops-data@psg.com; Mon, 10 Nov 2003 20:55:40 +0000 Received: from [200.196.233.36] (helo=200.196.233.36) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJJ4S-000EOc-9Q for v6ops@ops.ietf.org; Mon, 10 Nov 2003 20:55:36 +0000 Received: (qmail 46395 invoked by uid 89); 10 Nov 2003 19:02:05 -0200 Received: from unknown (HELO ipv6brspw2k) (robson.oliveira@ipv6dobrasil.com.br@200.158.204.84) by 0 with SMTP; 10 Nov 2003 19:02:05 -0200 From: "Robson Oliveira" To: "Fred Baker" Cc: Subject: RE: IETF 58 v6ops meeting baker-ipv6-renumbering slides Date: Mon, 10 Nov 2003 18:53:31 -0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <6.0.0.22.2.20031110140258.03f75dd0@mira-sjc5-b.cisco.com > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,RCVD_NUMERIC_HELO autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A sniffer like Ethereal or any other syslog tools of the own device (Servers and Routers) could grant a good reply report regarding the old address. If there are no reply to the old address, you may can turn off the link. -robson -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Monday, November 10, 2003 6:05 PM To: Robson Oliveira Cc: v6ops@ops.ietf.org Subject: RE: IETF 58 v6ops meeting baker-ipv6-renumbering slides At 01:56 PM 11/10/2003, Robson Oliveira wrote: >I would suggest the recommendation add "View the syslog or debug before link >removal, requests still be doing to this link. Some TOOLS can help you". Thanks. Specifically what tools would you recommend? I'm personally all in favor of tools. I'd like to be a little more specific than that, though. From owner-v6ops@ops.ietf.org Mon Nov 10 16:19:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14053 for ; Mon, 10 Nov 2003 16:19:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJJPa-000H8B-Vh for v6ops-data@psg.com; Mon, 10 Nov 2003 21:17:26 +0000 Received: from [66.218.79.81] (helo=web80511.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJJPZ-000H7z-93 for v6ops@ops.ietf.org; Mon, 10 Nov 2003 21:17:25 +0000 Message-ID: <20031110211721.64407.qmail@web80511.mail.yahoo.com> Received: from [130.129.140.51] by web80511.mail.yahoo.com via HTTP; Mon, 10 Nov 2003 13:17:21 PST Date: Mon, 10 Nov 2003 13:17:21 -0800 (PST) From: Fred Templin Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031110173314.23014.qmail@web80510.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1219058509-1068499041=:63762" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1219058509-1068499041=:63762 Content-Type: text/plain; charset=us-ascii Hmm - I may have spoken too soon, as it looks like RFC 2675 has some minimum packet sizing requirements that make it just a bit too big to use over IPv6-in-IPv4 tunnels. Maybe we should (bis) it? Fred osprey67@yahoo.com Fred Templin wrote: P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version --0-1219058509-1068499041=:63762 Content-Type: text/html; charset=us-ascii
Hmm - I may have spoken too soon, as it looks like RFC 2675 has
some minimum packet sizing requirements that make it just a bit
too big to use over IPv6-in-IPv4 tunnels. Maybe we should (bis) it?
 
Fred
osprey67@yahoo.com

Fred Templin <osprey67@yahoo.com> wrote:
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version
--0-1219058509-1068499041=:63762-- From owner-v6ops@ops.ietf.org Mon Nov 10 16:42:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14952 for ; Mon, 10 Nov 2003 16:42:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJJlW-000JW0-0d for v6ops-data@psg.com; Mon, 10 Nov 2003 21:40:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJJlR-000JUv-I2 for v6ops@ops.ietf.org; Mon, 10 Nov 2003 21:40:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAALe0N13625 for ; Mon, 10 Nov 2003 23:40:00 +0200 Date: Mon, 10 Nov 2003 23:39:59 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Accept ISP Scenarios Document as WG Draft? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, In the first session in Minneapolis, we had unanimous consensus that the ISP scenario document would serve as a good starting place for our work, and that we should accept it as a WG draft. The latest version of this document can be found at: http://www.ietf.org/internet-drafts/draft-lind-v6ops-isp-scenarios-01.txt Unless there are any objections from the mailing list, We'll ask the authors to publish the next version as a WG I-D. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Mon Nov 10 17:30:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17838 for ; Mon, 10 Nov 2003 17:30:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJKVT-000OXQ-L1 for v6ops-data@psg.com; Mon, 10 Nov 2003 22:27:35 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJKVR-000OX6-Vd for v6ops@ops.ietf.org; Mon, 10 Nov 2003 22:27:34 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAMRUAt009002; Mon, 10 Nov 2003 14:27:31 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn1-154.cisco.com [10.21.96.154]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK80714; Mon, 10 Nov 2003 14:27:28 -0800 (PST) Message-Id: <6.0.0.22.2.20031110162055.05acb808@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 10 Nov 2003 16:26:34 -0600 To: "Robson Oliveira" From: Fred Baker Subject: RE: IETF 58 v6ops meeting baker-ipv6-renumbering slides Cc: In-Reply-To: References: <6.0.0.22.2.20031110140258.03f75dd0@mira-sjc5-b.cisco.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.6 required=5.0 tests=BAYES_00,FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 02:53 PM 11/10/2003, Robson Oliveira wrote: >A sniffer like Ethereal or any other syslog tools of the own device (Servers >and Routers) could grant a good reply report regarding the old address. If >there are no reply to the old address, you may can turn off the link. OK. I mentioned traffic capture systems; I think you're additionally saying "ping scan the network and see what replies". That certainly would verify that the old prefix has been removed. It seems to me, though, that this really isn't the question. The question is whether there are any sessions remaining addressing applications via the old prefix - if someone is still using it, you don't want to remove it yet, and after they have all stopped, it doesn't really matter whether it is there or not. Hence, it seems to me that once the last session using an address goes quiescent, the address can be removed from the system. When there is no longer any traffic using the prefix, you can remove the prefix from the router serving the prefix. Maybe I'm missing your point? From owner-v6ops@ops.ietf.org Mon Nov 10 18:16:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21375 for ; Mon, 10 Nov 2003 18:16:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJLEU-0004QA-Rn for v6ops-data@psg.com; Mon, 10 Nov 2003 23:14:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJLES-0004Pt-IA for v6ops@ops.ietf.org; Mon, 10 Nov 2003 23:14:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAANDvp15362; Tue, 11 Nov 2003 01:13:59 +0200 Date: Tue, 11 Nov 2003 01:13:57 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-mech-v2-01.txt (first use of template!) In-Reply-To: <20031110193020.8BA9293@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 11 Nov 2003 itojun@iijlab.net wrote: [...] Filed: https://rt.psg.com/Ticket/Display.html?id=236 (took some trying, but managed in the end.) Now, all we have to do is wait for the editor's proposed resolution. -- 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 Nov 10 22:54:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03434 for ; Mon, 10 Nov 2003 22:54:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJPYG-0005ZQ-Bh for v6ops-data@psg.com; Tue, 11 Nov 2003 03:50:48 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJPYC-0005Z0-Ln for v6ops@ops.ietf.org; Tue, 11 Nov 2003 03:50:44 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 0F25B3F09A7; Mon, 10 Nov 2003 22:50:41 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id BDA9C6DA8B; Mon, 10 Nov 2003 22:50:39 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Tue, 11 Nov 2003 09:20:39 +0530 X-Sasl-Enc: YhRj6tQ+uCx5iSVhgX+xeQ 1068522639 Cc: " Erik Nordmark" Subject: Re: comments on mech-v2-01 References: In-Reply-To: Message-Id: <20031111035039.BDA9C6DA8B@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable See below... On Mon, 10 Nov 2003 16:13:28 +0100 (CET), "Erik Nordmark" said: > > 1) A race is triggered when an IPv6 router that has a configured > > tunnel with another router is doing dynamic mtu detection. The > > outcome of the race is that one or more ICMPv6 "packet too big" > > message might not be sent out to an host. > > > > Assume an IPv6 network like: > > > > [H1]-------->[R1]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>[R2]--------->[H2] > > > 5. H1->R1 TCP packet of size 1400 (this is a retry) > > 6. R1->H1 ICMPv6 "packet too big" with size 1300 > > 7. H1->R1 TCP packet of size 1400 (this is a retry) > > 8. ... (the above cycle might repeat if there are more IPv4 routers > > that send ICMPv4 "fragmentation needed" with 8 bytes of payload) > > I don't understand how it can repeat. Do you think it can repeat > forever? No it will not repeat forever. That is why I used "might" in point 8. > When the 8-byte payload ICMP errors are sent then R1 will effectively > compute the minimum received (per IPv4 path MTU discovery). > > It is true that in the case of 8-byte payload ICMP errors you get at > least two packet drops instead of at least one in the case of a single > layer of MTU discovery (R1 needs to learn the tunnel MTU which causes > at least one packet loss, and then H1 needs to learn the MTU from R1 > which causes at least one packet loss. (And in all cases there can be > more than one packet loss if there are multiple large packets in flight > at the same time.) Your wording sums it up nicely. My thinking is that such a case is non- obvious, and we should have a note about it in the draft. > > 9) Link-layer address (which is an IPv4 address) is not meant to be > > used with ND. Is there any reason that the sending (of link-layer > > address) is a "SHOULD NOT", and the receiving is a =93MUST ignore=94. > > The sending, and the receiving parts should be made consistent > > with respect to link- layer address. i.e. sending should be a > > "SHOULD NOT", and receiving should be a "SHOULD ignore=94, or > > sending should be a "MUST NOT", and receiving should be a "MUST > > ignore=94. > > The reason it was written like this was to not immediately invalidate > any older implementations that might have sent the link-layer address > options. I don't know if there ever were any such implementations. Do you think we should change it now? I prefer "SHOULD NOT" and "SHOULD ignore". CP From owner-v6ops@ops.ietf.org Mon Nov 10 23:39:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05121 for ; Mon, 10 Nov 2003 23:39:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJQGr-0009zs-Iu for v6ops-data@psg.com; Tue, 11 Nov 2003 04:36:53 +0000 Received: from [66.218.79.78] (helo=web80508.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJQGp-0009zX-5t for v6ops@ops.ietf.org; Tue, 11 Nov 2003 04:36:51 +0000 Message-ID: <20031111043650.67568.qmail@web80508.mail.yahoo.com> Received: from [130.129.133.218] by web80508.mail.yahoo.com via HTTP; Mon, 10 Nov 2003 20:36:50 PST Date: Mon, 10 Nov 2003 20:36:50 -0800 (PST) From: Fred Templin Subject: Re: draft-ietf-v6ops-mech-v2-01.txt (first use of template!) To: itojun@iijlab.net, v6ops@ops.ietf.org In-Reply-To: <20031110193020.8BA9293@coconut.itojun.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-867430678-1068525410=:66757" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-867430678-1068525410=:66757 Content-Type: text/plain; charset=us-ascii Seeing how this is the first use of the issue template, I suppose I'll go ahead and take the distinction of being the first one to complain about it. I disagree with the suggestion about adopting the RFC 2472, section 4.1 language for interface identifier construction, and don't believe it's worth the MECH authors spending any time on. But, now that it has been conveniently placed in the "issue tracker" form, does that mean that the authors are obligated to dig into the details and respond? This is the very concern I was expressing in my earlier message in terms of "issue overload" - shouldn't we be discussing the issues on the list first so that there can be some first-pass filtering before bogging down the authors? Thanks - Fred osprey67@yahoo.com itojun@iijlab.net wrote: [Document] draft-ietf-v6ops-mech-v2-01.txt Submitter name: itojun Submitter email address: itojun@iijlab.net Date first submitted: Sat, 8 Nov 2003 07:02:22 +0900 (JST) Reference: <20031107220222.A55C993@coconut.itojun.org> Comment type: T Priority: SHOULD Section: 3.7 Rationale/Explanation of issue: suggestion in section 3.7 (quoted below) is unneecessary, or seems too strong. reasons: - coupling link-local address with tunnel endpoint IPv4 address makes it harder to switch tunnel endpoint IPv4 address - reconfiguration of IPv6 link-local address (usually used for nexthop) is needed. therefore i prefer them to be separate. it is from my long operational experience. - RFC2472 section 4.1 has better way to generate interface ID. - SHOULD is too strong as the use of different selection algorithm of link-local address here does not impose any interoperability issue. RFC1933 did not have such requirement (SHOULD). RFC2893 introduced this. i did voiced my concern but was not integrated into RFC2893. > The Interface Identifier [RFC2373] for such an Interface SHOULD be > the 32-bit IPv4 address of that interface, with the bytes in the same > order in which they would appear in the header of an IPv4 packet, > padded at the left with zeros to a total of 64 bits. Note that the > "Universal/Local" bit is zero, indicating that the Interface > Identifier is not globally unique. When the host has more than one > IPv4 address in use on the physical interface concerned, an > administrative choice of one of these IPv4 addresses is made when > forming the link-local address. Requested change: resolution 1: remove the 3.7 paragraph 2, paragraph 3, and figure. resoltion 2: change SHOULD on 1st line of paragraph 2 line to MAY. resolution 3: change SHOULD on 1st line of paragraph 2 line to MAY. add reference to RFC2472 section 4.1 as an alternative. --0-867430678-1068525410=:66757 Content-Type: text/html; charset=us-ascii
Seeing how this is the first use of the issue template, I
suppose I'll go ahead and take the distinction of being
the first one to complain about it.
 
I disagree with the suggestion about adopting the RFC 2472,
section 4.1 language for interface identifier construction, and
don't believe it's worth the MECH authors spending any time on.
But, now that it has been conveniently placed in the "issue tracker"
form, does that mean that the authors are obligated to dig into
the details and respond?
 
This is the very concern I was expressing in my earlier message
in terms of "issue overload" - shouldn't we be discussing the issues
on the list first so that there can be some first-pass filtering before
bogging down the authors?
 
Thanks - Fred
osprey67@yahoo.com


itojun@iijlab.net wrote:
[Document] draft-ietf-v6ops-mech-v2-01.txt
Submitter name: itojun
Submitter email address: itojun@iijlab.net
Date first submitted: Sat, 8 Nov 2003 07:02:22 +0900 (JST)
Reference: <20031107220222.A55C993@coconut.itojun.org>
Comment type: T
Priority: SHOULD
Section: 3.7
Rationale/Explanation of issue:
suggestion in section 3.7 (quoted below) is unneecessary, or seems
too strong.

reasons:
- coupling link-local address with tunnel endpoint IPv4 address makes
it harder to switch tunnel endpoint IPv4 address - reconfiguration
of IPv6 link-local address (usually used for nexthop) is needed.
therefore i prefer them to be separate. it is from my long
operational experience.
- RFC2472 section 4.1 has better way to generate interface ID.
- SHOULD is too strong as the use of different selection algorithm
of link-local address here does not impose any interoperability issue.

RFC1933 did not have such requirement (SHOULD). RFC2893
introduced this. i did voiced my concern but was not integrated into
RFC2893.

> The Interface Identifier [RFC2373] for such an Interface SHOULD be
> the 32-bit IPv4 address of that interface, with the bytes in the same
> order in which they would appear in the header of an IPv4 packet,
> padded at the left with zeros to a total of 64 bits. Note that the
> "Universal/Local" bit is zero, indicating that the Interface
> Identifier is not globally unique. When the host has more than one
> IPv4 address in use on the physical interface concerned, an
> administrative choice of one of these IPv4 addresses is made when
> forming the link-local address.

Requested change:
resolution 1:
remove the 3.7 paragraph 2, paragraph 3, and figure.

resoltion 2:
change SHOULD on 1st line of paragraph 2 line to MAY.

resolution 3:
change SHOULD on 1st line of paragraph 2 line to MAY.
add reference to RFC2472 section 4.1 as an alternative.
--0-867430678-1068525410=:66757-- From owner-v6ops@ops.ietf.org Tue Nov 11 07:41:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29139 for ; Tue, 11 Nov 2003 07:41:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJXkL-0003Jt-PY for v6ops-data@psg.com; Tue, 11 Nov 2003 12:35:49 +0000 Received: from [196.15.242.242] (helo=c75febh001.gpg.gov.za) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJXix-00035O-HG for v6ops@ops.ietf.org; Tue, 11 Nov 2003 12:34:34 +0000 Received: from mail pickup service by c75febh001.gpg.gov.za with Microsoft SMTPSVC; Mon, 10 Nov 2003 18:32:04 +0200 Received: from optimus.ietf.org ([132.151.6.22]) by c75febh001.gpg.gov.za with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 Nov 2003 07:16:09 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4OF-0005i7-IS; Mon, 10 Nov 2003 00:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4O3-0005hc-JM for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 00:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25781 for ; Mon, 10 Nov 2003 00:14:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ4O1-0006ZA-00 for ipv6@ietf.org; Mon, 10 Nov 2003 00:14:49 -0500 Received: from web80504.mail.yahoo.com ([66.218.79.74]) by ietf-mx with smtp (Exim 4.12) id 1AJ4O0-0006Yb-00 for ipv6@ietf.org; Mon, 10 Nov 2003 00:14:48 -0500 Message-ID: <20031110051419.98144.qmail@web80504.mail.yahoo.com> Received: from [130.129.72.244] by web80504.mail.yahoo.com via HTTP; Sun, 09 Nov 2003 21:14:19 PST Date: Sun, 9 Nov 2003 21:14:19 -0800 (PST) From: Fred Templin Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1817518015-1068441259=:94772" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-OriginalArrivalTime: 10 Nov 2003 05:17:56.0537 (UTC) FILETIME=[FFF78A90:01C3A749] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1817518015-1068441259=:94772 Content-Type: text/plain; charset=us-ascii As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-1817518015-1068441259=:94772 Content-Type: text/html; charset=us-ascii
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-1817518015-1068441259=:94772-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Tue Nov 11 08:31:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00791 for ; Tue, 11 Nov 2003 08:31:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJYZn-0008xr-Vv for v6ops-data@psg.com; Tue, 11 Nov 2003 13:28:59 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJYZk-0008xT-OV for v6ops@ops.ietf.org; Tue, 11 Nov 2003 13:28:56 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hABDSnS26168; Tue, 11 Nov 2003 15:28:49 +0200 Date: Tue, 11 Nov 2003 15:28:48 +0200 (EET) From: Pekka Savola To: Fred Templin cc: itojun@iijlab.net, Subject: issue tracker usage [Re: draft-ietf-v6ops-mech-v2-01.txt (first use of template!)] In-Reply-To: <20031111043650.67568.qmail@web80508.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 10 Nov 2003, Fred Templin wrote: [...] > But, now that it has been conveniently placed in the "issue tracker" > form, does that mean that the authors are obligated to dig into > the details and respond? > > This is the very concern I was expressing in my earlier message > in terms of "issue overload" - shouldn't we be discussing the issues > on the list first so that there can be some first-pass filtering before > bogging down the authors? I'm not sure what's your specific concern here. To clarify, we're not recording discussions in the issue tracker. Any follow-up comments etc. are done on the list. The document editor, then, at some point, proposes a resolution to the issue. That is also discussed on the list. The resolution is recorded in the issue tracker. I fully support first discussing the issues on the list. That's fine, and that's why there is the "Reference" field in the template. Remember, the issue tracker is not meant to be an exclusive tool in the document improvement process. It's mostly aimed to be a tool where the submitter of an issue wants to get the issue formally recorded, and taken care of, using a process. -- 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 Nov 11 10:01:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03295 for ; Tue, 11 Nov 2003 10:01:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJZyd-000Ixu-8k for v6ops-data@psg.com; Tue, 11 Nov 2003 14:58:43 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJZyb-000Ixb-Ax for v6ops@ops.ietf.org; Tue, 11 Nov 2003 14:58:41 +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 hABEwa5u026086; Tue, 11 Nov 2003 07:58:37 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hABEwXQ25728; Tue, 11 Nov 2003 15:58:33 +0100 (MET) Date: Tue, 11 Nov 2003 15:57:41 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on mech-v2-01 To: Chirayu Patel Cc: v6ops@ops.ietf.org, Erik Nordmark In-Reply-To: "Your message with ID" <20031111035039.BDA9C6DA8B@server2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Your wording sums it up nicely. My thinking is that such a case is non- > obvious, and we should have a note about it in the draft. OK. I'll add that in the section on dynamic tunnel MTU. > > The reason it was written like this was to not immediately invalidate > > any older implementations that might have sent the link-layer address > > options. I don't know if there ever were any such implementations. > > Do you think we should change it now? I prefer "SHOULD NOT" and > "SHOULD ignore". Problem is if both ends of a pair of nodes don't satisfy the recommendation stated in the SHOULDs. In that case things would not interoperate. Thus I think there has to be a MUST applied to at least one of the sender and the receiver. Erik From owner-v6ops@ops.ietf.org Tue Nov 11 10:02:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03340 for ; Tue, 11 Nov 2003 10:02:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJZxs-000IrN-BC for v6ops-data@psg.com; Tue, 11 Nov 2003 14:57:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJZxn-000Ir0-6l for v6ops@ops.ietf.org; Tue, 11 Nov 2003 14:57:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hABEvoq27368 for ; Tue, 11 Nov 2003 16:57:50 +0200 Date: Tue, 11 Nov 2003 16:57:49 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: unmaneval comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Below are more more substantial comments to unmaneval; I'll send the editorial ones separately (maybe to the authors directly). I've concentrated on non-connectivity related parts only. I'm not sure of the document contents and reorganization. Currently it's very heavily built apon different mechanisms or protocols needed for the the unmanaged. Those should be included, of course, but what would be more useful is having a bit more background and discussion so that the document would be potentially useful in addition as a mechanism to mandate the specification of mechanisms Foo, Bar and Baz. One problem is of course also that there are some very generic issues which are pretty much common to each of the scenarios A-D, maybe it would make sense to describe these issues first in a common section, and go to scenario-specific details separately. substantial ----------- 1) I did not want to go to the connectivity parts at this point because it's a topic that we have difficulties getting basic understanding on. I'll just correct the most obvious problems in the current text. There seem to be some implied assumptions which are not shared, which is probably one reason why different folks are speaking across each other: 2.1.4 Recommendation Teredo appears to be a good fit for providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 deployment. The service is designed for minimizing the cost of deploying the server, which matches the requirement of minimizing the cost of the "supporting infrastructure" for peer-to-peer applications. ==> you seem to assume that peer-to-peer applications are the reason to deploy v6 and Teredo, and that all the peers would implement Teredo (and be behind particular kinds of NATs) so that all the traffic between them would flow smoothtly. I do not share these assumptions. More: To gauge the difference, we consider the case of a host engaging in Voice over IP: it will maintain its address reachable all the time, and it will send a large amount of traffic whenever it is engaged in a conversation. According to classic figures collected by AT&T, the average duration of a conversation is around 100 seconds, and a business telephone is likely to be engaged in a conversation about 10% of the time, which implies starting a conversation on average every 1000 seconds. The average load sent by a tunnel client to the tunnel server will be 10% of the average data rate of the client; assuming a 16kbps codec and 50 packets per second, the data rate of the client sums up to about 51 kbps, hence an average load on the tunnel server of 5 kbps. The load sent by the tunnel client to the tunnel server will be about one exchange of bubble per minute, to defend the address, plus one bubble exchange at the beginning of each session with a new peer; adding all headers, the bubble size is about 144 bytes, which results in about 20 bps of traffic on the server. In short, the amount of traffic seen by the Teredo server is 250 times less that the traffic seen by a Teredo client. ==> with your very specific assumptions about p2p applications and all the peers supporting Teredo, this may be close to the mark. In general, it is *very far* from the mark. With Teredo, the relays see the "250 times more traffic" (minus what goes directly), not the Tunnel Brokers. So the overheads are probably pretty equivalent except for the packets that traverse directly between the Teredo nodes. The tunnel approach is more expensive to provide, because the tunnel server will have to carry a much larger amount of traffic. It is unclear that a tunnel service can be provided as an almost free "supporting infrastructure", except perhaps if the service was directly provided by the same ISP that already provides IPv4 connectivity to the unmanaged network. ==> Teredo relays just have to bear that traffic except for Teredo-Teredo -traffic, instead of tunnel servers. Big deal. 2) I think the security sections need more text especially in the cases where NAT traversal is being done, but otherwise as well. A characteristic of case A is that a host located behind a NAT acquires global IPv6 connectivity, using either Teredo or an alternative tunneling mechanism. If no precaution is taken, there is a risk of exposing to the global Internet some applications and services that only expected to serve local hosts, located behind the NAT. Developers and administrators should make sure that the global IPv6 connectivity is restricted to only those applications that are expressly designed for global Internet connectivity. ==> I think we must be careful not to disturb the perceived "security model" of NATs etc. -- so we could e.g. state here like: For example, enabling IPv6 connectivity through a firewall or NAT should require explicit configuration from the user (with sufficient education on the dangers thereof), or there should be on-by-default stateful firewall configuration, which would default to "NAT-like" rules, allowing everything out but nothing but related sessions in. 3) case B assumes that the ISP and the gateway are dual-stack. This seems to imply that the link to the ISP would also be dual-stack, and it would be enabled for use. Is there a need to mention in particular the scenario where the ISP would offer IPv6 over a tunnel to the gateway -- isn't this missing from scenarios? In case B, we assume that the gateway and the ISP are both dual stack. The hosts on the local network may be IPv4 only, dual stack, or IPv6 only. The main requirements are: prefix delegation, and name resolution. We also study the potential need for communication between IPv4 and IPv6 hosts, and conclude that a dual stack approach 4) RA proxy mechanism should probably be replaced by a ND proxy, but the main point for this "prefix delegation" scenario is IMO to better describe why exactly RA/ND proxy would be useful here. Maybe it should highlight its usefulness if the ISP only gives a /64 prefix (for example)? etc. 3.1.1 RA proxy The implicit delegation mechanism assumes that the gateway is connected to the ISP by a point-to-point link. Examples of such point to point links are various types of configured tunnels and serial links, for example using PPP. The principle of RA proxy is simple: the gateway issues a "router solicitation" message on the serial link, receives a "router advertisement", learns a network prefix from the advertisement, and advertises the same prefix on the unmanaged network. 5) the explicit prefix delegation section does not describe the requirements for advertising the subprefixes to the downstream links, right? Also note that some form of manual prefix delegation could be possible, even though maybe not as flexible. 6) section 3.3.2 discusses the ways of publishing v6 addresses using different means and concludes DDNS is needed. What would be interesting to know whether there are any issues in the DDNS which do not work at the moment, need spcial attention, etc. ? Moreover, please explain how the nodes will use DDNS in this scenario, as it isn't clear. There may be some issues in taking it into use.. Dynamic configuration using the same type of ad hoc protocols that are common today is indeed possible, but the IETF should encourage the use of standard solutions based on DDNS. 7) The DNS resolving for local hosts needs a bit of beefing up..: When a DNS server is used, this server could in theory be located anywhere on the Internet. There is however a very strong argument for using a local server, which will remain reachable even if the network connectivity is down. ==> naturally, one probably important feature there is also being able to include services/nodes which (even though possibly using global addresses) are not meant for the generic consumption of all Internet users.. (I don't feel strongly about this point though) The use of a local server requires that IPv6 capable hosts discover this server, as explained in 3.3.1, and then that they use a protocol such as DDNS to publish their IPv6 addresses to this server. ==> this also implies that the DNS server explained in 3.3.1 actually *allows* for the use of DDNS for these updates. How is the security of DDNS achieved? Which domain/zone is used to do the updates (i.e., how do the users/hosts know that)? An alternative to using a local server is LLMNR, which uses a multicast mechanism to resolve DNS requests. LLMNR does not require any service from the gateway, and also does not require that hosts use DDNS. LLMNR relies on multicast for its operation. There are scaling issues with using multicast, as the procedure may become very chatty in large networks; but this is not a practical problem in most unmanaged networks. ==> remove the last sentence, it is not relevant for the unmanaged networks. ==> does enabling LLMNR have special config requirements, e.g. regarding the stack or the apps? 8) link-locals and apps; I'm very strongly opposed to thinking that link-local addresses are valid for generic consumption for apps for on-link traffic: Local applications, for example, could be restricted to only use link-local addresses, or addresses whose most significant bits match the prefix of the local subnet. 9) 6to4 mechanism has something like: There are three possible ways to alleviate this congestion. First, one can hope that many actors will deploy 6to4 relay routers, in order to facilitate the deployment of IPv6; congestion would be alleviated by the provision of a large number of gateways. Second, one could develop some "route optimization" process, so that the traffic would flow through a "shortcut path" rather than through the 6to4 relays; the relays would then avoid congestion by carrying only a small fraction of the traffic. Third, if neither the first nor the second solution materializes, some gateways may enter into contractual agreements with relay service providers; in this case, the 6to4 technology would become merely a variant of the configured tunnel technologies. ==> the "Second, ..." point can IMO be removed. I don't see a way to do that. On the other hand, if you want to describe the methods to alleviate the scaling problems of 6to4, one thing to say might be that the nodes not needing it would just enable it *in addition to* their other v6 connectivity. In this way, the load on the relays would decrease. However, I'm not sure this is a good idea, but if you want to add a consideration for scaling mitigation, that might be one way... 10) in section 4.1.3, it is clear that ISATAP is NOT applicable within the unmanaged network. The only place where it could even be *considered* is as a mechanism between the ISP and the home user, if the home user gets zero public IPv4 addresses, but its ISP would be willing to provide v6 to the users via an ISATAP services.. (I think this is pretty close to what you say later on).. (Of course, one could wonder why such an IPv6-willing ISP would not provide v6 services natively or using some other mechanism but.... :-) In theory, ISATAP could be used to provide hosts in an unmanaged network with IPv6 connectivity; the gateway might function as an ISATAP router. However, in a single subnet deployment, this solution is markedly inferior to native IPv6: it incurs more overhead, and is not easier to deploy. 11) actually, the naming requirements in case C (B but ISP not dual stack) seem to be potentially slightly different. At least, if the gateway does not act as a proxy DNS server for v6-only hosts, it isn't possible to obtain the v6 DNS server address from the ISP, right? 4.2 Naming requirements in case C Naming requirements are similar to case B. semi-substantial ---------------- A mechanism of bubbles, relayed by the servers, is used for establishing contacts between Teredo nodes, or for discovering the appropriate Teredo relay serving an IPv6 peer; the actual IPv6 packets are carried in UDP packets exchanged directly between the nodes, or exchanged through the relay serving an IPv6 peer. ==> s/the nodes/the Teredo nodes/ ==> s/an IPv6 peer/non-Teredo IPv6 peers/ (especially the first edit is very important..) 5 Meeting the case D requirements In case D, the ISP only provides IPv6 services. 5.1.1 IPv6 addressing requirements ==> you are missing "5.1" section there.. 5.3 Security requirements Security requirements in case D are analogous to those of case B. The use of a tunneling mechanism to provide IPv4 connectivity may introduce its own security issues, but the analysis of these issues can only be performed after this tunneling mechanism is fully designed. ==> security requirements for v6-only case are probably a bit different from the rest. I'd assume that by then the users would be used to a "no-NATs" model... 6 Provisional recommendations ==> I think it would be useful to try to prioritize and order these somehow, like "critical for deployment", "important", "to be done later". 12 References Normative references ==> there are no informative refs at all? ==> note that a large number of these are not being used in the document anymore and can be removed. -- 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 Nov 11 10:54:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06841 for ; Tue, 11 Nov 2003 10:54:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJano-000PMH-2d for v6ops-data@psg.com; Tue, 11 Nov 2003 15:51:36 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJanj-000PLn-V1 for v6ops@ops.ietf.org; Tue, 11 Nov 2003 15:51:31 +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 hABFpLUP028031; Tue, 11 Nov 2003 07:51:22 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hABFpJQ02553; Tue, 11 Nov 2003 16:51:19 +0100 (MET) Date: Tue, 11 Nov 2003 16:50:22 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: transmech substantial comments To: Pekka Savola Cc: 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > 1) section 2.3 on advertising addresses in the DNS is a bit out of place in > this document. If there was some other doc describing how to provision > services with addresses in the DNS, the discussion would be best placed > there. Can anyone think of such a document? I don't know of such a document. > In any case, I believe we need an additional recommendation, that a node > should not be added in the DNS before all the externally visible services > are supported (e.g., there should not be an AAAA record for foo.example.com, > until foo (an IMAP/SMTP server) supports both IMAP and SMTP over v6). > Alternatively, service names instead of node names can be used. I can add this. > also move the paragraph starting with "A possible implication" up before > the previous paragraph, as "A possible..." as it seems like a more logic > place for it. Don't understand where you think it belongs; the several preceeding paragraphs follow on eachother. Which paragraph do you think it should preceed? > 2) I believe unidirectional tunneling should be removed. Note that it seems > it has been used in three different meanings in the document: This is one issue I want explicit WG feedback on tomorrow. I don't have a problem removing them - it would simplify the text. > So, because the first definition is obviously closer to the mark: > - unidirectional tunnels with the first definition are a remnant of > automatic tunneling, and can be removed. That is definitely part of the reason for the explicit mention, but I don't know if it the only reason. > - the bidirectionality rules need to be reworded and described > better, and we may have to beef up the source address selection part of > a tunnel a bit. Yes, if we remove the unidirectional tunneling text then the IPv4 source address at the encapsulator can be described as something which is configured since both ends of the tunnel need to have matching IPv4 addresses for the tunnel. > 3) do we need to add the following kind of clarification to section 3.2.1 as > a caveat on fixed MTU use? > > One should note that even though MTU of a tunnel on a node is limited to > e.g. 1280 bytes, the nodes still must be able to process larger received > packets, in case that the peer has configured a higher MTU or if the peer > is using dynamic MTU detection. I could add this. > 4) We specify the that the ToS byte for the v4 header is 0 unless otherwise > specified, and refer to a couple of documents for that. A problem with this > is that I'm not sure if those documents actually tackle the problem of > *different* protocol-version tunnels -- rather, they (AFAIR) discuss the > issues of ToS byte in v4-over-v4, where mapping (or not mapping) the ToS > byte from the inner IP header is a trivial excercise. > > I fear that we may have to specify the rules for setting the ToS byte > ourselves, or at least give more guidance on that. I don't see why we'd need to do that. Tunnels, using the same versions or different versions, can cross a region where the DSCP is interpreted differently thus the issues whether to copy the DSCP when encapsulating is identical AFAIK. For the congestion bits the same considerations apply whether the IP versions are the same or different. So do you have a concrete argument that we need explicit text on this? (If we want this to move to DS sooner rather than later I think we should avoid this.) > 5) As a consequence from the move to bidirectional tunnels (I hope..), I > think we will need stronger text than what's in 3.5: Yes, if we remove the unidirectional tunnels it makes sense making this more explicit. > 6) the ingress filtering sections in 3.6 need beefing up a bit, reword: Done. > 7) Security considerations should be better in two aspects: > * the first sentence states: > > Tunneling is not known to introduce any security holes except for the > possibility to circumvent ingress filtering [RFC2827]. > > .. this is not correct, as noted later in this section on the attacks > against the pseudo-interface. ok; I'll rephrase. > * there should be text what to do if the current tradeoffs of configured > tunneling are not considered to be OK, in: Instead of claiming that GRE with keys (which are in RFC 1701 but not part of RFC 2784) is much secure, how about instead saying that AH/ESP can be applied to the tunnel? Erik From owner-v6ops@ops.ietf.org Tue Nov 11 11:06:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07405 for ; Tue, 11 Nov 2003 11:06:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJayo-00018W-EQ for v6ops-data@psg.com; Tue, 11 Nov 2003 16:02:58 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJayl-000184-Rr for v6ops@ops.ietf.org; Tue, 11 Nov 2003 16:02:56 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 2469F93; Wed, 12 Nov 2003 01:02:54 +0900 (JST) To: Erik.Nordmark@sun.com Cc: v6ops@ops.ietf.org Subject: Re: transmech substantial comments In-Reply-To: Your message of "Tue, 11 Nov 2003 16:50:22 +0100 (CET)" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031111160254.2469F93@coconut.itojun.org> Date: Wed, 12 Nov 2003 01:02:54 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > 4) We specify the that the ToS byte for the v4 header is 0 unless otherwise > > specified, and refer to a couple of documents for that. A problem with this > > is that I'm not sure if those documents actually tackle the problem of > > *different* protocol-version tunnels -- rather, they (AFAIR) discuss the > > issues of ToS byte in v4-over-v4, where mapping (or not mapping) the ToS > > byte from the inner IP header is a trivial excercise. > > > > I fear that we may have to specify the rules for setting the ToS byte > > ourselves, or at least give more guidance on that. > > I don't see why we'd need to do that. Tunnels, using the same versions or > different versions, can cross a region where the DSCP is interpreted > differently thus the issues whether to copy the DSCP when encapsulating is > identical AFAIK. > > For the congestion bits the same considerations apply whether the IP versions > are the same or different. > > So do you have a concrete argument that we need explicit text on this? > (If we want this to move to DS sooner rather than later I think we should > avoid this.) draft-ietf-ipsec-ecn-02.txt (expired) talks about the very issue. it is titled as IPsec-related document, but the consideration applies to any kind of tunnel. itojun From owner-v6ops@ops.ietf.org Tue Nov 11 11:36:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08758 for ; Tue, 11 Nov 2003 11:36:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJbT3-0004DW-2H for v6ops-data@psg.com; Tue, 11 Nov 2003 16:34:13 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJbT0-0004DK-Rw for v6ops@ops.ietf.org; Tue, 11 Nov 2003 16:34:10 +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 hABGXOxA001768; Tue, 11 Nov 2003 08:33:25 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hABGXKQ08927; Tue, 11 Nov 2003 17:33:21 +0100 (MET) Date: Tue, 11 Nov 2003 17:32:29 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Fred Templin Cc: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org In-Reply-To: "Your message with ID" <20031110051419.98144.qmail@web80504.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > As I said I would do in my 10/29/2003 note on the ipv6 list under > the subject heading: "Re: RFC 2461bis issue: MTU handling", I am > now prepared to submit a new version of my document on dynamic > MTU determination. (Please note that there are some significant > differences from the previous version.) I looked over the your document and I wonder how it applies to the WG's desire to clarify the transition mechanisms document and move that to Draft Standard soon. Thus I recommend the WG participants read the document so we can discuss that high-level issue on Wednesday. From one reading I see: Using period(?) hop-by-hop options in data packets to probe the IPv6 path MTU; those packets would be processed slowly by IPv6 routers. IPv6 fragmentation by IPv6 routers; not allowed per RFC 2460 Assuming security associations between the encapsulator and decapsulator Having decapsulators that are otherwise hosts send Router Advertisements seems a bit odd. I don't understand how the IPv4 path MTU is detected by the encapsulator/decapsulator somehow. Is this based on ICMPv4 packet too big message or something else? Erik From owner-v6ops@ops.ietf.org Tue Nov 11 11:39:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08949 for ; Tue, 11 Nov 2003 11:39:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJbVv-0004Xv-4o for v6ops-data@psg.com; Tue, 11 Nov 2003 16:37:11 +0000 Received: from [66.218.79.76] (helo=web80506.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJbVr-0004Xg-Eg for v6ops@ops.ietf.org; Tue, 11 Nov 2003 16:37:07 +0000 Message-ID: <20031111163706.40437.qmail@web80506.mail.yahoo.com> Received: from [130.129.133.218] by web80506.mail.yahoo.com via HTTP; Tue, 11 Nov 2003 08:37:05 PST Date: Tue, 11 Nov 2003 08:37:05 -0800 (PST) From: Fred Templin Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031110173314.23014.qmail@web80510.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1404901583-1068568625=:38822" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1404901583-1068568625=:38822 Content-Type: text/plain; charset=us-ascii Folks, I uncovered a few bugs and made some changes since yesterday. (I was using the wrong mechanism for L2 fragmentation! :^/ ) The new document version can be found at: www.geocities.com/osprey67/tunnelmtu-04.txt The changelog appears below: Fred osprey67@yahoo.com Appendix A. Changelog o Specified use of IPv4 fragmentation (instead of IPv6) as the L2 fragmentation mechanism. o Added CongestMTU for use during periods of congestion. o Added support for sending congestion indications not associated with probes. o Clarified DF bit settings. Fred Templin wrote: I would like to add some qualifying remarks to my previous message. Many of my earlier messages on this subject were preliminary, but this message and my current document are not. See: www.geocities.com/osprey67/tunnelmtu-03.txt This document offers the following important conclusion: "It is impossible for the network to anticipate the packet transmission strategy of the application." This result is perhaps not surprising and certainly not new, as it is accurately predicted by the End-to-End Principle. Some additional notes: - For the past several months, I have worked under the premise that a robust, secure, efficient, and generalized Path MTU discovery mechanism for IPv6-in-IPv4 tunnels was needed that operated autonomously and without direction from the application. I struggled for many months to come up with a solution that satisfied this design point and failed - as have many others over the past 15 years. - After finally accepting the above conclusion and recognizing the means by which the application could provide guidance to the network, the solution was immediately obvious and I was able to write the entire document on the 4.5 hr flight into Minneapolis. All those interested in path MTU discovery (and the more general subject of application<->network interactions) should read this document along with the normative references it cites (even reading just the Introduction should be sufficient if time is short). The document probably has a few bugs, and I would appreciate comments. But, the conclusions will not go away and are indeed inescapable. Thanks - Fred ftemplin@iprg.nokia.com P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version. Fred Templin wrote: As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-1404901583-1068568625=:38822 Content-Type: text/html; charset=us-ascii
Folks,
 
I uncovered a few bugs and made some changes since yesterday.
(I was using the wrong mechanism for L2 fragmentation! :^/ ) The
new document version can be found at:
 
 
The changelog appears below:
 
Fred
 
Appendix A. Changelog

   o  Specified use of IPv4 fragmentation (instead of IPv6) as the L2
      fragmentation mechanism.

   o  Added CongestMTU for use during periods of congestion.

   o  Added support for sending congestion indications not associated
      with probes.

   o  Clarified DF bit settings.



Fred Templin <osprey67@yahoo.com> wrote:
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 
 
  

Fred Templin <osprey67@yahoo.com> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-1404901583-1068568625=:38822-- From owner-v6ops@ops.ietf.org Tue Nov 11 12:11:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10684 for ; Tue, 11 Nov 2003 12:11:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJc0T-0008R8-Lk for v6ops-data@psg.com; Tue, 11 Nov 2003 17:08:45 +0000 Received: from [195.212.14.170] (helo=mail-gw1.hursley.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJc0P-0008Qk-FJ for v6ops@ops.ietf.org; Tue, 11 Nov 2003 17:08:41 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AJc0O-0002Lb-00; Tue, 11 Nov 2003 17:08:40 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AJc0N-0002LY-00; Tue, 11 Nov 2003 17:08:39 +0000 Received: from zurich.ibm.com (sig-9-145-241-14.de.ibm.com [9.145.241.14]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hABH8av110352; Tue, 11 Nov 2003 17:08:37 GMT Message-ID: <3FB1176E.506884A7@zurich.ibm.com> Date: Tue, 11 Nov 2003 18:07:58 +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: Jun-ichiro itojun Hagino CC: Erik.Nordmark@sun.com, v6ops@ops.ietf.org Subject: Re: transmech substantial comments References: <20031111160254.2469F93@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The guidelines for DSCP and tunnels are in RFC 2983, called, strangely enough, "Differentiated Services and Tunnels." It's Informational. Brian Jun-ichiro itojun Hagino wrote: > > > > 4) We specify the that the ToS byte for the v4 header is 0 unless otherwise > > > specified, and refer to a couple of documents for that. A problem with this > > > is that I'm not sure if those documents actually tackle the problem of > > > *different* protocol-version tunnels -- rather, they (AFAIR) discuss the > > > issues of ToS byte in v4-over-v4, where mapping (or not mapping) the ToS > > > byte from the inner IP header is a trivial excercise. > > > > > > I fear that we may have to specify the rules for setting the ToS byte > > > ourselves, or at least give more guidance on that. > > > > I don't see why we'd need to do that. Tunnels, using the same versions or > > different versions, can cross a region where the DSCP is interpreted > > differently thus the issues whether to copy the DSCP when encapsulating is > > identical AFAIK. > > > > For the congestion bits the same considerations apply whether the IP versions > > are the same or different. > > > > So do you have a concrete argument that we need explicit text on this? > > (If we want this to move to DS sooner rather than later I think we should > > avoid this.) > > draft-ietf-ipsec-ecn-02.txt (expired) talks about the very issue. > it is titled as IPsec-related document, but the consideration applies > to any kind of tunnel. > > itojun -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-v6ops@ops.ietf.org Tue Nov 11 12:26:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11514 for ; Tue, 11 Nov 2003 12:26:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJcEN-0009nN-6g for v6ops-data@psg.com; Tue, 11 Nov 2003 17:23:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJcEK-0009nB-Hy for v6ops@ops.ietf.org; Tue, 11 Nov 2003 17:23:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hABHMlN29922; Tue, 11 Nov 2003 19:22:47 +0200 Date: Tue, 11 Nov 2003 19:22:46 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Fred Templin , Christian Huitema , Jun-ichiro itojun Hagino , , Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 11 Nov 2003, Erik Nordmark wrote: > > As I said I would do in my 10/29/2003 note on the ipv6 list under > > the subject heading: "Re: RFC 2461bis issue: MTU handling", I am > > now prepared to submit a new version of my document on dynamic > > MTU determination. (Please note that there are some significant > > differences from the previous version.) > > I looked over the your document and I wonder how it applies to the WG's > desire to clarify the transition mechanisms document and move that > to Draft Standard soon. I completely agre with this sentiment. This enhanced MTU discovery is way too much of a moving target to be included at this point. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Nov 11 12:40:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12544 for ; Tue, 11 Nov 2003 12:40:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJcTQ-000Bdw-Th for v6ops-data@psg.com; Tue, 11 Nov 2003 17:38:40 +0000 Received: from [66.218.78.102] (helo=web40405.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJcTN-000BdZ-5D for v6ops@ops.ietf.org; Tue, 11 Nov 2003 17:38:37 +0000 Message-ID: <20031111173836.42273.qmail@web40405.mail.yahoo.com> Received: from [130.129.70.232] by web40405.mail.yahoo.com via HTTP; Tue, 11 Nov 2003 09:38:36 PST Date: Tue, 11 Nov 2003 09:38:36 -0800 (PST) From: Pyda Srisuresh Subject: Re: draft-satapati-v6ops-natpt-applicability-00 To: Suresh K Satapati , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Below are my comments on the draft. Overall, the document seems well done, even though I donot agree with some of the summary conclusions as stated. First, I woudl like to respond to Pekka's comments (ref: http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html) on the draft. 1. As for definition of NAT-PT, I agree with the notion that no ALGs are required for the basic NAT-PT operation. As such, the definition of NAT-PT shoudl not include these ALGs. Use of DNS-ALG for address assignment is desirable when dealing with hosts by name. FTP-ALG was included in the RFC as an example ALG for a commonly-known application. DNS-ALG and FTP-ALG are merely two ALGs that would be useful. I believe, the updated version of the RFC could be explicit about the definition. 2. pekkas comments in item 2 (in http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html) seem rather opinionated - not keeping transition scenarios in mind. Specifically, what prompts you to make comments like, "These scenarios, may be counterproductive in the face of dual-stack deployment."? The next sentence reads, "if the deployment of IPv6-only networks were decreed out of scope, some felt that no NAT-PT applicability statement would need to be published in the first place as it would not be applicable anywhere". This is yet another note that seems to be espousing religion. Who is decreeing that deploment of IPv6-only networks to be out of scope? Is it out of scope for this WG or for the Ipv6 deployers? The charter of the WG reads otherwise. 3. The item 3 - What are the issue you see with the deployment path for the scenarios discussed? ------------------------------------------------------------------------------ Below are my initial comments on the draft. 1. I believe, the RFC shoudl be updated and advanced to be a draft standard. teh updated RFC should include a) precise definition of NAT-PT, b) the applicability scenarios, c) Recent NAT and IPsec documents (NAT-MIB, MIDCOM-MIB, NAT-Traversal etc.) that augment NAT-PT d)deployment/inter-oprability experience from vendors. In other words, I believe, tis document itself should be a section of the DS update of the RFC 2766. 2. Section 3.1 - You should refer Midcom work here. ALGs can be moved out of the NAT-PT with the support of Midcom protocol. 3. Section 3.2 - Scalability - There are proposals that do address the scalability issue (refer Park's draft kere). 4. section 4.2.1 - proxying will require Client applications to change in several cases. Several applications do not have proxy servers. Most Proxy servers are for TCP based apps only. All in all, this seened like hand-waving to me, without a detailed coverage of limitaton of requiring/using proxies. 5. Summary - The sentence "In no case should NAT-PT be viewed as a generic solution for IPv6/IPv4 transition in an IPv6-only network." seemed totally out of place and a non-sequitor to the rest of the document. More later... regards, suresh --- Suresh K Satapati wrote: > Pekka, > > Lets not mislead the WG here. > > From the thread: > http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html > > I disagree with: > > 2 b) only a more limited set of IPv6-only networks > in the applicability statement. These scenarios, may be > counterproductive in the face of dual-stack deployment. > > 3. The recommendation of the specific scenarios. In the body of the > text, some applicability was identified in two kinds of networks: the > legacy IPv4 equipment and 3GPP. There was no full consensus that > going down that deployment path (the point above) would > necessarily make sense. > > As I see it, there was infact a consensus among the DT on the scenarios. > The above are more of your opinions on the draft. Pls do not represent the > DT on the above. > > I did not see a major disagreement on the applicable scenarios, except > from you (as in 2b and 3) . The slight opposition was on the IMS media > translation in 3GPP scenario. Others can speak for themselves on this. > > -- > Suresh > > On Fri, 7 Nov 2003, Pekka Savola wrote: > > > Hi, > > > > On Fri, 7 Nov 2003, Brian E Carpenter wrote: > > > I think this is very useful draft and it's in good shape. > > > I'd like to see the section on 3GPP2 completed, but otherwise > > > the sooner we get this analysis published, the better. > > > > Thanks Brian. Just in case, did you have a look at the "NAT-PT > > applicability considerations" thread, at: > > > > http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html > > > > .. which tried to provoke thoughts on several subjects relating to the > > document which might be unanimous. > > > > Do you have any further comments to make based on these? > > > > -- > > 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 Nov 11 12:50:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13103 for ; Tue, 11 Nov 2003 12:50:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJccN-000Cnv-Bg for v6ops-data@psg.com; Tue, 11 Nov 2003 17:47:55 +0000 Received: from [66.218.79.81] (helo=web80511.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJccK-000CmC-AF for v6ops@ops.ietf.org; Tue, 11 Nov 2003 17:47:52 +0000 Message-ID: <20031111174750.18560.qmail@web80511.mail.yahoo.com> Received: from [130.129.133.218] by web80511.mail.yahoo.com via HTTP; Tue, 11 Nov 2003 09:47:50 PST Date: Tue, 11 Nov 2003 09:47:50 -0800 (PST) From: Fred Templin Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Erik Nordmark Cc: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-493392522-1068572870=:17781" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-493392522-1068572870=:17781 Content-Type: text/plain; charset=us-ascii Erik, Thanks for the comments; as you may have seen I just posted an update to the document that fixes at least one of the issues you have identified (the new version is using the correct L2 fragmentation mechanism). See: www.geocities.com/osprey67/tunnelmtu-04.txt As to how the near endpoint of the tunnel detects the MTU of the IPv4 path to the far endpoint, it is done via authenticated IPv6 Router Advertisement messages from the far end that encode MTU values. One of the MTU values is a measure of the largest packet (or, packet fragment) that has been observed by the far end to traverse the tunnel in one piece, and the other two MTU values provide an indication of the far end's receive buffer size and fragment loss due to congestion. Thanks - Fred osprey67@yahoo.com See below: Erik Nordmark wrote: > As I said I would do in my 10/29/2003 note on the ipv6 list under > the subject heading: "Re: RFC 2461bis issue: MTU handling", I am > now prepared to submit a new version of my document on dynamic > MTU determination. (Please note that there are some significant > differences from the previous version.) I looked over the your document and I wonder how it applies to the WG's desire to clarify the transition mechanisms document and move that to Draft Standard soon. Thus I recommend the WG participants read the document so we can discuss that high-level issue on Wednesday. From one reading I see: Using period(?) hop-by-hop options in data packets to probe the IPv6 path MTU; those packets would be processed slowly by IPv6 routers. IPv6 fragmentation by IPv6 routers; not allowed per RFC 2460 Assuming security associations between the encapsulator and decapsulator Having decapsulators that are otherwise hosts send Router Advertisements seems a bit odd. I don't understand how the IPv4 path MTU is detected by the encapsulator/decapsulator somehow. Is this based on ICMPv4 packet too big message or something else? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-493392522-1068572870=:17781 Content-Type: text/html; charset=us-ascii
Erik,
 
Thanks for the comments; as you may have seen I just posted an update
to the document that fixes at least one of the issues you have identified
(the  new version is using the correct L2 fragmentation mechanism). See:
 
 
As to how the near endpoint of the tunnel detects the MTU of the IPv4 path
to the far endpoint, it is done via authenticated IPv6 Router Advertisement
messages from the far end that encode MTU values. One of the MTU values
is a measure of the largest packet (or, packet fragment) that has been
observed by the far end to traverse the tunnel in one piece, and the other
two MTU values provide an indication of the far end's receive buffer size
and fragment loss due to congestion.
 
Thanks - Fred
 
See below:

Erik Nordmark <Erik.Nordmark@sun.com> wrote:

> As I said I would do in my 10/29/2003 note on the ipv6 list under
> the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
> now prepared to submit a new version of my document on dynamic
> MTU determination. (Please note that there are some significant
> differences from the previous version.)

I looked over the your document and I wonder how it applies to the WG's
desire to clarify the transition mechanisms document and move that
to Draft Standard soon. 

Thus I recommend the WG participants read the document so we can
discuss that high-level issue on Wednesday.

From one reading I see:
Using period(?) hop-by-hop options in data packets to probe the IPv6
path MTU; those packets would be processed slowly by IPv6 routers.

IPv6 fragmentation by IPv6 routers; not allowed per RFC 2460

Assuming security associations between the encapsulator and decapsulator

Having decapsulators that are otherwise hosts send Router Advertisements seems
a bit odd.

I don't understand how the IPv4 path MTU is detected by the
encapsulator/decapsulator somehow. Is this based on ICMPv4 packet too big
message or something else?

Erik


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--0-493392522-1068572870=:17781-- From owner-v6ops@ops.ietf.org Tue Nov 11 15:05:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18782 for ; Tue, 11 Nov 2003 15:05:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJehN-000Pir-5u for v6ops-data@psg.com; Tue, 11 Nov 2003 20:01:13 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJehI-000Pie-Aq for v6ops@ops.ietf.org; Tue, 11 Nov 2003 20:01:08 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2003 12:07:41 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hABK16mU012425; Tue, 11 Nov 2003 12:01:06 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANL72008; Tue, 11 Nov 2003 12:00:51 -0800 (PST) Date: Tue, 11 Nov 2003 12:00:48 -0800 (PST) From: Suresh Satapati To: Pyda Srisuresh cc: v6ops@ops.ietf.org Subject: Re: draft-satapati-v6ops-natpt-applicability-00 In-Reply-To: <20031111173836.42273.qmail@web40405.mail.yahoo.com> Message-ID: References: <20031111173836.42273.qmail@web40405.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Suresh, My responses inline, only to comments on the draft. > ------------------------------------------------------------------------------ > > Below are my initial comments on the draft. > > 1. I believe, the RFC shoudl be updated and advanced to be a draft standard. > teh updated RFC should include a) precise definition of NAT-PT, b) the a) needs discussion and consensus of WG. I agree with the intention. > applicability scenarios, c) Recent NAT and IPsec documents (NAT-MIB, > MIDCOM-MIB, NAT-Traversal etc.) that augment NAT-PT > d)deployment/inter-oprability experience from vendors. In other words, I > believe, tis document itself should be a section of the DS update of the RFC > 2766. > Same as above. > 2. Section 3.1 - You should refer Midcom work here. ALGs can be moved out of > the NAT-PT with the support of Midcom protocol. I agree in principle. But I felt this is beyond the scope of this document. > > 3. Section 3.2 - Scalability - There are proposals that do address the > scalability issue (refer Park's draft kere). > Out of scope. We are not solving problems in this document. > 4. section 4.2.1 - proxying will require Client applications to change in > several cases. Several applications do not have proxy servers. Most Proxy > servers are for TCP based apps only. All in all, this seened like hand-waving > to me, without a detailed coverage of limitaton of requiring/using proxies. > Agreed. We could use a little more wording here. > 5. Summary - The sentence "In no case should NAT-PT be viewed as a generic > solution for IPv6/IPv4 transition in an IPv6-only network." seemed totally > out of place and a non-sequitor to the rest of the document. > This comes from the general agreement within the v6ops WG that dual-stack deployment is the way to go as long as you want to talk v4. > > --- Suresh K Satapati wrote: > > Pekka, > > > > Lets not mislead the WG here. > > > > From the thread: > > http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html > > > > I disagree with: > > > > 2 b) only a more limited set of IPv6-only networks > > in the applicability statement. These scenarios, may be > > counterproductive in the face of dual-stack deployment. > > > > 3. The recommendation of the specific scenarios. In the body of the > > text, some applicability was identified in two kinds of networks: the > > legacy IPv4 equipment and 3GPP. There was no full consensus that > > going down that deployment path (the point above) would > > necessarily make sense. > > > > As I see it, there was infact a consensus among the DT on the scenarios. > > The above are more of your opinions on the draft. Pls do not represent the > > DT on the above. > > > > I did not see a major disagreement on the applicable scenarios, except > > from you (as in 2b and 3) . The slight opposition was on the IMS media > > translation in 3GPP scenario. Others can speak for themselves on this. > > > > -- > > Suresh > > > > On Fri, 7 Nov 2003, Pekka Savola wrote: > > > > > Hi, > > > > > > On Fri, 7 Nov 2003, Brian E Carpenter wrote: > > > > I think this is very useful draft and it's in good shape. > > > > I'd like to see the section on 3GPP2 completed, but otherwise > > > > the sooner we get this analysis published, the better. > > > > > > Thanks Brian. Just in case, did you have a look at the "NAT-PT > > > applicability considerations" thread, at: > > > > > > http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html > > > > > > .. which tried to provoke thoughts on several subjects relating to the > > > document which might be unanimous. > > > > > > Do you have any further comments to make based on these? > > > > > > -- > > > 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 Nov 11 21:43:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04832 for ; Tue, 11 Nov 2003 21:43:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJkvD-000Ain-UW for v6ops-data@psg.com; Wed, 12 Nov 2003 02:39:55 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJkvB-000Aib-14 for v6ops@ops.ietf.org; Wed, 12 Nov 2003 02:39:53 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 7F09A3F886E; Tue, 11 Nov 2003 21:39:49 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id C9C9779D8D; Tue, 11 Nov 2003 21:39:48 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Wed, 12 Nov 2003 08:09:48 +0530 X-Sasl-Enc: 8kTdhzP92T2R2g3d24dqfw 1068604788 Cc: "Erik Nordmark" Subject: Re: comments on mech-v2-01 References: ARRAY(0xa04245c) In-Reply-To: ARRAY(0xa0421bc) Message-Id: <20031112023948.C9C9779D8D@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 11 Nov 2003 15:57:41 +0100 (CET), "Erik Nordmark" said: > > > The reason it was written like this was to not immediately > > > invalidate any older implementations that might have sent the link- > > > layer address options. I don't know if there ever were any such > > > implementations. > > > > Do you think we should change it now? I prefer "SHOULD NOT" and > > "SHOULD ignore". > > Problem is if both ends of a pair of nodes don't satisfy the > recommendation stated in the SHOULDs. In that case things would not > interoperate. Thus I think there has to be a MUST applied to at least > one of the sender and the receiver. Hmmm... You are right. So, it has to be either 1) "MUST" and "SHOULD ignore" (as it is today), or 2) "MUST", and "MUST ignore". Probably we should not care that much about invalidating older implementations (if any) as this is an easy requirement to implement, and go with the later. CP From owner-v6ops@ops.ietf.org Wed Nov 12 11:24:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25357 for ; Wed, 12 Nov 2003 11:24:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJxhL-0007ks-Ix for v6ops-data@psg.com; Wed, 12 Nov 2003 16:18:27 +0000 Received: from [66.218.79.75] (helo=web80505.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJxhE-0007k7-Q1 for v6ops@ops.ietf.org; Wed, 12 Nov 2003 16:18:20 +0000 Message-ID: <20031112161820.38208.qmail@web80505.mail.yahoo.com> Received: from [130.129.130.130] by web80505.mail.yahoo.com via HTTP; Wed, 12 Nov 2003 08:18:20 PST Date: Wed, 12 Nov 2003 08:18:20 -0800 (PST) From: Fred Templin Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031111163706.40437.qmail@web80506.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-411227274-1068653900=:37390" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-411227274-1068653900=:37390 Content-Type: text/plain; charset=us-ascii I have one more update to share on this document. It is found at: www.geocities.com/osprey67/tunnelmtu-05.txt Changelog is below: Fred Templin osprey67@yahoo.com Appendix A. Changelog o Removed support for IPv4 fragmentation to save state; eliminated control message overhead. Fred Templin wrote: Folks, I uncovered a few bugs and made some changes since yesterday. (I was using the wrong mechanism for L2 fragmentation! :^/ ) The new document version can be found at: www.geocities.com/osprey67/tunnelmtu-04.txt The changelog appears below: Fred osprey67@yahoo.com Appendix A. Changelog o Specified use of IPv4 fragmentation (instead of IPv6) as the L2 fragmentation mechanism. o Added CongestMTU for use during periods of congestion. o Added support for sending congestion indications not associated with probes. o Clarified DF bit settings. Fred Templin wrote: I would like to add some qualifying remarks to my previous message. Many of my earlier messages on this subject were preliminary, but this message and my current document are not. See: www.geocities.com/osprey67/tunnelmtu-03.txt This document offers the following important conclusion: "It is impossible for the network to anticipate the packet transmission strategy of the application." This result is perhaps not surprising and certainly not new, as it is accurately predicted by the End-to-End Principle. Some additional notes: - For the past several months, I have worked under the premise that a robust, secure, efficient, and generalized Path MTU discovery mechanism for IPv6-in-IPv4 tunnels was needed that operated autonomously and without direction from the application. I struggled for many months to come up with a solution that satisfied this design point and failed - as have many others over the past 15 years. - After finally accepting the above conclusion and recognizing the means by which the application could provide guidance to the network, the solution was immediately obvious and I was able to write the entire document on the 4.5 hr flight into Minneapolis. All those interested in path MTU discovery (and the more general subject of application<->network interactions) should read this document along with the normative references it cites (even reading just the Introduction should be sufficient if time is short). The document probably has a few bugs, and I would appreciate comments. But, the conclusions will not go away and are indeed inescapable. Thanks - Fred ftemplin@iprg.nokia.com P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version. Fred Templin wrote: As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-411227274-1068653900=:37390 Content-Type: text/html; charset=us-ascii
I have one more update to share on this document. It is found at:
 
 
Changelog is below:
 
Fred Templin
 
Appendix A. Changelog

   o  Removed support for IPv4 fragmentation to save state; eliminated
      control message overhead.


Fred Templin <osprey67@yahoo.com> wrote:
Folks,
 
I uncovered a few bugs and made some changes since yesterday.
(I was using the wrong mechanism for L2 fragmentation! :^/ ) The
new document version can be found at:
 
 
The changelog appears below:
 
Fred
 
Appendix A. Changelog

   o  Specified use of IPv4 fragmentation (instead of IPv6) as the L2
      fragmentation mechanism.

   o  Added CongestMTU for use during periods of congestion.

   o  Added support for sending congestion indications not associated
      with probes.

   o  Clarified DF bit settings.



Fred Templin <osprey67@yahoo.com> wrote:
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 
 
  

Fred Templin <osprey67@yahoo.com> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-411227274-1068653900=:37390-- From owner-v6ops@ops.ietf.org Wed Nov 12 11:54:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27180 for ; Wed, 12 Nov 2003 11:54:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJyCv-000ELr-Ha for v6ops-data@psg.com; Wed, 12 Nov 2003 16:51:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJyCp-000EKo-OA for v6ops@ops.ietf.org; Wed, 12 Nov 2003 16:50:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hACGoud16596; Wed, 12 Nov 2003 18:50:56 +0200 Date: Wed, 12 Nov 2003 18:50:55 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: transmech substantial comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 11 Nov 2003, Erik Nordmark wrote: > > 1) section 2.3 on advertising addresses in the DNS is a bit out of place in > > this document. If there was some other doc describing how to provision > > services with addresses in the DNS, the discussion would be best placed > > there. Can anyone think of such a document? > > I don't know of such a document. Now that I think about it, draft-ietf-dnsop-ipv6-dns-issues-02.txt at least could b expanded to include more guidelines rather than issues. I'll consider this.. > > also move the paragraph starting with "A possible implication" up before > > the previous paragraph, as "A possible..." as it seems like a more logic > > place for it. > > Don't understand where you think it belongs; the several preceeding > paragraphs follow on eachother. Which paragraph do you think it should > preceed? It seems to me that the paragraph starting with "Since the.." starts to describe a separate problem. There are two issues here AFAICS: 1) an ipv6 node is placed on a link "prematurely", and advertises its address in the DNS. 2) an ipv6 node without connectivity tries to reach a node by getting a AAAA record from DNS, and The general tone of a "A possible implication" -section seems to address 1) only, while the preceding paragraph discusses 2). So, saying "implication of these recommendations" seems to either belong after 1) (because it only covers 1), or reworded to be a bit more general. Right? > > - the bidirectionality rules need to be reworded and described > > better, and we may have to beef up the source address selection part of > > a tunnel a bit. > > Yes, if we remove the unidirectional tunneling text then the IPv4 source > address at the encapsulator can be described as something which is > configured since both ends of the tunnel need to have matching IPv4 > addresses for the tunnel. Right. (There is an obvious failure mode with multiple interfaces and a change in where the route towards the tunnel endpoint points to, of course -- which why it probably needs to be spelled out better as spelled out later.) > I don't see why we'd need to do that. Tunnels, using the same versions or > different versions, can cross a region where the DSCP is interpreted > differently thus the issues whether to copy the DSCP when encapsulating is > identical AFAIK. > > For the congestion bits the same considerations apply whether the IP > versions are the same or different. > > So do you have a concrete argument that we need explicit text on this? > (If we want this to move to DS sooner rather than later I think we should > avoid this.) No, I don't have a specific arguments. It just looked like a potential hole in the spec. But I'm OK with leaving it vague. > > * there should be text what to do if the current tradeoffs of configured > > tunneling are not considered to be OK, in: > > Instead of claiming that GRE with keys (which are in RFC 1701 but not > part of RFC 2784) is much secure, how about instead saying that AH/ESP > can be applied to the tunnel? One could say one or the other, or both (if they are actually more secure, which I'm not 100% sure about). My concern is just that setting up a GRE tunnel instead of IP-IP tunnel is typically fully equivalent (subject to a trivial modification to the MTU usage parts), and configured similarly. IPsec is of course a proper way to do it, but AFAIK it hasn't been implemented (v4-in-v6 IPsec, that is) -- that's at least what Francis Dupont has been saying (unless I misremember the context)... -- 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 Nov 12 12:04:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27642 for ; Wed, 12 Nov 2003 12:04:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJyMx-000GU1-SJ for v6ops-data@psg.com; Wed, 12 Nov 2003 17:01:27 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJyMv-000GTk-J1 for v6ops@ops.ietf.org; Wed, 12 Nov 2003 17:01:25 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hACH1LPh021024 for ; Wed, 12 Nov 2003 10:01:21 -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 <0HO9001OS0M7R4@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 12 Nov 2003 10:01:21 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HO9007530M4PA@mail.sun.net> for v6ops@ops.ietf.org; Wed, 12 Nov 2003 10:01:17 -0700 (MST) Date: Wed, 12 Nov 2003 09:04:10 -0800 From: Alain Durand Subject: Re: transmech substantial comments In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org, Erik Nordmark Message-id: <3BD6DC3A-1532-11D8-BA39-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Nov 12, 2003, at 8:50 AM, Pekka Savola wrote: > On Tue, 11 Nov 2003, Erik Nordmark wrote: >>> 1) section 2.3 on advertising addresses in the DNS is a bit out of >>> place in >>> this document. If there was some other doc describing how to >>> provision >>> services with addresses in the DNS, the discussion would be best >>> placed >>> there. Can anyone think of such a document? >> >> I don't know of such a document. > > Now that I think about it, draft-ietf-dnsop-ipv6-dns-issues-02.txt at > least could b expanded to include more guidelines rather than issues. You're more than welcome to contribute text! - Alain. From owner-v6ops@ops.ietf.org Wed Nov 12 14:14:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02432 for ; Wed, 12 Nov 2003 14:14:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK0MF-000GuW-GL for v6ops-data@psg.com; Wed, 12 Nov 2003 19:08:51 +0000 Received: from [66.218.79.73] (helo=web80503.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK0MB-000GuB-Uu for v6ops@ops.ietf.org; Wed, 12 Nov 2003 19:08:47 +0000 Message-ID: <20031112190845.16713.qmail@web80503.mail.yahoo.com> Received: from [130.129.130.130] by web80503.mail.yahoo.com via HTTP; Wed, 12 Nov 2003 11:08:45 PST Date: Wed, 12 Nov 2003 11:08:45 -0800 (PST) From: Fred Templin Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031112161820.38208.qmail@web80505.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1473857740-1068664125=:16558" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1473857740-1068664125=:16558 Content-Type: text/plain; charset=us-ascii Yes, it's me again - hopefully one last time. I took out a bit too much in my last iteration on the document. I have added the following new text under "Sending Packets:" "If the packet is 1280 bytes in length and it contains an IPv6 fragment header, the tunnel interface encapsluates the packet in IPv4 then fragments the encapsulated packet to a fragment size of 256 bytes. Each of the five resulting fragments will add a 20 byte IPv4 fragment header making each fragment 276 bytes. Thus, each fragment will fit within the ~200msec human perceptible delay budget for the lowest-common denominator link that may occur over the tunnel, which is 296 bytes for a 9.6kbps link ([RFC3150], section 2.3)." See: www.geocities.com/osprey67/tunnelmtu-06.txt Thanks - Fred osprey67@yahoo.com Fred Templin wrote: I have one more update to share on this document. It is found at: www.geocities.com/osprey67/tunnelmtu-05.txt Changelog is below: Fred Templin osprey67@yahoo.com Appendix A. Changelog o Removed support for IPv4 fragmentation to save state; eliminated control message overhead. Fred Templin wrote: Folks, I uncovered a few bugs and made some changes since yesterday. (I was using the wrong mechanism for L2 fragmentation! :^/ ) The new document version can be found at: www.geocities.com/osprey67/tunnelmtu-04.txt The changelog appears below: Fred osprey67@yahoo.com Appendix A. Changelog o Specified use of IPv4 fragmentation (instead of IPv6) as the L2 fragmentation mechanism. o Added CongestMTU for use during periods of congestion. o Added support for sending congestion indications not associated with probes. o Clarified DF bit settings. Fred Templin wrote: I would like to add some qualifying remarks to my previous message. Many of my earlier messages on this subject were preliminary, but this message and my current document are not. See: www.geocities.com/osprey67/tunnelmtu-03.txt This document offers the following important conclusion: "It is impossible for the network to anticipate the packet transmission strategy of the application." This result is perhaps not surprising and certainly not new, as it is accurately predicted by the End-to-End Principle. Some additional notes: - For the past several months, I have worked under the premise that a robust, secure, efficient, and generalized Path MTU discovery mechanism for IPv6-in-IPv4 tunnels was needed that operated autonomously and without direction from the application. I struggled for many months to come up with a solution that satisfied this design point and failed - as have many others over the past 15 years. - After finally accepting the above conclusion and recognizing the means by which the application could provide guidance to the network, the solution was immediately obvious and I was able to write the entire document on the 4.5 hr flight into Minneapolis. All those interested in path MTU discovery (and the more general subject of application<->network interactions) should read this document along with the normative references it cites (even reading just the Introduction should be sufficient if time is short). The document probably has a few bugs, and I would appreciate comments. But, the conclusions will not go away and are indeed inescapable. Thanks - Fred ftemplin@iprg.nokia.com P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version. Fred Templin wrote: As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-1473857740-1068664125=:16558 Content-Type: text/html; charset=us-ascii
Yes, it's me again - hopefully one last time. I took out a bit too much in
my last iteration on the document. I have added the following new text
under "Sending Packets:"

      "If the packet is 1280 bytes in length and it contains an IPv6
      fragment header, the tunnel interface encapsluates the packet
      in IPv4 then fragments the encapsulated packet to a fragment
      size of 256 bytes. Each of the five resulting fragments will
      add a 20 byte IPv4 fragment header making each fragment 276
      bytes. Thus, each fragment will fit within the ~200msec human
      perceptible delay budget for the lowest-common denominator
      link that may occur over the tunnel, which is 296 bytes for
      a 9.6kbps link ([RFC3150], section 2.3)."
 
See:
 
 
Thanks - Fred
osprey67@yahoo.com


Fred Templin <osprey67@yahoo.com> wrote:
I have one more update to share on this document. It is found at:
 
 
Changelog is below:
 
Fred Templin
 
Appendix A. Changelog

   o  Removed support for IPv4 fragmentation to save state; eliminated
      control message overhead.


Fred Templin <osprey67@yahoo.com> wrote:
Folks,
 
I uncovered a few bugs and made some changes since yesterday.
(I was using the wrong mechanism for L2 fragmentation! :^/ ) The
new document version can be found at:
 
 
The changelog appears below:
 
Fred
 
Appendix A. Changelog

   o  Specified use of IPv4 fragmentation (instead of IPv6) as the L2
      fragmentation mechanism.

   o  Added CongestMTU for use during periods of congestion.

   o  Added support for sending congestion indications not associated
      with probes.

   o  Clarified DF bit settings.



Fred Templin <osprey67@yahoo.com> wrote:
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 
 
  

Fred Templin <osprey67@yahoo.com> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-1473857740-1068664125=:16558-- From owner-v6ops@ops.ietf.org Wed Nov 12 14:31:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03092 for ; Wed, 12 Nov 2003 14:31:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK0fj-000KpL-Dq for v6ops-data@psg.com; Wed, 12 Nov 2003 19:28:59 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK0fg-000Kow-Nb for v6ops@ops.ietf.org; Wed, 12 Nov 2003 19:28:56 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA18996 for ; Wed, 12 Nov 2003 19:28:54 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 TAA09261 for ; Wed, 12 Nov 2003 19:28:54 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hACJSsg17118 for v6ops@ops.ietf.org; Wed, 12 Nov 2003 19:28:54 GMT Date: Wed, 12 Nov 2003 19:28:54 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Message-ID: <20031112192854.GB16674@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20031107220222.A55C993@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031107220222.A55C993@coconut.itojun.org> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A handful more comments on draft-ietf-v6ops-mech-v2-01.txt, which may be duplicates... 1. Why is IPv4 compatible addressing defined in the first section, if it is deprecated? 2. IPv4 compatibles are mentioned in 3.6 - this should be removed (aren't general multicast source addresses dropped anyway?) 3. Section 2 starts "the most straightforward way", though this is the only way in this document? 4. In 2.2 should we mention that that app may or may not be v6 aware or capable? The shin-application-transition draft could be pointed to, although it is not a WG item ist looks very good work. 5. In 2.3 there are 2 references to 6bone. Should probably use something else given 6bone is deprecated. 6. In section 3, or in the introduction, some mention should probably be made as to why automatic tunneling (6to4, RFC3056) is not inlcuded in the basic mechanisms (it postdates 2893 but is omitted). Tim From owner-v6ops@ops.ietf.org Wed Nov 12 17:47:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14098 for ; Wed, 12 Nov 2003 17:46:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK3i0-000MpW-0A for v6ops-data@psg.com; Wed, 12 Nov 2003 22:43:32 +0000 Received: from [66.218.79.71] (helo=web80501.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK3hx-000MpJ-Rb for v6ops@ops.ietf.org; Wed, 12 Nov 2003 22:43:29 +0000 Message-ID: <20031112224328.98984.qmail@web80501.mail.yahoo.com> Received: from [130.129.130.130] by web80501.mail.yahoo.com via HTTP; Wed, 12 Nov 2003 14:43:28 PST Date: Wed, 12 Nov 2003 14:43:28 -0800 (PST) From: Fred Templin Subject: transmech MTU comments To: v6ops@ops.ietf.org Cc: osprey67@yahoo.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1737028423-1068677008=:96194" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1737028423-1068677008=:96194 Content-Type: text/plain; charset=us-ascii Erik, My understanding of RFC 3168 is that when the tunnel interface forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1) codepoint in the traffic class field, it MAY set the codepoint to CE if congestion is experienced. I interpret the MAY to mean that the other option is to drop the packet. If the packet is to be dropped, should it be dropped silently? Also, could a link restriction be considered as congestion? If so, does drop silent also entail NOT sending an ICMPv6 "packet too big" message back to the source? Thanks - Fred ftemplin@iprg.nokia.com --0-1737028423-1068677008=:96194 Content-Type: text/html; charset=us-ascii
Erik,
 
My understanding of RFC 3168 is that when the tunnel interface
forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1)
codepoint in the traffic class field, it MAY set the codepoint to CE if
congestion is experienced. I interpret the MAY to mean that the other
option is to drop the packet. If the packet is to be dropped, should it
be dropped silently? Also, could a link restriction be considered as
congestion? If so, does drop silent also entail NOT sending an
ICMPv6 "packet too big" message back to the source?
 
Thanks - Fred
--0-1737028423-1068677008=:96194-- From owner-v6ops@ops.ietf.org Wed Nov 12 17:51:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14283 for ; Wed, 12 Nov 2003 17:51:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK3nk-000NNX-Qu for v6ops-data@psg.com; Wed, 12 Nov 2003 22:49:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK3ni-000NNF-Qg for v6ops@ops.ietf.org; Wed, 12 Nov 2003 22:49:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hACMnP221993 for ; Thu, 13 Nov 2003 00:49:25 +0200 Date: Thu, 13 Nov 2003 00:49:25 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Accept Application Transition Considerations as WG Draft? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, In the second session in Minneapolis, we had unanimous consensus that the application transition considerations document would serve as a good starting place for our work, and that we should accept it as a WG draft. The latest version of this document can be found at: http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-02.txt Unless there are any objections from the mailing list, We'll ask the authors to publish the next version as a WG I-D. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Wed Nov 12 17:55:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14401 for ; Wed, 12 Nov 2003 17:55:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK3rB-000Npz-O5 for v6ops-data@psg.com; Wed, 12 Nov 2003 22:53:01 +0000 Received: from [66.218.79.82] (helo=web80512.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK3r7-000Noo-TH for v6ops@ops.ietf.org; Wed, 12 Nov 2003 22:52:57 +0000 Message-ID: <20031112225257.90864.qmail@web80512.mail.yahoo.com> Received: from [130.129.130.130] by web80512.mail.yahoo.com via HTTP; Wed, 12 Nov 2003 14:52:57 PST Date: Wed, 12 Nov 2003 14:52:57 -0800 (PST) From: Fred Templin Subject: Re: transmech MTU comments To: v6ops@ops.ietf.org Cc: osprey67@yahoo.com In-Reply-To: <20031112224328.98984.qmail@web80501.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-186411013-1068677577=:90412" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-186411013-1068677577=:90412 Content-Type: text/plain; charset=us-ascii Along with this, what if we were to set the tunnel MTU to a value that is slightly larger than the size of the underlying IPv4 interface (minus 20bytes for IPv4 header)? In the dynamic case, the test could be: - packet has ECT(0), ECT(1) codepoint - forward if smaller than link MTU, setting to CE if necessary; dropping if too large - packet does not have ECT(0), ECT(1) - check the IPv4 path MTU, forward if not larger, else send ICMPv6 "packet too big" Can something like this go as a text change suggestion for MECH? Thanks - Fred osprey67@yahoo.com Fred Templin wrote: Erik, My understanding of RFC 3168 is that when the tunnel interface forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1) codepoint in the traffic class field, it MAY set the codepoint to CE if congestion is experienced. I interpret the MAY to mean that the other option is to drop the packet. If the packet is to be dropped, should it be dropped silently? Also, could a link restriction be considered as congestion? If so, does drop silent also entail NOT sending an ICMPv6 "packet too big" message back to the source? Thanks - Fred ftemplin@iprg.nokia.com --0-186411013-1068677577=:90412 Content-Type: text/html; charset=us-ascii
Along with this, what if we were to set the tunnel MTU to a
value that is slightly larger than the size of the underlying
IPv4 interface (minus 20bytes for IPv4 header)? In the dynamic
case, the test could be:
 
  - packet has ECT(0), ECT(1) codepoint - forward if smaller than
    link MTU, setting to CE if necessary; dropping if too large
 
  - packet does not have ECT(0), ECT(1) - check the IPv4 path
    MTU, forward if not larger, else send ICMPv6 "packet too big"
 
Can something like this go as a text change suggestion for MECH?
 
Thanks - Fred
osprey67@yahoo.com

Fred Templin <osprey67@yahoo.com> wrote:
Erik,
 
My understanding of RFC 3168 is that when the tunnel interface
forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1)
codepoint in the traffic class field, it MAY set the codepoint to CE if
congestion is experienced. I interpret the MAY to mean that the other
option is to drop the packet. If the packet is to be dropped, should it
be dropped silently? Also, could a link restriction be considered as
congestion? If so, does drop silent also entail NOT sending an
ICMPv6 "packet too big" message back to the source?
 
Thanks - Fred
--0-186411013-1068677577=:90412-- From owner-v6ops@ops.ietf.org Wed Nov 12 18:06:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15104 for ; Wed, 12 Nov 2003 18:06:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK420-000PFv-Tc for v6ops-data@psg.com; Wed, 12 Nov 2003 23:04:12 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK41w-000PF7-Ue for v6ops@ops.ietf.org; Wed, 12 Nov 2003 23:04:09 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA23327 for ; Wed, 12 Nov 2003 23:04:07 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 XAA13535 for ; Wed, 12 Nov 2003 23:04:06 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hACN46t22519 for v6ops@ops.ietf.org; Wed, 12 Nov 2003 23:04:06 GMT Date: Wed, 12 Nov 2003 23:04:06 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Renumbering: prior draft Message-ID: <20031112230406.GE19242@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I mentioned Christian's prior renumbering draft which I think was presented at the London IETF in 2001. Here's the URL: http://www.watersprings.org/pub/id/draft-huitema-ipv6-renumber-00.txt It looks at scenarios and requirements, perhaps more than operational procedure, but it still very relevant. If Fred isn't doing a parallel rapid/"unplanned" renumbering draft I would be happy to act as editor for one (drop me a line if interested and we can maybe get a small team together). Tim From owner-v6ops@ops.ietf.org Wed Nov 12 18:20:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16702 for ; Wed, 12 Nov 2003 18:20:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK4FB-0000eZ-47 for v6ops-data@psg.com; Wed, 12 Nov 2003 23:17:49 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK4F7-0000e9-UE for v6ops@ops.ietf.org; Wed, 12 Nov 2003 23:17:45 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Nov 2003 15:20:00 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hACNHimU006582; Wed, 12 Nov 2003 15:17:44 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANN07527; Wed, 12 Nov 2003 15:17:43 -0800 (PST) Date: Wed, 12 Nov 2003 15:17:43 -0800 (PST) From: Suresh Satapati To: Randy Bush cc: v6ops@ops.ietf.org Subject: NAT-PT Applicabilty for 3GPP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Randy, The scenario in question is the one mentioned in the 3GPP Scenarios document. Refer to RFC 3574 Section 4.2, subsection 1. As per the analysis/solution for this specific IMS scenario, please refer to Section 4.1 of "Analysis on IPv6 Transition in 3GPP Networks" http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-07.txt: Figure 1 shows a possible configuration scenario where the SIP ALG is separated from the CSCFs. The translator can either be set up in a single device with both SIP translation and media translation, or those functionalities can be divided to two different entities with an interface in between. We call the combined network element on the edge of the IPv6-only IMS an "Interworking Unit" in this document. A SIP-specific translation mechanism, which could e.g. re-use limited subsets of NAT-PT [RFC2766], needs to be specified. The problems related to NAT-PT are discussed in appendix A. In the above, though a SIP-specific translation mechanism is being recommended, I do not see how the recommended solution will be fundamentally different from NAT-PT. In this sense, the applicability of NAT-PT is still valid. Thanks -- Suresh From owner-v6ops@ops.ietf.org Wed Nov 12 18:26:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16967 for ; Wed, 12 Nov 2003 18:26:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK4Lo-0001LD-6H for v6ops-data@psg.com; Wed, 12 Nov 2003 23:24:40 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK4Lm-0001KK-A3; Wed, 12 Nov 2003 23:24:38 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK4Ll-0001S4-Pn; Wed, 12 Nov 2003 17:24:37 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 12 Nov 2003 17:24:37 -0600 To: Suresh Satapati Cc: v6ops@ops.ietf.org Subject: Re: NAT-PT Applicabilty for 3GPP References: Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In the above, though a SIP-specific translation mechanism is being > recommended, I do not see how the recommended solution will be > fundamentally different from NAT-PT. In this sense, the applicability > of NAT-PT is still valid. if A is a proper subset of B, a need for A does not mandate B, especially if A is a very localized hack and B is global, generic, and questionable. randy From owner-v6ops@ops.ietf.org Wed Nov 12 21:02:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22294 for ; Wed, 12 Nov 2003 21:02:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK6kS-000Hli-4T for v6ops-data@psg.com; Thu, 13 Nov 2003 01:58:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK6kM-000HjC-GG for v6ops@ops.ietf.org; Thu, 13 Nov 2003 01:58:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAD1w9M25531 for ; Thu, 13 Nov 2003 03:58:09 +0200 Date: Thu, 13 Nov 2003 03:58:08 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Accept Renumbering Procedures as WG Draft? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, In the second session in Minneapolis, we had consensus that the renumbering procedure document would serve as a good starting place for our work, and that we should accept it as a WG draft. The latest version of this document can be found at: http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-01.txt Unless there are any objections from the mailing list, We'll ask the authors to publish the next version as a WG I-D. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Wed Nov 12 23:13:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26374 for ; Wed, 12 Nov 2003 23:13:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8oI-0007Iz-Np for v6ops-data@psg.com; Thu, 13 Nov 2003 04:10:22 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8oD-0007IS-Rz for v6ops@ops.ietf.org; Thu, 13 Nov 2003 04:10:17 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Nov 2003 20:17:15 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAD4AFw5017831; Wed, 12 Nov 2003 20:10:16 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANN31222; Wed, 12 Nov 2003 20:10:15 -0800 (PST) Date: Wed, 12 Nov 2003 20:10:15 -0800 (PST) From: Suresh Satapati To: Randy Bush cc: v6ops@ops.ietf.org Subject: Re: NAT-PT Applicabilty for 3GPP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Its a matter of how you deploy B, that translates to pain felt locally or globally Our document actually does mention the restricted deployment of B. Besides there is no need to reinvent the wheel when there is B sitting at PS. One could go and build what they need out of B. -- Suresh On Wed, 12 Nov 2003, Randy Bush wrote: > > In the above, though a SIP-specific translation mechanism is being > > recommended, I do not see how the recommended solution will be > > fundamentally different from NAT-PT. In this sense, the applicability > > of NAT-PT is still valid. > > if A is a proper subset of B, a need for A does not mandate B, > especially if A is a very localized hack and B is global, generic, > and questionable. > > randy > > From owner-v6ops@ops.ietf.org Thu Nov 13 00:20:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28134 for ; Thu, 13 Nov 2003 00:20:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK9pM-000DZm-GF for v6ops-data@psg.com; Thu, 13 Nov 2003 05:15:32 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK9pJ-000DZR-Sr for v6ops@ops.ietf.org; Thu, 13 Nov 2003 05:15:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAD5FFI29199; Thu, 13 Nov 2003 07:15:15 +0200 Date: Thu, 13 Nov 2003 07:15:14 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: transmech MTU comments In-Reply-To: <20031112224328.98984.qmail@web80501.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 12 Nov 2003, Fred Templin wrote: > My understanding of RFC 3168 is that when the tunnel interface > forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1) > codepoint in the traffic class field, it MAY set the codepoint to CE if > congestion is experienced. I interpret the MAY to mean that the other > option is to drop the packet. If the packet is to be dropped, should it > be dropped silently? Also, could a link restriction be considered as > congestion? If so, does drop silent also entail NOT sending an > ICMPv6 "packet too big" message back to the source? Where in the spec do you read that the MAY? What I basically read is 9.1.1, first paragraph, a couple of the last sentences. But that applies to the decapsulating router only. RFC3168 doesn't seem to define how to drop the packet, by the way, so I assume by "dropping" they mean a silent discard. I'm not sure whether it makes sense to delve into ECN details in the spec.. -- 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 Nov 13 04:38:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18279 for ; Thu, 13 Nov 2003 04:38:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKDqe-0009b2-SA for v6ops-data@psg.com; Thu, 13 Nov 2003 09:33:08 +0000 Received: from [66.218.79.82] (helo=web80512.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKDqa-0009ai-If for v6ops@ops.ietf.org; Thu, 13 Nov 2003 09:33:04 +0000 Message-ID: <20031113093303.40594.qmail@web80512.mail.yahoo.com> Received: from [63.197.18.101] by web80512.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 01:33:03 PST Date: Thu, 13 Nov 2003 01:33:03 -0800 (PST) From: Fred Templin Subject: Re: transmech MTU comments To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-500724539-1068715983=:34757" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-500724539-1068715983=:34757 Content-Type: text/plain; charset=us-ascii Pekka, >On Wed, 12 Nov 2003, Fred Templin wrote: >> My understanding of RFC 3168 is that when the tunnel interface >> forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1) >> codepoint in the traffic class field, it MAY set the codepoint to CE if >> congestion is experienced. I interpret the MAY to mean that the other >> option is to drop the packet. If the packet is to be dropped, should it >> be dropped silently? Also, could a link restriction be considered as >> congestion? If so, does drop silent also entail NOT sending an >> ICMPv6 "packet too big" message back to the source? > > Where in the spec do you read that the MAY? What I basically read is > 9.1.1, first paragraph, a couple of the last sentences. Check section 5, second to last paragraph. > But that applies to the decapsulating router only. I don't think so. The processing entity inside the encapsulator accepts a packet from the overlying IPv6 interface and enqueues it to an underlying IPv6-in-IPv4 interface, so I would call that entity a "router" > RFC3168 doesn't seem to define how to drop the packet, by the way, so I > assume by "dropping" they mean a silent discard. OK. > I'm not sure whether it makes sense to delve into ECN details in the > spec.. Well, it seems it should be documented somewhere. What do you suggest? Fred osprey67@yahoo.com --0-500724539-1068715983=:34757 Content-Type: text/html; charset=us-ascii
Pekka,
 
>On Wed, 12 Nov 2003, Fred Templin wrote:
>> My understanding of RFC 3168 is that when the tunnel interface
>> forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1)
>> codepoint in the traffic class field, it MAY set the codepoint to CE if
>> congestion is experienced. I interpret the MAY to mean that the other
>> option is to drop the packet. If the packet is to be dropped, should it
>> be dropped silently? Also, could a link restriction be considered as
>> congestion? If so, does drop silent also entail NOT sending an
>> ICMPv6 "packet too big" message back to the source?
>
> Where in the spec do you read that the MAY?   What I basically read is
> 9.1.1, first paragraph, a couple of the last sentences. 
 
Check section 5, second to last paragraph.
 
> But that applies to the decapsulating router only.
 
I don't think so. The processing entity inside the encapsulator
accepts a packet from the overlying IPv6 interface and enqueues
it to an underlying IPv6-in-IPv4 interface, so I would call that entity
a "router"

> RFC3168 doesn't seem to define how to drop the packet, by the way, so I
> assume by "dropping" they mean a silent discard.
 
OK.

> I'm not sure whether it makes sense to delve into ECN details in the
> spec..
 
Well, it seems it should be documented somewhere.
What do you suggest?
 
Fred
--0-500724539-1068715983=:34757-- From owner-v6ops@ops.ietf.org Thu Nov 13 09:06:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27045 for ; Thu, 13 Nov 2003 09:06:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKI2Q-0009PU-Me for v6ops-data@psg.com; Thu, 13 Nov 2003 14:01:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKI2L-0009P1-Go for v6ops@ops.ietf.org; Thu, 13 Nov 2003 14:01:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADE1Sp04268 for ; Thu, 13 Nov 2003 16:01:28 +0200 Date: Thu, 13 Nov 2003 16:01:28 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: automatic tunneling and v6 interoperation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Christian presented issues in the Unamanged connectivity possibilities in Minneapolis on Wednesday. There are multiple issues which I don't think came across clearly. I hope this mail helps in clarifying them. 1) the implication of economics to automatic tunneling mechanisms Christian stated that tunnel brokers and similar mainly make sense (from economics perspective etc.) if the ISP [or maybe also a transit of the ISP, btw.] is providing the service. However, what was not clearly noted that similar economics problem exists with automatic mechanisms as well. For example, if you want to go from a Teredo host to {native,6to4} hosts, who is providing the relay service? Clearly, the ISP where the Teredo host resides is not, because then by definition they could deploy e.g. tunnel service instead. 2) the implication of "no relays" deployment to v6 interoperability If there are no relays, note that every node a Teredo host needs to communicate with has to implement and enable Teredo, as well as publicize the Teredo addresses in the DNS in addition to the others, correct? (Similar would be equally applicable to no-relays deployment of 6to4, with the difference that every site, not every node, would have one enabled 6to4 router and publicized addresses.) 3) lifespan of a solution Solution like this must be supported for a long time, as long as there are people who go through NATs, unless their mechanisms are collectively everywhere replaced by something else. That may or may not be reasonable, if you expect the implementation of the techniques in every node. ==> trying to summarize.. So, I don't think Teredo (or 6to4 for that matter, but it's slightly better from the second perspective) really solves the "economics of providing IPv6 service" -problem. The only thing it seems to solve, to an extent, is a relatively smooth and direct IPv6 connectivity between Teredo hosts. On the other hand, speaking to any other kind of nodes (e.g., 6to4, native, ...) is riddled with identical problems as the IPv6 deployment at ISPs. It's best to be sure to understand the problems automatic tunneling mechanisms try to solve. Both Teredo and 6to4 seem reasonably usable if used only between {6to4,6to4} and {Teredo,Teredo}, ({native|tunnel-service,native|tunnel-service} being the first category). But I guess the question is whether we want 3 separate IPv6 Internets, and reducing that would only be possible through the addition of the lowest common denominator, Teredo, everywhere? (The alternative is a network of relay systems, which don't make sense economically.) -- 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 Nov 13 09:45:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28988 for ; Thu, 13 Nov 2003 09:45:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIfG-000Djy-5g for v6ops-data@psg.com; Thu, 13 Nov 2003 14:41:42 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIfC-000Djf-9M for v6ops@ops.ietf.org; Thu, 13 Nov 2003 14:41: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 230308007; Thu, 13 Nov 2003 15:41:36 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , Subject: RE: automatic tunneling and v6 interoperation Date: Thu, 13 Nov 2003 15:41:34 +0100 Organization: Unfix Message-ID: <013601c3a9f4$3cedaef0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Pekka Savola wrote: > Christian presented issues in the Unamanged connectivity > possibilities in Minneapolis on Wednesday. > > There are multiple issues which I don't think came across > clearly. I hope this mail helps in clarifying them. > > 1) the implication of economics to automatic tunneling mechanisms > > Christian stated that tunnel brokers and similar mainly make > sense (from economics perspective etc.) if the ISP [or maybe also a > transit of the ISP, btw.] is providing the service. For SixXS we try to keep traffic as local as possible. Dutch users only use dutch POP's, german users only the .de POP etc. Most ISP's are peering at the IX's anyways, so that doesn't burden much in the traffic costs as peering is (usuall) free. Next to that one could consider the "tunnelbroker" system as a ftp or website, it generates traffic at both the ISP where the user is located and the POP's site, it's just another service. Seeing that the traffic is still very small (4.5mbit/s) spread over about 1000 active tunnels should also indicate that the cost for the hardware is higher than the cost for traffic. Indeed it is all generosity at the moment that ISP's allow other ISP's users to use this service. You could also view it as free advertisement for the ISP's hosting the POP's as the people using it will see that their IPv6 service is good which will quite probably mean that all other services provided by them are good too. > It's best to be sure to understand the problems automatic tunneling > mechanisms try to solve. Both Teredo and 6to4 seem > reasonably usable if used only between {6to4,6to4} and {Teredo,Teredo}, > ({native|tunnel-service,native|tunnel-service} being the > first category). We have almost finished adding and testing tinc (http://tinc.nl.linux.org) support to the SixXS software which allows endusers, even behind firewalls and also NAT's to tunnel IPv6 over UDP or TCP (over httptunnel? :) Thus this will allow anybody, anywhere to use the service. The heartbeat clients make it easy to setup these tunnels and also allows real dynamic proto-41 tunnels using the heartbeat protocol. Endpoints are updated on-the-fly when the POP receives a heartbeat from the client, allowing dynamic IPv4 non-24/7 hosts to use the service. Every POP is directly connected to the ISP's own IPv6 infrastructure thus routing is the same as for native clients, except that the last end is actually going over IPv4 instead. This would all function much better ofcourse when there where more POPs scathered around the world, or even better, a POP per ISP... Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP7OYHimqKFIzPnwjEQIIXQCfd7/9e8zymzVNM1DpRc41nZ96xuUAn3ta tdYvpGFrYMYhmV+5rUB2O4jg =CmW4 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Thu Nov 13 09:50:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29208 for ; Thu, 13 Nov 2003 09:50:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIln-000Ebf-Ed for v6ops-data@psg.com; Thu, 13 Nov 2003 14:48:27 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIll-000EbK-Sv for v6ops@ops.ietf.org; Thu, 13 Nov 2003 14:48:25 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIlk-0002CL-AU for v6ops@ops.ietf.org; Thu, 13 Nov 2003 08:48:24 -0600 Message-ID: <20031113144702.71379.qmail@web80510.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1699315951-1068734822=:71326" Date: Thu, 13 Nov 2003 06:47:02 -0800 (PST) From: Fred Templin Subject: ISATAP in unmanaged networks? To: v6ops@ops.ietf.org, ipv6@ietf.org Cc: osprey67@yahoo.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1699315951-1068734822=:71326 Content-Type: text/plain; charset=us-ascii [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hello, It just now occurs to me that Christian's unmanaged networks presentiation during v6ops yesterday did not mention ISATAP as one of the automatic tunneling alternatives, and I wonder why this is so. I have not studied this space, but it occurs to me that ISATAP could be tried as a first alternative to check whether the two hosts are separated by a NAT. If there is no intervening NAT, it seems to me that ISATAP would provide the benefit of not needing the UDP header and "bubble" packets, yielding greater efficiency. Otherwise, if blocked by a NAT the initiating host coud after a short timeout try again with Teredo. I know that ISATAP has been seen as in the Enterprise space, but I see potential applicability here for the unmanaged. Comments? Fred Templin osprey67@yahoo.com --0-1699315951-1068734822=:71326 Content-Type: text/html; charset=us-ascii
Hello,
 
It just now occurs to me that Christian's unmanaged networks
presentiation during v6ops yesterday did not mention ISATAP
as one of the automatic tunneling alternatives, and I wonder
why this is so.
 
I have not studied this space, but it occurs to me that ISATAP
could be tried as a first alternative to check whether the two
hosts are separated by a NAT. If there is no intervening NAT,
it seems to me that ISATAP would provide the benefit of not
needing the UDP header and "bubble" packets, yielding
greater efficiency. Otherwise, if blocked by a NAT the
initiating host coud after a short timeout try again with
Teredo.
 
I know that ISATAP has been seen as in the Enterprise
space, but I see potential applicability here for the
unmanaged. Comments?
 
Fred Templin
 
--0-1699315951-1068734822=:71326-- From owner-v6ops@ops.ietf.org Thu Nov 13 09:57:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29583 for ; Thu, 13 Nov 2003 09:57:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIsH-000Fiw-QL for v6ops-data@psg.com; Thu, 13 Nov 2003 14:55:09 +0000 Received: from [148.88.16.230] (helo=rebo.lancs.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIsD-000FiD-T1 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 14:55:06 +0000 Received: from mail.lancs.ac.uk ([148.88.1.10] helo=marl.lancs.ac.uk) by rebo.lancs.ac.uk with esmtp (Exim 4.22) id 1AKIsD-0005By-2t; Thu, 13 Nov 2003 14:55:05 +0000 Received: from misconfig008.lancs.ac.uk ([148.88.248.8] helo=minime) by marl.lancs.ac.uk with esmtp (Exim 3.36 #1) id 1AKIsC-0000EU-00; Thu, 13 Nov 2003 14:55:04 +0000 From: "Michael Mackay" To: "'Pekka Savola'" Cc: Subject: RE: Comments: draft-savola-v6ops-transarch-01.txt Date: Thu, 13 Nov 2003 14:55:01 -0000 Message-ID: <001f01c3a9f6$1d8f5ed0$08f85894@minime> 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, >> might it be useful to discuss these assumptions before moving on to >> the architecture... > >I think this has improved; a new section has been added before 2.1 already >in -02 version. Yup, I agree with 2.1 but it would be good to try to expand on it and formalise this a bit more, if not here then somewhere. I see this as potentially being a quite important bit of the draft and while you certainly can't cover the whole thing in its entirety or present complete arguments either way, there should be something that makes the reader aware of a set of the main assumptions of high-level transitioning deployment. >> How about introducing the idea of service provisioning here, not sure >> if it would count as a general principle >> Services to be deployed >> Behaviour/performance expected > >Hmm.. could you elaborate a bit more? did you have specific ideas in mind >how to integrate it to the rest of the document? That is, what level of >services you're referring to? The expected performance etc. in realistic >terms might also be difficult to estimate.. Absolutely, it certainly isn't realistic to go into any sort of detail about the actual performance you can expect but surely the services you want to deploy over the transitioning architecture would have a relatively large affect on the architecture you deploy. Both in terms of 'performance' characteristics (bandwidth, scalability, etc) and services (protocols, etc) you want it to support. I lumped them together (though they probably should be separate) to indicate that what you operate over/expect from the architecture would have a bearing on what you deploy in the architecture itself (and so should count as a 'principle'?). >> Might be good to include some more discussion of the 'starting point' >> of the transitioning, e.g. IPv4 w/wo NAT, dual stack (various flavours) >> or new (IPv6 only?) > >Could you elaborate a bit (please check -02 version btw, this has improved >as well!)? There *maybe* could be some brief description without starting >scenarios, like v4 w/ NAT or v4 w/o NAT, but otherwise I think it has been >covered.. Ah, sorry about the mix-up. I had the -01 version (that expires April 04) and hadn't seen that -02 was out. That's fine. >> Definitely, I think the idea of discussing responsibility for the >> provisioning of transitioning is important... > >Yep.. I'm not sure how to proceed from there, though. If you have >thoughts how to make these issues more concrete (not just questions here >and there, and discussed a bit here and there) I'm all ears :-) Not sure how to approach this as it's something I think that needs to be discussed and perhaps some consensus reached on the list. Other than emphasising that the impetus right now lies with early adopters (which you've done) and suggesting how this might pan out in the future... dunno :-) In an ideal world I suppose everyone should be responsible for their own little bit of the transitioning scope within their boundaries, from local administrators on their own networks to service providers and beyond. Defining who should do what and what they should then provide to their users might be one way to start thinking about it. What do you think? >> I think this is a good draft and something that should be discussed >> here sooner rather than later, however it's perhaps a bit too general >> at this stage and doesn't actually specify an architecture as much as >> put forward some useful guidelines. > >I'm trying to avoid preaching "gospel", giving folks thoughts is more >important :-) fair enough. >> Another point is that while now it is probably best to deploy dual >> stack with limited IPv6, it might be an idea to outline how this is >> likely to change in the future. > >True.. I suppose it really depends upon what you see as the scope for the draft. I agree with the phases outlined ranging from IPv4 only through various flavours of dual stack to IPv6 only and the issues raised in each, but it would be nice to give a clearer idea of the preconditions/motivators for each phase and as such the prompts for the next shift along i.e. from dual stack v4/6 to IPv6 only. This might help readers to understand where we are now and where we are going/when we can expect to get there. Sorry about the mix-up, hope this clarifies things a bit. All the best, Michael From owner-v6ops@ops.ietf.org Thu Nov 13 09:57:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29615 for ; Thu, 13 Nov 2003 09:57:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIqy-000FLl-9P for v6ops-data@psg.com; Thu, 13 Nov 2003 14:53:48 +0000 Received: from [66.218.79.79] (helo=web80509.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKIqu-000FLK-FV for v6ops@ops.ietf.org; Thu, 13 Nov 2003 14:53:44 +0000 Message-ID: <20031113145338.52776.qmail@web80509.mail.yahoo.com> Received: from [63.197.18.101] by web80509.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 06:53:38 PST Date: Thu, 13 Nov 2003 06:53:38 -0800 (PST) From: Fred Templin Subject: ISATAP in unmanaged networks? To: ipv6@ietf.org, v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-859950525-1068735218=:48226" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-859950525-1068735218=:48226 Content-Type: text/plain; charset=us-ascii Hello, It just now occurs to me that Christian's unmanaged networks presentiation during v6ops yesterday did not mention ISATAP as one of the automatic tunneling alternatives, and I wonder why this is so. I have not studied this space, but it occurs to me that ISATAP could be tried as a first alternative to check whether the two hosts are separated by a NAT. If there is no intervening NAT, it seems to me that ISATAP would provide the benefit of not needing the UDP header and "bubble" packets, yielding greater efficiency. Otherwise, if blocked by a NAT the initiating host coud after a short timeout try again with Teredo. I know that ISATAP has been seen as in the Enterprise space, but I see potential applicability here for the unmanaged. Comments? Fred Templin osprey67@yahoo.com --0-859950525-1068735218=:48226 Content-Type: text/html; charset=us-ascii
Hello,
 
It just now occurs to me that Christian's unmanaged networks
presentiation during v6ops yesterday did not mention ISATAP
as one of the automatic tunneling alternatives, and I wonder
why this is so.
 
I have not studied this space, but it occurs to me that ISATAP
could be tried as a first alternative to check whether the two
hosts are separated by a NAT. If there is no intervening NAT,
it seems to me that ISATAP would provide the benefit of not
needing the UDP header and "bubble" packets, yielding
greater efficiency. Otherwise, if blocked by a NAT the
initiating host coud after a short timeout try again with
Teredo.
 
I know that ISATAP has been seen as in the Enterprise
space, but I see potential applicability here for the
unmanaged. Comments?
 
Fred Templin
--0-859950525-1068735218=:48226-- From owner-v6ops@ops.ietf.org Thu Nov 13 10:00:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29836 for ; Thu, 13 Nov 2003 10:00:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIvG-000GAo-H0 for v6ops-data@psg.com; Thu, 13 Nov 2003 14:58:14 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIvD-000GAP-Rj for v6ops@ops.ietf.org; Thu, 13 Nov 2003 14:58:12 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 78FC98A; Thu, 13 Nov 2003 23:58:09 +0900 (JST) To: Fred Templin Cc: ipv6@ietf.org, v6ops@ops.ietf.org In-reply-to: osprey67's message of Thu, 13 Nov 2003 06:53:38 PST. <20031113145338.52776.qmail@web80509.mail.yahoo.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ISATAP in unmanaged networks? From: itojun@iijlab.net Date: Thu, 13 Nov 2003 23:58:09 +0900 Message-Id: <20031113145809.78FC98A@coconut.itojun.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I have not studied this space, but it occurs to me that ISATAP >could be tried as a first alternative to check whether the two >hosts are separated by a NAT. If there is no intervening NAT, >it seems to me that ISATAP would provide the benefit of not >needing the UDP header and "bubble" packets, yielding >greater efficiency. Otherwise, if blocked by a NAT the >initiating host coud after a short timeout try again with >Teredo. ISATAP requires an ISATAP router in a site to advertise RA in a pretty weird fashion, which is clearly a drawback. itojun From owner-v6ops@ops.ietf.org Thu Nov 13 10:12:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01488 for ; Thu, 13 Nov 2003 10:12:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJ6S-000HwG-AT for v6ops-data@psg.com; Thu, 13 Nov 2003 15:09:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJ6O-000HvX-12 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 15:09:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADF9eD05544; Thu, 13 Nov 2003 17:09:40 +0200 Date: Thu, 13 Nov 2003 17:09:40 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: ISATAP in unmanaged networks? In-Reply-To: <20031113145338.52776.qmail@web80509.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I removed ipv6@ietf.org from Cc: to avoid unnecessary cross-posting. On Thu, 13 Nov 2003, Fred Templin wrote: > I have not studied this space, but it occurs to me that ISATAP > could be tried as a first alternative to check whether the two > hosts are separated by a NAT. If there is no intervening NAT, > it seems to me that ISATAP would provide the benefit of not > needing the UDP header and "bubble" packets, yielding > greater efficiency. Otherwise, if blocked by a NAT the > initiating host coud after a short timeout try again with > Teredo. There are multiple cases to consider: - host/router is not behind a NAT: * the ISP is providing the ISATAP service ==> this is a cornercase of tunnel service by the ISP - host/router is behind a NAT: * .. when the ISP is doing the NAT (e.g., GPRS -kind of scenario, also sometimes used for commmon xDSL networks) ==> same as above, the service provided by the ISP I don't think there's really applicability for ISATAP in this space if the ISP is co-operating (which is the requirement for ISATAP anyway). Configured tunneling (+ enhancements) is simpler and more generic. -- 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 Nov 13 10:17:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02078 for ; Thu, 13 Nov 2003 10:17:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJC1-000Ipa-RN for v6ops-data@psg.com; Thu, 13 Nov 2003 15:15:33 +0000 Received: from [66.218.79.76] (helo=web80506.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKJBy-000Ip3-Ji for v6ops@ops.ietf.org; Thu, 13 Nov 2003 15:15:30 +0000 Message-ID: <20031113151529.24772.qmail@web80506.mail.yahoo.com> Received: from [63.197.18.101] by web80506.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 07:15:29 PST Date: Thu, 13 Nov 2003 07:15:29 -0800 (PST) From: Fred Templin Subject: Re: ISATAP in unmanaged networks? To: Pekka Savola Cc: v6ops@ops.ietf.org, ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-249950092-1068736529=:24572" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-249950092-1068736529=:24572 Content-Type: text/plain; charset=us-ascii Pekka, It is not at all true that the cooperation of an ISP is needed to support ISATAP. ISATAP works just fine in intermittently connected/disconnected networks - even of the mobile ad-hoc variety. I spent several years proving this in my previous employment at SRI, and nothing has changed since then. See the "goals for local communications within sites" document in the IPv6 space for other scenarios that would benefit from ISATAP. Fred osprey67@yahoo.com Pekka Savola wrote: I removed ipv6@ietf.org from Cc: to avoid unnecessary cross-posting. On Thu, 13 Nov 2003, Fred Templin wrote: > I have not studied this space, but it occurs to me that ISATAP > could be tried as a first alternative to check whether the two > hosts are separated by a NAT. If there is no intervening NAT, > it seems to me that ISATAP would provide the benefit of not > needing the UDP header and "bubble" packets, yielding > greater efficiency. Otherwise, if blocked by a NAT the > initiating host coud after a short timeout try again with > Teredo. There are multiple cases to consider: - host/router is not behind a NAT: * the ISP is providing the ISATAP service ==> this is a cornercase of tunnel service by the ISP - host/router is behind a NAT: * .. when the ISP is doing the NAT (e.g., GPRS -kind of scenario, also sometimes used for commmon xDSL networks) ==> same as above, the service provided by the ISP I don't think there's really applicability for ISATAP in this space if the ISP is co-operating (which is the requirement for ISATAP anyway). Configured tunneling (+ enhancements) is simpler and more generic. -- 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-249950092-1068736529=:24572 Content-Type: text/html; charset=us-ascii
Pekka,
 
It is not at all true that the cooperation of an ISP is needed to
support ISATAP. ISATAP works just fine in intermittently
connected/disconnected networks - even of the mobile ad-hoc
variety. I spent several years proving this in my previous
employment at SRI, and nothing has changed since then.
 
See the "goals for local communications within sites" document
in the IPv6 space for other scenarios that would benefit from ISATAP.
 
Fred
osprey67@yahoo.com 

Pekka Savola <pekkas@netcore.fi> wrote:
I removed ipv6@ietf.org from Cc: to avoid unnecessary cross-posting.

On Thu, 13 Nov 2003, Fred Templin wrote:
> I have not studied this space, but it occurs to me that ISATAP
> could be tried as a first alternative to check whether the two
> hosts are separated by a NAT. If there is no intervening NAT,
> it seems to me that ISATAP would provide the benefit of not
> needing the UDP header and "bubble" packets, yielding
> greater efficiency. Otherwise, if blocked by a NAT the
> initiating host coud after a short timeout try again with
> Teredo.

There are multiple cases to consider:

- host/router is not behind a NAT:
* the ISP is providing the ISATAP service
==> this is a cornercase of tunnel service by the ISP

- host/router is behind a NAT:
* .. when the ISP is doing the NAT (e.g., GPRS -kind of scenario, also
sometimes used for commmon xDSL networks)
==> same as above, the service provided by the ISP

I don't think there's really applicability for ISATAP in this space if the
ISP is co-operating (which is the requirement for ISATAP anyway).
Configured tunneling (+ enhancements) is simpler and more generic.

--
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-249950092-1068736529=:24572-- From owner-v6ops@ops.ietf.org Thu Nov 13 10:21:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02350 for ; Thu, 13 Nov 2003 10:21:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJFL-000JKg-No for v6ops-data@psg.com; Thu, 13 Nov 2003 15:18:59 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJF3-000JIm-IF for v6ops@ops.ietf.org; Thu, 13 Nov 2003 15:18:41 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJF1-0002Ey-4S for v6ops@ops.ietf.org; Thu, 13 Nov 2003 09:18:39 -0600 Message-ID: <20031113150908.55569.qmail@web80509.mail.yahoo.com> In-Reply-To: <20031113145809.78FC98A@coconut.itojun.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1155803347-1068736148=:54049" Date: Thu, 13 Nov 2003 07:09:08 -0800 (PST) From: Fred Templin Subject: Re: ISATAP in unmanaged networks? To: itojun@iijlab.net Cc: ipv6@ietf.org, v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1155803347-1068736148=:54049 Content-Type: text/plain; charset=us-ascii Itojun, I subscribe to the model that all nodes may indeed be routers. This comes mainly from my background in MANET, but I see the paradigm as possibly appropriate here as well. If each node in the site were a router, we would be sending an RS in the expectation of getting back an RA with more-specific routes and (in most cases) zero in the router_lifetime field. We will certainly still have our default router(s) as told by the Potential Router List. But, if we view the global DNS as an extension to the PRL, we can select ISATAP routers for more specific routes on an on-demand basis. Sorry for not saying all of this at the microphone yesterday, but I was preoccupied with other matters at the time. Thanks - Fred osprey67@yahoo.com itojun@iijlab.net wrote: >I have not studied this space, but it occurs to me that ISATAP >could be tried as a first alternative to check whether the two >hosts are separated by a NAT. If there is no intervening NAT, >it seems to me that ISATAP would provide the benefit of not >needing the UDP header and "bubble" packets, yielding >greater efficiency. Otherwise, if blocked by a NAT the >initiating host coud after a short timeout try again with >Teredo. ISATAP requires an ISATAP router in a site to advertise RA in a pretty weird fashion, which is clearly a drawback. itojun --0-1155803347-1068736148=:54049 Content-Type: text/html; charset=us-ascii
Itojun,
 
I subscribe to the model that all nodes may indeed be routers.
This comes mainly from my background in MANET, but I see
the paradigm as possibly appropriate here as well. If each node
in the site were a router, we would be sending an RS in the
expectation of getting back an RA with more-specific routes
and (in most cases) zero in the router_lifetime field.
 
We will certainly still have our default router(s) as told by the
Potential Router List. But, if we view the global DNS as an
extension to the PRL, we can select ISATAP routers for more
specific routes on an on-demand basis.
 
Sorry for not saying all of this at the microphone yesterday, but
I was preoccupied with other matters at the time.
 
Thanks - Fred
osprey67@yahoo.com
 

itojun@iijlab.net wrote:
>I have not studied this space, but it occurs to me that ISATAP
>could be tried as a first alternative to check whether the two
>hosts are separated by a NAT. If there is no intervening NAT,
>it seems to me that ISATAP would provide the benefit of not
>needing the UDP header and "bubble" packets, yielding
>greater efficiency. Otherwise, if blocked by a NAT the
>initiating host coud after a short timeout try again with
>Teredo.

ISATAP requires an ISATAP router in a site to advertise RA in a
pretty weird fashion, which is clearly a drawback.

itojun
--0-1155803347-1068736148=:54049-- From owner-v6ops@ops.ietf.org Thu Nov 13 10:34:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03155 for ; Thu, 13 Nov 2003 10:34:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJRU-000LP8-RS for v6ops-data@psg.com; Thu, 13 Nov 2003 15:31:32 +0000 Received: from [212.153.190.5] (helo=gw-nl3.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJRO-000LOH-UN for v6ops@ops.ietf.org; Thu, 13 Nov 2003 15:31:27 +0000 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl3.philips.com (Postfix) with ESMTP id EAE422B1F8; Thu, 13 Nov 2003 16:31:25 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 73DC019C45; Thu, 13 Nov 2003 16:31:25 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id C54A919C48; Thu, 13 Nov 2003 16:31:24 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id QAA05946; Thu, 13 Nov 2003 16:31:24 +0100 (MET) From: mariana.nikolova@philips.com To: Fred Templin Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: ISATAP and proto-41 in unmanaged networks? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Nov 2003 16:30:38 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 13/11/2003 16:30:42, Serialize complete at 13/11/2003 16:30:42 Content-Type: multipart/alternative; boundary="=_alternative 00554D99C1256DDD_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 00554D99C1256DDD_= Content-Type: text/plain; charset="us-ascii" Hi Fred, >It just now occurs to me that Christian's unmanaged networks presentiation during v6ops yesterday did not mention ISATAP as one of >the automatic tunneling alternatives, and I wonder why this is so. I wonder as well. Not only ISATAP but also proto-41 (that Jordi presented later on) were not mentioned in the Christian's presentation. Keeping in mind that both mechanisms (ISATAP for intra-site tunneling and proto-41 for inter-site tunneling) are often used I asked myself why they were kept undercover yesterday. Probably some comments form the designing team of unmanaged networks proposal? >ISATAP requires an ISATAP router in a site to advertise RA in apretty weird fashion, which is clearly a drawback. Itojun, Teredo also requires quite an infrastructure (Teredo servers, Teredo relays) to function properly. In general this is valid remark for all transition mechanisms. However, it is not a reason to ignore some of them and to push others. Greetings, Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- --=_alternative 00554D99C1256DDD_= Content-Type: text/html; charset="us-ascii"
Hi Fred,

>It just now occurs to me that Christian's unmanaged networks presentiation during v6ops yesterday did not mention ISATAP as one of >the automatic tunneling alternatives, and I wonder why this is so.

I wonder as well. Not only ISATAP but also proto-41 (that Jordi presented later on) were not mentioned in the Christian's presentation. Keeping in mind that both mechanisms (ISATAP for intra-site tunneling and proto-41 for inter-site tunneling) are often used I asked myself why they were kept undercover yesterday.

Probably some comments form the designing team of unmanaged networks proposal?

>ISATAP requires an ISATAP router in a site to advertise RA in apretty weird fashion, which is clearly a drawback.

Itojun, Teredo also requires quite an infrastructure (Teredo servers, Teredo relays) to function properly. In general this is valid remark for all transition mechanisms. However, it is not a reason to ignore some of them and to push others.  

Greetings,
Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
----------------------------------------------------------------------------------------------------------------- --=_alternative 00554D99C1256DDD_=-- From owner-v6ops@ops.ietf.org Thu Nov 13 10:36:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03248 for ; Thu, 13 Nov 2003 10:36:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJU2-000Lrg-3O for v6ops-data@psg.com; Thu, 13 Nov 2003 15:34:10 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJTo-000LqM-3e for v6ops@ops.ietf.org; Thu, 13 Nov 2003 15:33:56 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJTk-0002Fz-VT for v6ops@ops.ietf.org; Thu, 13 Nov 2003 09:33:53 -0600 Message-Id: <4.3.2.7.2.20031113071902.021a0c48@mailhost.iprg.nokia.com> In-Reply-To: <20031113150908.55569.qmail@web80509.mail.yahoo.com> References: <20031113145809.78FC98A@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Thu, 13 Nov 2003 07:23:29 -0800 To: ipv6@ietf.org, v6ops@ops.ietf.org From: Bob Hinden Subject: Re: ISATAP in unmanaged networks? Cc: itojun@iijlab.net, Fred Templin X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Folks, Please keep this thread on the v6ops list and do not cross post to ipv6. Thanks, Bob From owner-v6ops@ops.ietf.org Thu Nov 13 10:48:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04050 for ; Thu, 13 Nov 2003 10:48:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJds-000Nag-LI for v6ops-data@psg.com; Thu, 13 Nov 2003 15:44:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJdV-000NX4-W3 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 15:43:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADFhrT06388; Thu, 13 Nov 2003 17:43:53 +0200 Date: Thu, 13 Nov 2003 17:43:52 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: ISATAP in unmanaged networks? In-Reply-To: <20031113151529.24772.qmail@web80506.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 13 Nov 2003, Fred Templin wrote: > It is not at all true that the cooperation of an ISP is needed to > support ISATAP. ISATAP works just fine in intermittently > connected/disconnected networks - even of the mobile ad-hoc > variety. I spent several years proving this in my previous > employment at SRI, and nothing has changed since then. What you're referring to is (AFAIR) some kind of localized networks, so that one guy in the neighborhood gets IPv6 connectivity, and provides it to the others using ISATAP. (Btw, you should be careful to analyze how the ISATAP users verify that the ISATAP router is legal in this case.) I really don't see that as a relevant _mainstream_ scenario in the ISP/unmanaged scenarios. MANETs are outside of the scope of v6ops scenarios work AFAICS. -- 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 Nov 13 10:49:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04145 for ; Thu, 13 Nov 2003 10:49:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJfj-000NyR-6P for v6ops-data@psg.com; Thu, 13 Nov 2003 15:46:15 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJfb-000NxS-6S for v6ops@ops.ietf.org; Thu, 13 Nov 2003 15:46:07 +0000 Received: from consulintel02 ([130.129.132.131]) (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-md50000000029.tmp for ; Thu, 13 Nov 2003 16:46:47 +0100 Message-ID: <062801c3a9fd$2d197910$83848182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: ISATAP and proto-41 in unmanaged networks? Date: Thu, 13 Nov 2003 09:45:25 -0600 Organization: Consulintel MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0625_01C3A9CA.DD6A8760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 13 Nov 2003 16:46:47 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.132.131 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0625_01C3A9CA.DD6A8760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Just to clarify. I could agree with the several comments received on this direction, but = talking as one the unmanaged design teams members, I remember that we = decided to include only a couple of examples in the slides, instead of = going to a complete slide with all the list of possible candidates. May be we can talk about more complete descriptions when the next = release of the document is edited. Regards, Jordi ----- Original Message -----=20 From: mariana.nikolova@philips.com=20 To: Fred Templin=20 Cc: ipv6@ietf.org ; v6ops@ops.ietf.org=20 Sent: Thursday, November 13, 2003 9:30 AM Subject: ISATAP and proto-41 in unmanaged networks? Hi Fred,=20 >It just now occurs to me that Christian's unmanaged networks = presentiation during v6ops yesterday did not mention ISATAP as one of = >the automatic tunneling alternatives, and I wonder why this is so.=20 I wonder as well. Not only ISATAP but also proto-41 (that Jordi = presented later on) were not mentioned in the Christian's presentation. = Keeping in mind that both mechanisms (ISATAP for intra-site tunneling = and proto-41 for inter-site tunneling) are often used I asked myself why = they were kept undercover yesterday.=20 Probably some comments form the designing team of unmanaged networks = proposal?=20 >ISATAP requires an ISATAP router in a site to advertise RA in apretty = weird fashion, which is clearly a drawback.=20 Itojun, Teredo also requires quite an infrastructure (Teredo servers, = Teredo relays) to function properly. In general this is valid remark for = all transition mechanisms. However, it is not a reason to ignore some of = them and to push others. =20 Greetings,=20 Mariana = -------------------------------------------------------------------------= ---------------------------------------- Dr. Mariana Nikolova =20 Philips Research Laboratories Eindhoven=20 Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com=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. ------=_NextPart_000_0625_01C3A9CA.DD6A8760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Just to = clarify.
 
I could agree with the several comments = received on=20 this direction, but talking as one the unmanaged design teams members, I = remember that we decided to include only a couple of examples in the = slides,=20 instead of going to a complete slide with all the list of possible=20 candidates.
 
May be we can talk about = more complete=20 descriptions when the next release of the document is = edited.
 
Regards,
Jordi
----- Original Message -----
From:=20 mariana.nikolova@philips.com= =20
Sent: Thursday, November 13, = 2003 9:30=20 AM
Subject: ISATAP and proto-41 in = unmanaged=20 networks?


Hi Fred,=20

>It just now occurs = to me that=20 Christian's unmanaged networks presentiation during v6ops yesterday = did not=20 mention ISATAP as one of >the automatic tunneling alternatives, and = I=20 wonder why this is so.

I wonder as=20 well. Not only ISATAP but also proto-41 (that Jordi presented later = on) were=20 not mentioned in the Christian's presentation. Keeping in mind that = both=20 mechanisms (ISATAP for intra-site tunneling and proto-41 for = inter-site=20 tunneling) are often used I asked myself why they were kept undercover = yesterday.

Probably = some comments=20 form the designing team of unmanaged networks proposal? =

>ISATAP requires an ISATAP router in a = site to=20 advertise RA in apretty weird fashion, which is clearly a = drawback.=20

Itojun, Teredo also requires = quite an=20 infrastructure (Teredo servers, Teredo relays) to function properly. = In=20 general this is valid remark for all transition mechanisms. However, = it is not=20 a reason to ignore some of them and to push others.  =20

Greetings,=20 =
Mariana
----------------------------------------------------------= -------------------------------------------------------
Dr.=20 Mariana Nikolova    
Philips Research Laboratories = Eindhoven=20
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: = WDC 1.35,=20     phone: +31-40-27-45455
e-mail: = mariana.nikolova@philips.com=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. ------=_NextPart_000_0625_01C3A9CA.DD6A8760-- From owner-v6ops@ops.ietf.org Thu Nov 13 11:08:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05132 for ; Thu, 13 Nov 2003 11:08:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJyI-0001ZW-4n for v6ops-data@psg.com; Thu, 13 Nov 2003 16:05:26 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJy7-0001Xd-Bv for v6ops@ops.ietf.org; Thu, 13 Nov 2003 16:05:15 +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); Thu, 13 Nov 2003 08:05:14 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 08:05:14 -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); Thu, 13 Nov 2003 08:05:14 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 08:05:05 -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, 13 Nov 2003 08:05:18 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.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: automatic tunneling and v6 interoperation Date: Thu, 13 Nov 2003 08:05:17 -0800 Message-ID: Thread-Topic: automatic tunneling and v6 interoperation Thread-Index: AcOp8Lg2gyD6HzkTRBW4EH99ZIxpLgADIrRQ From: "Christian Huitema" To: "Pekka Savola" , X-OriginalArrivalTime: 13 Nov 2003 16:05:18.0690 (UTC) FILETIME=[EEEEFC20:01C3A9FF] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > 1) the implication of economics to automatic tunneling mechanisms >=20 > Christian stated that tunnel brokers and similar mainly make sense (from > economics perspective etc.) if the ISP [or maybe also a transit of the > ISP, btw.] is providing the service. >=20 > However, what was not clearly noted that similar economics problem exists > with automatic mechanisms as well. For example, if you want to go from > a Teredo host to {native,6to4} hosts, who is providing the relay service? > Clearly, the ISP where the Teredo host resides is not, because then by > definition they could deploy e.g. tunnel service instead. The hypothesis is that the relay is close to the "native host". During the transition period, the native ISP have an interest in providing a relay service for use by their native subscribers. Their subscribers will enjoy better connectivity, i.e. will be happier. Providing the service does not result in extra bandwidth requirement: the packets are exchanged between your subscribers and the Internet; they are simply using a v6-v4 path instead of a v6-v6 path. > 2) the implication of "no relays" deployment to v6 interoperability >=20 > If there are no relays, note that every node a Teredo host needs to > communicate with has to implement and enable Teredo, as well as publicize > the Teredo addresses in the DNS in addition to the others, correct? They don't actually publish a Teredo address. I showed you Tuesday the result of "ipconfig" on my XP laptop: I have public addresses associated to the wireless interface, using the 2001:468:19ff:80::/64 prefix announced on the IETF network; the Teredo interface is available for use as a local relay, but only documents a link-local address on that interface. (And we do not advertise link local addresses in the DNS). > (Similar would be equally applicable to no-relays deployment of 6to4, with > the difference that every site, not every node, would have one enabled > 6to4 router and publicized addresses.) We should discuss 6to4 separately. There are significant differences. > 3) lifespan of a solution >=20 > Solution like this must be supported for a long time, as long as there are > people who go through NATs, unless their mechanisms are collectively > everywhere replaced by something else. That may or may not be reasonable, > if you expect the implementation of the techniques in every node. >=20 > =3D=3D> trying to summarize.. >=20 > So, I don't think Teredo (or 6to4 for that matter, but it's slightly > better from the second perspective) really solves the "economics of > providing IPv6 service" -problem. The only thing it seems to solve, to an > extent, is a relatively smooth and direct IPv6 connectivity between Teredo > hosts. On the other hand, speaking to any other kind of nodes (e.g., > 6to4, native, ...) is riddled with identical problems as the IPv6 > deployment at ISPs. See above. The trick is that the relays are deployed by other ISPS, for the benefits of their own customers. > But I guess the question is whether we want 3 separate IPv6 Internets, and > reducing that would only be possible through the addition of the lowest > common denominator, Teredo, everywhere? (The alternative is a network of > relay systems, which don't make sense economically.) We were actually careful to avoid that in the design of Teredo and in our implementation choices. Native hosts definitely do not have to advertise a Teredo address, and they would not have to implement a "host based relay" if the ISP provided the service. An IPv6 ISP that really wants to isolate its customers from the Teredo technology can do that by providing native connectivity and a Teredo relay (not a server). The ISP's customers will not need to implement their own relay. -- Christian Huitema=20 From owner-v6ops@ops.ietf.org Thu Nov 13 11:31:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06280 for ; Thu, 13 Nov 2003 11:31:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKKKq-000577-Tt for v6ops-data@psg.com; Thu, 13 Nov 2003 16:28:44 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKKKo-00056p-B4 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 16:28:42 +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 hADGSc5u005318; Thu, 13 Nov 2003 09:28:38 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADGSZQ07017; Thu, 13 Nov 2003 17:28:36 +0100 (MET) Date: Thu, 13 Nov 2003 17:27:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Tim Chown Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20031112192854.GB16674@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thnaks for the comments. > 1. Why is IPv4 compatible addressing defined in the first section, > if it is deprecated? To say that it is deprecated. But perhaps we should ask to do this in the ipv6 addressing architecture update. > 2. IPv4 compatibles are mentioned in 3.6 - this should be removed > (aren't general multicast source addresses dropped anyway?) I think dropping compatibles make sense because they shouldn't be used any more. > 3. Section 2 starts "the most straightforward way", though this > is the only way in this document? Yes. Is that confusing? Suggestions for different way to start things off? > 4. In 2.2 should we mention that that app may or may not be v6 aware or > capable? The shin-application-transition draft could be pointed to, > although it is not a WG item ist looks very good work. Already received a comment about not adding AAAAs until the apps/services on the node support IPv6. Would that address your comment or should I add something slightly different? > 5. In 2.3 there are 2 references to 6bone. Should probably use something > else > given 6bone is deprecated. oops. I'll say something vague as "connected to the Internet using IPv6" unless there is a better suggestion. > 6. In section 3, or in the introduction, some mention should probably be > made > as to why automatic tunneling (6to4, RFC3056) is not inlcuded in the > basic mechanisms (it postdates 2893 but is omitted). Explicitly listing others is a potential slippery slope; we can argue for a long time which ones to explicitly list as not being included :-( Isn't the current text sufficient? It says: Other transition mechanisms, including other tunneling mechanisms, are outside the scope of this document. Erik From owner-v6ops@ops.ietf.org Thu Nov 13 11:32:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06343 for ; Thu, 13 Nov 2003 11:32:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKKMt-0005Nj-DP for v6ops-data@psg.com; Thu, 13 Nov 2003 16:30:51 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKKMp-0005NC-Rw for v6ops@ops.ietf.org; Thu, 13 Nov 2003 16:30:48 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADGUix07360; Thu, 13 Nov 2003 18:30:44 +0200 Date: Thu, 13 Nov 2003 18:30:44 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: v6ops@ops.ietf.org Subject: RE: automatic tunneling and v6 interoperation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 13 Nov 2003, Christian Huitema wrote: [on the traffic from Teredo host to {native,6to4}] > The hypothesis is that the relay is close to the "native host". During > the transition period, the native ISP have an interest in providing a > relay service for use by their native subscribers. Their subscribers > will enjoy better connectivity, i.e. will be happier. Providing the > service does not result in extra bandwidth requirement: the packets are > exchanged between your subscribers and the Internet; they are simply > using a v6-v4 path instead of a v6-v6 path. Could you describe how the Teredo host finds this relay (close to the native host)? Note that I was not describing the traffic from the native host to a Teredo host. > > 2) the implication of "no relays" deployment to v6 interoperability > > > > If there are no relays, note that every node a Teredo host needs to > > communicate with has to implement and enable Teredo, as well as > publicize > > the Teredo addresses in the DNS in addition to the others, correct? > > They don't actually publish a Teredo address. I showed you Tuesday the > result of "ipconfig" on my XP laptop: I have public addresses associated > to the wireless interface, using the 2001:468:19ff:80::/64 prefix > announced on the IETF network; the Teredo interface is available for use > as a local relay, but only documents a link-local address on that > interface. (And we do not advertise link local addresses in the DNS). Again, the local relay onyl addresses the communication from native -> Teredo direction -- what about the other direction? Where are the relays, and if not, the address needs to be in the DNS, right? > > So, I don't think Teredo (or 6to4 for that matter, but it's slightly > > better from the second perspective) really solves the "economics of > > providing IPv6 service" -problem. The only thing it seems to solve, > to an > > extent, is a relatively smooth and direct IPv6 connectivity between > Teredo > > hosts. On the other hand, speaking to any other kind of nodes (e.g., > > 6to4, native, ...) is riddled with identical problems as the IPv6 > > deployment at ISPs. > > See above. The trick is that the relays are deployed by other ISPS, for > the benefits of their own customers. No, this addresses (to some degree) only the other direction. What about those who sit behind an ISP who doesn't care about v6? > An IPv6 ISP that really wants to isolate its customers from the Teredo > technology can do that by providing native connectivity and a Teredo > relay (not a server). The ISP's customers will not need to implement > their own relay. Again, what about the Teredo hosts which have no such relays? -- 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 Nov 13 12:02:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08057 for ; Thu, 13 Nov 2003 12:02:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKKp3-000A9z-Fk for v6ops-data@psg.com; Thu, 13 Nov 2003 16:59:57 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKKot-000A95-7X for v6ops@ops.ietf.org; Thu, 13 Nov 2003 16:59:47 +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 hADGXNUP023682; Thu, 13 Nov 2003 08:33:24 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADGXKQ10460; Thu, 13 Nov 2003 17:33:20 +0100 (MET) Date: Thu, 13 Nov 2003 17:32:22 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: transmech MTU comments To: Fred Templin Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20031112224328.98984.qmail@web80501.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > My understanding of RFC 3168 is that when the tunnel interface > forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1) > codepoint in the traffic class field, it MAY set the codepoint to CE if > congestion is experienced. I interpret the MAY to mean that the other > option is to drop the packet. If the packet is to be dropped, should it > be dropped silently? Also, could a link restriction be considered as > congestion? If so, does drop silent also entail NOT sending an > ICMPv6 "packet too big" message back to the source? My understanding is that larger than MTU is not congestion, that packets would not be dropped as an alternative to setting CE, and that congestion for tunnels isn't any different than congestion in general. What tunnel adds is the question of what the encasulator puts in the ECT bits in the outer header (where copying them from the inner header makes sense in many cases) and whether the decapulator does anything with the received ECT bits in the outer header (and I think that 3168 says that unless there are security concerns, copying them from the outer to the inner header makes sense). Thus I think the text in the mech document about ECN are sufficient. Erik From owner-v6ops@ops.ietf.org Thu Nov 13 12:03:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08127 for ; Thu, 13 Nov 2003 12:03:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKKqT-000ANK-EB for v6ops-data@psg.com; Thu, 13 Nov 2003 17:01:25 +0000 Received: from [212.153.190.6] (helo=gw-nl4.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKKqQ-000AN0-Fp for v6ops@ops.ietf.org; Thu, 13 Nov 2003 17:01:22 +0000 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id ACF4A2C234; Thu, 13 Nov 2003 18:01:21 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id E58A919C45; Thu, 13 Nov 2003 18:01:20 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 708FB19C49; Thu, 13 Nov 2003 18:01:20 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id SAA05681; Thu, 13 Nov 2003 18:01:19 +0100 (MET) From: mariana.nikolova@philips.com To: "JORDI PALET MARTINEZ" Cc: v6ops@ops.ietf.org Subject: Comment on draft-palet-v6ops-proto41-nat-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Nov 2003 18:00:33 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 13/11/2003 18:00:37, Serialize complete at 13/11/2003 18:00:37 Content-Type: multipart/alternative; boundary="=_alternative 005D890BC1256DDD_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 005D890BC1256DDD_= Content-Type: text/plain; charset="us-ascii" Hi Jordi, I have a comment on the following paragraph in Section 5 of your draft "6to4 and Proto-41 forwarding can coexist in the same NAT box. In that case, an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local 6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures. This fact avoids the problems created by mobile users when they visit a network that uses 6to4, in the case they have some automatic proto-41 setup. " Let's analyze how a router works when it's simultaneously supports 6to4 and proto-41 mechanisms as you proposed above. If there is an proto-41 entity such as (source IPv4 address, target IPv4 address, ID=41) in the NAT table of the router, then the so called prerouting is done for all packets matching this entity. Note, this is the first action taken by the router before any other actions are taken. With other words, the router forwards all incoming IPv4 packets with PF=41 to the target IPv4 address before even decapsulating them and looking what the IPv6 dest address is. So, what is written above "an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local 6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures." does not work in practice, because it require that the router first decapculates and looks the IPv6 dest. address. Summing up, I do see that 6to4 and proto-41 can coexist n the same NAT box but rather as two separate modes, i.e. the router can switch between 6to4 and proto-41 depending of certain preferences as the default one is 6to4 for example. In fact, I see the applicability of proto-41 in IPv4-only NAT boxes, but if the latter are upgraded to 6to4 routers it seems to me overdone to keep proto-41 as well. Greetings, Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- --=_alternative 005D890BC1256DDD_= Content-Type: text/html; charset="us-ascii"
Hi Jordi,

I have a comment on the following paragraph in Section 5 of your draft

"6to4 and Proto-41 forwarding can coexist in the same NAT box. In that  case, an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local  6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures. This fact avoids the problems created by mobile users when they visit a network that uses 6to4, in the case they have some automatic proto-41 setup. "
Let's analyze how a router works when it's simultaneously supports 6to4 and proto-41 mechanisms  as you proposed above.

If there is an proto-41 entity such as (source IPv4 address, target IPv4 address, ID=41) in the NAT table of the router, then the so called prerouting is done for all packets matching this entity. Note, this is the first action taken by the router  before any other actions are taken. With other words, the router forwards all incoming IPv4 packets with PF=41 to the target IPv4 address before even decapsulating them and looking what the IPv6 dest address is.  So, what is written above "an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local  6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures."  does not work in practice, because it require that the router first decapculates and  looks the IPv6 dest. ad! dress.

Summing up, I do see that 6to4 and proto-41 can coexist n the same NAT box but rather as two separate modes, i.e. the router can switch between 6to4 and proto-41 depending of certain preferences as the default one is 6to4 for example.  In fact, I see the applicability of proto-41 in IPv4-only NAT boxes, but if the latter are upgraded to 6to4 routers it seems to me overdone to keep proto-41 as well.  

Greetings,
Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
----------------------------------------------------------------------------------------------------------------- --=_alternative 005D890BC1256DDD_=-- From owner-v6ops@ops.ietf.org Thu Nov 13 12:19:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08982 for ; Thu, 13 Nov 2003 12:19:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKL5Q-000CX3-BJ for v6ops-data@psg.com; Thu, 13 Nov 2003 17:16:52 +0000 Received: from [212.153.190.6] (helo=gw-nl4.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKL5O-000CWi-DR for v6ops@ops.ietf.org; Thu, 13 Nov 2003 17:16:50 +0000 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id BA2742B226 for ; Thu, 13 Nov 2003 18:16:49 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 5BB0519C46 for ; Thu, 13 Nov 2003 18:16:49 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 1243919C45 for ; Thu, 13 Nov 2003 18:16:49 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id SAA12808 for ; Thu, 13 Nov 2003 18:16:48 +0100 (MET) From: mariana.nikolova@philips.com To: v6ops@ops.ietf.org Subject: Re: ISATAP and proto-41 in unmanaged networks? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Nov 2003 18:16:04 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 13/11/2003 18:16:06, Serialize complete at 13/11/2003 18:16:06 Content-Type: multipart/alternative; boundary="=_alternative 005EF499C1256DDD_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_44,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 005EF499C1256DDD_= Content-Type: text/plain; charset="us-ascii" >May be we can talk about more complete descriptions when the next release of the document is edited. Agree! Thanks, Mariana --=_alternative 005EF499C1256DDD_= Content-Type: text/html; charset="us-ascii"
>May be we can talk about more complete descriptions when the next release of the document is edited.
Agree!

Thanks,
Mariana --=_alternative 005EF499C1256DDD_=-- From owner-v6ops@ops.ietf.org Thu Nov 13 12:51:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10688 for ; Thu, 13 Nov 2003 12:51:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKLZU-000HN8-Rw for v6ops-data@psg.com; Thu, 13 Nov 2003 17:47:56 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKLZK-000HKH-P2 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 17:47:47 +0000 Received: from consulintel02 ([130.129.132.131]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 48-md50000000035.tmp for ; Thu, 13 Nov 2003 18:48:28 +0100 Message-ID: <099d01c3aa0e$2cea9120$83848182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Comment on draft-palet-v6ops-proto41-nat-03.txt Date: Thu, 13 Nov 2003 11:47:12 -0600 Organization: Consulintel MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_099A_01C3A9DB.E09FB200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 13 Nov 2003 18:48:28 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.132.131 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_099A_01C3A9DB.E09FB200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mariana, Yes, you're right. My feeling is that it could be implementation = dependent, but not sure right now. Definitively we need to work more on this. Regards, Jordi ----- Original Message -----=20 From: mariana.nikolova@philips.com=20 To: JORDI PALET MARTINEZ=20 Cc: v6ops@ops.ietf.org=20 Sent: Thursday, November 13, 2003 11:00 AM Subject: Comment on draft-palet-v6ops-proto41-nat-03.txt Hi Jordi,=20 I have a comment on the following paragraph in Section 5 of your draft = "6to4 and Proto-41 forwarding can coexist in the same NAT box. In that = case, an IPv6 over IPv4 packet received, will be forwarded to the = private LAN only if the IPv6 destination does not belong to the local = 6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, = following 6to4 procedures. This fact avoids the problems created by = mobile users when they visit a network that uses 6to4, in the case they = have some automatic proto-41 setup. " Let's analyze how a router works when it's simultaneously supports = 6to4 and proto-41 mechanisms as you proposed above.=20 If there is an proto-41 entity such as (source IPv4 address, target = IPv4 address, ID=3D41) in the NAT table of the router, then the so = called prerouting is done for all packets matching this entity. Note, = this is the first action taken by the router before any other actions = are taken. With other words, the router forwards all incoming IPv4 = packets with PF=3D41 to the target IPv4 address before even = decapsulating them and looking what the IPv6 dest address is. So, what = is written above "an IPv6 over IPv4 packet received, will be forwarded = to the private LAN only if the IPv6 destination does not belong to the = local 6to4 /48 prefix. Otherwise it will be decapsulated in the NAT = box, following 6to4 procedures." does not work in practice, because it = require that the router first decapculates and looks the IPv6 dest. ad! = dress.=20 Summing up, I do see that 6to4 and proto-41 can coexist n the same NAT = box but rather as two separate modes, i.e. the router can switch between = 6to4 and proto-41 depending of certain preferences as the default one is = 6to4 for example. In fact, I see the applicability of proto-41 in = IPv4-only NAT boxes, but if the latter are upgraded to 6to4 routers it = seems to me overdone to keep proto-41 as well. =20 Greetings,=20 Mariana = -------------------------------------------------------------------------= ---------------------------------------- Dr. Mariana Nikolova =20 Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com=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. ------=_NextPart_000_099A_01C3A9DB.E09FB200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mariana,
 
Yes, you're right. My feeling is that = it could be=20 implementation dependent, but not sure right now.
 
Definitively we need to work more on=20 this.
 
Regards,
Jordi
----- Original Message -----
From:=20 mariana.nikolova@philips.com= =20
Sent: Thursday, November 13, = 2003 11:00=20 AM
Subject: Comment on=20 draft-palet-v6ops-proto41-nat-03.txt


Hi Jordi, =

I have a comment on the following paragraph = in Section=20 5 of your draft

"6to4=20 and Proto-41 forwarding can coexist in the same NAT box. In that =  case,=20 an IPv6 over IPv4 packet received, will be forwarded to the private = LAN only=20 if the IPv6 destination does not belong to the local  6to4 /48 = prefix.=20 Otherwise it will be decapsulated in the NAT box, following 6to4 = procedures.=20 This fact avoids the problems created by mobile users when they visit = a=20 network that uses 6to4, in the case they have some automatic proto-41 = setup.=20 "

Let's analyze how a = router works=20 when it's simultaneously supports 6to4 and proto-41 mechanisms =  as you=20 proposed above.

If = there is an=20 proto-41 entity such as (source IPv4 address, target IPv4 address, = ID=3D41) in=20 the NAT table of the router, then the so called prerouting is = done for=20 all packets matching this entity. Note, this is the first action taken = by the=20 router  before any other actions are taken. With other words, the = router=20 forwards all incoming IPv4 packets with PF=3D41 to the target IPv4 = address=20 before even decapsulating them and looking what the IPv6 dest address = is.=20  So, what is written above "an IPv6 over IPv4 packet received, will be forwarded to the = private LAN=20 only if the IPv6 destination does not belong to the local  6to4 = /48=20 prefix. Otherwise it will be decapsulated in the NAT box, following = 6to4=20 procedures."  does not = work in=20 practice, because it require that the router first decapculates and=20  looks the IPv6 dest. ad! dress.

Summing up, I do see that 6to4 and proto-41 can coexist n the = same NAT=20 box but rather as two separate modes, i.e. the router can switch = between 6to4=20 and proto-41 depending of certain preferences as the default one is = 6to4 for=20 example.  In fact, I see the applicability of proto-41 in = IPv4-only NAT=20 boxes, but if the latter are upgraded to 6to4 routers it seems to me = overdone=20 to keep proto-41 as well.  

Greetings,=20 =
Mariana
----------------------------------------------------------= -------------------------------------------------------
Dr.=20 Mariana Nikolova    
Philips Research Laboratories = Eindhoven=20 (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The=20 Netherlands
room: WDC 1.35,     phone: = +31-40-27-45455
e-mail:=20 mariana.nikolova@philips.com=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. ------=_NextPart_000_099A_01C3A9DB.E09FB200-- From owner-v6ops@ops.ietf.org Thu Nov 13 13:24:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11495 for ; Thu, 13 Nov 2003 13:24:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKM5Q-000LSR-9N for v6ops-data@psg.com; Thu, 13 Nov 2003 18:20:56 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKM5L-000LRO-TW for v6ops@ops.ietf.org; Thu, 13 Nov 2003 18:20:52 +0000 Received: from consulintel02 ([130.129.132.131]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 27-md50000000036.tmp for ; Thu, 13 Nov 2003 19:21:32 +0100 Message-ID: <0a3901c3aa12$cb266450$83848182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-palet-v6ops-proto41-nat-03 as WG item Date: Thu, 13 Nov 2003 12:20:15 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 13 Nov 2003 19:21:32 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.132.131 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, In the yesterday meeting, I've presented the latest version of = http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-03, = the slides are available at = http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf58.zip = (previous slides from Vienna also at = http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf57.zip). As nobody provided any new suggestions or objections to this document, = during the meeting, my feeling is that it could be accepted as WG item. In addition to the comment from Mariana, I got a couple of suggestions = off-line that we will like to address in the next few days, so will like = to take the opportunity publish the review already as WG item version 00 = and keep going with the work. Please, let me know if you feel this is acceptable or do you have any = objections. 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 Thu Nov 13 13:57:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12708 for ; Thu, 13 Nov 2003 13:57:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKMbG-000POa-CC for v6ops-data@psg.com; Thu, 13 Nov 2003 18:53:50 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKMb8-000PNY-7Y for v6ops@ops.ietf.org; Thu, 13 Nov 2003 18:53:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADIrck10077; Thu, 13 Nov 2003 20:53:38 +0200 Date: Thu, 13 Nov 2003 20:53:37 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item In-Reply-To: <0a3901c3aa12$cb266450$83848182@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 13 Nov 2003, JORDI PALET MARTINEZ wrote: [...] > Please, let me know if you feel this is acceptable or do you have any > objections. I do not think it clearly falls within the charter of the WG. The only clear possibility I see is charter item (6), but that would not be acceptable until the analysis/scenarios work is complete and a clear need has been identified. In Vienna, there was some discussions about usefulness of documenting the existing techniques and practice, but I don't find that as our goal in the charter. We're loaded enough already. The analysis work must be finished before jumping to the mechanisms. -- 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 Nov 13 14:23:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14043 for ; Thu, 13 Nov 2003 14:23:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKN17-0002TD-Sx for v6ops-data@psg.com; Thu, 13 Nov 2003 19:20:33 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKN14-0002Sw-V9 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 19:20:30 +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); Thu, 13 Nov 2003 11:20:29 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 11:20:30 -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); Thu, 13 Nov 2003 11:20:20 -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); Thu, 13 Nov 2003 11:19:49 -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, 13 Nov 2003 11:20:16 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.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: automatic tunneling and v6 interoperation Date: Thu, 13 Nov 2003 11:20:31 -0800 Message-ID: Thread-Topic: automatic tunneling and v6 interoperation Thread-Index: AcOqA38CViCGf2MJS9+OQR9ms18cBAAFk8Ig From: "Christian Huitema" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 13 Nov 2003 19:20:16.0691 (UTC) FILETIME=[2B7C4830:01C3AA1B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > [on the traffic from Teredo host to {native,6to4}] > > The hypothesis is that the relay is close to the "native host". During > > the transition period, the native ISP have an interest in providing a > > relay service for use by their native subscribers. Their subscribers > > will enjoy better connectivity, i.e. will be happier. Providing the > > service does not result in extra bandwidth requirement: the packets are > > exchanged between your subscribers and the Internet; they are simply > > using a v6-v4 path instead of a v6-v6 path. >=20 > Could you describe how the Teredo host finds this relay (close to the > native host)? Note that I was not describing the traffic from the native > host to a Teredo host. This is actually documented in section 4.1.5 of the Teredo draft. The Teredo client sends an ICMP request to the IPv6 node, through the Teredo server. The native host receives the request over the native interface, and sends an ICMP reply. The ICMP reply is routed to the nearest Teredo relay over native IPv6. (Not routed very far if the gateway is on the host, but that is not necessary.) The Teredo client receives the reply from the relay, and associates the native IPv6 address to the IPv4 & UDP port of the relay. Further packets to that address are sent directly to this relay. There is a minimum of security in that exchange: the echo request carries a nonce, and the Teredo host checks that the reply carries the same nonce. > > > 2) the implication of "no relays" deployment to v6 interoperability > > > > > > If there are no relays, note that every node a Teredo host needs to > > > communicate with has to implement and enable Teredo, as well as > > publicize > > > the Teredo addresses in the DNS in addition to the others, correct? > > > > They don't actually publish a Teredo address. I showed you Tuesday the > > result of "ipconfig" on my XP laptop: I have public addresses associated > > to the wireless interface, using the 2001:468:19ff:80::/64 prefix > > announced on the IETF network; the Teredo interface is available for use > > as a local relay, but only documents a link-local address on that > > interface. (And we do not advertise link local addresses in the DNS). >=20 > Again, the local relay onyl addresses the communication from native -> > Teredo direction -- what about the other direction? Where are the relays, > and if not, the address needs to be in the DNS, right? No. See above. > > > So, I don't think Teredo (or 6to4 for that matter, but it's slightly > > > better from the second perspective) really solves the "economics of > > > providing IPv6 service" -problem. The only thing it seems to solve, > > to an > > > extent, is a relatively smooth and direct IPv6 connectivity between > > Teredo > > > hosts. On the other hand, speaking to any other kind of nodes (e.g., > > > 6to4, native, ...) is riddled with identical problems as the IPv6 > > > deployment at ISPs. > > > > See above. The trick is that the relays are deployed by other ISPS, for > > the benefits of their own customers. >=20 > No, this addresses (to some degree) only the other direction. What about > those who sit behind an ISP who doesn't care about v6? They will use the relay provided by the ISP who cares, and they will only use that relay for the clients of this caring ISP. =20 > > An IPv6 ISP that really wants to isolate its customers from the Teredo > > technology can do that by providing native connectivity and a Teredo > > relay (not a server). The ISP's customers will not need to implement > > their own relay. >=20 > Again, what about the Teredo hosts which have no such relays? They have to rely on a Teredo relay in the network. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Nov 13 14:25:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14118 for ; Thu, 13 Nov 2003 14:25:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKN4J-0002sF-Th for v6ops-data@psg.com; Thu, 13 Nov 2003 19:23:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKN4D-0002rf-EA for v6ops@ops.ietf.org; Thu, 13 Nov 2003 19:23:45 +0000 Received: from consulintel02 ([130.129.132.131]) (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-md50000000037.tmp for ; Thu, 13 Nov 2003 20:24:27 +0100 Message-ID: <0acb01c3aa1b$958de850$83848182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item Date: Thu, 13 Nov 2003 13:23:10 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 13 Nov 2003 20:24:27 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.132.131 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, In the charter (http://www.ietf.org/html.charters/v6ops-charter.html), I = can read as number 1: "Solicit input from network operators and users to identify=20 operational or security issues with the IPv4/IPv6 Internet, and=20 determine solutions or workarounds to those issues. This includes identifying standards work that is needed in other IETF WGs or areas and working with those groups/areas to begin appropriate work. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts." In my opinion, as already explained, proto-41 is nothing new. What is = new is the operational/security issues of its usage (as described in = this paragraph from the charter), and this is what the document does. In = addition, the document determine solutions/workarounds for the = operation, so again, falls within this paragraph in the charter. Also, as you said, it can fall under 6 (I feel more under 5, but both = are closely related). But in this case it suggest to me a new transition = mechanism, and as said, proto-41 is not one. In any case, if we are talking about 5/6, you indicate that should not = be acceptable until the analysis/scenarios work is complete. I will like = to know where in the charter is stated that we can't document an = operational situation until the scenarios are done. Finally, in my opinion, this is not related to the workload of the WG. = Getting the document as a WG chapter will not change that. The = discussions about this document have already happened in the mailing = list, and I guess should continue there. So what is the difference ? The = alternative is we move to a personal submission, and my feeling is that = will imply more workload. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Thursday, November 13, 2003 12:53 PM Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item > On Thu, 13 Nov 2003, JORDI PALET MARTINEZ wrote: > [...] > > Please, let me know if you feel this is acceptable or do you have = any > > objections. >=20 > I do not think it clearly falls within the charter of the WG. The = only > clear possibility I see is charter item (6), but that would not be > acceptable until the analysis/scenarios work is complete and a clear = need > has been identified. >=20 > In Vienna, there was some discussions about usefulness of documenting = the > existing techniques and practice, but I don't find that as our goal in = the=20 > charter. >=20 > We're loaded enough already. The analysis work must be finished = before=20 > jumping to the mechanisms. >=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 Thu Nov 13 14:33:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14518 for ; Thu, 13 Nov 2003 14:33:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKNBw-0003xi-D6 for v6ops-data@psg.com; Thu, 13 Nov 2003 19:31:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKNBu-0003xD-96 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 19:31:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADJVdJ10807; Thu, 13 Nov 2003 21:31:39 +0200 Date: Thu, 13 Nov 2003 21:31:38 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: v6ops@ops.ietf.org Subject: RE: automatic tunneling and v6 interoperation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 13 Nov 2003, Christian Huitema wrote: > > Could you describe how the Teredo host finds this relay (close to the > > native host)? Note that I was not describing the traffic from the > native > > host to a Teredo host. > > This is actually documented in section 4.1.5 of the Teredo draft. The > Teredo client sends an ICMP request to the IPv6 node, through the Teredo > server. The native host receives the request over the native interface, > and sends an ICMP reply. The ICMP reply is routed to the nearest Teredo > relay over native IPv6. (Not routed very far if the gateway is on the > host, but that is not necessary.) The Teredo client receives the reply > from the relay, and associates the native IPv6 address to the IPv4 & UDP > port of the relay. Further packets to that address are sent directly to > this relay. Ok, thanks -- missed that. Who has the incentive of deploying Teredo servers then? Assume there will be 10,000,000 hosts implementing Teredo, and assuming that the users surf the web, use the services, etc. and e.g. 1/10 of the traffic is going towards native destinations (could be a lot more as well). Even if this would result in one new site in a minute, wouldn't there still be dozens or even hundreds of thousands ICMP packets passing through Teredo servers, if they would not be distributed as well? (The number of packets would be quite high, and the associated state 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 Thu Nov 13 15:03:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16053 for ; Thu, 13 Nov 2003 15:03:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKNe1-00085R-OZ for v6ops-data@psg.com; Thu, 13 Nov 2003 20:00:45 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKNdy-00084x-KP for v6ops@ops.ietf.org; Thu, 13 Nov 2003 20:00:42 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA21834 for ; Thu, 13 Nov 2003 20:00:37 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 UAA19964 for ; Thu, 13 Nov 2003 20:00:37 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hADK0b106030 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 20:00:37 GMT Date: Thu, 13 Nov 2003 20:00:37 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item Message-ID: <20031113200036.GB3473@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <0a3901c3aa12$cb266450$83848182@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Nov 13, 2003 at 08:53:37PM +0200, Pekka Savola wrote: > On Thu, 13 Nov 2003, JORDI PALET MARTINEZ wrote: > > I do not think it clearly falls within the charter of the WG. The only > clear possibility I see is charter item (6), but that would not be > acceptable until the analysis/scenarios work is complete and a clear need > has been identified. I think it fits charter item 1. It does not involve new work. > We're loaded enough already. The analysis work must be finished before > jumping to the mechanisms. I would hope the unman eval work will be finished before Christmas, and the Proto-41 issue will/could address one recommended development path there (at least based on what Christian presented yesterday). So it is not long to wait. The flip side of the coin is that we are already in the position of deployment leading standardisation by some way in v6ops. Tim From owner-v6ops@ops.ietf.org Thu Nov 13 15:16:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17823 for ; Thu, 13 Nov 2003 15:16:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKNr4-0009Za-H5 for v6ops-data@psg.com; Thu, 13 Nov 2003 20:14:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKNr1-0009Yr-Q8 for v6ops@ops.ietf.org; Thu, 13 Nov 2003 20:14:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADKE8411657; Thu, 13 Nov 2003 22:14:08 +0200 Date: Thu, 13 Nov 2003 22:14:08 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: v6ops@ops.ietf.org Subject: RE: automatic tunneling and v6 interoperation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 13 Nov 2003, Christian Huitema wrote: > > Who has the incentive of deploying Teredo servers then? > > The answer so far is: > > 1) providers of application software and services that rely on IPv6 > connectivity and are currently providing application relays to make > their apps work. Have you analyzed the increases in connection setup delay due to the packet exchanges (whether through bubbles, servers or relays). I see a potential problem here if deployed by apps (going across the globe..), although probably not a major one. > 2) transit providers who actually benefit from any increase in the > general amount of traffic. By the same analogue, the transit provides would actually benefit from deploying 6to4 relays. They haven't. Maybe they will. But I doubt this is enough of an incentive, especially as the packets exchanged are just tiny ICMP messages, amounting to very little increase in the traffic, in the bit/s terms. > Yes, that may result in many packets, but no more packets than the > initial bubbles between two Teredo clients. These are small packets and > the amount of traffic ends up being manageable. In typical cases, the > cost per user is of the order of pennies per year. Dealing with NAT in > applications actually costs much more, e.g. in phone calls to the > support line. The small packets are probably not a problem, bandwidth-wise. The latency may be a problem, as well has having no such service to begin with. -- 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 Nov 13 17:05:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23113 for ; Thu, 13 Nov 2003 17:05:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPWf-000Llf-76 for v6ops-data@psg.com; Thu, 13 Nov 2003 22:01:17 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPWZ-000Lks-F6; Thu, 13 Nov 2003 22:01:11 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hADM01Ss024655; Thu, 13 Nov 2003 23:00:06 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Nov 2003 23:00:01 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639907@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Randy Bush'" , Suresh Satapati Cc: v6ops@ops.ietf.org Subject: RE: NAT-PT Applicabilty for 3GPP Date: Thu, 13 Nov 2003 22:59:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I brought up the same issue during the DT work and agree with Randy's point that if a scenario exists that requires a subset of NAT-PT (i.e. 3GPP IMS) then it does not necessarily imply that NAT-PT as specified in RFC 2766 is applicable. The draft could however point out which parts of NAT-PT are applicable in this case. Regarding the actual SIP solution there is a reference in 3gpp-analysis-07 to draft-elmalki-sipping-3gpp-translator-00. Following Margaret's comments last time and the recommendation in draft-ietf-3gpp-analysis it is on the SIPPING agenda this time. For those who may be interested here's a new version of the draft: http://standards.ericsson.net/karim/draft-elmalki-sipping-3gpp-translator-00.txt /Karim > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Randy Bush > Sent: den 13 november 2003 00:25 > To: Suresh Satapati > Cc: v6ops@ops.ietf.org > Subject: Re: NAT-PT Applicabilty for 3GPP > > > > In the above, though a SIP-specific translation mechanism is being > > recommended, I do not see how the recommended solution will be > > fundamentally different from NAT-PT. In this sense, the > applicability > > of NAT-PT is still valid. > > if A is a proper subset of B, a need for A does not mandate B, > especially if A is a very localized hack and B is global, generic, > and questionable. > > randy > > From owner-v6ops@ops.ietf.org Thu Nov 13 17:14:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23981 for ; Thu, 13 Nov 2003 17:14:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPhL-000MyD-G6 for v6ops-data@psg.com; Thu, 13 Nov 2003 22:12:19 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPhE-000MxK-RP for v6ops@ops.ietf.org; Thu, 13 Nov 2003 22:12:12 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 13 Nov 2003 23:09:47 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hADMC0Tt028906 for ; Thu, 13 Nov 2003 23:12:01 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 22:12:10 +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: automatic tunneling and v6 interoperation Date: Thu, 13 Nov 2003 22:12:10 -0000 Message-ID: Thread-Topic: automatic tunneling and v6 interoperation Thread-Index: AcOqHTu1sks0paemQl2Z+EQSI6YLCAAFLhdw From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 13 Nov 2003 22:12:10.0519 (UTC) FILETIME=[2F018A70:01C3AA33] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On the side of this discussion (: sorry for the bother :) Here's (yet another) alternate possibility to enable IPv6 to traverse IPv4 PAT/NAT. It applies to IPv6 Mobile Nodes and Mobile Routers only, but if you have MIPv6 available, the rest of the way is pretty simple. I proposed it to Nemo and the suggestion I received was actually to post it to v6Ops. So here it is... Can you please consider: http://www.ietf.org/internet-drafts/draft-thubert-nemo-ipv4-traversal-01 .txt Thanks :) Pascal > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: jeudi 13 novembre 2003 20:32 > To: Christian Huitema > Cc: v6ops@ops.ietf.org > Subject: RE: automatic tunneling and v6 interoperation >=20 > On Thu, 13 Nov 2003, Christian Huitema wrote: > > > Could you describe how the Teredo host finds this relay (close to the > > > native host)? Note that I was not describing the traffic from the > > native > > > host to a Teredo host. > > > > This is actually documented in section 4.1.5 of the Teredo draft. The > > Teredo client sends an ICMP request to the IPv6 node, through the Teredo > > server. The native host receives the request over the native interface, > > and sends an ICMP reply. The ICMP reply is routed to the nearest Teredo > > relay over native IPv6. (Not routed very far if the gateway is on the > > host, but that is not necessary.) The Teredo client receives the reply > > from the relay, and associates the native IPv6 address to the IPv4 & UDP > > port of the relay. Further packets to that address are sent directly to > > this relay. >=20 > Ok, thanks -- missed that. >=20 > Who has the incentive of deploying Teredo servers then? Assume there will > be 10,000,000 hosts implementing Teredo, and assuming that the users surf > the web, use the services, etc. and e.g. 1/10 of the traffic is going > towards native destinations (could be a lot more as well). Even if this > would result in one new site in a minute, wouldn't there still be dozens > or even hundreds of thousands ICMP packets passing through Teredo servers, > if they would not be distributed as well? (The number of packets would be > quite high, and the associated state as well?) >=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 Thu Nov 13 18:22:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28755 for ; Thu, 13 Nov 2003 18:22:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQkT-0005T1-MJ for v6ops-data@psg.com; Thu, 13 Nov 2003 23:19:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKQkP-0005SZ-WB for v6ops@ops.ietf.org; Thu, 13 Nov 2003 23:19:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADNJ9h15448; Fri, 14 Nov 2003 01:19:09 +0200 Date: Fri, 14 Nov 2003 01:19:08 +0200 (EET) From: Pekka Savola To: "Pascal Thubert (pthubert)" cc: v6ops@ops.ietf.org Subject: RE: automatic tunneling and v6 interoperation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 13 Nov 2003, Pascal Thubert (pthubert) wrote: > On the side of this discussion (: sorry for the bother :) Here's (yet > another) alternate possibility to enable IPv6 to traverse IPv4 PAT/NAT. > It applies to IPv6 Mobile Nodes and Mobile Routers only, but if you have > MIPv6 available, the rest of the way is pretty simple. I proposed it to > Nemo and the suggestion I received was actually to post it to v6Ops. So > here it is... Can you please consider: > > http://www.ietf.org/internet-drafts/draft-thubert-nemo-ipv4-traversal-01 > .txt This has IPR application and Cisco is providing RAND terms. My own personal interest stopped just here -><-. (The same applies to Nemo basic protocol as well, btw.) Btw, Teredo has IPR application as well, the good thing is Microsoft is offering RF terms for Standards Track implementations. That may be a problem has well, but not as severe one as RAND. -- 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 Nov 13 20:17:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03010 for ; Thu, 13 Nov 2003 20:17:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKSXG-000Ib9-Fn for v6ops-data@psg.com; Fri, 14 Nov 2003 01:14:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKSXE-000Ias-6i for v6ops@ops.ietf.org; Fri, 14 Nov 2003 01:14:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAE1E1K16988; Fri, 14 Nov 2003 03:14:01 +0200 Date: Fri, 14 Nov 2003 03:14:00 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item In-Reply-To: <0acb01c3aa1b$958de850$83848182@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 13 Nov 2003, JORDI PALET MARTINEZ wrote: > In the charter (http://www.ietf.org/html.charters/v6ops-charter.html), I can read as number 1: > "Solicit input from network operators and users to identify > operational or security issues with the IPv4/IPv6 Internet, and > determine solutions or workarounds to those issues. This includes > identifying standards work that is needed in other IETF WGs or > areas and working with those groups/areas to begin appropriate > work. These issues will be documented in Informational or BCP > RFCs, or in Internet-Drafts." Please note the next paragraph; even though starting as "For example, ..." it seems to paint a different meaning for the intent of the paragraph. -- 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 Nov 13 20:21:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03228 for ; Thu, 13 Nov 2003 20:21:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKSch-000JCQ-Lq for v6ops-data@psg.com; Fri, 14 Nov 2003 01:19:43 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKScb-000JBy-Kf for v6ops@ops.ietf.org; Fri, 14 Nov 2003 01:19:37 +0000 Received: from consulintel02 ([130.129.132.131]) (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-md50000000044.tmp for ; Fri, 14 Nov 2003 02:20:18 +0100 Message-ID: <11e301c3aa4d$4a80bae0$83848182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item Date: Thu, 13 Nov 2003 19:19:00 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 14 Nov 2003 02:20:18 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.132.131 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Come on ! "For example, important pieces of the Internet infrastructure such as DNS, SMTP and SIP have specific operational issues when they operate in a shared IPv4/IPv6 network. The v6ops WG will cooperate with the relevant areas and WGs to document those issues, and find protocol or operational solutions to those problems." This is providing a few clear examples, but at no way excluding whatever = else can come from operational experience. I'm starting to believe that we are not in the OPS area ? Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Thursday, November 13, 2003 7:14 PM Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item > On Thu, 13 Nov 2003, JORDI PALET MARTINEZ wrote: > > In the charter = (http://www.ietf.org/html.charters/v6ops-charter.html), I can read as = number 1: > > "Solicit input from network operators and users to identify=20 > > operational or security issues with the IPv4/IPv6 Internet, and=20 > > determine solutions or workarounds to those issues. This includes > > identifying standards work that is needed in other IETF WGs or > > areas and working with those groups/areas to begin appropriate > > work. These issues will be documented in Informational or BCP > > RFCs, or in Internet-Drafts." >=20 > Please note the next paragraph; even though starting as "For example, = ..."=20 > it seems to paint a different meaning for the intent of the paragraph. >=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 > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Nov 13 20:54:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04361 for ; Thu, 13 Nov 2003 20:54:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKT6t-000N2B-8I for v6ops-data@psg.com; Fri, 14 Nov 2003 01:50:55 +0000 Received: from [66.218.79.76] (helo=web80506.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKT6r-000N1w-1G for v6ops@ops.ietf.org; Fri, 14 Nov 2003 01:50:53 +0000 Message-ID: <20031114015051.86422.qmail@web80506.mail.yahoo.com> Received: from [205.226.2.67] by web80506.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 17:50:51 PST Date: Thu, 13 Nov 2003 17:50:51 -0800 (PST) From: Fred Templin Subject: Re: transmech MTU comments To: Erik Nordmark 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Erik, --- Erik Nordmark wrote: > > My understanding of RFC 3168 is that when the tunnel interface > > forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1) > > codepoint in the traffic class field, it MAY set the codepoint to CE if > > congestion is experienced. I interpret the MAY to mean that the other > > option is to drop the packet. If the packet is to be dropped, should it > > be dropped silently? Also, could a link restriction be considered as > > congestion? If so, does drop silent also entail NOT sending an > > ICMPv6 "packet too big" message back to the source? > > My understanding is that larger than MTU is not congestion, that > packets would not be dropped as an alternative to setting CE, and > that congestion for tunnels isn't any different than congestion in general. > > What tunnel adds is the question of what the encasulator puts in the ECT > bits in the outer header (where copying them from the inner header > makes sense in many cases) and whether the decapulator does anything with > the received ECT bits in the outer header (and I think that 3168 says > that unless there are security concerns, copying them from the outer > to the inner header makes sense). My only concern in this case is what happens at the decapsulator if an ECT/CE codepoint is set in the inner header but the outer header contains Not-ECT. Which one do we trust, in that case, and should the behavior be documented? > Thus I think the text in the mech document about ECN are sufficient. Agreed on other fronts except the above. Fred osprey67@yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 13 21:16:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05635 for ; Thu, 13 Nov 2003 21:16:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKTTB-000Ppu-4a for v6ops-data@psg.com; Fri, 14 Nov 2003 02:13:57 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKTT9-000Ppc-C9 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 02:13:55 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAE2DrPh014186; Thu, 13 Nov 2003 19:13:54 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAE2DmQ05534; Fri, 14 Nov 2003 03:13:48 +0100 (MET) Date: Fri, 14 Nov 2003 03:12:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: transmech MTU comments To: Fred Templin Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20031114015051.86422.qmail@web80506.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > My only concern in this case is what happens at the decapsulator > if an ECT/CE codepoint is set in the inner header but the outer > header contains Not-ECT. Which one do we trust, in that case, > and should the behavior be documented? Section 9.1 in RFC 3168 already documents this. Erik From owner-v6ops@ops.ietf.org Fri Nov 14 08:36:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09632 for ; Fri, 14 Nov 2003 08:36:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKe2V-000KHO-Cq for v6ops-data@psg.com; Fri, 14 Nov 2003 13:31:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKe2Q-000KGy-BU for v6ops@ops.ietf.org; Fri, 14 Nov 2003 13:31:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAEDUxs26180 for ; Fri, 14 Nov 2003 15:30:59 +0200 Date: Fri, 14 Nov 2003 15:30:58 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: transmech editorial comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, when writing up the comments, I thought I remembered to take all the substantial ones.. now I see that there a few with a minor point as well, but I really don't see resistance to them.. semi-editorial -------------- - The exit node of the tunnel (the decapsulator) receives the encapsulated packet, reassembles the packet if needed, removes the IPv4 header, updates the IPv6 header, and processes the received IPv6 packet. ==> why would the exit node update the IPv6 header? I assume that would be done for Hop Limit processing, but that's already covered by the further processing - The encapsulator MAY need to maintain soft state information for each tunnel recording such parameters as the MTU of the tunnel in order to process IPv6 packets forwarded into the tunnel. In cases where the number of tunnels that any one host or router is using is large, it is helpful to observe that this state information can be cached and discarded when not in use. ==> s/MAY/may/ (this kind of stuff should be a duplicate of 3.2.2) ==> move the sentence "In cases..." in section 3.2.2, e.g., before the last paragraph. (Actually you could consider moving about all of that to sect 3.2.2 as the state kept in the fixed MTU option is rather small.) 1) It would result in more fragmentation than needed. IPv4 layer fragmentation SHOULD be avoided due to the performance problems ==> s/SHOULD/should/ (this really isn't an interop requirement, and the actual uppercase reqs are later in the spec) ... 3.3. Hop Limit IPv6-over-IPv4 tunnels are modeled as "single-hop". That is, the IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the tunnel. The single-hop model serves to hide the existence of a tunnel. The tunnel is opaque to users of the network, and is not detectable by network diagnostic tools such as traceroute. The single-hop model is implemented by having the encapsulators and decapsulators process the IPv6 hop limit field as they would if they were forwarding a packet on to any other datalink. That is, they decrement the hop limit by 1 when forwarding an IPv6 packet. (The originating node and final destination do not decrement the hop limit.) ==> this seems a bit unclear forwarding for the case where the tunnel is not used for forwarding when the hop limit is not decremented. I tried to think of a better rewording, but perhaps the easiest fix would be to remove: That is, the IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the tunnel. .. because the description is already there in the next paragraph, and this one is wrong. Header Checksum: Calculate the checksum of the IPv4 header. ==> the ID-nits requires to describe how one treats the checksum field for the purposes of checksumming. Maybe a reference IP doc is OK, nothing more than that. fully editorial --------------- - Dual IP layer (also known as Dual Stack): A technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers. - Configured tunneling of IPv6 over IPv4: Point-to-point tunnels made by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures. ==> maybe the latter should be reworded to be similar, like: "A technique for establishing point-to-point tunnels by ...." ? 2.1. Address Configuration Because they support both protocols, IPv6/IPv4 nodes may be ==> s/they/the nodes/ 2.3. Advertising Addresses in the DNS There are some constraint placed on the use of the DNS during ==> s/constraint/constraints/ If an IPv6 node is isolated from an IPv6 perspective (e.g., it is not connected to the 6bone to take a concrete example) constraint #3 would mean that it should not have an address in the DNS. ==> reword 6bone (someone already mentioned this I think) This works great when other dual stack nodes try to contact the isolated dual stack node. There is no IPv6 address in the DNS thus ==> s/This works great/Following these guidelines enhances the the robustness/ ? terminate the TCP connection. This means that the normal TCP timeout of a few minutes apply. Once TCP times out the application will ==> s/apply/applies/ - Determine when to fragment and when to report an ICMP "packet too big" error back to the source. ==> s/ICMP/ICMPv6/ or IPv6 ICMP as a link layer with a very large MTU (65535-20 bytes to be exact; 20 bytes "extra" are needed for the encapsulating IPv4 header). The encapsulator would need only to report IPv6 ICMP "packet too big" ==> s/need only/only need/ such a scheme would be inefficient for two reasons and therefor MUST ==> s/therefor/therefore/ reassembled at the tunnel endpoint. For tunnels that terminate at a router, this would require additional memory to reassemble ==> s/memory/memory and other resources/ Hence, the encapsulator MUST NOT treat the tunnel as an interface with an MTU of 64 kilobytes, but instead either use the fixed static MTU below, or use OPTIONAL dynamic MTU determination based on the IPv4 path MTU to the tunnel endpoint. ==> s/below//, s/use// having a fixed interface MTU of 1280 bytes. An implementation MAY have a configuration knob which can be used to set a larger value of the tunnel MTU than 1280 bytes, but if so the default MUST be 1280 bytes. A larger fixed MTU should not be configured unless it has ==> s/than 1280 bytes//, s/if so/if so,/ (because the default must be 1280, no need to repeat) large tunnel MTUs to only do so when the MTU of the IPv4 path to the tunnel endpoint is large to avoid causing excessive fragmentation. ==> s/large/large enough/ should not receive any ICMPv4 "packet too big" message as a result of the packets it has encapsulated. ==> s/message/messages/ Encapsulators that have a large number of tunnels can choose between ==> s/can/may/ Implementations MAY provide a mechanism to allow the administrator to configure the IPv4 TTL such as the one specified in the IP Tunnel MIB [RFC2667]. ==> reword (removes "the one ..."): Implementations MAY provide a mechanism, for example IP Tunnel MIB [RFC2667], to allow the administrator to configure the IPv4 TTL. [RFC3168] for issues relating to the ToS byte and ==> s/ToS/Type of Service/ (I wonder if we should call the field DSCP...) Time to Live: Set in implementation-specific manner. ==> reword: Set in an implementation-specific manner, as described in section 3.3. ... 41 (Assigned payload type number for IPv6) ==> s/)/)./ Destination Address: IPv4 address of tunnel endpoint. ==>s/tunnel/the tunnel/ Any IPv6 options are preserved in the packet (after the IPv6 header). ==> this seems like an irrelevant sentence, could be removed? The decapsulator MUST be capable of reassembling an IPv4 packet that is the maximum of 1280 bytes and the largest interface MTU on the ==> s/interface/(IPv4) interface/ All IPv6 options are preserved even if the encapsulating IPv4 packet is fragmented. ==> again, this doesn't seem relevant and could be removed. The encapsulating IPv4 header is discarded. The length of the IPv6 packet MUST be determined from the IPv6 payload length since the IPv4 packet might be padded (thus have a length which is larger than the IPv6 packet plus the added IPv4 header). ==> the relevance of the latter should be clarified, like: The encapsulating IPv4 header is discarded. When reconstructing the IPv6 packet, the length MUST be determined from the IPv6 payload length since the IPv4 packet might be padded (thus have a length which is larger than the IPv6 packet plus the added IPv4 header). .... The Interface Identifier [RFC2373] for such an Interface SHOULD be ==> s/2373/3513/ (also later in another place) ==> s/I/i/ The IPv6 Link-local address [RFC2373] for an IPv4 virtual interface ==> s/L/l/ +-------+-------+-------+-------+-------+-------+------+------+ | FE 80 00 00 00 00 00 00 | +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | 00 | 00 | IPv4 Address | +-------+-------+-------+-------+-------+-------+------+------+ ==> the bars between the last and second last set of zeros are inconsistent with the rest...? When IP-in-IP tunneling (independent of IP versions) is used it is important that this not be a tool to bypass any ingress filtering in use for non- tunneled packets. ==> s/not be a tool/isn't used/ ? Thus the rules in this document are derived based on should ingress filtering be used for IPv4 and IPv6, the use of tunneling should not provide an easy way to circumvent the filtering. ==> maybe could start a new paragraph from here? possibility to circumvent ingress filtering [RFC2827]. This specification prevent tunneling from introducing additional ==> s/prevent/prevents/ weaknesses when IPv4 and/or IPv6 ingress filtering is in used by requiring that decapsulators only accept packets if they have been ==> s/in// -- 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 Nov 14 10:18:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14971 for ; Fri, 14 Nov 2003 10:18:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKfeb-00064H-J7 for v6ops-data@psg.com; Fri, 14 Nov 2003 15:14:33 +0000 Received: from [212.153.235.103] (helo=gw-nl6.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKfeT-00063d-44 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 15:14:25 +0000 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl6.philips.com (Postfix) with ESMTP id 3D0C75D40D; Fri, 14 Nov 2003 16:14:24 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id C77BA19C49; Fri, 14 Nov 2003 16:14:23 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 6FFBD19C48; Fri, 14 Nov 2003 16:14:23 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id QAA04654; Fri, 14 Nov 2003 16:14:23 +0100 (MET) From: mariana.nikolova@philips.com To: "JORDI PALET MARTINEZ" Cc: Subject: Re: Comment on draft-palet-v6ops-proto41-nat-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 14 Nov 2003 16:13:39 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 14/11/2003 16:13:41, Serialize complete at 14/11/2003 16:13:41 Content-Type: multipart/alternative; boundary="=_alternative 0053BED6C1256DDE_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 0053BED6C1256DDE_= Content-Type: text/plain; charset="us-ascii" Hi Jordi, >Yes, you're right. My feeling is that it could be implementation dependent, but not sure right now. Ok! Then, let's continue the analysis I have started at beginning of this thread. Suppose the order in which a router will process a packet with PF=41 is implementation dependent (as you suggest, although I think this is more theoritical option than practical, but nevertheless it might exist and it's good to analyse it for sake of completness of our analysis). So, let's suppose now that the first action the router will take when it gets an incoming 41-packet is to act as a 6to4 router, instead of applying proto-41 immidiately. Then, the router decapsulates the packet and looks what the IPv6 dest address is. If the prefix of the IPv6 dest address equals the 6to4 /48 router prefix, the packet is forwarded to its final destination (standard 6to4 way of processing the packets), otherwise, the I-D says it is forwarded to fixed node in the private network. Now, my question is "Which is this node?" Observe, at this level the router already works with IPv6 packets and it cannot apply proto-41 which is exclusively defined for IPv4 packets. If such forwarding (as you describe in the document) takes plays, then it is not proto-41, it is simply IPv6 forwarding. Sumarizing, the analysis in the whole thread shows that either you apply 6to4 or proto-41 transition mechanism but not mixing them. And this is my argument when I say if they coexist in a NAT box they should be implemented as two independent modes. I think this should be written very clearly in the draft in order to avoid misunderstanding. Greetings, Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- "JORDI PALET MARTINEZ" Sent by: owner-v6ops@ops.ietf.org 13-11-2003 18:47 Please respond to "JORDI PALET MARTINEZ" To: cc: (bcc: Mariana Nikolova/EHV/RESEARCH/PHILIPS) Subject: Re: Comment on draft-palet-v6ops-proto41-nat-03.txt Classification: Hi Mariana, Yes, you're right. My feeling is that it could be implementation dependent, but not sure right now. Definitively we need to work more on this. Regards, Jordi ----- Original Message ----- From: mariana.nikolova@philips.com To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Sent: Thursday, November 13, 2003 11:00 AM Subject: Comment on draft-palet-v6ops-proto41-nat-03.txt Hi Jordi, I have a comment on the following paragraph in Section 5 of your draft "6to4 and Proto-41 forwarding can coexist in the same NAT box. In that case, an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local 6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures. This fact avoids the problems created by mobile users when they visit a network that uses 6to4, in the case they have some automatic proto-41 setup. " Let's analyze how a router works when it's simultaneously supports 6to4 and proto-41 mechanisms as you proposed above. If there is an proto-41 entity such as (source IPv4 address, target IPv4 address, ID=41) in the NAT table of the router, then the so called prerouting is done for all packets matching this entity. Note, this is the first action taken by the router before any other actions are taken. With other words, the router forwards all incoming IPv4 packets with PF=41 to the target IPv4 address before even decapsulating them and looking what the IPv6 dest address is. So, what is written above "an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local 6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures." does not work in practice, because it require that the router first decapculates and looks the IPv6 dest. ad! dress. Summing up, I do see that 6to4 and proto-41 can coexist n the same NAT box but rather as two separate modes, i.e. the router can switch between 6to4 and proto-41 depending of certain preferences as the default one is 6to4 for example. In fact, I see the applicability of proto-41 in IPv4-only NAT boxes, but if the latter are upgraded to 6to4 routers it seems to me overdone to keep proto-41 as well. Greetings, Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- ********************************** 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. --=_alternative 0053BED6C1256DDE_= Content-Type: text/html; charset="us-ascii"
Hi Jordi,

>Yes, you're right. My feeling is that it could be implementation dependent, but not sure right now.

Ok! Then, let's continue the analysis I have started at beginning of this thread. Suppose the order in which a router will process a packet with PF=41 is implementation dependent (as you suggest, although I think this is more theoritical option than practical, but nevertheless it might exist and it's good to analyse it for sake of completness of our analysis).

So, let's  suppose now that the first action the router will take when it gets an incoming 41-packet is to act as a 6to4 router, instead of applying proto-41 immidiately. Then, the router  decapsulates the packet and looks what the IPv6 dest address is. If the prefix of the IPv6 dest address equals the 6to4 /48  router prefix, the packet is forwarded to its final destination (standard 6to4 way of processing the packets), otherwise, the I-D says it is forwarded to fixed node in the private network.
Now, my question is "Which is this node?" Observe, at this level the router already works with IPv6 packets and it cannot apply proto-41 which is exclusively defined for IPv4 packets. If such forwarding (as you describe in the document) takes plays, then it is not proto-41, it is simply IPv6 forwarding.

Sumarizing, the analysis in the whole thread shows that either you  apply 6to4 or proto-41 transition mechanism but not mixing them. And this is my argument when I say if they coexist in a NAT box they should be implemented as two independent modes.
I think this should be written very clearly in the draft in order to avoid misunderstanding.

Greetings,
Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
-----------------------------------------------------------------------------------------------------------------







"JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>

Sent by:
owner-v6ops@ops.ietf.org

13-11-2003 18:47
Please respond to "JORDI PALET MARTINEZ"

       
        To:        <v6ops@ops.ietf.org>
        cc:        (bcc: Mariana Nikolova/EHV/RESEARCH/PHILIPS)
        Subject:        Re: Comment on  draft-palet-v6ops-proto41-nat-03.txt

        Classification:        




Hi Mariana,
 
Yes, you're right. My feeling is that it could be implementation dependent, but not sure right now.
 
Definitively we need to work more on this.
 
Regards,
Jordi
----- Original Message -----
From: mariana.nikolova@philips.com
To: JORDI PALET MARTINEZ
Cc: v6ops@ops.ietf.org
Sent: Thursday, November 13, 2003 11:00 AM
Subject: Comment on draft-palet-v6ops-proto41-nat-03.txt


Hi Jordi,

I have a comment on the following paragraph in Section 5 of your draft

"6to4 and Proto-41 forwarding can coexist in the same NAT box. In that  case, an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local  6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures. This fact avoids the problems created by mobile users when they visit a network that uses 6to4, in the case they have some automatic proto-41 setup. "

Let's analyze how a router works when it's simultaneously supports 6to4 and proto-41 mechanisms  as you proposed above.

If there is an proto-41 entity such as (source IPv4 address, target IPv4 address, ID=41) in the NAT table of the router, then the so called prerouting is done for all packets matching this entity. Note, this is the first action taken by the router  before any other actions are taken. With other words, the router forwards all incoming IPv4 packets with PF=41 to the target IPv4 address before even decapsulating them and looking what the IPv6 dest address is.  So, what is written above "an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local  6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures."  does not work in practice, because it require that the router first decapculates and  looks the IPv6 dest. ad! dress.

Summing up, I do see that 6to4 and proto-41 can coexist n the same NAT box but rather as two separate modes, i.e. the router can switch between 6to4 and proto-41 depending of certain preferences as the default one is 6to4 for example.  In fact, I see the applicability of proto-41 in IPv4-only NAT boxes, but if the latter are upgraded to 6to4 routers it seems to me overdone to keep proto-41 as well.  

Greetings,
Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
-----------------------------------------------------------------------------------------------------------------

**********************************
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.

--=_alternative 0053BED6C1256DDE_=-- From owner-v6ops@ops.ietf.org Fri Nov 14 11:13:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18050 for ; Fri, 14 Nov 2003 11:13:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKgWu-000D9c-LJ for v6ops-data@psg.com; Fri, 14 Nov 2003 16:10:40 +0000 Received: from [212.153.190.6] (helo=gw-nl4.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKgWr-000D90-Om for v6ops@ops.ietf.org; Fri, 14 Nov 2003 16:10:37 +0000 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id A05B92B5C3 for ; Fri, 14 Nov 2003 17:10:36 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 413AF19C4D for ; Fri, 14 Nov 2003 17:10:36 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id CEA9419C4B for ; Fri, 14 Nov 2003 17:10:35 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id RAA12292 for ; Fri, 14 Nov 2003 17:10:35 +0100 (MET) From: mariana.nikolova@philips.com To: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 14 Nov 2003 17:09:52 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 14/11/2003 17:09:53, Serialize complete at 14/11/2003 17:09:53 Content-Type: multipart/alternative; boundary="=_alternative 0058E477C1256DDE_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 0058E477C1256DDE_= Content-Type: text/plain; charset="us-ascii" > I do not think it clearly falls within the charter of the WG. Well, indeed the charter allows for highly subjective interpretation ...., but nevertheless charter item 1 fits very well. >The only clear possibility I see is charter item (6), but that would not be >acceptable until the analysis/scenarios work is complete and a clear need >has been identified. During the plenary there was a clear indication from the WG members that the group spends too much time on analysis/scenarios/aspects and this process has to be speeded up. I do hope this will happen. Furthermore, IPv6 comes to commercial deployment and needs well defined transition mechanisms (which makes the scenarios feasible) and alternative paths. proto-41 is one of them (in addition to some others) and there is no much time to wait ..... Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- --=_alternative 0058E477C1256DDE_= Content-Type: text/html; charset="us-ascii"
> I do not think it clearly falls within the charter of the WG.  

Well, indeed the charter allows for highly subjective interpretation ...., but nevertheless charter item 1 fits very well.

>The only clear possibility I see is charter item (6), but that would not be
>acceptable until the analysis/scenarios work is complete and a clear need
>has been identified.

During the plenary there was a clear indication from the WG members that the group spends too much time on analysis/scenarios/aspects and this process has to be speeded up. I do hope this will happen.
Furthermore, IPv6 comes to commercial deployment and needs well defined transition mechanisms (which makes the scenarios feasible) and alternative paths. proto-41 is one of them (in addition to some others) and there is no much time to wait .....

Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
----------------------------------------------------------------------------------------------------------------- --=_alternative 0058E477C1256DDE_=-- From owner-v6ops@ops.ietf.org Fri Nov 14 11:21:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18471 for ; Fri, 14 Nov 2003 11:21:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKgeX-000E3x-PZ for v6ops-data@psg.com; Fri, 14 Nov 2003 16:18:33 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKgeS-000E3J-Vr for v6ops@ops.ietf.org; Fri, 14 Nov 2003 16:18: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 hAEGIN5u026138; Fri, 14 Nov 2003 09:18:24 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAEGILQ09268; Fri, 14 Nov 2003 17:18:21 +0100 (MET) Date: Fri, 14 Nov 2003 17:15:06 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: transmech editorial comments To: Pekka Savola Cc: 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for the careful read. I've applied all of them. One question below. > - The exit node of the tunnel (the decapsulator) receives the > encapsulated packet, reassembles the packet if needed, removes > the IPv4 header, updates the IPv6 header, and processes the > received IPv6 packet. > > ==> why would the exit node update the IPv6 header? I assume that would be > done for Hop Limit processing, but that's already covered by the further > processing Correct. fixed. > ==> this seems a bit unclear forwarding for the case where the tunnel is not > used for forwarding when the hop limit is not decremented. I tried to think > of a better rewording, but perhaps the easiest fix would be to remove: > > That is, the > IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the > tunnel. How about replacing it with? That is, forwarding packets into a tunnel or packets received on a tunnel has the same impact on the IPv6 hop limit as for other interfaces. > - Determine when to fragment and when to report an ICMP "packet > too big" error back to the source. > > ==> s/ICMP/ICMPv6/ or IPv6 ICMP I also found text in several places with "IPvX ICMP" which I replaced with "ICMPvX". > Implementations MAY provide a mechanism, for example IP Tunnel MIB > [RFC2667], to allow the administrator to configure the IPv4 TTL. > > [RFC3168] for issues relating to the ToS byte and > > ==> s/ToS/Type of Service/ (I wonder if we should call the field DSCP...) DSCP is 6 bits out of the byte AFAIK, so keeping Type-of-service makes sense to me. > Any IPv6 options are preserved in the packet (after the IPv6 header). > > ==> this seems like an irrelevant sentence, could be removed? Sure. (Especially since IPv6 doesn't have options after the base header - it might have extension headers which contain options ...) Erik From owner-v6ops@ops.ietf.org Fri Nov 14 11:27:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18743 for ; Fri, 14 Nov 2003 11:27:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKgkx-000Epn-G5 for v6ops-data@psg.com; Fri, 14 Nov 2003 16:25:11 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKgks-000EoL-HA for v6ops@ops.ietf.org; Fri, 14 Nov 2003 16:25:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAEGOtY28888; Fri, 14 Nov 2003 18:24:56 +0200 Date: Fri, 14 Nov 2003 18:24:55 +0200 (EET) From: Pekka Savola To: mariana.nikolova@philips.com cc: v6ops@ops.ietf.org Subject: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 14 Nov 2003 mariana.nikolova@philips.com wrote: > During the plenary there was a clear indication from the WG members that > the group spends too much time on analysis/scenarios/aspects and this > process has to be speeded up. I do hope this will happen. On the contrary, the WG spends too *little* time on analysis work, which is the reason for all the perceived problems of timeliness. Our problem is that only few seem to care about it at all, just complain that we aren't doing transition mechanisms and other stuff to suit the market windows. That's not going to happen until we're done. If everyone pitched in in the final rush for the analysis/scenarios work, we might actually be done soon! I certainly see a hope of progress in the short term, but then again, we need more input to the work! This was probably said already two years ago, but folks didn't take it seriously, so you see the effect.. Please, *DO* participate in the analysis/scenarios 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 Fri Nov 14 11:34:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19138 for ; Fri, 14 Nov 2003 11:34:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKgrf-000FlZ-7Z for v6ops-data@psg.com; Fri, 14 Nov 2003 16:32:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKgrc-000FlJ-46 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 16:32:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAEGVwq28983; Fri, 14 Nov 2003 18:31:58 +0200 Date: Fri, 14 Nov 2003 18:31:58 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: transmech editorial comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 14 Nov 2003, Erik Nordmark wrote: > > ==> this seems a bit unclear forwarding for the case where the tunnel is not > > used for forwarding when the hop limit is not decremented. I tried to think > > of a better rewording, but perhaps the easiest fix would be to remove: > > > > That is, the > > IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the > > tunnel. > > How about replacing it with? > That is, forwarding > packets into a tunnel or packets received on a tunnel has the same > impact on the IPv6 hop limit as for other interfaces. This would be good independently, but the big picture is: IPv6-over-IPv4 tunnels are modeled as "single-hop". That is, the IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the tunnel. The single-hop model serves to hide the existence of a tunnel. The tunnel is opaque to users of the network, and is not detectable by network diagnostic tools such as traceroute. The single-hop model is implemented by having the encapsulators and decapsulators process the IPv6 hop limit field as they would if they were forwarding a packet on to any other datalink. That is, they decrement the hop limit by 1 when forwarding an IPv6 packet. (The originating node and final destination do not decrement the hop limit.) ... wouldn't we just be repeating the second paragraph in a bit shorter fashion? Btw, maybe one should reword "implemented", because that isn't really "implementation-specific", to avoid that connotation. Maybe use "achieved" ? > > Implementations MAY provide a mechanism, for example IP Tunnel MIB > > [RFC2667], to allow the administrator to configure the IPv4 TTL. > > > > [RFC3168] for issues relating to the ToS byte and > > > > ==> s/ToS/Type of Service/ (I wonder if we should call the field DSCP...) > > DSCP is 6 bits out of the byte AFAIK, so keeping Type-of-service makes sense > to me. 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 Fri Nov 14 11:57:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20284 for ; Fri, 14 Nov 2003 11:57:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKhEL-000JHi-4G for v6ops-data@psg.com; Fri, 14 Nov 2003 16:55:33 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKhEF-000JH9-25 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 16:55:27 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA19998 for ; Fri, 14 Nov 2003 16:55:24 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 QAA19927 for ; Fri, 14 Nov 2003 16:55:23 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAEGtNB21050 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 16:55:23 GMT Date: Fri, 14 Nov 2003 16:55:23 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Message-ID: <20031114165523.GK19013@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20031112192854.GB16674@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Nov 13, 2003 at 05:27:36PM +0100, Erik Nordmark wrote: > > > 1. Why is IPv4 compatible addressing defined in the first section, > > if it is deprecated? > > To say that it is deprecated. But perhaps we should ask to do this > in the ipv6 addressing architecture update. OK, but that could simply be in the changes section, not in the definitions section, as if the 3.6 reference is removed IPv4 compatibles are then only mentioned in the changes section. having them in the defs kind of suggests they are valid. > > 3. Section 2 starts "the most straightforward way", though this > > is the only way in this document? > > Yes. Is that confusing? Suggestions for different way to start things off? I guess if we said "the recommended way" that might get some objection. I think part of the "problem" is that the draft doesn't set context anywhere, e.g. it doesn't state why automatic methods such as 6to4 are not cited, or why NAT-PT isn't mentioned as a "less straightforward" way of having compatibility. Perhaps "The only way for IPv6 nodes to remain fully compatible with IPv4-only nodes is by...", and then make some comment that without that translation is needed? (a quick grep shows not one instance of the word "translation" so again I think some text near the start setting the scope here would really help). In short, the first line of the abstract would suggest that translation methods should be cited, but in fact the document really focuses on tunnel methods that IPv6 hosts/routers can use to communicate over IPv4 networks. Maybe this focus changed over the three iterationbs of this RFC? > > 4. In 2.2 should we mention that that app may or may not be v6 aware or > > capable? The shin-application-transition draft could be pointed to, > > although it is not a WG item ist looks very good work. > > Already received a comment about not adding AAAAs until the apps/services > on the node support IPv6. > Would that address your comment or should I add something slightly different? I think one thing shin-application-transition captures well is the issue of v4/v6 enabled on the host and v4/v6 application capability (and thus the potential usage of mapped addresses for example). I guess 2.2 talks about the protocol used on the wire, so the presentation to the app as a mapped address may be out of scope here. > Isn't the current text sufficient? It says: > Other transition mechanisms, including other tunneling mechanisms, > are outside the scope of this document. See above - I think the first sentence of the abstract suggests otherwise, and this sentence I think is used in the intro text at least too. If you just want to make one change, then a statement in the asbtract and after paragraph 1 of the intro to say that translation techniques are not in scope would help, I think. Sorry if this seems a little pedantic :) Tim From owner-v6ops@ops.ietf.org Fri Nov 14 12:02:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20415 for ; Fri, 14 Nov 2003 12:02:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKhJJ-000Jvc-1o for v6ops-data@psg.com; Fri, 14 Nov 2003 17:00:41 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKhJC-000Jus-U1 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 17:00:35 +0000 Received: from consulintel02 ([130.129.132.131]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 63-md50000000066.tmp for ; Fri, 14 Nov 2003 18:01:19 +0100 Message-ID: <1a6a01c3aad0$bf057030$83848182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Date: Fri, 14 Nov 2003 11:00:00 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 14 Nov 2003 18:01:19 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.132.131 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, While I agree in the importance of the analysis word, and I try to spend = some of my time on it, there is nothing in the charter that doesn't = allow to continue other works in parallel, that doesn't define new = transition mechanism. By the way, I'm still waiting your reply on this = to my previous email. Not allowing the WG to work on what they feel is interesting, is = definitively mining the WG effort, and avoiding the progress. Most of the WG participants are in the REAL market, and we know what is = going there, and we know that if IETF doesn't do the work soon, we will = have non-IETF solutions, what clearly is much worst. We need to be much more flexible in the process and allow for some = parallel work. Obviously it could mean that some of the documents = couldn't go to last call. FINE ! Hopefully we will have a bunch of = things to go to last call together in a few months. PLEASE, do allow and facilitate the pro-activity and democracy of the = WG, and if needed allow the WG to interpret the charter instead of = mandating what you or the AD or the IESG or whoever feels is correct, = while the WG doesn't believe in it. Otherwise, this will not longer be a = WG, just a bunch of people willing to work outside of IETF. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: Cc: Sent: Friday, November 14, 2003 10:24 AM Subject: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 = as WG item] > On Fri, 14 Nov 2003 mariana.nikolova@philips.com wrote: > > During the plenary there was a clear indication from the WG members = that=20 > > the group spends too much time on analysis/scenarios/aspects and = this=20 > > process has to be speeded up. I do hope this will happen. >=20 > On the contrary, the WG spends too *little* time on analysis work, = which=20 > is the reason for all the perceived problems of timeliness. >=20 > Our problem is that only few seem to care about it at all, just = complain > that we aren't doing transition mechanisms and other stuff to suit the > market windows. That's not going to happen until we're done. >=20 > If everyone pitched in in the final rush for the analysis/scenarios = work,=20 > we might actually be done soon! I certainly see a hope of progress in = the=20 > short term, but then again, we need more input to the work! >=20 > This was probably said already two years ago, but folks didn't take it = > seriously, so you see the effect.. >=20 > Please, *DO* participate in the analysis/scenarios effort! >=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 Nov 14 12:03:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20486 for ; Fri, 14 Nov 2003 12:03:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKhKa-000KJd-2g for v6ops-data@psg.com; Fri, 14 Nov 2003 17:02:00 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKhKX-000KJL-Ls for v6ops@ops.ietf.org; Fri, 14 Nov 2003 17:01:57 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id CD5038A; Sat, 15 Nov 2003 02:01:56 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] In-Reply-To: Your message of "Fri, 14 Nov 2003 18:24:55 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031114170156.CD5038A@coconut.itojun.org> Date: Sat, 15 Nov 2003 02:01:56 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > This was probably said already two years ago, but folks didn't take it > seriously, so you see the effect.. > > Please, *DO* participate in the analysis/scenarios effort! one thing i'm observing about analysis/scenarios effort is that, there are so many configuration option for IPv4 network (for instance, if there are 100 ISPs there will be 100, or more!, different network designs, all with good reasons). so i'm now not sure if we can really generalize those various configuration into 4 analysis/scenario domains. thererefore, i'm thinking of submitting a draft which describes what we (IIJ, AS2497) did to deploy IPv6 backbone as well as IPv6 services. before start writing stuff up, my question is: - does it sound useful? - doesn't it jeopadize ISP analysis/scenario effort, or is it okay to have generalized analysis/scneario doc and specific-ISP doc in parallel? - if it is useful, can other ISP/enterprise/whatever do the similar thing? NOTE: i'm on ISP scenario group. i'm not very active in the group though (sorry). itojun From owner-v6ops@ops.ietf.org Fri Nov 14 12:12:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20871 for ; Fri, 14 Nov 2003 12:12:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKhSI-000LUA-Fr for v6ops-data@psg.com; Fri, 14 Nov 2003 17:09:58 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKhSG-000LTn-C0 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 17:09:56 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA20657 for ; Fri, 14 Nov 2003 17:09:55 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 RAA20341 for ; Fri, 14 Nov 2003 17:09:54 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAEH9qP21329 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 17:09:52 GMT Date: Fri, 14 Nov 2003 17:09:52 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Message-ID: <20031114170952.GN19013@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20031114170156.CD5038A@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031114170156.CD5038A@coconut.itojun.org> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Nov 15, 2003 at 02:01:56AM +0900, Jun-ichiro itojun Hagino wrote: > > thererefore, i'm thinking of submitting a draft which describes what > we (IIJ, AS2497) did to deploy IPv6 backbone as well as IPv6 services. > > before start writing stuff up, my question is: > - does it sound useful? Yes, we had such a draft presented this week. Another would not hurt. > - doesn't it jeopadize ISP analysis/scenario effort, or is it okay to > have generalized analysis/scneario doc and specific-ISP doc in > parallel? I think it is good to have. > - if it is useful, can other ISP/enterprise/whatever do the similar > thing? I don't see why not. Where the draft ended up in the process is a different question (it would be a personal draft for reference only, I assume), but the dissemination would be very useful. Tim From owner-v6ops@ops.ietf.org Fri Nov 14 12:21:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21121 for ; Fri, 14 Nov 2003 12:21:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKhaX-000May-Dv for v6ops-data@psg.com; Fri, 14 Nov 2003 17:18:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKhaV-000Maf-6d for v6ops@ops.ietf.org; Fri, 14 Nov 2003 17:18:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAEHIKH29785; Fri, 14 Nov 2003 19:18:20 +0200 Date: Fri, 14 Nov 2003 19:18:19 +0200 (EET) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] In-Reply-To: <20031114170952.GN19013@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 14 Nov 2003, Tim Chown wrote: [...] > I don't see why not. Where the draft ended up in the process is a different > question (it would be a personal draft for reference only, I assume), but > the dissemination would be very useful. FWIW, I agree with Tim's points. A draft would likely help us focus the generic document better as well. Of course, it might never actully even end up being published, but its goal would probably be fulfilled by discussion only. -- 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 Nov 14 12:34:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21736 for ; Fri, 14 Nov 2003 12:34:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKhnO-000OXV-4I for v6ops-data@psg.com; Fri, 14 Nov 2003 17:31:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKhnL-000OXF-L1 for v6ops@ops.ietf.org; Fri, 14 Nov 2003 17:31:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAEHVdj30009; Fri, 14 Nov 2003 19:31:39 +0200 Date: Fri, 14 Nov 2003 19:31:39 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] In-Reply-To: <1a6a01c3aad0$bf057030$83848182@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 14 Nov 2003, JORDI PALET MARTINEZ wrote: > While I agree in the importance of the analysis word, and I try to spend > some of my time on it, there is nothing in the charter that doesn't > allow to continue other works in parallel, that doesn't define new > transition mechanism. By the way, I'm still waiting your reply on this > to my previous email. Charter item (6) says: Identify open operational or security issues with the deployment scenarios documented in (5) [...] And item (5): 5. Publish Informational or BCP RFCs [...] ... a draft does not fulfill that criteria. IESG approval on document probably would be interpreted to be it. Working group last call with no issues raised is stretch but could maybe be considered, but anything prior to that would be clearly premature. Of course, it's OK to work on the subjects in parallel, maybe even using the mailing list if it's nonintrusive, but one should definitely not expect them to become official WG items prematurely. > Not allowing the WG to work on what they feel is interesting, is > definitively mining the WG effort, and avoiding the progress. News: that's how chartering works. Basically, the WG is chartered to do certain specific things, not whatever the general WG populace thinks is interesting. > PLEASE, do allow and facilitate the pro-activity and democracy of the > WG, and if needed allow the WG to interpret the charter instead of > mandating what you or the AD or the IESG or whoever feels is correct, > while the WG doesn't believe in it. Otherwise, this will not longer be a > WG, just a bunch of people willing to work outside of IETF. The WG does not set the charter. I fail to see why you even *consider* that the WG would have the authority to interpret it? Sure, if WG feels something is in charter, that's fine. But that still doesn't mean *anything*. The same works the other way 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 Nov 14 13:14:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23158 for ; Fri, 14 Nov 2003 13:14:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKiOq-0004Hj-HG for v6ops-data@psg.com; Fri, 14 Nov 2003 18:10:28 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKiOk-0004Gg-Dv for v6ops@ops.ietf.org; Fri, 14 Nov 2003 18:10:22 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAEI9ot05667; Fri, 14 Nov 2003 10:09:50 -0800 X-mProtect: <200311141809> 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 smtpdKfuJo0; Fri, 14 Nov 2003 10:09:48 PST Message-ID: <3FB51C0B.7030509@iprg.nokia.com> Date: Fri, 14 Nov 2003 10:16:43 -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: ipv6@ietf.org, v6ops@ops.ietf.org CC: ftemplin@iprg.nokia.com Subject: [Fwd: Re: [pmtud] Re: [dccp] PMTU issues] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm cross-posting this from another list, since it relates to the recent discussions on Path MTU discovery: Fred ftemplin@iprg.nokia.com Fred Templin wrote: > I hate to say it, but frankly I think this whole PMTU business is > a bunch of hooey. We have RFCs 1191 and 1981 as the service for > packetization layers that require network level feedback, and those > packetization layers can happily continue doing what they've been > doing for the past decade or so. > > But, new packetization layers that take the example of PLPMTUD > require no feedback from the network and so they should have a > means by which to turn the network layer feedback off. This should > eventually dampen the noise from the unnecessary ICMP's as the > new packetization layers supplant the old. > > Anyway, that's my story and I'm sticking to it. > > Fred > ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Nov 14 13:25:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23500 for ; Fri, 14 Nov 2003 13:25:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKiaW-0005rd-Jp for v6ops-data@psg.com; Fri, 14 Nov 2003 18:22:32 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKiaU-0005rJ-QE for v6ops@ops.ietf.org; Fri, 14 Nov 2003 18:22:30 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAEIMSJ15502; Fri, 14 Nov 2003 10:22:28 -0800 X-mProtect: <200311141822> 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 smtpdzhOK68; Fri, 14 Nov 2003 10:22:26 PST Message-ID: <3FB51F01.3000701@iprg.nokia.com> Date: Fri, 14 Nov 2003 10:29: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: Fred Templin , v6ops@ops.ietf.org Subject: Re: transmech MTU comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>My only concern in this case is what happens at the decapsulator >>if an ECT/CE codepoint is set in the inner header but the outer >>header contains Not-ECT. Which one do we trust, in that case, >>and should the behavior be documented? >> >> > >Section 9.1 in RFC 3168 already documents this. > > Then, can we have a more-specific reference in the document to provide better guidance to implementors, e.g., ([RFC3168], section 9.1)? Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Nov 14 15:42:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28886 for ; Fri, 14 Nov 2003 15:42:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKkgJ-0000Dd-O3 for v6ops-data@psg.com; Fri, 14 Nov 2003 20:36:39 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKkgI-0000DK-0V for v6ops@ops.ietf.org; Fri, 14 Nov 2003 20:36:38 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAEKaQw19735; Fri, 14 Nov 2003 12:36:26 -0800 X-mProtect: <200311142036> 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 smtpdx26vPf; Fri, 14 Nov 2003 12:36:25 PST Message-ID: <3FB53E67.7010805@iprg.nokia.com> Date: Fri, 14 Nov 2003 12:43:19 -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: JORDI PALET MARTINEZ , v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >5. Publish Informational or BCP RFCs [...] > >... a draft does not fulfill that criteria. IESG approval on document >probably would be interpreted to be it. Working group last call with no >issues raised is stretch but could maybe be considered, but anything >prior to that would be clearly premature. > >Of course, it's OK to work on the subjects in parallel, maybe even using >the mailing list if it's nonintrusive, but one should definitely not >expect them to become official WG items prematurely. > Then, let's have ISATAP as a WG item; it's been around for three years and there is nothing premature about that. (Better yet would be to just go ahead and publish it NOW.) I want ISATAP as a work of the IETF as it should be so that we can declare success together. Let's get on board with the new technology before the real world passes us by. Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Nov 14 16:39:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00336 for ; Fri, 14 Nov 2003 16:39:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKlcS-0009HQ-Tu for v6ops-data@psg.com; Fri, 14 Nov 2003 21:36:44 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKlcP-0009Fv-Dh for v6ops@ops.ietf.org; Fri, 14 Nov 2003 21:36:41 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Nov 2003 13:39:23 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAELabti019247; Fri, 14 Nov 2003 13:36:39 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANP10705; Fri, 14 Nov 2003 13:36:34 -0800 (PST) Date: Fri, 14 Nov 2003 13:36:32 -0800 (PST) From: Suresh Satapati To: "Karim El-Malki (HF/EAB)" , "'Randy Bush'" cc: v6ops@ops.ietf.org Subject: RE: NAT-PT Applicabilty for 3GPP In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639907@ESEALNT442.al.sw.ericsson.se> Message-ID: References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639907@ESEALNT442.al.sw.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Karim, This may be redundant to you, but to seek WG opinion I will repeat the argument here on this list. > I brought up the same issue during the DT work and agree with Randy's > point that if a scenario exists that requires a subset of NAT-PT (i.e. 3GPP > IMS) then it does not necessarily imply that NAT-PT as specified in RFC 2766 > is applicable. The draft could however point out which parts of NAT-PT are > applicable in this case. > > Regarding the actual SIP solution there is a reference in 3gpp-analysis-07 > to draft-elmalki-sipping-3gpp-translator-00. Following Margaret's comments > last time and the recommendation in draft-ietf-3gpp-analysis it is on the > SIPPING agenda this time. For those who may be interested here's a new version > of the draft: > http://standards.ericsson.net/karim/draft-elmalki-sipping-3gpp-translator-00.txt > This whole "subset applicability" argument stems from incorrect assumption that NAT-PT (RFC 2766) mandates DNS-ALG. In the past for v4 land, ALGs have been specified in separate documents. For e.g. RFC 2663/3022 clearly defines the role of "NAT", and for DNS-ALG there is RFC 2694. RFC2766 mentions DNS-ALG (and FTP-ALG) as an example, in addition to basic NAT-PT operation. There is no text that states NAT-PT mandates DNS-ALG. This clarification came from the author of NAT-PT, as well. Pls refer to previous posting: http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01460.html > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > > Behalf Of Randy Bush > > Sent: den 13 november 2003 00:25 > > To: Suresh Satapati > > Cc: v6ops@ops.ietf.org > > Subject: Re: NAT-PT Applicabilty for 3GPP > > > > > > > In the above, though a SIP-specific translation mechanism is being > > > recommended, I do not see how the recommended solution will be > > > fundamentally different from NAT-PT. In this sense, the > > applicability > > > of NAT-PT is still valid. > > > > if A is a proper subset of B, a need for A does not mandate B, > > especially if A is a very localized hack and B is global, generic, > > and questionable. > > > > randy > > > > > From owner-v6ops@ops.ietf.org Fri Nov 14 17:35:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02308 for ; Fri, 14 Nov 2003 17:35:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKmUV-000IHx-6g for v6ops-data@psg.com; Fri, 14 Nov 2003 22:32:35 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKmUH-000IEq-4q for v6ops@ops.ietf.org; Fri, 14 Nov 2003 22:32:21 +0000 Received: from consulintel02 ([12.162.212.142]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 37-md50000000071.tmp for ; Fri, 14 Nov 2003 23:33:06 +0100 Message-ID: <1c7701c3aaff$1830ce60$83848182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Date: Fri, 14 Nov 2003 16:30:39 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 14 Nov 2003 23:33:06 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 12.162.212.142 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, Why you keep going with 5 and 6 if 1 is clear ? You insist in the charter, and I'm reading the charter, starting with 1 = ... Anyway, at the moment I see more positive feedback to get this item as a = WG item than negative one ... so lets don't keep with this non-endless = discussion, and wait for some more replies to see what the WG consensus = is. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Friday, November 14, 2003 11:31 AM Subject: Re: spending time on analysis [Re: = draft-palet-v6ops-proto41-nat-03 as WG item] > On Fri, 14 Nov 2003, JORDI PALET MARTINEZ wrote: > > While I agree in the importance of the analysis word, and I try to = spend > > some of my time on it, there is nothing in the charter that doesn't > > allow to continue other works in parallel, that doesn't define new > > transition mechanism. By the way, I'm still waiting your reply on = this > > to my previous email. >=20 > Charter item (6) says: >=20 > Identify open operational or security issues with the deployment > scenarios documented in (5) [...] >=20 > And item (5): >=20 > 5. Publish Informational or BCP RFCs [...] >=20 > ... a draft does not fulfill that criteria. IESG approval on = document=20 > probably would be interpreted to be it. Working group last call with = no=20 > issues raised is stretch but could maybe be considered, but anything=20 > prior to that would be clearly premature. >=20 > Of course, it's OK to work on the subjects in parallel, maybe even = using=20 > the mailing list if it's nonintrusive, but one should definitely not=20 > expect them to become official WG items prematurely. >=20 > > Not allowing the WG to work on what they feel is interesting, is > > definitively mining the WG effort, and avoiding the progress. >=20 > News: that's how chartering works. Basically, the WG is chartered to = do=20 > certain specific things, not whatever the general WG populace thinks = is=20 > interesting. >=20 > > PLEASE, do allow and facilitate the pro-activity and democracy of = the > > WG, and if needed allow the WG to interpret the charter instead of > > mandating what you or the AD or the IESG or whoever feels is = correct, > > while the WG doesn't believe in it. Otherwise, this will not longer = be a > > WG, just a bunch of people willing to work outside of IETF. >=20 > The WG does not set the charter. I fail to see why you even = *consider*=20 > that the WG would have the authority to interpret it? >=20 > Sure, if WG feels something is in charter, that's fine. But that = still=20 > doesn't mean *anything*. The same works the other way as well. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Nov 14 20:54:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09268 for ; Fri, 14 Nov 2003 20:54:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKpZx-0000Qq-LW for v6ops-data@psg.com; Sat, 15 Nov 2003 01:50:25 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKpZu-0000Q0-Sc for v6ops@ops.ietf.org; Sat, 15 Nov 2003 01:50:22 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF1noJ08641; Fri, 14 Nov 2003 17:49:50 -0800 X-mProtect: <200311150149> 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 smtpdLCZnxU; Fri, 14 Nov 2003 17:49:49 PST Message-ID: <3FB587DD.6060906@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:56:45 -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: dccp@ietf.org, pmtud@ietf.org CC: Fred Templin , ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues References: <1068827087.4798.322.camel@lap10-c703.uibk.ac.at> <20031114163817.6006E8A@coconut.itojun.org> <3FB516E7.5040702@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit BTW, one last parting thought on this subject (and then I'll shut up) is that we have perhaps an opportunity to specify the following good thing: A packetization layer should set an ECN codepoint in the packets it sends IFF it is also doing Packetization Layer Path MTU Discovery (PLPMTUD) and is not expecting to get ICMP's back from the network in response to too-large packets being dropped. I have already implied this in my document, which should hit the I-D repository soon. See: www.geocities.com/osprey67/tunnelmtu-06.txt But, perhaps this needs to be spelled out in a more general-use type of document, e.g., a per-hop behavoir (PHB) document for RFC 3168? Thanks - Fred ftemplin@iprg.nokia.com Fred Templin wrote: > I hate to say it, but frankly I think this whole PMTU business is > a bunch of hooey. We have RFCs 1191 and 1981 as the service for > packetization layers that require network level feedback, and those > packetization layers can happily continue doing what they've been > doing for the past decade or so. > > But, new packetization layers that take the example of PLPMTUD > require no feedback from the network and so they should have a > means by which to turn the network layer feedback off. This should > eventually dampen the noise from the unnecessary ICMP's as the > new packetization layers supplant the old. > > Anyway, that's my story and I'm sticking to it. > > Fred > ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Sat Nov 15 01:05:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15138 for ; Sat, 15 Nov 2003 01:05:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKtTr-000GDd-0S for v6ops-data@psg.com; Sat, 15 Nov 2003 06:00:23 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKtTo-000GBl-Ff for v6ops@ops.ietf.org; Sat, 15 Nov 2003 06:00:20 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1AKtTl-000AmK-QN for v6ops@ops.ietf.org; Fri, 14 Nov 2003 22:00:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200311150304.hAF34uIe031104@coyote.icir.org> In-Reply-To: Message from Fred Templin of "Fri, 14 Nov 2003 17:56:45 PST." <3FB587DD.6060906@iprg.nokia.com> To: Fred Templin cc: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues Date: Fri, 14 Nov 2003 19:04:56 -0800 From: Eddie Kohler X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A packetization layer should set an ECN codepoint in > the packets it sends IFF it is also doing Packetization > Layer Path MTU Discovery (PLPMTUD) and is not > expecting to get ICMP's back from the network in > response to too-large packets being dropped. Why overload the ECN bit this way? ECN should be used to indicate end-to-end congestion control compliance. In fact RFC 3168 requires that: "... the transport protocol must be capable of reacting appropriately to the receipt of CE packets." THat's independent of MTU discovery, or at least should be pointed out. Eddie From owner-v6ops@ops.ietf.org Sat Nov 15 06:56:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05425 for ; Sat, 15 Nov 2003 06:56:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKyyR-0003Su-0N for v6ops-data@psg.com; Sat, 15 Nov 2003 11:52:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKyyO-0003Sb-5J for v6ops@ops.ietf.org; Sat, 15 Nov 2003 11:52:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAFBq8011075; Sat, 15 Nov 2003 13:52:10 +0200 Date: Sat, 15 Nov 2003 13:52:08 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] In-Reply-To: <1c7701c3aaff$1830ce60$83848182@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 14 Nov 2003, JORDI PALET MARTINEZ wrote: > Why you keep going with 5 and 6 if 1 is clear ? You asked about parallel work: > > While I agree in the importance of the analysis word, and I try to spend > > some of my time on it, there is nothing in the charter that doesn't > > allow to continue other works in parallel, that doesn't define new > > transition mechanism. By the way, I'm still waiting your reply on this > > to my previous email. and I responded. > You insist in the charter, and I'm reading the charter, starting with 1 ... At least without major modifications, I do not see this draft to belong under 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 Sat Nov 15 06:58:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05481 for ; Sat, 15 Nov 2003 06:58:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKz2Q-0004Hr-8D for v6ops-data@psg.com; Sat, 15 Nov 2003 11:56:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKz2O-0004GM-H0 for v6ops@ops.ietf.org; Sat, 15 Nov 2003 11:56:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAFBuE711110; Sat, 15 Nov 2003 13:56:14 +0200 Date: Sat, 15 Nov 2003 13:56:14 +0200 (EET) From: Pekka Savola To: Fred Templin cc: JORDI PALET MARTINEZ , Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] In-Reply-To: <3FB53E67.7010805@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 14 Nov 2003, Fred Templin wrote: > Then, let's have ISATAP as a WG item; it's been around for three > years and there is nothing premature about that. (Better yet would > be to just go ahead and publish it NOW.) We don't yet know whether we need ISATAP. We don't yet know where we would need ISATAP, if we needed it. Thus, if we took it up, we would not know where to develop it. I.e., there should not be a tool without clear purpose. Therefore starting to work on ISATAP would be premature, even though it has been under individual specification for a long time now. We just have to know where and how to use the mechanisms before getting down the path of working on them. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat Nov 15 07:25:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05977 for ; Sat, 15 Nov 2003 07:25:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKzS7-0008l1-D4 for v6ops-data@psg.com; Sat, 15 Nov 2003 12:22:59 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKzS3-0008ko-FX for v6ops@ops.ietf.org; Sat, 15 Nov 2003 12:22:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAFCMpX11548; Sat, 15 Nov 2003 14:22:51 +0200 Date: Sat, 15 Nov 2003 14:22:51 +0200 (EET) From: Pekka Savola To: jordi.palet@consulintel.es cc: v6ops@ops.ietf.org Subject: palet-v6ops-proto41-nat-03 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, I wrote up my comments on palet-v6ops-proto41-nat-03 on the plane. HTH. substantial ----------- 1) too proactive, e.g. the last 3 paragraphs of the abstract etc. -- if the goal is to document the mechanism, this needs rewording. 2) there is no clear description whether bidirectional NATs also work in traditional/outbound NAT way unless explicitly configured? This would be a huge benefit, as outbound NATs don't need to be configured to be used. 3) 6to4 interoperability requires more discussion. One should spell out that the NAT box would have to act as a 6to4 router; or were you suggesting that the NAT box would somehow blindly look at inside the packet and look at the destination address part? FWIW, why would the two methods need to co-exist? The NAT box could support both, but have only one mechanism enabled at a time? This way the vendor doesn't have to take a stance which method to choose for implementing/enabling -- it could do both 6to4 and proto-41 forwarding.. 4) you seem to be recommending implementing bidirectional NAT and the manual configs at the end of section 5. I don't think this is useful advice. It's better that the NAT boxes are stupid devices, and don't have to bastardize the users w/ DNS-ALG as well: In addition, considering that the code changes needed to support a full bidirectional NAT will be minimum, this option should also be considered, at least as a configurable option, in an easy way by the user (very simple http interface). ==> (also note:) s/minimum/minimal/, s/in an easy way by/as an easy way to/ ? According to that the tunnel broker must properly create the script or configuration file that will setup the client tunnel endpoint. In that case they should have requested the public addresses (can be automatically detected) and the local interface ID or name of the tunnel client. ==> tunnel brokers are not required to have "scripts", reword this section to be a bit more generic? 5) note that when a user is behind a NAT today, I don't think IPv6 should be enabled: 1) automatically without user intervention (and resulting warnings), or 2) a default firewall configuration which gives NAT-like ("everything out/nothing in") properties .. this would mitigate the risks of unknowingly punching through NATs.. I don't think the security threat in the third paragraph of the security considerations is a relevant or real one -- similar is already possible. That could be removed.. 6) I don't think the document describes that this method won't work if a second node behind the NAT starts using proto-41 forwarding correct? semi-substantial ----------------- Abstract ==> the abstract must not have references, and it should be shorter; single paragraph of some 5-15 (or thereabouts) lines. 1. Introduction Most of the existing solutions for the transition to IPv6 rely in tunnels assuming that the client end-point is an IPv6 capable router. However, nowadays the installed base of IPv4-only NAT boxes/routers is still quite big, while most of the client operating systems already support IPv6. Some IPv4-only NAT boxes/routers allow the establishment of IPv6 tunnels from systems in the private LAN (using private IPv4 addresses) to routers or tunnel servers in the public Internet. ==> one should beef up this "mini-problem statement" a bit; note that proto-41 is not a prerequisite for tunneling, one could use e.g. UDP. This document kind of makes that assumption. ==> the end-point must not be a router, but it must be v6 capable node, yes. ==> s/rely in/rely on/ This fact should be taken into consideration by tunnel broker implementations in future versions, in order to properly create the script in case the client is located in a private network. ==> which fact? describe in detail or refer to section 6? Note that e.g. running "scripts" is a tunnel broker implementation detail.. The document does not discuss how the local private network is organized, for example, in case the Tunnel Client is an IPv6 router providing IPv6 connectivity to other systems. The behavior in this case should be the same as any other IPv6 native network (that is using stateless or stateful autoconfiguration, or any other typical functionalities like Home Agent, etc). ==> this section seems to need rewording; the first part especially, and the last part starting from "This behaviour" or at least from "(that is" should be removed completely. RFC 2663 [5] distinguishes several types of NAT routers. This document focuses on how proto 41 forwarding works over the two most common types: Traditional NAT and NAPT. ==> what about the other types? Even if out-of-scope for this spec, some clearer statement is needed. different transport ports for each one. Entries in NAT table have the form [source IP address, source TCP/UDP port, target IP address, target TCP/UDP port]. Both types can be combined in the same NAT router. ==> and what about the others, like ICMP? To facilitate that, a default configuration could be defined. For example, in the case of simple NAT routers used in most SOHO accesses, the default configuration could include a pre-defined private network address for the LAN interface and a pre-defined private address for the host where all the proto-41 traffic is forwarded. ==> this kind of special config would seem like a bad idea. Some use net-10, some others, etc. There is no way such config could be useful.. 6to4 and Proto-41 forwarding can coexist in the same NAT box. In that case, an IPv6 over IPv4 packet received, will be forwarded to the private LAN only if the IPv6 destination does not belong to the local 6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, following 6to4 procedures. This fact avoids the problems created by mobile users when they visit a network that uses 6to4, in the case they have some automatic proto-41 setup. ==> do you mean that the NAT box is a 6to4 router (if so, say it!), or that the box somehow intercepts and decapsulates the packet (state more explicitly how to decapsulate and which 6to4 procedures)? ==> I'd also reword the last sentence. 8. References ==> split to Informative and Normative references. editorial --------- Internet Draft Jordi Palet Document: draft-palet-v6ops-proto41-nat-03.txt Cesar Olvera Consulintel Category: David Fernandez ==> s/Jordi/J./, s/Cesar/C./, etc. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. ==> no numbered references in the status of this memo are allowed the usual way is to finish the tunnel directly in a device with an IPv4 public address. ==> s/finish/terminate/ (similar elsewhere in the document, also "ending" has been used sometimes...) ==> s/an IPv4 public/a public IPv4/ Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. ==> these are not being used (and shouldn't be anyway), so you can remove this section | | Public IPv4 | | +-----+ | ==> the diagram has been muched up in two places, the '|''s are off-base.. Although this mechanism is not usable on all existing IPv4-only NAT boxes/routers, the large number of them that already support it gives an opportunity to rapidly deploy a huge number of IPv6 nodes and networks (in case the node behind the NAT is an IPv6 router) without the need of using or designing new transition mechanisms. ==> s/all/all the/ ==> I'd reword this as well, at least the start of the paragraph, after "boxes/routers".. 3.1 3.1 Traditional (or) Outbound NAT ==> remove extra "3.1" As stated in [5], “with a Bidirectional NAT, sessions can be ==> there are a few special weird chars like before "with" in the doc, also later in the document. Check these out. Btw, I'd recommend trying to remove the explicit DOS-style line breaks as well. What it is needed in our case is just the basic mechanism included in bi-directional NAT to statically associate one of the private ==> s/What it is needed in our case is just/It's required that/ In this way, all ingoing IPv6 over IPv4 traffic will be forwarded to ==> s/ingoing/incoming/ bidirectional way, even when no outgoing traffic is generated. IN ==> s/IN/In/ 6to4 and Proto-41 forwarding can coexist in the same NAT box. In that case, an IPv6 over IPv4 packet received, will be forwarded to the ==> s/an IPv6 over IPv4 packet received,/if an IPv6-over-IPv4 packet is received, it/ compatibility reasons (with existing network configurations), it could be still considered to maintain the support proto-41. ==> s/be still/still be/ -- 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 Nov 15 07:25:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06006 for ; Sat, 15 Nov 2003 07:25:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKzSy-0008v8-DB for v6ops-data@psg.com; Sat, 15 Nov 2003 12:23:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKzSv-0008uu-51 for v6ops@ops.ietf.org; Sat, 15 Nov 2003 12:23:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAFCNmZ11558 for ; Sat, 15 Nov 2003 14:23:48 +0200 Date: Sat, 15 Nov 2003 14:23:47 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6onbydefault-00 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk substantial ----------- 1) I think the document needs to be more specific about the scenarios where the different issues exist in, and what is the result of the fix (+remainder issues). That is, the document should also give a big picture of the different issues and how they connect with each other. I'm not sure about the best way to do it, but one thing to consider would be whether one could try to formulate a brief and concise problem statement (after the introduction to the issues etc.) of the problem. 2) Should the discussion of AI_ADDRCONFIG go in? If so, I might be able to try to hack up some text after done.. 3) I don't quite understand the last paragraph of section 2.1: Fixing the destination address selection mechanism by adding such a rule is only a mitigating factor if applications use standard name resolution API's that implement this mechanism, and these applications try addresses in the order returned. This may not be an acceptable assumption in some cases, as there are applications that use hard coded addresses and address search orders (DNS resolver is one example), and/or literal addresses passed in from the user. Such applications will obviously be subject to whatever connection delays are associated with attempting a connection to an unreachable destination. This is discussed in more detail in the next few sections. ==> first, destination address selection is done w/ getaddrinfo(), so if apps use that (after an added rule), they're OK (so, isn't the meaning of the first sentence reversed?) ==> isn't the DNS resolver implementation itself quite bit of a special case here? ==> last, I don't really understand the point about literal addresses; if the user specifies an address, he gives just one of them. It either works or doesn't; there is no selection among them. If the user gives the IPv6 address, the problem will be in ND, as an already documented problem. If the user gives the IPv4 address, it works. 4) This document contains a rather long description of on-link assumption issues. Could this be summarized a bit more, inserting a normative reference to the on-link assumption document? 5) I don't remember that the second paragraph of section 2.2.1 in the onlink document? I'm not sure if I understand the problem correctly: - if there is an entry in default router list, on-link assumption is not done, and all the packets w/o more specifics go to the router, and - if there is not an entry in the default router list, but there are more specific routes through a router, the on-link assumption is valid for the packets which do not match the more specific routes. This seems like the desired behaviour. Did I miss something? 6) Transport protocol robustness section has: It should abort a connection in those states when receiving any ICMPv6 Destination Unreachable message. It should make this distinction when a connection is in any other state. ==> shouldn't the should in the last sentence actually be "should not" ? ==> one should maybe consider the other protocols, such as UDP and SCTP here as well -- or at least list them as items for further study :-) ==> would it make sense to also discuss issues relating to blackhole problems, i.e., packets getting discarded somewhere without feedback e.g. using ICMP? There is pretty much nothing to do then, but that should probably be mentioned explicitly as an existing problem.. 7) 3.2.1 Dealing with Poor IPv6 Network Performance ... one other way to deal with this could be something like: Another approach could be to restrict IPv6 just to a smaller, better working address range, e.g., the internal network or nationally interconnected networks, but this can't be a long term solution. Regardless of whether the user selects a short-term fix to the problem, the first imperative should be working on enhancing the performance of IPv6. 8) The application robustness section should probably refer to the application transition guidelines, as it specifically describes this problem. This section can probably be reduced in length a bit. (note: s/connection results/connection may result) semi-substantial ---------------- Abstract This document discusses problems that can occur when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The problems include application connection delays, poor connectivity, and network security. Its purpose is to raise awareness of these problems so that they can be fixed or worked around. ==> there has been some confusion around this document at some point, so maybe could try to add something like (+Introduction too): The purpose of this document is not to try to specify whether IPv6 should be enabled by default or not, but to raise the awareness of the potential issues involved. .... Consider a scenario in which a dual stack system has IPv6 enabled and placed on a link with no IPv6 routers. The system is using IPv6 Stateless Address Autoconfiguration [AUTOCONF], so it only has a link-local IPv6 address configured. It also has a single IPv4 address that happens to be a private address as defined in [PRIVADDR]. ==> it would be useful if one could generalize a bit from this.. To allow applications to correctly fall back to IPv4 when IPv6 packets are destined beyond their allowed scope, the devices enforcing the scope boundary should send ICMPv6 Destination Unreachable messages back to senders of such packets. The sender's ==> s/should/must/ ? An example of such a situation is a node which obtains IPv4 connectivity natively through an ISP, but whose IPv6 connectivity is obtained through a configured tunnel whose other endpoint is topologically such that most IPv6 communication is done through triangular routes. Operational experience on the 6bone shows that ==> s/triangular routes/triangular IPv4 topology/ ? A similar problem could exist for VPN software. A VPN could protect all IPv4 packets but drop all others onto the local subnet unprotected. At least one widely used VPN behaves this way. This is ==> you use a very unusual meaning for the word "drop". Consider rewording.. :-) The VPN doesn't know about IPv6, so instead of protecting the packets and sending them to the remote end of the VPN, it passes such packets in the clear to the local network. ==> note that the packets end up in the local network only if there is the on-link assumption, or someone hijacking the traffic through advertising a prefix, right? 3.3.1 Mitigating Security Risks Establishing a security policy that is the same for IPv4 and IPv6 would help mitigate this risk. ==> I'd state that a bit differently. The most important thing is that a conscious decision has been made about the policy, and the policy is not breached. It *could* be OK to specify that IPv6 is different as well.. so consider rewording to like: The security policy must take a stance whether it applies equally to both IPv4 and IPv6 traffic; the most important thing is to be aware of the problem. However, having a similar policy is probably desirable. 5. Security Considerations This document raises security concerns in Section 3.3. ==> this needs improvement, but may be good enough for now.. editorial --------- ==> one should probably consider using the compact option of xml2rfc, especially because the sections at the end are very short. Dual Stack IPv6 on by Default ==> s/Dual/Issues with Dual/ ? depends on security policy enforced somewhere else on the network (such as from a firewall), then there is potential for new attacks ==> s/from/in/ -- 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 Nov 15 07:26:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06055 for ; Sat, 15 Nov 2003 07:26:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKzTn-0008yZ-3c for v6ops-data@psg.com; Sat, 15 Nov 2003 12:24:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKzTk-0008xK-Aw for v6ops@ops.ietf.org; Sat, 15 Nov 2003 12:24:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAFCOdw11568 for ; Sat, 15 Nov 2003 14:24:39 +0200 Date: Sat, 15 Nov 2003 14:24:39 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: onlinkassumption-00 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk substantial ----------- 1) I believe the document should try to say more clearly in which practical scenarios this problem at least surfaces at, like in the abstract (and similar in the introduction): 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. to: 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 is particularly problematic with IPv6-capable nodes which do not have IPv6 connectivity, e.g., a default router. 2) this is not so relevant for this particular draft, but maybe for the generic on-by-default document: The unreachability determination for a destination as it pertains to this rule is an implementation detail. One implementable method is to do a simple forwarding table lookup on the destination, and to deem the destination as reachable if the lookup succeeds. ==> the interesting question is, how would this work without an on-link assumption? For example, if default route would exist, but the router would go down, would a destination be considered unreachable if the Neighbor Discovery goes into a state where it's clear the destination is not reachable? For that matter, I wonder how that info would be passed down to getaddrinfo in libc in any case... :-/ 3) The SEND threat could very well be moved under section 3 as a subsection of its own? semi-editorial -------------- on-link until at least address resolution has failed, which is no less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER) ==> isn't this four seconds, i.e., (MAX_MULTICAT_SOLICIT + 1) * RETRANS_TIMER .. remember that the last retransmission attempt has to time out as well before giving up ? 2. Attempt to resolve the destination on every link. If the destination is indeed on-link, the first option may not succeed since the wrong link could be picked. The second option would always succeed in reaching the destination (assuming that it's reachable) but is more complex to implement. ==> the good question would be what would happen if the address was resolved on two links and there was a response from both! duplicating the packet, picking one etc. -- doesn't really work! 4. Conclusion ==> instead of just deleting everything related to the on-link assumption, it may be reasonable to suggest some summary of the problems or that in previous versions of the specification, the behaviour was different.. But that's likely to be ironed out with IPv6 WG. ... 5. Security Considerations VPN case ==> does this (the cisco vpn issue?) need more elaboration here? editorial --------- ==> there are so many empty lines here, so I suggest using the "compact" mode of xml2rfc (if that's what you're using). Internet-Draft On-Link Assumption August 2003 ==> I'd use a bit longer "Short name", like "On-Link Assumption Harmful" 2. Background ==> s/Background/Background to the Onlink Assumption/ For example, two systems that are manually configured with global addresses while on separate links are then plugged in back-to-back. They can still communicate with each other via their global addresses because they'll correctly assume that each is on-link. ==> is there something missing after "while ..." -- I can't quite parse this? least one reachable IPv4 address, the delay associated with NUD of ==> s/NUD/Neighbor Unreachability Detection (NUD)/ 4. Conclusion ==> s/Conclusion/Proposed Changes to RFC2461/ ? -- 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 Nov 15 07:34:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06331 for ; Sat, 15 Nov 2003 07:34:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKzbH-000AOT-12 for v6ops-data@psg.com; Sat, 15 Nov 2003 12:32:27 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKzbC-000ANn-UP for v6ops@ops.ietf.org; Sat, 15 Nov 2003 12:32:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAFCWLj11720 for ; Sat, 15 Nov 2003 14:32:21 +0200 Date: Sat, 15 Nov 2003 14:32:21 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-07: (semi-)editorial issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Trying to give a final polish to the 3gpp analysis document, here are the editorial-ish modifications I wrote up. I don't think there should be too many objections to these, so I didn't bother to separate them out individually. More substantive ones coming.. semi-substantial ---------------- 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes. It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE activates the appropriate PDP context depending on the type of application it has started or depending on the address of the peer host it needs to communicate with. ==> I think it would be useful to state that (because PDP context activation is a time-consuming process) it might make sense to activate both PDP context in advance, just in case they're used, as long as there are any applications for the opened PDP context? Maybe reword the last sentence and add a bit: If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may activate the appropriate PDP context depending on the type of application it has started; it may also make sense to open both PDP contexts in advance, before they are used, because the activation of a context may take a relatively long time. .. somehow I don't think activating PDP context based on the peer address is a realistic option right? If IPv6 PDP contexts are available and IPv6-in-IPv4 tunneling is needed, it is recommended to activate an IPv6 PDP context and perform tunneling in the network. This case is described in more detail in section 3.2. ==> I don't understand this at all. If IPv6 PDP context is available, it is available natively. The UE doesn't know about v6-in-v4 tunneling in the first place. So, isn't there some confusion here? Or did the text mean to say something like, "If both v6 or v4 can be used, v6 should be preferred"? Not sure if that's needed, but if so, consider e.g.: If an application can use both IPv4 and IPv6, and IPv6 PDP contexts are available, it is preferable to try IPv6 communication first. ... but this is already stated in the "As a general guideline..." -paragraph, so seems redundant? An application running on a UE can identify whether the endpoint is an IPv4 or IPv6 capable node by examining the destination address. Alternatively, if a user supplies a name to be resolved, the DNS may contain records sufficient to identify which protocol should be used to initiate the connection with the endpoint. In dual stack networks, one of the main concerns of an operator is the correct address space and routing management. The operator must maintain address spaces for both protocols. Public IPv4 addresses are often a scarce resource for the operator and typically it is not possible for a UE to have a globally unique IPv4 address (continuously) allocated for its use. Use of private IPv4 addresses means use of NATs when communicating with a peer node outside the operator's network. In large networks, NAT systems can become very complex, expensive and difficult to maintain. ==> I don't see a direct relation of this paragraph to the recommendations in this document: the first part describes (incorrectly) how to get the address of the peer; the second part describes dual-stack considerations; the last part describes IPv4 NAT's. I suggest removing it. The one thing that may make to preserve in some form is that the 3GPP operators typically use the private IPv4 addresses. semi-editorial -------------- can typically access both IPv4 and IPv6 services without additional translators in the network. However, it is good to remember that public IPv4 addresses are a scarce resource and in many cases IPv4 NATs are deployed. Public/global IP addresses are also needed for peer-to-peer services: the node needs a public/global IP address ==> s/a scarce resource/hard to come by/ (they aren't really scarce as such, but it takes just a huge amount of paperwork etc. to get them..) Note that this scenario is comparable to 6bone [6BONE] network operation. ==> remove this; 6bone is being run down for good, and no other alternative reference is out there. We can live without it.. 11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt ==> add here something like: [[ RFC-editor note: remove the section prior to publication ]] editorial --------- IMS scenarios are the following: - UE connecting to a node in an IPv4 network through IMS - Two IMS islands connected via IPv4 network ==> s/via/via an/ "In order to preserve name space continuity, the following administrative policies are RECOMMENDED: - every recursive DNS server SHOULD be either IPv4-only or dual stack, - every single DNS zone SHOULD be served by at least one IPv4 ==> here there seem to be some odd extra spaces etc. -- cut'n'paste error? In a 3GPP network, one IPv6 island can contain the GGSN while another island can contain the operator's IPv6 application servers. ==> s/can/may/ (twice) ? As a general guideline, IPv6-only UEs are not recommended in the early phases of transition until the IPv6 deployment has become so prevalent that direct ==> split to a new paragraph, starting from "As a gene..." On the user data transport level, the translation is IPv4-IPv6 protocol translation, where the user data traffic transported is translated from IPv6 to IPv4, and vice versa. ==> there should have been an empty line before this paragraph, missing somewhere? -- 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 Nov 15 14:16:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15756 for ; Sat, 15 Nov 2003 14:16:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL5pE-0003eT-FQ for v6ops-data@psg.com; Sat, 15 Nov 2003 19:11:16 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL5p9-0003bz-LC for v6ops@ops.ietf.org; Sat, 15 Nov 2003 19:11:11 +0000 Received: from consulintel02 ([65.214.230.64]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 11-md50000000077.tmp for ; Sat, 15 Nov 2003 20:11:57 +0100 Message-ID: <025d01c3abac$2726e190$40e6d641@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Date: Sat, 15 Nov 2003 13:10:34 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sat, 15 Nov 2003 20:11:57 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 65.214.230.64 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > At least without major modifications, I do not see this draft to = belong=20 > under 1). Based on what ? Quite a subjective observation, and I think is quite = wrong for a chair to take a subjective position. ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Saturday, November 15, 2003 5:52 AM Subject: Re: spending time on analysis [Re: = draft-palet-v6ops-proto41-nat-03 as WG item] > On Fri, 14 Nov 2003, JORDI PALET MARTINEZ wrote: > > Why you keep going with 5 and 6 if 1 is clear ? >=20 > You asked about parallel work: >=20 > > > While I agree in the importance of the analysis word, and I try to = spend > > > some of my time on it, there is nothing in the charter that = doesn't > > > allow to continue other works in parallel, that doesn't define new > > > transition mechanism. By the way, I'm still waiting your reply on = this > > > to my previous email. >=20 > and I responded. >=20 > > You insist in the charter, and I'm reading the charter, starting = with 1 ... >=20 > At least without major modifications, I do not see this draft to = belong=20 > under 1). >=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 Nov 15 14:27:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15922 for ; Sat, 15 Nov 2003 14:27:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL62z-00061r-AC for v6ops-data@psg.com; Sat, 15 Nov 2003 19:25:29 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL62t-00061C-Nn for v6ops@ops.ietf.org; Sat, 15 Nov 2003 19:25:24 +0000 Received: from consulintel02 ([65.214.230.64]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 21-md50000000077.tmp for ; Sat, 15 Nov 2003 20:26:11 +0100 Message-ID: <029901c3abae$23f2a6b0$40e6d641@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: palet-v6ops-proto41-nat-03 comments Date: Sat, 15 Nov 2003 13:24:48 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sat, 15 Nov 2003 20:26:11 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 65.214.230.64 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, Thanks a lot for your comments. Will start working on addressing them immediately, and will provide any = feekback or clarifications if needed. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: Cc: Sent: Saturday, November 15, 2003 6:22 AM Subject: palet-v6ops-proto41-nat-03 comments > Hi, >=20 > I wrote up my comments on palet-v6ops-proto41-nat-03 on the plane. = HTH. >=20 > substantial > ----------- >=20 > 1) too proactive, e.g. the last 3 paragraphs of the abstract etc. -- = if the > goal is to document the mechanism, this needs rewording. >=20 > 2) there is no clear description whether bidirectional NATs also work = in > traditional/outbound NAT way unless explicitly configured? This would = be a > huge benefit, as outbound NATs don't need to be configured to be used. >=20 > 3) 6to4 interoperability requires more discussion. One should spell = out > that the NAT box would have to act as a 6to4 router; or were you = suggesting > that the NAT box would somehow blindly look at inside the packet and = look at > the destination address part? >=20 > FWIW, why would the two methods need to co-exist? The NAT box could = support > both, but have only one mechanism enabled at a time? This way the = vendor > doesn't have to take a stance which method to choose for > implementing/enabling -- it could do both 6to4 and proto-41 = forwarding.. >=20 > 4) you seem to be recommending implementing bidirectional NAT and the = manual > configs at the end of section 5. I don't think this is useful advice. = It's > better that the NAT boxes are stupid devices, and don't have to = bastardize > the users w/ DNS-ALG as well: >=20 > In addition, considering that the code changes needed to support a > full bidirectional NAT will be minimum, this option should also be > considered, at least as a configurable option, in an easy way by = the > user (very simple http interface). >=20 > =3D=3D> (also note:) s/minimum/minimal/, s/in an easy way by/as an = easy way to/ > ? >=20 > According to that the tunnel broker must properly create the script > or configuration file that will setup the client tunnel endpoint. = In > that case they should have requested the public addresses (can be > automatically detected) and the local interface ID or name of the > tunnel client. >=20 > =3D=3D> tunnel brokers are not required to have "scripts", reword this = section > to be a bit more generic? >=20 > 5) note that when a user is behind a NAT today, I don't think IPv6 = should be > enabled:=20 > 1) automatically without user intervention (and resulting warnings), = or > 2) a default firewall configuration which gives NAT-like ("everything > out/nothing in") properties >=20 > .. this would mitigate the risks of unknowingly punching through = NATs.. >=20 > I don't think the security threat in the third paragraph of the = security > considerations is a relevant or real one -- similar is already = possible.=20 > That could be removed.. >=20 > 6) I don't think the document describes that this method won't work if = a > second node behind the NAT starts using proto-41 forwarding correct? >=20 >=20 >=20 > semi-substantial > ----------------- >=20 > Abstract >=20 > =3D=3D> the abstract must not have references, and it should be = shorter; single > paragraph of some 5-15 (or thereabouts) lines. >=20 >=20 > 1. Introduction >=20 > Most of the existing solutions for the transition to IPv6 rely in > tunnels assuming that the client end-point is an IPv6 capable = router. > However, nowadays the installed base of IPv4-only NAT boxes/routers > is still quite big, while most of the client operating systems > already support IPv6. >=20 > Some IPv4-only NAT boxes/routers allow the establishment of IPv6 > tunnels from systems in the private LAN (using private IPv4 > addresses) to routers or tunnel servers in the public Internet. >=20 > =3D=3D> one should beef up this "mini-problem statement" a bit; note = that > proto-41 is not a prerequisite for tunneling, one could use e.g. UDP. = This > document kind of makes that assumption. >=20 > =3D=3D> the end-point must not be a router, but it must be v6 capable = node, yes. > =3D=3D> s/rely in/rely on/ >=20 > This fact should be taken into consideration by tunnel broker > implementations in future versions, in order to properly create the > script in case the client is located in a private network. >=20 > =3D=3D> which fact? describe in detail or refer to section 6? Note = that e.g. > running "scripts" is a tunnel broker implementation detail.. >=20 > The document does not discuss how the local private network is > organized, for example, in case the Tunnel Client is an IPv6 router > providing IPv6 connectivity to other systems. The behavior in this > case should be the same as any other IPv6 native network (that is > using stateless or stateful autoconfiguration, or any other typical > functionalities like Home Agent, etc). >=20 > =3D=3D> this section seems to need rewording; the first part = especially, and the > last part starting from "This behaviour" or at least from "(that is" = should > be removed completely. >=20 > RFC 2663 [5] distinguishes several types of NAT routers. This > document focuses on how proto 41 forwarding works over the two most > common types: Traditional NAT and NAPT. >=20 > =3D=3D> what about the other types? Even if out-of-scope for this = spec, some > clearer statement is needed. >=20 > different transport ports for each one. Entries in NAT table have = the > form [source IP address, source TCP/UDP port, target IP address, > target TCP/UDP port]. Both types can be combined in the same NAT > router. >=20 > =3D=3D> and what about the others, like ICMP? =20 >=20 > To facilitate that, a default configuration could be defined. For > example, in the case of simple NAT routers used in most SOHO > accesses, the default configuration could include a pre-defined > private network address for the LAN interface and a pre-defined > private address for the host where all the proto-41 traffic is > forwarded. >=20 > =3D=3D> this kind of special config would seem like a bad idea. Some = use > net-10, some others, etc. There is no way such config could be = useful.. >=20 >=20 > 6to4 and Proto-41 forwarding can coexist in the same NAT box. In = that > case, an IPv6 over IPv4 packet received, will be forwarded to the > private LAN only if the IPv6 destination does not belong to the = local > 6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box, > following 6to4 procedures. This fact avoids the problems created by > mobile users when they visit a network that uses 6to4, in the case > they have some automatic proto-41 setup. >=20 > =3D=3D> do you mean that the NAT box is a 6to4 router (if so, say = it!), or that > the box somehow intercepts and decapsulates the packet (state more > explicitly how to decapsulate and which 6to4 procedures)? >=20 > =3D=3D> I'd also reword the last sentence. >=20 > 8. References >=20 > =3D=3D> split to Informative and Normative references. >=20 > editorial > --------- >=20 > Internet Draft Jordi Palet > Document: draft-palet-v6ops-proto41-nat-03.txt Cesar Olvera > Consulintel > Category: David Fernandez >=20 > =3D=3D> s/Jordi/J./, s/Cesar/C./, etc. >=20 > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026 [1]. >=20 > =3D=3D> no numbered references in the status of this memo are allowed >=20 > the usual way is to finish the tunnel directly in a device with an > IPv4 public address. >=20 > =3D=3D> s/finish/terminate/ (similar elsewhere in the document, also = "ending" > has been used sometimes...) > =3D=3D> s/an IPv4 public/a public IPv4/ >=20 >=20 > Conventions used in this document >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this > document are to be interpreted as described in RFC-2119 [4]. >=20 >=20 > =3D=3D> these are not being used (and shouldn't be anyway), so you can = remove > this section >=20 > | | > Public IPv4 | | > +-----+ | >=20 > =3D=3D> the diagram has been muched up in two places, the '|''s are = off-base.. >=20 > Although this mechanism is not usable on all existing IPv4-only NAT > boxes/routers, the large number of them that already support it = gives > an opportunity to rapidly deploy a huge number of IPv6 nodes and > networks (in case the node behind the NAT is an IPv6 router) = without > the need of using or designing new transition mechanisms. >=20 > =3D=3D> s/all/all the/ > =3D=3D> I'd reword this as well, at least the start of the paragraph, = after > "boxes/routers".. >=20 >=20 > 3.1 3.1 Traditional (or) Outbound NAT >=20 > =3D=3D> remove extra "3.1" >=20 > As stated in [5], "with a Bidirectional NAT, sessions can be >=20 > =3D=3D> there are a few special weird chars like before "with" in the = doc, also > later in the document. Check these out. Btw, I'd recommend trying to > remove the explicit DOS-style line breaks as well. >=20 > What it is needed in our case is just the basic mechanism included = in > bi-directional NAT to statically associate one of the private >=20 > =3D=3D> s/What it is needed in our case is just/It's required that/ >=20 > In this way, all ingoing IPv6 over IPv4 traffic will be forwarded to >=20 > =3D=3D> s/ingoing/incoming/ >=20 > bidirectional way, even when no outgoing traffic is generated. IN >=20 > =3D=3D> s/IN/In/ >=20 > 6to4 and Proto-41 forwarding can coexist in the same NAT box. In = that > case, an IPv6 over IPv4 packet received, will be forwarded to the >=20 > =3D=3D> s/an IPv6 over IPv4 packet received,/if an IPv6-over-IPv4 = packet=20 > is received, it/ >=20 > compatibility reasons (with existing network configurations), it=20 > could be still considered to maintain the support proto-41. >=20 > =3D=3D> s/be still/still be/ >=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 Nov 15 14:51:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16632 for ; Sat, 15 Nov 2003 14:51:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL6PC-000Ahn-Ob for v6ops-data@psg.com; Sat, 15 Nov 2003 19:48:26 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL6LJ-0009pR-Cc for v6ops@ops.ietf.org; Sat, 15 Nov 2003 19:44:25 +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); Sat, 15 Nov 2003 11:44:25 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 15 Nov 2003 11:44:25 -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); Sat, 15 Nov 2003 11:44:27 -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, 15 Nov 2003 11:44:23 -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, 15 Nov 2003 11:44:26 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.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: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Date: Sat, 15 Nov 2003 11:44:20 -0800 Message-ID: Thread-Topic: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Thread-Index: AcOrcQmHlD4qDGnCSnuhYhND1tcUHQALFCbg From: "Christian Huitema" To: "Pekka Savola" , "Fred Templin" Cc: "JORDI PALET MARTINEZ" , X-OriginalArrivalTime: 15 Nov 2003 19:44:26.0244 (UTC) FILETIME=[E0500440:01C3ABB0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On Fri, 14 Nov 2003, Fred Templin wrote: > > Then, let's have ISATAP as a WG item; it's been around for three > > years and there is nothing premature about that. (Better yet would > > be to just go ahead and publish it NOW.) >=20 > We don't yet know whether we need ISATAP. Correction. We very well know we do. In fact, we know it so much that there is actual deployment at many sites, and interoperable implementations by several vendors. You can only write that "we don't know" if you define knowledge in the very narrow sense of "we do not have a requirement document that explains why we absolutely cannot do without it." Let's go back to April 2002, when the IESG decided to close NGTRANS and to put a temporary stop to the definition of transition mechanisms. The feeling at the time was that having too many mechanisms would create confusion, and that we should only develop those mechanisms that correspond to a clear scenario.=20 That sounded logical, but the implementation of that idea in NGTRANS turned out to be terrible. The WG embarked in an exercise of defining a set of transition scenarios for various deployment areas, and the exercise proved both contentious and cumbersome. It took us about a year to agree on the first scenarios (3GPP and unmanaged), and we have yet to complete the ISP and enterprise scenario. The obvious explanation is that the world is very diverse, and trying to have a single document reflect everybody's ideas of a transition requires lengthy negotiations. The negotiations continue with the requirement documents, which may be even more contentious. The example of ISATAP is quite telling. It would be very easy to write a simple 2 paragraph document explaining how ISATAP can be used to provide IPv6 connectivity in an enterprise network as an overlay over the existing IPv4 infrastructure. We may not unanimously approve that this is needed, but we should never require unanimity in such cases. If there is a substantial constituency that approves the requirement, the IETF tradition is to acknowledge that the requirement exists. The V6OPS working group is a prime example of the current IETF decease: expanding a lot of energy to achieve no result. The symptom is very clear: vendors are shipping products based on internet drafts, without getting the benefits of IETF peer review.=20 I would propose one simple way to meet the "describe your scenario" requirement: ask anyone who proposes a transition technology to include in the draft a two paragraph description of what scenario the proposal is supposed to facilitate. The WG should then verify that there is some demand for the scenario, but should not require unanimity or even "rough consensus": just because someone believes I don't need something does not change my need for it. The role of the working group should be peer review: make sure that the proposal is well engineered and meets it stated requirement without causing harm. We must break the current analysis/paralysis. -- Christian Huitema From owner-v6ops@ops.ietf.org Sat Nov 15 15:16:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17499 for ; Sat, 15 Nov 2003 15:16:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL6nJ-000Ehg-Bh for v6ops-data@psg.com; Sat, 15 Nov 2003 20:13:21 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL6n8-000Eh8-SI for v6ops@ops.ietf.org; Sat, 15 Nov 2003 20:13:11 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA16564 for ; Sat, 15 Nov 2003 20:13:09 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 UAA05527 for ; Sat, 15 Nov 2003 20:13:08 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAFKD8x03113 for v6ops@ops.ietf.org; Sat, 15 Nov 2003 20:13:08 GMT Date: Sat, 15 Nov 2003 20:13:08 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Message-ID: <20031115201308.GI2471@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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Nov 15, 2003 at 11:44:20AM -0800, Christian Huitema wrote: > > I would propose one simple way to meet the "describe your scenario" > requirement: ask anyone who proposes a transition technology to include > in the draft a two paragraph description of what scenario the proposal > is supposed to facilitate. The WG should then verify that there is some > demand for the scenario, but should not require unanimity or even "rough > consensus": just because someone believes I don't need something does > not change my need for it. The role of the working group should be peer > review: make sure that the proposal is well engineered and meets it > stated requirement without causing harm. I agree with Christian's general sentiments. The 18 month navel-inspecting period has served no purpose other than to ensure that ISATAP, DSTM and Teredo have been commercially implemented and deployed, but without the IETF standardisation process behind them to help ensure interoperability between those implementations or indeed with other transition tools. This isn't a criticism of the design teams. Indeed the deployment scenarios are so broad (esp. for enterprise) that it is no surprise that only the most narrow of scenarios (3GPP) has been (nearly) completed. I don't see any reason why ISATAP, DSTM and Teredo could not be adopted as WG items and standardised using all the expertise of the V6 Ops WG minds, rather than being forced into implementation and deployment outside of the IETF, without WG input. Christian's solution seems sound. I would venture that we could consider accepting DSTM, ISATAP and Teredo as WG items (if the WG members agree) independently of the analysis, and then once finalised only put them to Proposed Standard once the need is agreed by analysis or by the WG. At least that way the mechanisms would be on the WG table, in the open for all to see and work on. I think it is the WG that should agree adoption of a mechanism. The problem has been that for 18 months the IESG has denied the WG that choice. Tim From owner-v6ops@ops.ietf.org Sat Nov 15 15:25:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18212 for ; Sat, 15 Nov 2003 15:25:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL6wL-000G6H-CT for v6ops-data@psg.com; Sat, 15 Nov 2003 20:22:41 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL6wG-000G5U-5p for v6ops@ops.ietf.org; Sat, 15 Nov 2003 20:22:36 +0000 Received: from consulintel02 ([65.214.230.64]) (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-md50000000077.tmp for ; Sat, 15 Nov 2003 21:23:23 +0100 Message-ID: <034701c3abb6$21db3ec0$40e6d641@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Date: Sat, 15 Nov 2003 14:22:00 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sat, 15 Nov 2003 21:23:23 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 65.214.230.64 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Probably I don't need to say that I fully agree ... but I can't shut up, = sorry ;-) In fact, I feel that will be good to heard in this list as many voices = as they support this. Regards, Jordi ----- Original Message -----=20 From: "Christian Huitema" To: "Pekka Savola" ; "Fred Templin" = Cc: "JORDI PALET MARTINEZ" ; = Sent: Saturday, November 15, 2003 1:44 PM Subject: RE: spending time on analysis [Re: = draft-palet-v6ops-proto41-nat-03 as WG item] > On Fri, 14 Nov 2003, Fred Templin wrote: > > Then, let's have ISATAP as a WG item; it's been around for three > > years and there is nothing premature about that. (Better yet would > > be to just go ahead and publish it NOW.) >=20 > We don't yet know whether we need ISATAP. Correction. We very well know we do. In fact, we know it so much that there is actual deployment at many sites, and interoperable implementations by several vendors. You can only write that "we don't know" if you define knowledge in the very narrow sense of "we do not have a requirement document that explains why we absolutely cannot do without it." Let's go back to April 2002, when the IESG decided to close NGTRANS and to put a temporary stop to the definition of transition mechanisms. The feeling at the time was that having too many mechanisms would create confusion, and that we should only develop those mechanisms that correspond to a clear scenario.=20 That sounded logical, but the implementation of that idea in NGTRANS turned out to be terrible. The WG embarked in an exercise of defining a set of transition scenarios for various deployment areas, and the exercise proved both contentious and cumbersome. It took us about a year to agree on the first scenarios (3GPP and unmanaged), and we have yet to complete the ISP and enterprise scenario. The obvious explanation is that the world is very diverse, and trying to have a single document reflect everybody's ideas of a transition requires lengthy negotiations. The negotiations continue with the requirement documents, which may be even more contentious. The example of ISATAP is quite telling. It would be very easy to write a simple 2 paragraph document explaining how ISATAP can be used to provide IPv6 connectivity in an enterprise network as an overlay over the existing IPv4 infrastructure. We may not unanimously approve that this is needed, but we should never require unanimity in such cases. If there is a substantial constituency that approves the requirement, the IETF tradition is to acknowledge that the requirement exists. The V6OPS working group is a prime example of the current IETF decease: expanding a lot of energy to achieve no result. The symptom is very clear: vendors are shipping products based on internet drafts, without getting the benefits of IETF peer review.=20 I would propose one simple way to meet the "describe your scenario" requirement: ask anyone who proposes a transition technology to include in the draft a two paragraph description of what scenario the proposal is supposed to facilitate. The WG should then verify that there is some demand for the scenario, but should not require unanimity or even "rough consensus": just because someone believes I don't need something does not change my need for it. The role of the working group should be peer review: make sure that the proposal is well engineered and meets it stated requirement without causing harm. We must break the current analysis/paralysis. -- Christian Huitema ********************************** 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 Nov 15 15:28:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18393 for ; Sat, 15 Nov 2003 15:28:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL6zd-000GcX-MZ for v6ops-data@psg.com; Sat, 15 Nov 2003 20:26:05 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL6zZ-000Gbw-5q for v6ops@ops.ietf.org; Sat, 15 Nov 2003 20:26:01 +0000 Received: from consulintel02 ([65.214.230.64]) (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-md50000000077.tmp for ; Sat, 15 Nov 2003 21:26:48 +0100 Message-ID: <035101c3abb6$9c35b970$40e6d641@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20031115201308.GI2471@login.ecs.soton.ac.uk> Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Date: Sat, 15 Nov 2003 14:25:26 -0600 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sat, 15 Nov 2003 21:26:48 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 65.214.230.64 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,WHY_WAIT autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I'm not sure if the problem has been the IESG, the AD, the chairs or the = WG itself, probably all of us. Now the WG at least has the option to speak up (some of us are already = doing it) ... so what are you waiting for folks ? Regards, Jordi ----- Original Message -----=20 From: "Tim Chown" To: Sent: Saturday, November 15, 2003 2:13 PM Subject: Re: spending time on analysis [Re: = draft-palet-v6ops-proto41-nat-03 as WG item] > On Sat, Nov 15, 2003 at 11:44:20AM -0800, Christian Huitema wrote: > >=20 > > I would propose one simple way to meet the "describe your scenario" > > requirement: ask anyone who proposes a transition technology to = include > > in the draft a two paragraph description of what scenario the = proposal > > is supposed to facilitate. The WG should then verify that there is = some > > demand for the scenario, but should not require unanimity or even = "rough > > consensus": just because someone believes I don't need something = does > > not change my need for it. The role of the working group should be = peer > > review: make sure that the proposal is well engineered and meets it > > stated requirement without causing harm. >=20 > I agree with Christian's general sentiments. >=20 > The 18 month navel-inspecting period has served no purpose other than = to=20 > ensure that ISATAP, DSTM and Teredo have been commercially implemented = and=20 > deployed, but without the IETF standardisation process behind them to = help=20 > ensure interoperability between those implementations or indeed with = other=20 > transition tools. >=20 > This isn't a criticism of the design teams. Indeed the deployment = scenarios > are so broad (esp. for enterprise) that it is no surprise that only = the > most narrow of scenarios (3GPP) has been (nearly) completed. =20 >=20 > I don't see any reason why ISATAP, DSTM and Teredo could not be = adopted > as WG items and standardised using all the expertise of the V6 Ops WG = minds,=20 > rather than being forced into implementation and deployment outside of = the=20 > IETF, without WG input. >=20 > Christian's solution seems sound. I would venture that we could = consider > accepting DSTM, ISATAP and Teredo as WG items (if the WG members = agree) > independently of the analysis, and then once finalised only put them = to=20 > Proposed Standard once the need is agreed by analysis or by the WG. = At=20 > least that way the mechanisms would be on the WG table, in the open = for all=20 > to see and work on.=20 >=20 > I think it is the WG that should agree adoption of a mechanism. The = problem=20 > has been that for 18 months the IESG has denied the WG that choice. >=20 > Tim > ********************************** 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 Nov 15 20:12:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27706 for ; Sat, 15 Nov 2003 20:12:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALBMB-0006zE-GL for v6ops-data@psg.com; Sun, 16 Nov 2003 01:05:39 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALBM8-0006xY-3b for v6ops@ops.ietf.org; Sun, 16 Nov 2003 01:05:36 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id DF438415F09; Sat, 15 Nov 2003 20:05:27 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 3C87F7324A; Sat, 15 Nov 2003 20:05:27 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: "Pekka Savola" , v6ops@ops.ietf.org Date: Sun, 16 Nov 2003 06:35:27 +0530 X-Sasl-Enc: ahlvdk37jYkyGq7h8TzRKA 1068944727 Subject: Re: onlinkassumption-00 comments References: In-Reply-To: Message-Id: <20031116010527.3C87F7324A@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 15 Nov 2003 14:24:39 +0200 (EET), "Pekka Savola" said: > > on-link until at least address resolution has failed, which is no > less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER) > > ==> isn't this four seconds, i.e., (MAX_MULTICAT_SOLICIT + 1) * > RETRANS_TIMER .. remember that the last retransmission attempt has to > time out as well before giving up ? There is no delay before sending the first one, and for each NS (MAX_MULTICAST_SOLICIT in number) there is a RETRANS_TIMER wait. Hence, it will be (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). CP From owner-v6ops@ops.ietf.org Sat Nov 15 23:36:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04061 for ; Sat, 15 Nov 2003 23:36:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALEZv-000BdJ-HW for v6ops-data@psg.com; Sun, 16 Nov 2003 04:32:03 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALEZt-000Bd1-Jb for v6ops@ops.ietf.org; Sun, 16 Nov 2003 04:32:01 +0000 Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2003 20:32:34 -0800 Received: from SSENTHIL-W2K1.cisco.com ([10.32.254.221]) by sj-core-3.cisco.com (8.12.6/8.12.6) with SMTP id hAG4VrrY009654; Sat, 15 Nov 2003 20:31:57 -0800 (PST) Message-Id: <4.3.2.7.2.20031115151613.01f5a900@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 15 Nov 2003 20:31:52 -0800 To: "Christian Huitema" From: Senthil Sivakumar Subject: RE: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Cc: "Pekka Savola" , "Fred Templin" , "JORDI PALET MARTINEZ" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 11:44 AM 11/15/2003 -0800, Christian Huitema wrote: > > On Fri, 14 Nov 2003, Fred Templin wrote: > > > Then, let's have ISATAP as a WG item; it's been around for three > > > years and there is nothing premature about that. (Better yet would > > > be to just go ahead and publish it NOW.) > > > > We don't yet know whether we need ISATAP. > >Correction. We very well know we do. In fact, we know it so much that >there is actual deployment at many sites, and interoperable >implementations by several vendors. You can only write that "we don't >know" if you define knowledge in the very narrow sense of "we do not >have a requirement document that explains why we absolutely cannot do >without it." This is true for almost all of the proposed transition mechanisms. There are implementations and deployments. >The example of ISATAP is quite telling. It would be very easy to write a >simple 2 paragraph document explaining how ISATAP can be used to provide >IPv6 connectivity in an enterprise network as an overlay over the >existing IPv4 infrastructure. We may not unanimously approve that this >is needed, but we should never require unanimity in such cases. If there >is a substantial constituency that approves the requirement, the IETF >tradition is to acknowledge that the requirement exists. The WG is taking second and third looks on the transition mechanisms proposed and as I see there is a process of elimination going on.. By the time this WG is done, there would not be any more transition mechanisms and we would have to start from scratch.. >I would propose one simple way to meet the "describe your scenario" >requirement: ask anyone who proposes a transition technology to include >in the draft a two paragraph description of what scenario the proposal >is supposed to facilitate. The WG should then verify that there is some >demand for the scenario, but should not require unanimity or even "rough >consensus": just because someone believes I don't need something does Not seeking even rough consensus is a bad idea. It would lead to anyone developing anything that they want with the blessings of IETF and that is bad for the IETF and the industry. It does not have to be a unanimous decision but at least a rough consensus should be sought. Senthil >not change my need for it. The role of the working group should be peer >review: make sure that the proposal is well engineered and meets it >stated requirement without causing harm. > >We must break the current analysis/paralysis. > >-- Christian Huitema From owner-v6ops@ops.ietf.org Sun Nov 16 20:51:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14753 for ; Sun, 16 Nov 2003 20:51:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALYPC-0006rs-Jq for v6ops-data@psg.com; Mon, 17 Nov 2003 01:42:18 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALYOu-0006qi-IX for v6ops@ops.ietf.org; Mon, 17 Nov 2003 01:42:00 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 0610041E00B for ; Sun, 16 Nov 2003 20:39:20 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 4D8CD7E796; Sun, 16 Nov 2003 20:39:19 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Mon, 17 Nov 2003 07:09:19 +0530 X-Sasl-Enc: Ir4f5vWAU9VjafF37kpAjg 1069033159 Subject: Comments on unman-scenarios-03 Message-Id: <20031117013919.4D8CD7E796@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Few comments on the unman-scenarios-03 draft. CP High-Level ---------- 1. None of the cases consider a dual-stack gateway that is connected to the ISP. # [Host1]----------v # [Gateway]------[Gateway]------------[ISP] # [Host2]----------^ | # | # | # [Host3]-------------------------+ Internal gateways may be IPv4-only, or dual-stack or IPv6 only. I think some general text should be mentioned about connectivity, naming, and application support in hosts that are located behind an internal gateway (IPv4-only, dual, and IPv6-only) for each of the cases. For example, in case C, if the network has an IPv4 only gateway, then it might not be possible certain local applications on the hosts behind this gateway. 2. All hosts that have static (IPv6) addresses can host servers. With that in mind, I think the text related to server applications in case A should be modified. The current text reads, ,---- | Server applications are also not a primary focus of Case A. Server | applications require DNS support, which is difficult to engineer for | clients located behind a NAT, which is likely to be present in this | case. Besides, server applications at present cater mostly to IPv4 | clients; putting up an IPv6-only server is not very attractive. `---- As long as the IPv6 host has a static address, the ease/difficulty of providing DNS support will be similar to case B or C. The other assumption regarding attractiveness will not hold true if the global scenario is that the unmanaged network is late in getting IPv6 support, and the rest (or a large part) of the world is already using IPv6. Semi-editorial -------------- 3. ,---- | Deploying servers usually requires providing each server with a | stable DNS name, and associating a global IPv4 address with that | name, whether the address be that of the server itself or that of | the router acting as a firewall or NAT. Since updating DNS is a | management task, it falls somewhat outside the scope of an unmanaged | network. On the other hand, it is also possible to use out-of-band | techniques (such as cut-and-paste into an instant message system) to | pass around the address of the target server. `---- I think for the purposes of this document, and the companion (eval) document, updating DNS should not be considered as a management task whose scope is outside the scope of an unmanaged network. In my opinion the availability of stable addresses, and broadband will actually trigger the demand to simplify the infrastructure needed to host servers in home networks. I propose s/Since updating DNS is a management task, it falls somewhat outside the scope of an unmanaged network.// 4. ,---- | As we transition to IPv6, we must meet the requirements of the | various applications, which we can summarize in the following way: | applications that used to work well with IPv4 should continue | working well during the transition; it should be possible to use | IPv6 to deploy new applications that are currently hard to deploy in | IPv4 networks; and the deployment of these IPv6 applications should | be simple and easy to manage, but the solutions should also be | robust and secure. `---- Few requirements are missing: a) During the transition applications must work well with with both IPv4 and IPv6 networks to ease application deployment. b) Interworking may have to be defined for applications that will execute on IPv4-only networks, and IPv6-only networks. (I am unable to phrase this one properly). For example, a p2p application on a IPv4 only network may want to interact with a peer on a IPv6 network. For this interworking technology, and gateways have to be developed. 3. ,---- | Client applications require global connectivity. In an IPv6 network, | we would expect the client to use a global IPv6 address, which will | have to remain stable for the duration of the client-server session. `---- The second sentence "In an IPv6 network..." seems out of place. This section is list requirements of client applications in home networks (independent of the network technology). The second sentence can probably be replaced with: "Client applications need a global address that will remain stable for the duration of the client-server session." 4. ,---- | Many servers try to look up a DNS name associated to the IP address | of the client. In an IPv4 network, this IP address will often be | allocated by the Internet service provider to the gateway, and the | corresponding PTR record will be maintained by the ISP. In many | cases, these PTR records are perfunctory, derived in an algorithmic | fashion from the IPv4 address; the main information that they | contain is the domain name of the ISP. Whether or not an equivalent | function should be provided in an IPv6 network is unclear. `---- It might help to appreciate the last sentence better, if it is mentioned that even though few servers do a reverse lookup, there are many IPv4 ISP's that do not provide reverse lookup databases. 5. Section 4.3 Naming requirements for P2P applications are not mentioned. 6. ,---- | Private conversations by one of the authors with developers of peer- | to-peer applications suggest that many would be willing to consider | an "IPv6-only" model if they can get two guarantees: | | 1) That there is no regression from IPv4, i.e. that all customers | who could participate in a peer-to-peer application using IPv4 | can also be reached by IPv6. | | 2) That IPv6 provides a solution for at least some of their hard | problems, e.g. enabling peers located behind an IPv4 NAT to | participate in a peer-to-peer application. `---- This text can be removed/reworded. Point 1, is already covered in the requirement summary in beginning of section 4. Point 2, can be reworded, and merged with the first paragraph in this section (Requirements of peer-to- peer applications). 7. [DNSOPV6] has expired, and if a new version is not going to be released, relevant parts of that draft should be moved to this document. Probably section 5.2.2 should mention that if a DNS server is being deployed in the network then it should accessible over both IPv4, and IPv6. 8. ,---- | Network level translation poses similar problems: in practice, | network level actions must be complemented by "application layer | gateways" that will rewrite references to IP addresses in the | protocol, and while these relays are not necessary for every | application, they are necessary for enough applications to make any | sort of generalized translation quite problematic; hosts may need to | be parameterized to use the translation service; and designing the | right algorithm to decide when to translate DNS requests has proven | very difficult. `---- I don't quite follow "the right algorithm to decide when to translate DNS requests". Is there any reference, or has this issue been discussed in the past? 9. ,---- | Not assuming translation services in the network appears to be both | more practical and more robust. If the market requirement for a new | device requires that it interact with both IPv4 and IPv6 hosts, we | may expect the manufacturers of these devices to program them with a | dual stack capability; in particular, we expect general purpose | systems such as personal computers to be effectively dual-stack. `---- Instead of using the words "device", "device interaction with hosts", "client", and "server applications" should be used as this section takls of these applications, The paragraph can be rephrased to : "Not assuming translation services in the network appears to be both more practical and more robust. If the market requirement for a new application requires that it interact with both IPv4 and IPv6 hosts, we may expect the developers of these applications to program them with support for both IPv4, and IPv6. Hence, the devices that are expected to run these applications will have to be dual-stack." 10. Section 5.2.2 ,---- | In Case B, the upgraded gateway will act as an IPv6 router; it | will... `---- Should it not be: "In Case B, the upgraded gateway will act either as an IPv6 router, or as a ND proxy [NDPROXY]; it will..." 11. ,---- | several solutions will be assessed in a companion memo [EVAL]. `---- -or- ,---- | Possible solutions will be compared in the evaluation draft. `---- Such instances should be removed from the text, and the purpose of the [EVAL] document should be made clear in the Introduction. 12. Section 5.2.2 It would not hurt, if it is mentioned that the the type of IPv6 connectivity for the hosts is native. 13. ,---- | There are multiple solutions, including domain name delegation. `---- What are the other solutions? 14. ,---- | A delegation of some domain name is required in order to publish the | IPv6 addresses of servers in the DNS. `---- This point is suppossed to be different for case B, and case C. I am unable to see the difference. Both the cases require a domain name delegation. 15. ,---- | - the requirement that tunneling protocols used for IPv6 access over | IPv4 be designed for secure use `---- This requirement is more of a transition mechanism requirement, and less of an application requirement. I also could not find where this requirement is discussed. The only thing I could find is a general requirement for all solutions to be secure, which is listed in section 16. 17. ,---- | The security solutions currently used in IPv4 networks include a | combination of firewall functions in the gateway, authentication and | authorization functions in the applications, encryption and | authentication services provides by IP security, Transport Layer | Security and application specific services, and host-based security | products such as anti-virus software, and host firewalls. The | applicability of these tools in IPv6 unmanaged networks will be | studied in a companion document. `---- I think this one should be mentioned upfront in the Introduction section as it will help to clarify the scope of the document. Is the document mentioned in the last sentence published? Editorial --------- 18. ,---- | There are some cases in which the "gateway" is replaced by a layer-2 | bridge. In such deployments, the hosts have direct access to the ISP | service. In order to avoid lengthy developments, we will treat these | cases as if the gateway was not present, i.e. as if each host was | connected directly to the ISP. `---- I am unsure if word developments is correctly used. Plus, the text about connected directly to the ISP is repeated. I propose to rephrase the paragraph to: "There are some cases in which the "gateway" is replaced by a layer-2 bridge. In such deployments, the hosts have direct access to the ISP service, and the gateway is assumed to be absent." 19. Modify the section titles so that the words start with upper case. 20. ,---- | The application requirements for IPv6 Unmanaged Networks fall into | three general categories: connectivity, naming, and security. | Connectivity issues include the provision of IPv6 addresses and | their quality: do hosts need global addresses, should these `---- s/The application requirements/The requirements related to applications/ I was confused when I had initially read the first sentence. I could not make out if the sentence meant requirements of the network, or the requirements of the application. 4. Section 4.4 I am a bit lost...what does collateral effect mean? :-) 5. ,---- | In order to get some clarity, we distinguish three entities involved | in the transition of an unmanaged network: the ISP (possibly | including ISP consumer premise equipment (CPE)), the home gateway, | and the hosts (computers and appliances). Each can support IPv4- | only, both IPv4 and IPv6 or IPv6-only. That gives us 27 | possibilities. `---- Reword to "In order to get some clarity, we distinguish three entities involved in the transition of an unmanaged network: the ISP, the home gateway, and the hosts (computers and appliances). Each can support IPv4-only, both IPv4 and IPv6 or IPv6-only. This gives us 27 possibilities. Note, that ISP transition may also include the transition of the ISP provided home gateway, aka, CPE (Customer Premise Equipment)." 6. We describe the most important cases. We will assume that in all cases the hosts are a combination of IPv4-only, dual stack and (perhaps) IPv6- only hosts. s/(perhaps)// 7. ,---- | In fact, we can consider three non-NAT variants: directly connected | host; gateway acting as a bridge; and gateway acting as a non-NAT IP | router. `---- s/In fact, we can consider three non-NAT variants:/There are three types of non-NAT variants:/ 8. Section names of 5.x should be made consistent with the actual case name. For example, section 5.1 should be renamed to "Case A, gateway without IPv6 support". 9. ,---- | There are two variations of this case, depending on the type of | service implemented by the gateway. In many cases, the gateway is a | direct obstacle to the deployment of IPv6, but a gateway which is | some form of bridge-mode CPE or which is a plain (neither filtering | nor NAT) router does not really fall into this category. `---- Rephrase. Just to make it a bit more clear. "There are two variations of this case, depending on the type of service implemented by the gateway. In many cases, the gateway is a direct obstacle to the deployment of IPv6. In other cases, the gateway is some form of bridge-mode CPE or a plain (neither filtering nor NAT) router." 10. ,---- | If the local gateway provides global IPv4 addresses to the local | hosts, then these hosts can individually exercise the mechanisms | described in case C, "IPv6 connectivity without provider support." | If the local gateway implements a NAT function, another type of | mechanism is needed. The mechanism to provide connectivity to peers | behind NAT should be easy to deploy, and light weight; it will have | to involve tunneling over a protocol that can easily traverse NAT, | either TCP or preferably UDP, as tunneling over TCP can result in | poor performances in case of time-outs and retransmission. If | servers are needed, these servers will in practice have to be | deployed as part of the "support infrastructure" for the peer-to- | peer network or for an IPv6-based service; economic reality implies | that the cost of running these servers should be as low as possible. `---- The lines starting from "If servers are needed..." should be moved to 10.1.1. I am not sure what they are suppossed to convey. Maybe they can be removed. 11. ,---- | problems: first, one must develop relays for all applications; | second, one must develop a management infrastructure to provision | the host with the addresses of the relays; in addition, the | application may have to be modified if one wants to use the relay `---- s/; in addition/, and third/ 12. s/peer to peer/peer-to-peer/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Mon Nov 17 01:27:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20117 for ; Mon, 17 Nov 2003 01:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALcj0-000JMs-5Q for v6ops-data@psg.com; Mon, 17 Nov 2003 06:19:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALcin-000JM0-Iv for v6ops@ops.ietf.org; Mon, 17 Nov 2003 06:18:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAH6Ijw16254; Mon, 17 Nov 2003 08:18:46 +0200 Date: Mon, 17 Nov 2003 08:18:45 +0200 (EET) From: Pekka Savola To: Chirayu Patel cc: v6ops@ops.ietf.org Subject: Re: onlinkassumption-00 comments In-Reply-To: <20031116010527.3C87F7324A@server2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 16 Nov 2003, Chirayu Patel wrote: > > on-link until at least address resolution has failed, which is no > > less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER) > > > > ==> isn't this four seconds, i.e., (MAX_MULTICAT_SOLICIT + 1) * > > RETRANS_TIMER .. remember that the last retransmission attempt has to > > time out as well before giving up ? > > There is no delay before sending the first one, and for each NS > (MAX_MULTICAST_SOLICIT in number) there is a RETRANS_TIMER wait. Hence, > it will be (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). I mean, there has to be some delay after sending the first address resolution request (before the first retransmit). So the delay after initiating the retransmissions is 3 seconds, but there should be some delay before that as well, yes? -- 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 Nov 17 02:26:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03986 for ; Mon, 17 Nov 2003 02:26:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALdho-000Lpo-Rp for v6ops-data@psg.com; Mon, 17 Nov 2003 07:21:52 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALdhd-000LpM-3i for v6ops@ops.ietf.org; Mon, 17 Nov 2003 07:21:41 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 982A24210F7; Mon, 17 Nov 2003 02:21:39 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 7D8BC7E465; Mon, 17 Nov 2003 02:21:39 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: "Pekka Savola" Date: Mon, 17 Nov 2003 12:51:39 +0530 X-Sasl-Enc: 8O3S8nTyrSSLVC30wnvY0A 1069053699 Cc: v6ops@ops.ietf.org Subject: Re: onlinkassumption-00 comments References: In-Reply-To: Message-Id: <20031117072139.7D8BC7E465@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 17 Nov 2003 08:18:45 +0200 (EET), "Pekka Savola" said: > On Sun, 16 Nov 2003, Chirayu Patel wrote: > > > on-link until at least address resolution has failed, which is > > > no less than three seconds (MAX_MULTICAST_SOLICIT * > > > RETRANS_TIMER) > > > > > > ==> isn't this four seconds, i.e., (MAX_MULTICAT_SOLICIT + 1) * > > > RETRANS_TIMER .. remember that the last retransmission attempt has > > > to time out as well before giving up ? > > > > There is no delay before sending the first one, and for each NS > > (MAX_MULTICAST_SOLICIT in number) there is a RETRANS_TIMER wait. > > Hence, it will be (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). > > I mean, there has to be some delay after sending the first address ^^^^^^^^^^^^^^^^^^^^ The only delay will be for processing i.e. table lookup etc, and not a timer based delay. It will be negligible when compared to RETRANS_TIMER. So, for all practical purposes the aggregate delay will be (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). > resolution request (before the first retransmit). > > So the delay after initiating the retransmissions is 3 seconds, but > there should be some delay before that as well, yes? From owner-v6ops@ops.ietf.org Mon Nov 17 05:03:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07048 for ; Mon, 17 Nov 2003 05:03:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALgAK-0003go-1s for v6ops-data@psg.com; Mon, 17 Nov 2003 09:59:28 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALgA5-0003fp-Al for v6ops@ops.ietf.org; Mon, 17 Nov 2003 09:59:13 +0000 Received: from fakat.com (pc5205203.nac.telia.se [131.115.205.203]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id hAH9xrwN022994; Mon, 17 Nov 2003 10:59:54 +0100 (CET) (envelope-from jasko@fakat.com) Message-ID: <3FB89BE0.8080605@fakat.com> Date: Mon, 17 Nov 2003 10:58:56 +0100 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-07: (semi-)editorial issues References: In-Reply-To: X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > If an application can use both IPv4 and IPv6, and IPv6 PDP contexts are > available, it is preferable to try IPv6 communication first. > i don't like this 'try ipv6' paradigm. either ipv6 is there and is working without i need to try it, or it is not there and is not working. how many times do i have to try it before i will think it stinks and will stop trying and simply disable it and stick to ipv4? jasminko From owner-v6ops@ops.ietf.org Mon Nov 17 05:09:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07138 for ; Mon, 17 Nov 2003 05:09:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALgIL-0004AM-N9 for v6ops-data@psg.com; Mon, 17 Nov 2003 10:07:45 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALgI9-000490-T5 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 10:07:34 +0000 Received: from fakat.com (pc5205203.nac.telia.se [131.115.205.203]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id hAHA5hwN023017; Mon, 17 Nov 2003 11:05:44 +0100 (CET) (envelope-from jasko@fakat.com) Message-ID: <3FB89D3E.1010505@fakat.com> Date: Mon, 17 Nov 2003 11:04:46 +0100 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: pekkas@netcore.fi, v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] References: <20031114170156.CD5038A@coconut.itojun.org> In-Reply-To: <20031114170156.CD5038A@coconut.itojun.org> X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun, > thererefore, i'm thinking of submitting a draft which describes what > we (IIJ, AS2497) did to deploy IPv6 backbone as well as IPv6 services. > > before start writing stuff up, my question is: > - does it sound useful? > - doesn't it jeopadize ISP analysis/scenario effort, or is it okay to > have generalized analysis/scneario doc and specific-ISP doc in > parallel? > - if it is useful, can other ISP/enterprise/whatever do the similar > thing? > yes, that would be very useful. my question is: can your work somehow be combined as an example within the existing scenarios/solutions draft that the isp design team is working on? hopefully, what you have done will agree with what the team proposes and if that would not be the case, it would be interesting to see why/how theory and practice differ. jasminko From owner-v6ops@ops.ietf.org Mon Nov 17 05:29:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07444 for ; Mon, 17 Nov 2003 05:29:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALgaY-0005Kz-DX for v6ops-data@psg.com; Mon, 17 Nov 2003 10:26:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALgaM-0005KC-Aq for v6ops@ops.ietf.org; Mon, 17 Nov 2003 10:26:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHAQGG19074; Mon, 17 Nov 2003 12:26:17 +0200 Date: Mon, 17 Nov 2003 12:26:15 +0200 (EET) From: Pekka Savola To: Chirayu Patel cc: v6ops@ops.ietf.org Subject: Re: onlinkassumption-00 comments In-Reply-To: <20031117072139.7D8BC7E465@server2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Chirayu Patel wrote: > > > There is no delay before sending the first one, and for each NS > > > (MAX_MULTICAST_SOLICIT in number) there is a RETRANS_TIMER wait. > > > Hence, it will be (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). > > > > I mean, there has to be some delay after sending the first address > ^^^^^^^^^^^^^^^^^^^^ > > The only delay will be for processing i.e. table lookup etc, and not a > timer based delay. It will be negligible when compared to RETRANS_TIMER. > > So, for all practical purposes the aggregate delay will be > (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). Ok, we were talking past each other. I thought MAX_MULTICAST_SOLICIT was the number of _retransmissions_, but it already seems to include the first solicitation (which is not a retransmission but the original solicitation).. so we agree. -- 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 Nov 17 05:31:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07473 for ; Mon, 17 Nov 2003 05:31:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALgdG-0005Ru-7A for v6ops-data@psg.com; Mon, 17 Nov 2003 10:29:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALgcw-0005Qj-Ds for v6ops@ops.ietf.org; Mon, 17 Nov 2003 10:29:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHAS0a19083; Mon, 17 Nov 2003 12:28:00 +0200 Date: Mon, 17 Nov 2003 12:27:59 +0200 (EET) From: Pekka Savola To: Jasminko Mulahusic cc: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-07: (semi-)editorial issues In-Reply-To: <3FB89BE0.8080605@fakat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Jasminko Mulahusic wrote: > > If an application can use both IPv4 and IPv6, and IPv6 PDP contexts are > > available, it is preferable to try IPv6 communication first. > > i don't like this 'try ipv6' paradigm. either ipv6 is there and is > working without i need to try it, or it is not there and is not working. > how many times do i have to try it before i will think it stinks and > will stop trying and simply disable it and stick to ipv4? While I mostly agree with you say, could you reprase this in the sense that makes it clearer what you'd like to see in the document in this regard? -- 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 Nov 17 05:48:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07789 for ; Mon, 17 Nov 2003 05:48:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALgsk-0006Uu-Vy for v6ops-data@psg.com; Mon, 17 Nov 2003 10:45:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALgsY-0006TU-1m for v6ops@ops.ietf.org; Mon, 17 Nov 2003 10:45:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHAj7r19359; Mon, 17 Nov 2003 12:45:07 +0200 Date: Mon, 17 Nov 2003 12:45:06 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: v6ops@ops.ietf.org Subject: RE: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Senthil Sivakumar already replied about the same way I will but I'll try to respond anyway.. On Sat, 15 Nov 2003, Christian Huitema wrote: > Correction. We very well know we do. In fact, we know it so much that > there is actual deployment at many sites, and interoperable > implementations by several vendors. You can only write that "we don't > know" if you define knowledge in the very narrow sense of "we do not > have a requirement document that explains why we absolutely cannot do > without it." The latter is pretty close to what's written in our charter. We're not there to find uses for transition mechanisms. We're here to do only what must be done. > The V6OPS working group is a prime example of the current IETF decease: > expanding a lot of energy to achieve no result. The symptom is very > clear: vendors are shipping products based on internet drafts, without > getting the benefits of IETF peer review. Achieving no result is probably considered a bug rather than feature if one believes the IETF exists to provide peer review of the technologies the vendors wish to standardize. I don't. > I would propose one simple way to meet the "describe your scenario" > requirement: ask anyone who proposes a transition technology to include > in the draft a two paragraph description of what scenario the proposal > is supposed to facilitate. The WG should then verify that there is some > demand for the scenario, but should not require unanimity or even "rough > consensus": just because someone believes I don't need something does > not change my need for it. The role of the working group should be peer > review: make sure that the proposal is well engineered and meets it > stated requirement without causing harm. You can devise a use for every tool out there, and more besides. Writing such an applicability statement is trivial; a couple of years I made the case myself in a paper I wrote. But that doesn't mean those methods are necessary or useful. The main point of v6ops (AFAICS) is to show the folks how to start deploying IPv6 in the most common scenarios. It'd both act as a guide how to go on with it ("look, you can do X, you don't need Y"), and as a way to identify required transition mechanisms which will be necessary. > We must break the current analysis/paralysis. It would be much easier if more people did the work, instead of complained about the work not having any result... -- 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 Nov 17 06:17:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08296 for ; Mon, 17 Nov 2003 06:17:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALhLZ-0008Ow-Kq for v6ops-data@psg.com; Mon, 17 Nov 2003 11:15:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALhLM-0008NO-Jw for v6ops@ops.ietf.org; Mon, 17 Nov 2003 11:14:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHBEqL19705 for ; Mon, 17 Nov 2003 13:14:52 +0200 Date: Mon, 17 Nov 2003 13:14:52 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis: tunneling inside 3GPP operator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'd propose to resolve the issue of tunneling inside the 3GPP operator by rewording: Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their own don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they may provide an adequate solution depending on the design of the network and in presence of other router redundancy mechanisms. On the other hand, routing protocol based mechanisms can provide redundancy. to something like: Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their own don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they usually provide an adequate solution depending on the design of the network and in presence of other router redundancy mechanisms, such as the use of IPv6 routing protocols. ... because, IPv6 routing protocols do provide redundancy and ops folks use them all the time, and to make the last sentence a bit more crisp. Other than that, I don't have objections to this issue. -- 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 Nov 17 06:17:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08312 for ; Mon, 17 Nov 2003 06:17:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALhKH-0008JX-A7 for v6ops-data@psg.com; Mon, 17 Nov 2003 11:13:49 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALhK3-0008In-QT for v6ops@ops.ietf.org; Mon, 17 Nov 2003 11:13:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHBDYC19693 for ; Mon, 17 Nov 2003 13:13:34 +0200 Date: Mon, 17 Nov 2003 13:13:34 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis: Recommendation on tunneling in the UE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Having read the -07 document, I have some cooked up some text to make the related issues a bit clearer. The original: ==== However, the UE may attach to a 3GPP network, in which the Serving GPRS Support Node (SGSN), the GGSN, and the Home Location Register (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP contexts. This may happen in early phases of IPv6 deployment. If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism. The use of private IPv4 addresses in the UE depends on the support of these addresses by the tunneling mechanism and the deployment scenario. In some cases public IPv4 addresses are required, but if the tunnel endpoints are in the same private domain, or the tunneling mechanism works through IPv4 NAT, private IPv4 addresses can be used. One deployment scenario example is using a laptop computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and IPv4 PDP context is activated. The used tunneling mechanism (automatic or configured) in that case depends on the support of tunneling mechanisms in the laptop computer. ===== Consider rewording: ===== However, the UE may attach to a 3GPP network, in which the Serving GPRS Support Node (SGSN), the GGSN, and the Home Location Register (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP contexts. This may happen in early phases of IPv6 deployment. In theory, the user's own 3GPP operator might not support IPv6 at all. However, such scenario is considered out of scope of this document; the considerations for Unmanaged networks would apply [UNMANSCEN] [UNMANAN]. Presupposing some form of IPv6 support, there are two cases to consider when the visited network does not support IPv6 PDP contexts: 1. The UE is used as a "modem" with e.g. a laptop computer. The UE does not have to even support IPv6 PDP contexts, and all the transition issues are dealt with by the supporting equipment. 2. The UE is used independently, running IPv6 applications, and would desire IPv6 connectivity. In both cases, it may be desirable to be able to create a tunnel between the UE (or the supporting equipment) and the user's 3GPP operator's IPv6 equipment. A way to easily manage the setup of a simple configured tunnel would be sufficient, unless the basic IPv6 deployment in visited networks could be assumed and no tunneling would be needed at all. ======= as part of this, the "no tunneling mechanisms thing" should be added back to the security considerations in: ==== In particular, this memo does not recommend the following technique which has security issues, not further analyzed here: - NAT-PT or other translator as a generic-purpose transition mechanism, ==== ... I think this keeps the basic substance of the old text while trying to pin down more explicitly what the problems are. I explicitly defined "tunneling from the UE to the general Internet" out of scope... I don't think a complete non-support of v6 is a 3GPP scenario :-) However, instead of vague "tunneling is needed" statement, I put a more precise statement that a simple way to do configured tunnels would be enough. I may be biased :-). -- 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 Nov 17 06:20:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08347 for ; Mon, 17 Nov 2003 06:20:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALhOE-0008Xm-No for v6ops-data@psg.com; Mon, 17 Nov 2003 11:17:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALhO2-0008We-4Y for v6ops@ops.ietf.org; Mon, 17 Nov 2003 11:17:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHBHdw19745 for ; Mon, 17 Nov 2003 13:17:39 +0200 Date: Mon, 17 Nov 2003 13:17:39 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis: DNS over v4 if availablen Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Relating to the previous "Need for UE <-> 3GPP configuration" configuration issue (closed now), I'd maybe augment the text: DNS server addresses typically also need to be configured in the UE. In the case of IPv4 type PDP context, the (IPv4) DNS server addresses can be received in the PDP context activation (a control plane mechanism). Same kind of mechanism is also available for IPv6: so-called Protocol Configuration Options Information Element (PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible to use [DHCPv6-SL] or [RFC3315] and [DHCP-DNS] for receiving DNS server addresses. The authors note that the general IPv6 DNS discovery problem is being solved by the IETF dnsop Working Group. The DNS server addresses can also be received over the air (using SMS), or typed in manually in the UE. .. by adding a sentence at the end: Note that as long as IPv4 PDP context is active, DNS lookups can also be done over IPv4 transport. .. just to highlight the fact that w/ dual-stack UE deployment, not having v6 DNS is not necessary a big deal (yet!) -- 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 Nov 17 06:44:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08791 for ; Mon, 17 Nov 2003 06:44:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALhli-000A9a-SO for v6ops-data@psg.com; Mon, 17 Nov 2003 11:42:10 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALhlW-000A80-2e; Mon, 17 Nov 2003 11:41:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHBecJ20104; Mon, 17 Nov 2003 13:40:38 +0200 Date: Mon, 17 Nov 2003 13:40:38 +0200 (EET) From: Pekka Savola To: Suresh Satapati cc: "Karim El-Malki (HF/EAB)" , "'Randy Bush'" , Subject: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I hijacked the thread to bring up a point about IMS/SIP transition in the 3GPP analysis document as it is now.. On Fri, 14 Nov 2003, Suresh Satapati wrote: > This whole "subset applicability" argument stems from incorrect > assumption that NAT-PT (RFC 2766) mandates DNS-ALG. Maybe, maybe not.. > In the past for v4 land, ALGs have been specified in separate documents. > For e.g. RFC 2663/3022 clearly defines the role of "NAT", and for > DNS-ALG there is RFC 2694. Yes, but then again, you don't need DNS-ALG in the v4<->v4 NAT, because the destination address families are the same. On the other hand, you *do* need it in NAT-PT (or, you have to get the corresponding functionality in some other way, e.g. manual configuration). But that aside... The critical point, I think, is whether the 3GPP analysis about IMS interworking is written so that it recommends NAT-PT. Personally, I don't think we should do that. Instead, we should defer the problem to a SIP working group (SIPPING?) to figure out.. because *they* will be using SIP for interaction, and they know best which kind of solution they'd need (whether based on NAT-PT or something else). I don't think v6ops has the expertise to specify which method would be most appropriate in this SIP/IMS internetworking scenario. -- 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 Nov 17 07:53:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10209 for ; Mon, 17 Nov 2003 07:53:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALioC-000EGR-Ov for v6ops-data@psg.com; Mon, 17 Nov 2003 12:48:48 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALinx-000EDb-TC for v6ops@ops.ietf.org; Mon, 17 Nov 2003 12:48:34 +0000 Received: from fakat.com (pc5205203.nac.telia.se [131.115.205.203]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id hAHCmBwN023494; Mon, 17 Nov 2003 13:48:11 +0100 (CET) (envelope-from jasko@fakat.com) Message-ID: <3FB8C352.9060209@fakat.com> Date: Mon, 17 Nov 2003 13:47:14 +0100 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-07: (semi-)editorial issues References: In-Reply-To: X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > While I mostly agree with you say, could you reprase this in the sense > that makes it clearer what you'd like to see in the document in this > regard? > do we have to say anything? as i see it, this is nothing special to this document. if you still want something in the doc... i believe when both v4 and v6 are available, it is up to the application to decide which one to use. -------- If an application can use both IPv4 and IPv6, and both IPv4 and IPv6 PDP contexts are available, it is up to the application to make the decision which protocol it will use. -------- jasminko From owner-v6ops@ops.ietf.org Mon Nov 17 08:43:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11406 for ; Mon, 17 Nov 2003 08:43:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALjcG-000Htd-53 for v6ops-data@psg.com; Mon, 17 Nov 2003 13:40:32 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALjc2-000Hrp-Cm for v6ops@ops.ietf.org; Mon, 17 Nov 2003 13:40:18 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA01804 for ; Mon, 17 Nov 2003 13:40:16 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 NAA07725 for ; Mon, 17 Nov 2003 13:40:16 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAHDeGa02880 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 13:40:16 GMT Date: Mon, 17 Nov 2003 13:40:16 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] Message-ID: <20031117134016.GK2162@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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Nov 17, 2003 at 12:45:06PM +0200, Pekka Savola wrote: > > You can devise a use for every tool out there, and more besides. Writing > such an applicability statement is trivial; a couple of years I made the > case myself in a paper I wrote. But that doesn't mean those methods are > necessary or useful. I agree some level of analysis is very useful, both for specifics of the mechanisms, and how they interact with other mechanisms. But also the requirements on the whole architecture are important, e.g. Teredo and 6to4 both like talking to other Teredo or 6to4 systems respectively and would require a heavy investment in relays if they are to communicate with native IPv6 systems. I agree that ideally the WG needs to decide if certain tools are required from the analysis. But that result will depend on how the scenario document is phrased. For example, a scenario of dual-stack hosts in an IPv6-only infrastructure could quite reasonably lead to a DSTM-like solution. Likewise, the device-behind-a-NAT scenario could lead to a Teredo-like solution. The question then becomes what are valid scenarios, as any scenario can lead to a certain best (or only) solution. And how do we judge those solutions in the big picture (e.g. the requirement of wide-spread deployment of Teredo or 6to4 relays in ISP networks?). > The main point of v6ops (AFAICS) is to show the folks how to start > deploying IPv6 in the most common scenarios. It'd both act as a guide how > to go on with it ("look, you can do X, you don't need Y"), and as a way to > identify required transition mechanisms which will be necessary. I think the basic transition mechanism doc is fine, and we have basic tools for "structured" deployment - native, dual-stack, and (though loosely specified) tunnel brokers. It seems some of the reluctance to adopt certain tools has a tension between the "perfect transition" and the "reality now", as was reflected in the IAB/IESG Minneapolis presentation - do we define standards for the Internet, or standardise what is on the Internet? The "reality now" has quite widespread use of 6to4 (which is standardised) and Teredo (which is not), although both have loosely similar architectural implications. > It would be much easier if more people did the work, instead of complained > about the work not having any result... But as Christian and others point out, this is a potentially complex task, most especially for enterprise. One could see now where ISATAP provides a unique solution for a certain sparse deployment in an enterprise, for example. Enterprise is the hardest of all four to nail down. One could foresee that ISPs would need to deploy system(s) that act as combined tunnel broker, Teredo relay and 6to4 relay as a "migration broker" if we do ultimately end up going down those paths. That's quite a price. But I don't see the big archiecture discussion happening - I would have thought this might be independent of the four (ISP/3GPP/unman/ent) scenarios? Tim From owner-v6ops@ops.ietf.org Mon Nov 17 09:12:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12349 for ; Mon, 17 Nov 2003 09:12:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALk3h-000Jat-4o for v6ops-data@psg.com; Mon, 17 Nov 2003 14:08:53 +0000 Received: from [141.3.10.81] (helo=iramx2.ira.uni-karlsruhe.de) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALk3U-000Ja7-MF for v6ops@ops.ietf.org; Mon, 17 Nov 2003 14:08:40 +0000 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1ALk3S-0003k5-00 for ; Mon, 17 Nov 2003 15:08:38 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) for id 1ALk3S-0006nD-00; Mon, 17 Nov 2003 15:08:38 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:6:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1ALk3R-0004br-00 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 15:08:37 +0100 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 1ALk3Q-0001oU-00 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 15:08:36 +0100 Date: Mon, 17 Nov 2003 15:08:36 +0100 From: Roland Bless To: v6ops@ops.ietf.org Subject: v6onbydefault: Missing answers for DNS AAAA queries Message-Id: <20031117150836.18551a90.bless@tm.uka.de> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, we are using dual-stacked v6/v4 hosts now since several years in our institute. One really annoying behavior are looong DNS timeouts when the resolver lib asks for AAAA records, but the queried server does not respond (not even sends back an error) and simply drops the query. Some user even wanted to turn off v6(!) because he found it so annoying to wait for his favorite news site. Mainly, a provider of commercials who embeds his advertisements into news web sites causes the problem. Requests to the hostmaster to correct this behavior were not answered so far. Any suggestions how to cope with these problems? Is it covered in the 6onbydefault draft? Is it worthwhile to be considered there? Regards, Roland P.S.: until recently the resolver lib allowed to turn off AAAA queries by replacing the dns6 entry in the nsswitch.conf with a dns entry. From owner-v6ops@ops.ietf.org Mon Nov 17 09:20:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12488 for ; Mon, 17 Nov 2003 09:20:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALkBy-000K6w-6s for v6ops-data@psg.com; Mon, 17 Nov 2003 14:17:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALkBm-000K5a-8j for v6ops@ops.ietf.org; Mon, 17 Nov 2003 14:17:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHEHBF22523; Mon, 17 Nov 2003 16:17:12 +0200 Date: Mon, 17 Nov 2003 16:17:11 +0200 (EET) From: Pekka Savola To: Roland Bless cc: v6ops@ops.ietf.org Subject: Re: v6onbydefault: Missing answers for DNS AAAA queries In-Reply-To: <20031117150836.18551a90.bless@tm.uka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for reminding about this issue. On Mon, 17 Nov 2003, Roland Bless wrote: > Any suggestions how to cope with these problems? Is it covered in the > 6onbydefault draft? Is it worthwhile to be considered there? Yes, it is known. Yes, it should probably be at least referrred to in this document. Yes, it should be worked around where possible (see the thread about AI_ADDRCONFIG), and fixed where appropriate. See draft-morishita-dnsop-misbehavior-against-aaaa-00.txt for 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 Mon Nov 17 09:48:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13146 for ; Mon, 17 Nov 2003 09:48:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALkcX-000MPY-Kt for v6ops-data@psg.com; Mon, 17 Nov 2003 14:44:53 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALkcL-000MOf-PM for v6ops@ops.ietf.org; Mon, 17 Nov 2003 14:44:41 +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 hAHEib5u020296; Mon, 17 Nov 2003 07:44:38 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAHEiZQ10079; Mon, 17 Nov 2003 15:44:35 +0100 (MET) Date: Mon, 17 Nov 2003 15:43:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: transmech editorial comments 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > This would be good independently, but the big picture is: > > IPv6-over-IPv4 tunnels are modeled as "single-hop". That is, the > IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the > tunnel. The single-hop model serves to hide the existence of a > tunnel. The tunnel is opaque to users of the network, and is not > detectable by network diagnostic tools such as traceroute. > > The single-hop model is implemented by having the encapsulators and > decapsulators process the IPv6 hop limit field as they would if they > were forwarding a packet on to any other datalink. That is, they > decrement the hop limit by 1 when forwarding an IPv6 packet. (The > originating node and final destination do not decrement the hop > limit.) > > ... wouldn't we just be repeating the second paragraph in a bit shorter > fashion? The text actual reads as the first paragraph introduces the concept of the single-hop tunnel and I think that one becomes a bit thin if the 2nd sentence is dropped. I'll suggest other ways of making the concept more clear. The second paragraph is then about the implementation of the concept. > Btw, maybe one should reword "implemented", because that isn't really > "implementation-specific", to avoid that connotation. Maybe use > "achieved" ? I'll find a better word. Erik From owner-v6ops@ops.ietf.org Mon Nov 17 09:48:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13170 for ; Mon, 17 Nov 2003 09:48:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALkeJ-000MYO-F6 for v6ops-data@psg.com; Mon, 17 Nov 2003 14:46:43 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALke7-000MXo-Ik for v6ops@ops.ietf.org; Mon, 17 Nov 2003 14:46: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 hAHEk3xA010574; Mon, 17 Nov 2003 06:46:04 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAHEk0Q10298; Mon, 17 Nov 2003 15:46:01 +0100 (MET) Date: Mon, 17 Nov 2003 15:44:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: transmech MTU comments To: Fred Templin Cc: Erik Nordmark , Fred Templin , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3FB51F01.3000701@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Then, can we have a more-specific reference in the document to provide > better guidance to implementors, e.g., ([RFC3168], section 9.1)? Will do. Erik From owner-v6ops@ops.ietf.org Mon Nov 17 09:49:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13186 for ; Mon, 17 Nov 2003 09:49:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALkeZ-000MZD-BT for v6ops-data@psg.com; Mon, 17 Nov 2003 14:46:59 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALkeE-000MY8-6G for v6ops@ops.ietf.org; Mon, 17 Nov 2003 14:46:38 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHEkaSs004775; Mon, 17 Nov 2003 15:46:36 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 15:46:35 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639910@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues Date: Mon, 17 Nov 2003 15:46:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A quick comment on your editorials: > If the > 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may > activate the appropriate PDP context depending on the type of > application it has started; it may also make sense to > open both PDP > contexts in advance, before they are used, because the > activation of > a context may take a relatively long time. > > .. somehow I don't think activating PDP context based on the > peer address is > a realistic option right? The above talks about application not peer address. So it is referring to IPv6-only applications for example. When these are started they may prompt the v6 pdp context activation. /Karim From owner-v6ops@ops.ietf.org Mon Nov 17 10:06:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13840 for ; Mon, 17 Nov 2003 10:06:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALkud-000Nyo-8n for v6ops-data@psg.com; Mon, 17 Nov 2003 15:03:35 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALkuA-000NwU-3Q for v6ops@ops.ietf.org; Mon, 17 Nov 2003 15:03:06 +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 hAHF2rUP017074; Mon, 17 Nov 2003 07:02:54 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAHF2pQ13059; Mon, 17 Nov 2003 16:02:51 +0100 (MET) Date: Mon, 17 Nov 2003 16:01:42 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Tim Chown Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20031114165523.GK19013@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > OK, but that could simply be in the changes section, not in the definitions > section, as if the 3.6 reference is removed IPv4 compatibles are then only > mentioned in the changes section. having them in the defs kind of suggests > they are valid. I misspoke - strictly speaking this document doesn't deprecate them - it just no longer uses them. The doc contains this in the changes section: Removed automatic tunneling and use of IPv4-compatible addresses. We could make this document deprecate them, but it would make more sense to perform such an action in draft-ietf-ipv6-addr-arch-v4-00.txt > > > 3. Section 2 starts "the most straightforward way", though this > > > is the only way in this document? > > > > Yes. Is that confusing? Suggestions for different way to start things off? > > I guess if we said "the recommended way" that might get some objection. > I think part of the "problem" is that the draft doesn't set context anywhere, > e.g. it doesn't state why automatic methods such as 6to4 are not cited, or > why NAT-PT isn't mentioned as a "less straightforward" way of having > compatibility. Perhaps "The only way for IPv6 nodes to remain fully > compatible with IPv4-only nodes is by...", and then make some comment that > without that translation is needed? (a quick grep shows not one instance of > the word "translation" so again I think some text near the start setting the > scope here would really help). I agree that this document describes how implementors can build car engines; it does not teach people to drive cars. Hence providing an overview of all possible transition or even tunneling mechanisms is out of scope. We can have other RFCs do that. "The only way ... fully ..." is an even more questionable opinion than "the most straightforward way ..." - a http proxy can be argued to be fully compatible from the perspective of http applications. So I'm still not seeing how you would like to edit the document on the table to make it more clear; you seem to be mixing this clarifying task with wanting a different, more overview'ish, document on the table. > In short, the first line of the abstract would suggest that translation > methods should be cited, but in fact the document really focuses on tunnel > methods that IPv6 hosts/routers can use to communicate over IPv4 networks. > Maybe this focus changed over the three iterationbs of this RFC? I think the abstract contains marketing - maybe time to get rid of that. > See above - I think the first sentence of the abstract suggests otherwise, > and this sentence I think is used in the intro text at least too. If you > just want to make one change, then a statement in the asbtract and after > paragraph 1 of the intro to say that translation techniques are not in > scope would help, I think. "first"? I assume you mean that 3rd sentence in the abstract which says: They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. I suggest just dropping that sentence. It is easier to say that dual stack and configured tunnels are in scope than trying to first define what "translation" is for the sole purpose of saying that it is out of scope. FWIW I think the definitional problem is a hard one; is a http proxy (on a dual stack node) a "translation" or not. Erik From owner-v6ops@ops.ietf.org Mon Nov 17 10:10:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14305 for ; Mon, 17 Nov 2003 10:10:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALkyi-000OOM-TN for v6ops-data@psg.com; Mon, 17 Nov 2003 15:07:48 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALkyW-000ON6-Qk for v6ops@ops.ietf.org; Mon, 17 Nov 2003 15:07: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 hAHF7SUP019455; Mon, 17 Nov 2003 07:07:28 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAHF7PQ13482; Mon, 17 Nov 2003 16:07:26 +0100 (MET) Date: Mon, 17 Nov 2003 16:06:17 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Tim Chown Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20031114165523.GK19013@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Suggested updated abstract which should make the scope more clear: This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. The document specifies the two mechanisms "dual stack" and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling provides a mean to carry IPv6 packets over unmodified IPv4 routing infrastructures. Erik From owner-v6ops@ops.ietf.org Mon Nov 17 10:22:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15260 for ; Mon, 17 Nov 2003 10:22:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALl9s-000PWN-4d for v6ops-data@psg.com; Mon, 17 Nov 2003 15:19:20 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALl9g-000PUo-4K for v6ops@ops.ietf.org; Mon, 17 Nov 2003 15:19:08 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA04645 for ; Mon, 17 Nov 2003 15:19:06 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 PAA12974 for ; Mon, 17 Nov 2003 15:19:06 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAHFJ6Y04589 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 15:19:06 GMT Date: Mon, 17 Nov 2003 15:19:06 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Message-ID: <20031117151906.GX2162@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20031114165523.GK19013@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Nov 17, 2003 at 04:01:42PM +0100, Erik Nordmark wrote: > > We could make this document deprecate them, but it would make > more sense to perform such an action in draft-ietf-ipv6-addr-arch-v4-00.txt OK, I misunderstood what was happening; I thought compatibles were being deprecated. > I think the abstract contains marketing - maybe time to get rid of that. OK. It looks like a lot of text is carried forward in the early pages from the first version which I guess was written a few years ago now. > "first"? I assume you mean that 3rd sentence in the abstract which says: > They are designed to allow IPv6 nodes to > maintain complete compatibility with IPv4, which should greatly > simplify the deployment of IPv6 in the Internet, and facilitate the > eventual transition of the entire Internet to IPv6. > > I suggest just dropping that sentence. OK. > It is easier to say that dual stack and configured tunnels are in scope than > trying to first define what "translation" is for the sole purpose of > saying that it is out of scope. FWIW I think the definitional problem > is a hard one; is a http proxy (on a dual stack node) a "translation" or not. Fair point. If we say the best way for two hosts to interoperate is to both support the same v4 or v6 stack, it does beg the question as to what the alternative is, if its not even hinted at. But since noone else has commented I suggest you ignore that concern :) Tim From owner-v6ops@ops.ietf.org Mon Nov 17 10:24:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15348 for ; Mon, 17 Nov 2003 10:24:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALlCd-000PjB-5o for v6ops-data@psg.com; Mon, 17 Nov 2003 15:22:11 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALlCR-000PiG-50 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 15:21:59 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA04712 for ; Mon, 17 Nov 2003 15:21:57 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 PAA13100 for ; Mon, 17 Nov 2003 15:21:57 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAHFLvQ04706 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 15:21:57 GMT Date: Mon, 17 Nov 2003 15:21:57 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Message-ID: <20031117152157.GA2162@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20031114165523.GK19013@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Nov 17, 2003 at 04:06:17PM +0100, Erik Nordmark wrote: > > Suggested updated abstract which should make the scope more clear: > > This document specifies IPv4 compatibility mechanisms that can be > implemented by IPv6 hosts and routers. > The document specifies the two mechanisms "dual stack" and configured > tunneling. Dual stack implies providing complete implementations of both > versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling > provides a mean to carry IPv6 packets over unmodified IPv4 > routing infrastructures. Much better. Removes the "best way..." concern nicely. We should progress v4 compatible deprecation if this isn't in here. Thanks, Tim From owner-v6ops@ops.ietf.org Mon Nov 17 10:28:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15675 for ; Mon, 17 Nov 2003 10:28:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALlGO-0000Bg-Uh for v6ops-data@psg.com; Mon, 17 Nov 2003 15:26:04 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALlFz-00008B-BG; Mon, 17 Nov 2003 15:25:39 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHFPWI2001107; Mon, 17 Nov 2003 16:25:32 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 16:25:32 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639911@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Suresh Satapati'" , "'Randy Bush'" Cc: v6ops@ops.ietf.org Subject: RE: NAT-PT Applicabilty for 3GPP Date: Mon, 17 Nov 2003 16:25:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > This may be redundant to you, but to seek WG opinion I will > repeat the > argument here on this list. > > > I brought up the same issue during the DT work and agree > with Randy's > > point that if a scenario exists that requires a subset of > NAT-PT (i.e. 3GPP > > IMS) then it does not necessarily imply that NAT-PT as > specified in RFC 2766 > > is applicable. The draft could however point out which > parts of NAT-PT are > > applicable in this case. > > > > Regarding the actual SIP solution there is a reference in > 3gpp-analysis-07 > > to draft-elmalki-sipping-3gpp-translator-00. Following > Margaret's comments > > last time and the recommendation in > draft-ietf-3gpp-analysis it is on the > > SIPPING agenda this time. For those who may be interested > here's a new version > > of the draft: > > > >http://standards.ericsson.net/karim/draft-elmalki-sipping-3gp > p-translator-00.txt > > >This whole "subset applicability" argument stems from incorrect assumption that >NAT-PT (RFC 2766) mandates DNS-ALG. That is not the only issue IMO. According to RFC 2766 an implementation will take incoming packets destined to PREFIX::a.b.c.d and translate them to IPv4 destination a.b.c.d. It will also locally assign and use an ipv4 source addr/port. We don't want this behaviour when the binding between IPv6 and IPv4 address/ports is set and must be known by an external box (e.g. SIP proxy). This is a solution we've been looking at. NAT-PT does not allow the bindings to be set by another box. So I am still of the opinion that what we want for the SIP case is likely to be different from RFC2766, but that is in contrast with what is written in the applicability draft. > >In the past for v4 land, ALGs have been specified in separate documents. >For e.g. RFC 2663/3022 clearly defines the role of "NAT", and for >DNS-ALG there is RFC 2694. > >RFC2766 mentions DNS-ALG (and FTP-ALG) as an example, in addition to >basic NAT-PT operation. There is no text that states NAT-PT mandates >DNS-ALG. It does however mandate a certain way of establishing v4/v6 address bindings (above) and it does not consider that the bindings may be set by an external box. To me this in effect assumes that a SIP ALG will be there to intercept and modify packets in order to make use of the NAT-PT for SIP services. However we already got some input from SIP folks that going for SIP editing is not a good solution (discussions to be continued on SIP IPv6/v4 translation in SIPPING). /Karim From owner-v6ops@ops.ietf.org Mon Nov 17 11:12:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18470 for ; Mon, 17 Nov 2003 11:12:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALlxF-0002u2-NB for v6ops-data@psg.com; Mon, 17 Nov 2003 16:10:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALlx3-0002tA-BG for v6ops@ops.ietf.org; Mon, 17 Nov 2003 16:10:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHGA6624489; Mon, 17 Nov 2003 18:10:06 +0200 Date: Mon, 17 Nov 2003 18:10:06 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639910@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > If the > > 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may > > activate the appropriate PDP context depending on the type of > > application it has started; it may also make sense to > > open both PDP > > contexts in advance, before they are used, because the > > activation of > > a context may take a relatively long time. > > > > .. somehow I don't think activating PDP context based on the > > peer address is > > a realistic option right? > > The above talks about application not peer address. > So it is referring to IPv6-only applications for example. > When these are started they may prompt the v6 pdp context activation. Agreed -- but the original document included "peer address" as well. That should be gone in my proposed text..? -- 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 Nov 17 11:16:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18634 for ; Mon, 17 Nov 2003 11:16:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALm0z-00034o-M3 for v6ops-data@psg.com; Mon, 17 Nov 2003 16:14:13 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALm0m-00033j-7g for v6ops@ops.ietf.org; Mon, 17 Nov 2003 16:14:00 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHGDuSs003678; Mon, 17 Nov 2003 17:13:56 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 17:13:56 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639912@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE Date: Mon, 17 Nov 2003 17:13:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Consider rewording: > ===== > However, the UE may attach to a 3GPP network, in which > the Serving > GPRS Support Node (SGSN), the GGSN, and the Home > Location Register > (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP > contexts. This may happen in early phases of IPv6 deployment. > > In theory, the user's own 3GPP operator might not > support IPv6 at > all. However, such scenario is considered out of scope of this > document; the considerations for Unmanaged networks would apply > [UNMANSCEN] [UNMANAN]. There are some differences between unmanaged and 3gpp. For example the "gateway" (when it runs NAT) in Unmanaged scenarios puts some restrictions on the mechanisms that can be used. The same case does not apply to a 3gpp UE (which is not going to run NAT). So cases which Unmanaged considers of limited applicability are instead applicable here (e.g. single private v4 host connected to v6 ISP over a v4-only gateway/connection). IMO we should qualify the above statement further by saying that the 3gpp scenarios involve single priv. v4 host + ipv4 gateway cases, therefore some of the solutions which are recommended in Unmanaged are not equally recommended here. However on the other hand that seems to be a reason for considering them in the 3gpp analysis doc in the first place... > > Presupposing some form of IPv6 support, there are two cases > to consider when the visited network does not support IPv6 PDP > contexts: > > 1. The UE is used as a "modem" with e.g. a laptop computer. > The UE does not have to even support IPv6 PDP contexts, > and all the transition issues are dealt with by the > supporting equipment. > > 2. The UE is used independently, running IPv6 applications, > and would desire IPv6 connectivity. > > In both cases, it may be desirable to be able to create a tunnel > between the UE (or the supporting equipment) and the user's 3GPP > operator's IPv6 equipment. > > A way to easily manage the setup of a simple configured tunnel > would be sufficient, unless the basic IPv6 deployment in visited > networks could be assumed and no tunneling would be > needed at all. I don't think it is feasible to assume that we can easily set up configured tunnels in UEs without any user intervention. It would certainly need some automated mechanism which is probably what you mean by "easily manage the setup". Without having to specify a new one there are existing mechanisms for this that can make things easier and more transparent to users. I think it makes sense to refer to ISATAP as an existing solution that addresses this problem. I would suggest to add to the end of the parag above: A 3GPP operator that provides individual hosts with private IPv4 addresses could install an ISATAP router for example, so that each of these hosts could obtain a globally routable IPv6 address. /Karim From owner-v6ops@ops.ietf.org Mon Nov 17 11:27:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18940 for ; Mon, 17 Nov 2003 11:27:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALmAM-0003nL-Lx for v6ops-data@psg.com; Mon, 17 Nov 2003 16:23:54 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALmA2-0003lw-A0 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 16:23:34 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHGNWI2020524; Mon, 17 Nov 2003 17:23:32 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 17:23:32 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639913@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues Date: Mon, 17 Nov 2003 17:23:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > If the > > > 3GPP network supports both IPv4 and IPv6 PDP > contexts, the UE may > > > activate the appropriate PDP context depending on > the type of > > > application it has started; it may also make sense to > > > open both PDP > > > contexts in advance, before they are used, because the > > > activation of > > > a context may take a relatively long time. > > > > > > .. somehow I don't think activating PDP context based on the > > > peer address is > > > a realistic option right? > > > > The above talks about application not peer address. > > So it is referring to IPv6-only applications for example. > > When these are started they may prompt the v6 pdp context > activation. > > Agreed -- but the original document included "peer address" > as well. That > should be gone in my proposed text..? OK I see. Reread the original now. I think the meaning of the "peer address" part of the sentence was along the lines of: if you only have a v4 pdp context and you discover that the peer is v6-only then set up a v6 pdp ctxt. Is the issue that this was not clear or that this does not make sense? /Karim From owner-v6ops@ops.ietf.org Mon Nov 17 11:34:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19201 for ; Mon, 17 Nov 2003 11:34:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALmIZ-0004Iu-I3 for v6ops-data@psg.com; Mon, 17 Nov 2003 16:32:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALmIN-0004I3-Eq for v6ops@ops.ietf.org; Mon, 17 Nov 2003 16:32:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHGW9i25046; Mon, 17 Nov 2003 18:32:09 +0200 Date: Mon, 17 Nov 2003 18:32:08 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639913@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote: > OK I see. Reread the original now. I think the meaning of the > "peer address" part of the sentence was along the lines of: if you > only have a v4 pdp context and you discover that the peer is v6-only > then set up a v6 pdp ctxt. Is the issue that this was not clear or > that this does not make sense? Isn't it already way too late to activate the v6 PDP context if you wait until looking up the addresses, because PDP context activation takes a lot of time? And actually, if an application gets e.g. both AAAA and A records back from the DNS, you don't know which will end up being used. The point of the reword was to state that activating based on the peer address basis doesn't usually make sense, and application-based activation may not 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 Mon Nov 17 12:03:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21455 for ; Mon, 17 Nov 2003 12:03:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALmjr-0005vV-2D for v6ops-data@psg.com; Mon, 17 Nov 2003 17:00:35 +0000 Received: from [64.104.193.196] (helo=syd-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALmje-0005uj-M7 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 17:00:22 +0000 Received: from cisco.com (64.104.160.31) by syd-iport-1.cisco.com with ESMTP; 18 Nov 2003 03:20:55 +0430 Received: from SSENTHIL-W2K1.cisco.com ([10.32.254.221]) by bej-core-1.cisco.com (8.12.9/8.12.6) with SMTP id hAHGxDj1005133; Tue, 18 Nov 2003 00:59:15 +0800 (CST) Message-Id: <4.3.2.7.2.20031117085223.02abf310@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Nov 2003 09:00:03 -0800 To: "Karim El-Malki (HF/EAB)" From: Senthil Sivakumar Subject: RE: NAT-PT Applicabilty for 3GPP Cc: "'Suresh Satapati'" , "'Randy Bush'" , v6ops@ops.ietf.org In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639911@ESEALNT442.al.sw.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >That is not the only issue IMO. >According to RFC 2766 an implementation will take incoming packets destined >to PREFIX::a.b.c.d and translate them to IPv4 destination a.b.c.d. It will >also >locally assign and use an ipv4 source addr/port. We don't want this behaviour Can you please point out where in the NAT-PT RFC it says it should be locally assigned or where it explicitly prohibits mappings installed from an external entity? Senthil >when the binding between IPv6 and IPv4 address/ports is set and must be >known by >an external box (e.g. SIP proxy). This is a solution we've been looking at. >NAT-PT does not allow the bindings to be set by another box. So I am still >of the >opinion that what we want for the SIP case is likely to be different from >RFC2766, >but that is in contrast with what is written in the applicability draft. > > > > >In the past for v4 land, ALGs have been specified in separate documents. > >For e.g. RFC 2663/3022 clearly defines the role of "NAT", and for > >DNS-ALG there is RFC 2694. > > > >RFC2766 mentions DNS-ALG (and FTP-ALG) as an example, in addition to > >basic NAT-PT operation. There is no text that states NAT-PT mandates > >DNS-ALG. > >It does however mandate a certain way of establishing v4/v6 address bindings >(above) and it does not consider that the bindings may be set by an external >box. To me this in effect assumes that a SIP ALG will be there to intercept >and modify packets in order to make use of the NAT-PT for SIP services. >However >we already got some input from SIP folks that going for SIP editing is not a >good solution (discussions to be continued on SIP IPv6/v4 translation in >SIPPING). > >/Karim From owner-v6ops@ops.ietf.org Mon Nov 17 12:09:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22135 for ; Mon, 17 Nov 2003 12:09:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALmq0-0006HE-Tu for v6ops-data@psg.com; Mon, 17 Nov 2003 17:06:56 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALmpo-0006GY-6C for v6ops@ops.ietf.org; Mon, 17 Nov 2003 17:06:44 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHH6gSs016975; Mon, 17 Nov 2003 18:06:42 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 18:06:42 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639914@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues Date: Mon, 17 Nov 2003 18:06:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > OK I see. Reread the original now. I think the meaning of the > > "peer address" part of the sentence was along the lines of: if you > > only have a v4 pdp context and you discover that the peer > is v6-only > > then set up a v6 pdp ctxt. Is the issue that this was not clear or > > that this does not make sense? > > Isn't it already way too late to activate the v6 PDP context > if you wait > until looking up the addresses, because PDP context > activation takes a lot > of time? As you say it would be better if the pdp context was already there but in the above case you have little other choice? (also some other considerations on "in advance" activation below) > > And actually, if an application gets e.g. both AAAA and A > records back > from the DNS, you don't know which will end up being used. True, if both are returned then we don't know since it's up to the app. I was taking the case where there is only a AAAA record and you only have a v4 pdp ctxt. > > The point of the reword was to state that activating based > on the peer > address basis doesn't usually make sense, and > application-based activation > may not either.. You could activate pdp contexts in advance or you may do that based on app.s and in special cases (above) peer addresses. The "in advance" option is attractive but there are cases where it doesn't work well: if the application needs a pdp context with certain QoS and APN (e.g. corporate) characteristics that is not currently active. So I am not convinced that we should be making the above point. /Karim From owner-v6ops@ops.ietf.org Mon Nov 17 12:26:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23499 for ; Mon, 17 Nov 2003 12:26:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALn5d-0007GW-3g for v6ops-data@psg.com; Mon, 17 Nov 2003 17:23:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALn5Q-0007G7-KW for v6ops@ops.ietf.org; Mon, 17 Nov 2003 17:22:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHHMoX26241; Mon, 17 Nov 2003 19:22:50 +0200 Date: Mon, 17 Nov 2003 19:22:49 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639914@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote: > As you say it would be better if the pdp context was already there > but in the above case you have little other choice? (also some > other considerations on "in advance" activation below) Sure, but activating both v4 and v6 to begin with (if there are any v6-using apps on the UE) should be the safest choice.. > > And actually, if an application gets e.g. both AAAA and A > > records back > > from the DNS, you don't know which will end up being used. > > True, if both are returned then we don't know since it's up > to the app. I was taking the case where there is only a AAAA > record and you only have a v4 pdp ctxt. Sure, if we can assume something about apps and the scenarios where the UE will be used, fine. > You could activate pdp contexts in advance or you may do > that based on app.s and in special cases (above) peer > addresses. The "in advance" option is attractive but there > are cases where it doesn't work well: if the application needs > a pdp context with certain QoS and APN (e.g. corporate) > characteristics that is not currently active. So I am not > convinced that we should be making the above point. I'm not sure how common those cases are. I'd assume they are not too common. Therefore, it would seem to clarify better how the PDP contexts are typically used. Could you care to try to suggest a different reword to clarify the different considerations with PDP context activation? -- 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 Nov 17 12:59:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25554 for ; Mon, 17 Nov 2003 12:59:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALnbl-0008yY-75 for v6ops-data@psg.com; Mon, 17 Nov 2003 17:56:17 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALnbV-0008y0-VP for v6ops@ops.ietf.org; Mon, 17 Nov 2003 17:56:01 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Nov 2003 09:56:01 -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); Mon, 17 Nov 2003 09:55:48 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Nov 2003 09:55:41 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Nov 2003 09:56:01 -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); Mon, 17 Nov 2003 09:55:59 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 17 Nov 2003 09:56:04 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.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: Comments on unman-scenarios-03 Date: Mon, 17 Nov 2003 09:56:03 -0800 Message-ID: Thread-Topic: Comments on unman-scenarios-03 Thread-Index: AcOsr1NjSnzaEdTxSbqU6dYHOBXCiwAhDkvg From: "Christian Huitema" To: "Chirayu Patel" , X-OriginalArrivalTime: 17 Nov 2003 17:56:04.0050 (UTC) FILETIME=[11877320:01C3AD34] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Chirayu, Sorry, but your comments are coming too late. The draft already went through last call (back in June). The purpose of version 03 was to take into account some IESG comments. The high level issues you mentioned, stacked gateways or static addresses, were discussed through the draft progression and were considered somewhat marginal. Their absence in the draft is intentional. -- Christian Huitema > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Chirayu Patel > Sent: Sunday, November 16, 2003 5:39 PM > To: v6ops@ops.ietf.org > Subject: Comments on unman-scenarios-03 >=20 >=20 > Hello, >=20 > Few comments on the unman-scenarios-03 draft. >=20 > CP >=20 >=20 > High-Level > ---------- >=20 > 1. >=20 > None of the cases consider a dual-stack gateway that is connected > to the ISP. >=20 > # [Host1]----------v > # [Gateway]------[Gateway]------------[ISP] > # [Host2]----------^ | > # | > # | > # [Host3]-------------------------+ >=20 > Internal gateways may be IPv4-only, or dual-stack or IPv6 only. >=20 > I think some general text should be mentioned about connectivity, naming, > and application support in hosts that are located behind an internal > gateway (IPv4-only, dual, and IPv6-only) for each of the cases. >=20 > For example, in case C, if the network has an IPv4 only gateway, then it > might not be possible certain local applications on the hosts behind > this gateway. >=20 > 2. >=20 > All hosts that have static (IPv6) addresses can host servers. With that > in mind, I think the text related to server applications in case A should > be modified. >=20 > The current text reads, >=20 > ,---- > | Server applications are also not a primary focus of Case A. Server > | applications require DNS support, which is difficult to engineer for > | clients located behind a NAT, which is likely to be present in this > | case. Besides, server applications at present cater mostly to IPv4 > | clients; putting up an IPv6-only server is not very attractive. > `---- >=20 > As long as the IPv6 host has a static address, the ease/difficulty of > providing DNS support will be similar to case B or C. The other > assumption regarding attractiveness will not hold true if the global > scenario is that the unmanaged network is late in getting IPv6 support, > and the rest (or a large part) of the world is already using IPv6. >=20 >=20 > Semi-editorial > -------------- >=20 > 3. >=20 > ,---- > | Deploying servers usually requires providing each server with a > | stable DNS name, and associating a global IPv4 address with that > | name, whether the address be that of the server itself or that of > | the router acting as a firewall or NAT. Since updating DNS is a > | management task, it falls somewhat outside the scope of an unmanaged > | network. On the other hand, it is also possible to use out-of-band > | techniques (such as cut-and-paste into an instant message system) to > | pass around the address of the target server. > `---- >=20 > I think for the purposes of this document, and the companion (eval) > document, updating DNS should not be considered as a management task > whose scope is outside the scope of an unmanaged network. In my opinion > the availability of stable addresses, and broadband will actually > trigger the demand to simplify the infrastructure needed to host servers > in home networks. >=20 > I propose s/Since updating DNS is a management task, it falls somewhat > outside the scope of an unmanaged network.// >=20 > 4. >=20 > ,---- > | As we transition to IPv6, we must meet the requirements of the > | various applications, which we can summarize in the following way: > | applications that used to work well with IPv4 should continue > | working well during the transition; it should be possible to use > | IPv6 to deploy new applications that are currently hard to deploy in > | IPv4 networks; and the deployment of these IPv6 applications should > | be simple and easy to manage, but the solutions should also be > | robust and secure. > `---- >=20 > Few requirements are missing: >=20 > a) During the transition applications must work well with with both > IPv4 and IPv6 networks to ease application deployment. >=20 > b) Interworking may have to be defined for applications that will > execute on IPv4-only networks, and IPv6-only networks. (I am unable > to phrase this one properly). For example, a p2p application on a > IPv4 only network may want to interact with a peer on a IPv6 > network. For this interworking technology, and gateways have to be > developed. >=20 > 3. >=20 > ,---- > | Client applications require global connectivity. In an IPv6 network, > | we would expect the client to use a global IPv6 address, which will > | have to remain stable for the duration of the client-server session. > `---- >=20 > The second sentence "In an IPv6 network..." seems out of place. This > section is list requirements of client applications in home networks > (independent of the network technology). The second sentence can probably > be replaced with: >=20 > "Client applications need a global address that will remain stable for > the duration of the client-server session." >=20 > 4. >=20 > ,---- > | Many servers try to look up a DNS name associated to the IP address > | of the client. In an IPv4 network, this IP address will often be > | allocated by the Internet service provider to the gateway, and the > | corresponding PTR record will be maintained by the ISP. In many > | cases, these PTR records are perfunctory, derived in an algorithmic > | fashion from the IPv4 address; the main information that they > | contain is the domain name of the ISP. Whether or not an equivalent > | function should be provided in an IPv6 network is unclear. > `---- >=20 > It might help to appreciate the last sentence better, if it is mentioned > that even though few servers do a reverse lookup, there are many IPv4 > ISP's that do not provide reverse lookup databases. >=20 > 5. Section 4.3 >=20 > Naming requirements for P2P applications are not mentioned. >=20 > 6. >=20 > ,---- > | Private conversations by one of the authors with developers of peer- > | to-peer applications suggest that many would be willing to consider > | an "IPv6-only" model if they can get two guarantees: > | > | 1) That there is no regression from IPv4, i.e. that all customers > | who could participate in a peer-to-peer application using IPv4 > | can also be reached by IPv6. > | > | 2) That IPv6 provides a solution for at least some of their hard > | problems, e.g. enabling peers located behind an IPv4 NAT to > | participate in a peer-to-peer application. > `---- >=20 > This text can be removed/reworded. Point 1, is already covered in the > requirement summary in beginning of section 4. Point 2, can be reworded, > and merged with the first paragraph in this section (Requirements of > peer-to- > peer applications). >=20 > 7. [DNSOPV6] has expired, and if a new version is not going to be > released, relevant parts of that draft should be moved to this > document. Probably section 5.2.2 should mention that if a DNS server > is being deployed in the network then it should accessible over both > IPv4, and IPv6. >=20 > 8. >=20 > ,---- > | Network level translation poses similar problems: in practice, > | network level actions must be complemented by "application layer > | gateways" that will rewrite references to IP addresses in the > | protocol, and while these relays are not necessary for every > | application, they are necessary for enough applications to make any > | sort of generalized translation quite problematic; hosts may need to > | be parameterized to use the translation service; and designing the > | right algorithm to decide when to translate DNS requests has proven > | very difficult. > `---- >=20 > I don't quite follow "the right algorithm to decide when to translate > DNS requests". Is there any reference, or has this issue been discussed > in the past? >=20 > 9. >=20 > ,---- > | Not assuming translation services in the network appears to be both > | more practical and more robust. If the market requirement for a new > | device requires that it interact with both IPv4 and IPv6 hosts, we > | may expect the manufacturers of these devices to program them with a > | dual stack capability; in particular, we expect general purpose > | systems such as personal computers to be effectively dual-stack. > `---- >=20 > Instead of using the words "device", "device interaction with hosts", > "client", and "server applications" should be used as this section takls > of these applications, The paragraph can be rephrased to : >=20 > "Not assuming translation services in the network appears to be both more > practical and more robust. If the market requirement for a new > application requires that it interact with both IPv4 and IPv6 hosts, we > may expect the developers of these applications to program them with > support for both IPv4, and IPv6. Hence, the devices that are expected to > run these applications will have to be dual-stack." >=20 > 10. Section 5.2.2 >=20 > ,---- > | In Case B, the upgraded gateway will act as an IPv6 router; it > | will... > `---- >=20 > Should it not be: >=20 > "In Case B, the upgraded gateway will act either as an IPv6 router, or as > a ND proxy [NDPROXY]; it will..." >=20 > 11. >=20 > ,---- > | several solutions will be assessed in a companion memo [EVAL]. > `---- >=20 > -or- >=20 > ,---- > | Possible solutions will be compared in the evaluation draft. > `---- >=20 > Such instances should be removed from the text, and the purpose of the > [EVAL] document should be made clear in the Introduction. >=20 > 12. Section 5.2.2 >=20 > It would not hurt, if it is mentioned that the the type of IPv6 > connectivity for the hosts is native. >=20 > 13. >=20 > ,---- > | There are multiple solutions, including domain name delegation. > `---- >=20 > What are the other solutions? >=20 > 14. >=20 > ,---- > | A delegation of some domain name is required in order to publish the > | IPv6 addresses of servers in the DNS. > `---- >=20 > This point is suppossed to be different for case B, and case C. I am > unable to see the difference. Both the cases require a domain name > delegation. >=20 > 15. >=20 > ,---- > | - the requirement that tunneling protocols used for IPv6 access over > | IPv4 be designed for secure use > `---- >=20 > This requirement is more of a transition mechanism requirement, and less > of an application requirement. I also could not find where this > requirement is discussed. The only thing I could find is a general > requirement for all solutions to be secure, which is listed in section > 16. >=20 > 17. >=20 > ,---- > | The security solutions currently used in IPv4 networks include a > | combination of firewall functions in the gateway, authentication and > | authorization functions in the applications, encryption and > | authentication services provides by IP security, Transport Layer > | Security and application specific services, and host-based security > | products such as anti-virus software, and host firewalls. The > | applicability of these tools in IPv6 unmanaged networks will be > | studied in a companion document. > `---- >=20 > I think this one should be mentioned upfront in the Introduction section > as it will help to clarify the scope of the document. >=20 > Is the document mentioned in the last sentence published? >=20 > Editorial > --------- >=20 > 18. >=20 > ,---- > | There are some cases in which the "gateway" is replaced by a layer-2 > | bridge. In such deployments, the hosts have direct access to the ISP > | service. In order to avoid lengthy developments, we will treat these > | cases as if the gateway was not present, i.e. as if each host was > | connected directly to the ISP. > `---- >=20 > I am unsure if word developments is correctly used. Plus, the text about > connected directly to the ISP is repeated. I propose to rephrase the > paragraph to: >=20 > "There are some cases in which the "gateway" is replaced by a layer-2 > bridge. In such deployments, the hosts have direct access to the ISP > service, and the gateway is assumed to be absent." >=20 > 19. Modify the section titles so that the words start with upper case. >=20 > 20. >=20 > ,---- > | The application requirements for IPv6 Unmanaged Networks fall into > | three general categories: connectivity, naming, and security. > | Connectivity issues include the provision of IPv6 addresses and > | their quality: do hosts need global addresses, should these > `---- >=20 > s/The application requirements/The requirements related to applications/ >=20 > I was confused when I had initially read the first sentence. I could not > make out if the sentence meant requirements of the network, or the > requirements of the application. >=20 > 4. Section 4.4 >=20 > I am a bit lost...what does collateral effect mean? :-) >=20 > 5. >=20 > ,---- > | In order to get some clarity, we distinguish three entities involved > | in the transition of an unmanaged network: the ISP (possibly > | including ISP consumer premise equipment (CPE)), the home gateway, > | and the hosts (computers and appliances). Each can support IPv4- > | only, both IPv4 and IPv6 or IPv6-only. That gives us 27 > | possibilities. > `---- >=20 > Reword to >=20 > "In order to get some clarity, we distinguish three entities involved in > the transition of an unmanaged network: the ISP, the home gateway, and > the hosts (computers and appliances). Each can support IPv4-only, both > IPv4 and IPv6 or IPv6-only. This gives us 27 possibilities. Note, that > ISP transition may also include the transition of the ISP provided home > gateway, aka, CPE (Customer Premise Equipment)." >=20 > 6. >=20 > We describe the most important cases. We will assume that in all cases > the hosts are a combination of IPv4-only, dual stack and (perhaps) > IPv6- > only hosts. >=20 > s/(perhaps)// >=20 > 7. >=20 > ,---- > | In fact, we can consider three non-NAT variants: directly connected > | host; gateway acting as a bridge; and gateway acting as a non-NAT IP > | router. > `---- >=20 > s/In fact, we can consider three non-NAT variants:/There are three types > of non-NAT variants:/ >=20 > 8. Section names of 5.x should be made consistent with the actual case > name. For example, section 5.1 should be renamed to "Case A, gateway > without IPv6 support". >=20 > 9. >=20 > ,---- > | There are two variations of this case, depending on the type of > | service implemented by the gateway. In many cases, the gateway is a > | direct obstacle to the deployment of IPv6, but a gateway which is > | some form of bridge-mode CPE or which is a plain (neither filtering > | nor NAT) router does not really fall into this category. > `---- >=20 > Rephrase. Just to make it a bit more clear. >=20 > "There are two variations of this case, depending on the type of service > implemented by the gateway. In many cases, the gateway is a direct > obstacle to the deployment of IPv6. In other cases, the gateway is some > form of bridge-mode CPE or a plain (neither filtering nor NAT) router." >=20 > 10. >=20 > ,---- > | If the local gateway provides global IPv4 addresses to the local > | hosts, then these hosts can individually exercise the mechanisms > | described in case C, "IPv6 connectivity without provider support." > | If the local gateway implements a NAT function, another type of > | mechanism is needed. The mechanism to provide connectivity to peers > | behind NAT should be easy to deploy, and light weight; it will have > | to involve tunneling over a protocol that can easily traverse NAT, > | either TCP or preferably UDP, as tunneling over TCP can result in > | poor performances in case of time-outs and retransmission. If > | servers are needed, these servers will in practice have to be > | deployed as part of the "support infrastructure" for the peer-to- > | peer network or for an IPv6-based service; economic reality implies > | that the cost of running these servers should be as low as possible. > `---- >=20 > The lines starting from "If servers are needed..." should be moved to > 10.1.1. I am not sure what they are suppossed to convey. Maybe they can > be removed. >=20 > 11. >=20 > ,---- > | problems: first, one must develop relays for all applications; > | second, one must develop a management infrastructure to provision > | the host with the addresses of the relays; in addition, the > | application may have to be modified if one wants to use the relay > `---- >=20 > s/; in addition/, and third/ >=20 > 12. >=20 > s/peer to peer/peer-to-peer/ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Mon Nov 17 13:06:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25801 for ; Mon, 17 Nov 2003 13:06:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALnjS-0009Kc-5x for v6ops-data@psg.com; Mon, 17 Nov 2003 18:04:14 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALnjG-0009KI-FL for v6ops@ops.ietf.org; Mon, 17 Nov 2003 18:04:02 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAHI3rX24476; Mon, 17 Nov 2003 10:03:53 -0800 X-mProtect: <200311171803> 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 smtpd9eQW6B; Mon, 17 Nov 2003 10:03:52 PST Message-ID: <3FB90F37.7030106@iprg.nokia.com> Date: Mon, 17 Nov 2003 10:11: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: Pekka Savola CC: Christian Huitema , v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Sat, 15 Nov 2003, Christian Huitema wrote: > > >>The V6OPS working group is a prime example of the current IETF decease: >>expanding a lot of energy to achieve no result. The symptom is very >>clear: vendors are shipping products based on internet drafts, without >>getting the benefits of IETF peer review. >> >> > >Achieving no result is probably considered a bug rather than feature if >one believes the IETF exists to provide peer review of the technologies >the vendors wish to standardize. I don't. > > In the specific instance of ISATAP, I take exception to this remark. ISATAP was originally developed under government contract and institutional funding during my employment at SRI International and therefore *is not* the product of any particular vendor. What ISATAP *is* is a superior technical approach at solving real-world needs for IPv6 deployment. This falls squarely under the auspices of the IETF if only we choose to recognize it and get on board before the real world passes us by. The IETF I have known is an organization of brilliant technologists who are not afraid to push through new technologies to further the advancement of the Internet. That is why we have an IP-based network today, and not OSI or any of the other approaches that have fallen by the wayside over the years. Pekka, I appeal to you as one of our finest such technologists to get this train back on the tracks under the IETF auspices so we can go forward together as it should be. Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Mon Nov 17 13:07:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26193 for ; Mon, 17 Nov 2003 13:07:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALnkw-0009QR-FM for v6ops-data@psg.com; Mon, 17 Nov 2003 18:05:46 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALnkj-0009P7-P5; Mon, 17 Nov 2003 18:05:33 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHI5SSs028260; Mon, 17 Nov 2003 19:05:28 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 19:05:28 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639917@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Senthil Sivakumar'" Cc: "'Suresh Satapati'" , "'Randy Bush'" , v6ops@ops.ietf.org Subject: RE: NAT-PT Applicabilty for 3GPP Date: Mon, 17 Nov 2003 19:05:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >That is not the only issue IMO. > >According to RFC 2766 an implementation will take incoming > packets destined > >to PREFIX::a.b.c.d and translate them to IPv4 destination > a.b.c.d. It will > >also > >locally assign and use an ipv4 source addr/port. We don't > want this behaviour > > Can you please point out where in the NAT-PT RFC it says it > should be > locally assigned > or where it explicitly prohibits mappings installed from an > external entity? I assume your question wants to highlight the fact that RFC 2766 doesn't rule that out. OK. Still I don't see your point? If it allows local pools, which are in fact the most likely thing people implement, and does not specify communication with an external box then it is not the spec we want to recommend. My point is that if we say NAT-PT is applicable for SIP then people will expect to read RFC 2766 and implement it. If they do that they are likely to implement a local pool of v4 addresses and a SIP ALG (that does SIP editing). Since SIP folks are not in favour of SIP editing I don't think we should say that NAT-PT is applicable to the SIP case. It is much cleaner to create a SIP specific solution for this case that is not related to generic NAT-PT and its problems. /Karim From owner-v6ops@ops.ietf.org Mon Nov 17 13:14:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26611 for ; Mon, 17 Nov 2003 13:14:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALnrR-0009qm-14 for v6ops-data@psg.com; Mon, 17 Nov 2003 18:12:29 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALnrE-0009py-Rm for v6ops@ops.ietf.org; Mon, 17 Nov 2003 18:12:16 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id C1FD0423B2D; Mon, 17 Nov 2003 13:12:13 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 4A5DC75D0A; Mon, 17 Nov 2003 13:12:13 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: "Christian Huitema" , v6ops@ops.ietf.org Date: Mon, 17 Nov 2003 23:42:12 +0530 X-Sasl-Enc: QY+VL3PVnaaROqdQGScDyQ 1069092732 Subject: RE: Comments on unman-scenarios-03 References: In-Reply-To: Message-Id: <20031117181213.4A5DC75D0A@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Oh well! :-( I really wish there was some field within the draft to indicate its status. Anyways, I had read unman-scenarios to get to the next one (unmaneval). Comments on that one are typed out...but it is too late in the night. Will send them out tomorrow. CP On Mon, 17 Nov 2003 09:56:03 -0800, "Christian Huitema" said: > Chirayu, > > Sorry, but your comments are coming too late. The draft already went > through last call (back in June). The purpose of version 03 was to take > into account some IESG comments. The high level issues you mentioned, > stacked gateways or static addresses, were discussed through the draft > progression and were considered somewhat marginal. Their absence in the > draft is intentional. > > -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Nov 17 13:37:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27353 for ; Mon, 17 Nov 2003 13:37:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALoCY-000BQM-VK for v6ops-data@psg.com; Mon, 17 Nov 2003 18:34:18 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALoCM-000BPf-RX for v6ops@ops.ietf.org; Mon, 17 Nov 2003 18:34:06 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2003 10:37:29 -0800 Received: from SSENTHIL-W2K1.cisco.com ([128.107.176.137]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHIY3th018201; Mon, 17 Nov 2003 10:34:04 -0800 (PST) Message-Id: <4.3.2.7.2.20031117102434.01dde328@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Nov 2003 10:34:03 -0800 To: "Karim El-Malki (HF/EAB)" From: Senthil Sivakumar Subject: RE: NAT-PT Applicabilty for 3GPP Cc: "'Suresh Satapati'" , "'Randy Bush'" , v6ops@ops.ietf.org In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639917@ESEALNT442.al.sw.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.1.0.80455 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 07:05 PM 11/17/2003 +0100, Karim El-Malki (HF/EAB) wrote: > > >That is not the only issue IMO. > > >According to RFC 2766 an implementation will take incoming > > packets destined > > >to PREFIX::a.b.c.d and translate them to IPv4 destination > > a.b.c.d. It will > > >also > > >locally assign and use an ipv4 source addr/port. We don't > > want this behaviour > > > > Can you please point out where in the NAT-PT RFC it says it > > should be > > locally assigned > > or where it explicitly prohibits mappings installed from an > > external entity? > >I assume your question wants to highlight the fact that RFC 2766 >doesn't rule that out. OK. Still I don't see your point? I My point was, RFC2766 does not mandate you installing the mappings locally, nor does it prevent you to install mappings from an external entity, unlike what you have stated in your earlier email. >f it allows >local pools, which are in fact the most likely thing people >implement, and does not specify communication with an external box >then it is not the spec we want to recommend. > >My point is that if we say NAT-PT is applicable for SIP then people >will expect to read RFC 2766 and implement it. If they do that >they are likely to implement a local pool of v4 addresses and a >SIP ALG (that does SIP editing). Since SIP folks are not in favour >of SIP editing I don't think we should say that NAT-PT is applicable >to the SIP case. It is much cleaner to create a SIP specific solution >for this case that is not related to generic NAT-PT and its problems. NAT-PT RFC does not specify anything about how SIP ALG/Proxy should be implemented. That could be a seperate document, if one needs it. If you want a SIP ALG/Proxy, you could implement as per the SIP protocol specification and make use of the NAT-PT header translator functionality to let the media pass through the translator. So NAT-PT is applicable there and that is what is noted in the applicability statement. Re-inventing something that has already been done seems to be a waste of time. Senthil >/Karim From owner-v6ops@ops.ietf.org Mon Nov 17 14:32:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29508 for ; Mon, 17 Nov 2003 14:32:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALp33-000Ef3-6r for v6ops-data@psg.com; Mon, 17 Nov 2003 19:28:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALp2i-000Edz-Eo for v6ops@ops.ietf.org; Mon, 17 Nov 2003 19:28:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHJS6002640; Mon, 17 Nov 2003 21:28:06 +0200 Date: Mon, 17 Nov 2003 21:28:06 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: Chirayu Patel , Subject: RE: Comments on unman-scenarios-03 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Christian Huitema wrote: > Sorry, but your comments are coming too late. The draft already went > through last call (back in June). The purpose of version 03 was to take > into account some IESG comments. The high level issues you mentioned, > stacked gateways or static addresses, were discussed through the draft > progression and were considered somewhat marginal. Their absence in the > draft is intentional. Some of the few editorial nits can probably be fixed at AUTH48, but unless you, Chirayu, think that there have been really significant omissions that we should pull the draft back from the IESG's approval, please state those. On a more happy note, please ensure that the similar issues have been proposerly addressed in the analysis document. -- 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 Nov 17 15:03:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01438 for ; Mon, 17 Nov 2003 15:03:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALpXt-000Gh9-T6 for v6ops-data@psg.com; Mon, 17 Nov 2003 20:00:25 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALpXF-000Gdp-F7 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 19:59:45 +0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAHJxWUP003172; Mon, 17 Nov 2003 11:59:33 -0800 (PST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAHJxVIr022536; Mon, 17 Nov 2003 14:59:31 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id hAHJxVid008399; Mon, 17 Nov 2003 14:59:31 -0500 (EST) Message-Id: <200311171959.hAHJxVid008399@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Pekka Savola cc: v6ops@ops.ietf.org From: Sebastien Roy Subject: Re: v6onbydefault-00 comments In-Reply-To: Message from Pekka Savola of "Sat, 15 Nov 2003 14:23:47 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Nov 2003 14:59:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > substantial > ----------- > > 1) I think the document needs to be more specific about the scenarios where > the different issues exist in, and what is the result of the fix (+remainder > issues). That is, the document should also give a big picture of the > different issues and how they connect with each other. > > I'm not sure about the best way to do it, but one thing to consider would be > whether one could try to formulate a brief and concise problem statement > (after the introduction to the issues etc.) of the problem. Agreed. The introduction section could be more detailed and include a more general description of the problem statement. In addition to that, there needs to be some glue to tie everything together (in a conclusion section perhaps?). > > 2) Should the discussion of AI_ADDRCONFIG go in? If so, I might be able to > try to hack up some text after done.. That would be excellent. > > 3) I don't quite understand the last paragraph of section 2.1: > > Fixing the destination address selection mechanism by adding such a > rule is only a mitigating factor if applications use standard name > resolution API's that implement this mechanism, and these > applications try addresses in the order returned. This may not be an > acceptable assumption in some cases, as there are applications that > use hard coded addresses and address search orders (DNS resolver is > one example), and/or literal addresses passed in from the user. Such > applications will obviously be subject to whatever connection delays > are associated with attempting a connection to an unreachable > destination. This is discussed in more detail in the next few > sections. > > ==> first, destination address selection is done w/ getaddrinfo(), so if > apps use that (after an added rule), they're OK (so, isn't the meaning of > the first sentence reversed?) What I meant to say was that all bets are off if applications don't use destination address selection. Is that not how you interpreted the sentence? > > ==> isn't the DNS resolver implementation itself quite bit of a special case > here? Maybe, and maybe this is the wrong context to be talking about the resolver's potential problems. In any case, shouldn't the resolver be doing something more useful with that list of server addresses other than try them in round-robin fashion? If none of the IPv6 servers are reachable, should it ever bother trying them? > > ==> last, I don't really understand the point about literal addresses; if > the user specifies an address, he gives just one of them. It either works > or doesn't; there is no selection among them. If the user gives the IPv6 > address, the problem will be in ND, as an already documented problem. > If the user gives the IPv4 address, it works. Ok, that part of the sentence can be yanked. > > 4) This document contains a rather long description of on-link assumption > issues. Could this be summarized a bit more, inserting a normative > reference to the on-link assumption document? Yes, that was the original intent, but we ran out of time before the submission deadline. This will be done in the next version. > > 5) I don't remember that the second paragraph of section 2.2.1 in the onlink > document? The 2nd paragraph of v6onbydefault's section 2.2.1 wasn't brought over to the onlinkassumption document. That was an oversight. > I'm not sure if I understand the problem correctly: > > - if there is an entry in default router list, on-link assumption is not > done, and all the packets w/o more specifics go to the router, and > - if there is not an entry in the default router list, but there are more > specific routes through a router, the on-link assumption is valid for the > packets which do not match the more specific routes. > > This seems like the desired behaviour. Did I miss something? That's the desired behaviour, but the ND spec never mentions that more specific routes should ever be considered by hosts. According to the conceptual model for hosts in rfc2461, hosts should either consult their default router list for sending packets off-link, or send packets on-link. > > 6) Transport protocol robustness section has: > > It should abort a > connection in those states when receiving any ICMPv6 Destination > Unreachable message. It should make this distinction when a > connection is in any other state. > > ==> shouldn't the should in the last sentence actually be "should not" ? I don't think so. For example, a connection in ESTABLISHED state shouldn't be aborted if an ICMPv6 "soft error" is received. So there _should_ be a distinction between soft and hard errors for states other than SYN-SENT. > > ==> one should maybe consider the other protocols, such as UDP and SCTP here > as well -- or at least list them as items for further study :-) Yes, we'll see what we can do here in the next version. > > ==> would it make sense to also discuss issues relating to blackhole > problems, i.e., packets getting discarded somewhere without feedback e.g. > using ICMP? There is pretty much nothing to do then, but that should > probably be mentioned explicitly as an existing problem.. Yes, it should be mentioned as this is a common problem (especially with firewalls). > > 7) 3.2.1 Dealing with Poor IPv6 Network Performance > > ... one other way to deal with this could be something like: > > Another approach could be to restrict IPv6 just to a smaller, better > working address range, e.g., the internal network or nationally > interconnected networks, but this can't be a long term solution. I'm not sure I completely understand what you mean be "restrict", but I'll assume for the moment that you mean restrict the addresses returned by name lookups... Many enterprise networks already have neutered DNS deployments where the internal servers only answer to queries for internal records, so your idea might be doable there. How would this be done in an ISP? > > Regardless of whether the user selects a short-term fix to the problem, > the first imperative should be working on enhancing the performance of > IPv6. Indeed. > > 8) The application robustness section should probably refer to the > application transition guidelines, as it specifically describes this > problem. This section can probably be reduced in length a bit. Agreed. > > (note: s/connection results/connection may result) O.k. > > semi-substantial > ---------------- > > ==> there has been some confusion around this document at some point, so > maybe could try to add something like (+Introduction too): > > The purpose of this document is not to try to specify whether IPv6 > should be enabled by default or not, but to raise the awareness of > the potential issues involved. Agreed. > > Consider a scenario in which a dual stack system has IPv6 enabled and > placed on a link with no IPv6 routers. The system is using IPv6 > Stateless Address Autoconfiguration [AUTOCONF], so it only has a > link-local IPv6 address configured. It also has a single IPv4 > address that happens to be a private address as defined in > [PRIVADDR]. > > ==> it would be useful if one could generalize a bit from this.. Yes it would. The problems aren't specific to this exact scenario. > > To allow applications to correctly fall back to IPv4 when IPv6 > packets are destined beyond their allowed scope, the devices > enforcing the scope boundary should send ICMPv6 Destination > Unreachable messages back to senders of such packets. The sender's > > ==> s/should/must/ ? I agree. The sentence doesn't really make sense otherwise. > > An example of such a situation is a node which obtains IPv4 > connectivity natively through an ISP, but whose IPv6 connectivity is > obtained through a configured tunnel whose other endpoint is > topologically such that most IPv6 communication is done through > triangular routes. Operational experience on the 6bone shows that > > ==> s/triangular routes/triangular IPv4 topology/ ? How about, "triangular IPv4 paths"? The word "topologically" already exists earlier in the sentence. > > A similar problem could exist for VPN software. A VPN could protect > all IPv4 packets but drop all others onto the local subnet > unprotected. At least one widely used VPN behaves this way. This is > > ==> you use a very unusual meaning for the word "drop". Consider rewording.. > :-) > > The VPN doesn't > know about IPv6, so instead of protecting the packets and sending > them to the remote end of the VPN, it passes such packets in the > clear to the local network. Yikes. That sounds better. :-) > > ==> note that the packets end up in the local network only if there is the > on-link assumption, or someone hijacking the traffic through advertising a > prefix, right? Right, we should make that clearer. > > 3.3.1 Mitigating Security Risks > > Establishing a security policy that is the same for IPv4 and IPv6 > would help mitigate this risk. > > ==> I'd state that a bit differently. The most important thing is that a > conscious decision has been made about the policy, and the policy is not > breached. It *could* be OK to specify that IPv6 is different as well.. so > consider rewording to like: > > The security policy must take a stance whether it applies equally > to both IPv4 and IPv6 traffic; the most important thing is to be aware of > the problem. However, having a similar policy is probably desirable. Agreed. > > 5. Security Considerations > > This document raises security concerns in Section 3.3. > > ==> this needs improvement, but may be good enough for now.. Yes, we're open to suggestions here. > > editorial > --------- > > ==> one should probably consider using the compact option of xml2rfc, > especially because the sections at the end are very short. Ok, I'll try that. > > Dual Stack IPv6 on by Default > > ==> s/Dual/Issues with Dual/ ? Ok. > > depends on security policy enforced somewhere else on the network > (such as from a firewall), then there is potential for new attacks > > ==> s/from/in/ Ok. Thank you, -Seb From owner-v6ops@ops.ietf.org Mon Nov 17 15:08:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02087 for ; Mon, 17 Nov 2003 15:08:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALpd3-000GzF-21 for v6ops-data@psg.com; Mon, 17 Nov 2003 20:05:45 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALpcr-000GyA-5k for v6ops@ops.ietf.org; Mon, 17 Nov 2003 20:05:33 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAHK50c25003; Mon, 17 Nov 2003 12:05:00 -0800 X-mProtect: <200311172005> 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 smtpdCQSaLe; Mon, 17 Nov 2003 12:04:59 PST Message-ID: <3FB92B9A.8020409@iprg.nokia.com> Date: Mon, 17 Nov 2003 12:12: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: Eddie Kohler CC: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues References: <200311150304.hAF34uIe031104@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eddie, A transport protocol that is smart enough to react to the receipt of CE packets should also be smart enough to figure out the size of the largest piece of data that can traverse the network without incurring fragmentation. Such a "smart transport" should be able to figure this out with *no* feedback from unreliable and untrustworthy ICMP messages from the network if the example from Packetization Layer Path MTU Discovery (PLPMTUD) is taken. So, if the ICMP's are unneeded, I believe it is desireable to have a way to turn them off. This would serve the beneficial purpose of reducing the overall congestion in the Internet as deployment of transports that don't need the ICMPs ramps up Thanks - Fred ftemplin@iprg.nokia.com Eddie Kohler wrote: >> A packetization layer should set an ECN codepoint in >> the packets it sends IFF it is also doing Packetization >> Layer Path MTU Discovery (PLPMTUD) and is not >> expecting to get ICMP's back from the network in >> response to too-large packets being dropped. >> >> > >Why overload the ECN bit this way? ECN should be used to indicate >end-to-end congestion control compliance. In fact RFC 3168 requires that: >"... the transport protocol must be capable of reacting appropriately to >the receipt of CE packets." THat's independent of MTU discovery, or at >least should be pointed out. > >Eddie > > From owner-v6ops@ops.ietf.org Mon Nov 17 16:10:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05000 for ; Mon, 17 Nov 2003 16:10:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALqaG-000L0J-32 for v6ops-data@psg.com; Mon, 17 Nov 2003 21:06:56 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALqZu-000Kz3-S8 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 21:06:34 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 13:14:38 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHL6Ww5001149; Mon, 17 Nov 2003 13:06:32 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANQ72603; Mon, 17 Nov 2003 13:06:31 -0800 (PST) Date: Mon, 17 Nov 2003 13:06:28 -0800 (PST) From: Suresh Satapati To: Pekka Savola cc: "Karim El-Malki (HF/EAB)" , "'Randy Bush'" , v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, > I hijacked the thread to bring up a point about IMS/SIP transition in the > 3GPP analysis document as it is now.. > > On Fri, 14 Nov 2003, Suresh Satapati wrote: > > This whole "subset applicability" argument stems from incorrect > > assumption that NAT-PT (RFC 2766) mandates DNS-ALG. > > Maybe, maybe not.. > > > In the past for v4 land, ALGs have been specified in separate documents. > > For e.g. RFC 2663/3022 clearly defines the role of "NAT", and for > > DNS-ALG there is RFC 2694. > > Yes, but then again, you don't need DNS-ALG in the v4<->v4 NAT, because > the destination address families are the same. On the other hand, you I am afraid you are *wrong*. DNS-ALG is not used *merely* for translation between address families. DNS-ALG is used to translate addresses contained in PTR queries and any addresses in DNS responses (like Answer, Additional RRs). The translation could be be replacing a private (rfc 1918) address w/ a public address. This has been extended to v6<->v4, where an IPv6 address is being replaced w/ an IPv4 one. > *do* need it in NAT-PT (or, you have to get the corresponding > functionality in some other way, e.g. manual configuration). > > But that aside... > > The critical point, I think, is whether the 3GPP analysis about IMS > interworking is written so that it recommends NAT-PT. Personally, I don't > think we should do that. I think IMS interworking is indeed better understood by 3GPP folks. Let's not add to confusion w/ personal opinions. > > Instead, we should defer the problem to a SIP working group (SIPPING?) to > figure out.. because *they* will be using SIP for interaction, and they > know best which kind of solution they'd need (whether based on NAT-PT or No concerns on defering the problem to SIP folks, as long as we agree what the problem is. If the problem is figuring out the bindings during SIP signalling through an external mechanism, then yes I agree. That is all to the problem. Defining a translator that uses those bindings to do header translation has already been defined in RFC2766. SIP wg. should not invent another one. > something else). I don't think v6ops has the expertise to specify which > method would be most appropriate in this SIP/IMS internetworking scenario. See my point above. -- From owner-v6ops@ops.ietf.org Mon Nov 17 16:41:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07088 for ; Mon, 17 Nov 2003 16:41:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALr4m-000N0A-IP for v6ops-data@psg.com; Mon, 17 Nov 2003 21:38:28 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALr4P-000MxE-Ku for v6ops@ops.ietf.org; Mon, 17 Nov 2003 21:38:05 +0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAHLbvxA008212; Mon, 17 Nov 2003 13:37:58 -0800 (PST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAHLbvbx025458; Mon, 17 Nov 2003 16:37:57 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id hAHLbvid008852; Mon, 17 Nov 2003 16:37:57 -0500 (EST) Message-Id: <200311172137.hAHLbvid008852@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Pekka Savola cc: v6ops@ops.ietf.org From: Sebastien Roy Subject: Re: onlinkassumption-00 comments In-Reply-To: Message from Pekka Savola of "Sat, 15 Nov 2003 14:24:39 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Nov 2003 16:37:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk pekkas@netcore.fi wrote: > substantial > ----------- > > 1) I believe the document should try to say more clearly in which practical > scenarios this problem at least surfaces at, like in the abstract (and > similar in the introduction): > > 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. > > to: > > 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 is particularly problematic with > IPv6-capable nodes which do not have IPv6 connectivity, e.g., a default > router. Agreed. > > 2) this is not so relevant for this particular draft, but maybe for the > generic on-by-default document: > > The unreachability determination for a destination as it pertains to > this rule is an implementation detail. One implementable method is > to do a simple forwarding table lookup on the destination, and to > deem the destination as reachable if the lookup succeeds. > > ==> the interesting question is, how would this work without an on-link > assumption? For example, if default route would exist, but the router would > go down, would a destination be considered unreachable if the Neighbor > Discovery goes into a state where it's clear the destination is not > reachable? I suppose not since the default route isn't removed until the router lifetime expires. That's a drawback to this approach, it's subject to the effective maintenance of the forwarding table. There might be a better way of doing rule 1, this was one example. > For that matter, I wonder how that info would be passed down to > getaddrinfo in libc in any case... :-/ That's an implementation detail. I can think of a number of ways of doing it, one of which is described in the 1st paragraph of section 8 in rfc3484. > > 3) The SEND threat could very well be moved under section 3 as a subsection > of its own? Ok. > > semi-editorial > -------------- > > on-link until at least address resolution has failed, which is no > less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER) > > ==> isn't this four seconds, i.e., (MAX_MULTICAT_SOLICIT + 1) * > RETRANS_TIMER .. remember that the last retransmission attempt has to time > out as well before giving up ? I believe this issue has already been addressed. For completeness, here's the text from rfc2461 section 7.2.2: If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT solicitations, address resolution has failed. The sender MUST return ICMP destination unreachable indications with code 3 (Address Unreachable) for each packet queued awaiting address resolution. > > 2. Attempt to resolve the destination on every link. > > If the destination is indeed on-link, the first option may not > succeed since the wrong link could be picked. The second option > would always succeed in reaching the destination (assuming that it's > reachable) but is more complex to implement. > > ==> the good question would be what would happen if the address was resolved > on two links and there was a response from both! duplicating the packet, > picking one etc. -- doesn't really work! Good point, I'll add that in. > > 4. Conclusion > > ==> instead of just deleting everything related to the on-link assumption, > it may be reasonable to suggest some summary of the problems or that in > previous versions of the specification, the behaviour was different.. But > that's likely to be ironed out with IPv6 WG. I'm not sure I completely understand the problem you're bringing up. Are you worried that the conclusion won't make sense once the IPv6 WG updates Neighbor Discovery with these suggestions? > > 5. Security Considerations > > VPN case > > ==> does this (the cisco vpn issue?) need more elaboration here? I don't have objections to elaborating. What do you think would be useful? > > editorial > --------- > > ==> there are so many empty lines here, so I suggest using the "compact" > mode of xml2rfc (if that's what you're using). Yes, that's how I generated the drafts. I'll try the compact mode. > > Internet-Draft On-Link Assumption August 2003 > > ==> I'd use a bit longer "Short name", like "On-Link Assumption Harmful" Agreed. > > 2. Background > > ==> s/Background/Background to the Onlink Assumption/ Agreed. > > For > example, two systems that are manually configured with global > addresses while on separate links are then plugged in back-to-back. > They can still communicate with each other via their global addresses > because they'll correctly assume that each is on-link. > > ==> is there something missing after "while ..." -- I can't quite parse > this? I don't think so. Removing the cosmetic bits in the sentence boils it down to: "two systems that are configured while on separate links are then plugged in back-to-back". While they were on separate links, they were configured. They were then plugged in back-to-back. > > least one reachable IPv4 address, the delay associated with NUD of > > ==> s/NUD/Neighbor Unreachability Detection (NUD)/ O.k. > > 4. Conclusion > > ==> s/Conclusion/Proposed Changes to RFC2461/ ? Yes, that makes it more clear. Thank you, -Seb From owner-v6ops@ops.ietf.org Mon Nov 17 17:27:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09991 for ; Mon, 17 Nov 2003 17:27:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALrm5-000Pxv-3C for v6ops-data@psg.com; Mon, 17 Nov 2003 22:23:13 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALrlq-000Pw5-Hd; Mon, 17 Nov 2003 22:22:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHMMBH07003; Tue, 18 Nov 2003 00:22:11 +0200 Date: Tue, 18 Nov 2003 00:22:11 +0200 (EET) From: Pekka Savola To: Suresh Satapati cc: "Karim El-Malki (HF/EAB)" , "'Randy Bush'" , Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Suresh Satapati wrote: > > Yes, but then again, you don't need DNS-ALG in the v4<->v4 NAT, because > > the destination address families are the same. On the other hand, you > > I am afraid you are *wrong*. > > DNS-ALG is not used *merely* for translation between address families. > DNS-ALG is used to translate addresses contained in PTR queries and any addresses > in DNS responses (like Answer, Additional RRs). The translation could be > be replacing a private (rfc 1918) address w/ a public address. Again, it is not required. Many NAT boxes do implement this, but many others do not. IPv4 NAT is fully functional without a DNS ALG. > This has been extended to v6<->v4, where an IPv6 address is being > replaced w/ an IPv4 one. Right, but you cannot implement NAT-PT without DNS-ALG, or something to replace the functionality (whereas with v4 NAT, there is no need for the functionality). > > Instead, we should defer the problem to a SIP working group (SIPPING?) to > > figure out.. because *they* will be using SIP for interaction, and they > > know best which kind of solution they'd need (whether based on NAT-PT or > > No concerns on defering the problem to SIP folks, as long as we agree what > the problem is. If the problem is figuring out the bindings during SIP > signalling through an external mechanism, then yes I agree. That is all to > the problem. > > Defining a translator that uses those bindings to do header translation > has already been defined in RFC2766. SIP wg. should not invent another > one. I'm not sure actually what the problem is. All it is that folks think that an optional mechanism for v6-only SIP <-> IPv4 SIP should be specified. I don't personally care much for the details, but the SIP folks probably know better which kind of tool might solve the problem. If it's sufficiently close to NAT-PT, why not reuse parts of it and specify something to create the mappings; if not, maybe it's worth doing something else. I just don't think this WG is the right place to define 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 Nov 17 17:34:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10223 for ; Mon, 17 Nov 2003 17:34:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALrtu-0000PZ-TP for v6ops-data@psg.com; Mon, 17 Nov 2003 22:31:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALrti-0000Oq-0z for v6ops@ops.ietf.org; Mon, 17 Nov 2003 22:31:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHMV2u07184; Tue, 18 Nov 2003 00:31:02 +0200 Date: Tue, 18 Nov 2003 00:31:02 +0200 (EET) From: Pekka Savola To: Sebastien Roy cc: v6ops@ops.ietf.org Subject: Re: onlinkassumption-00 comments In-Reply-To: <200311172137.hAHLbvid008852@strat.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Just responding to a few comments which were maybe still a bit unclear.. On Mon, 17 Nov 2003, Sebastien Roy wrote: > > 4. Conclusion > > > > ==> instead of just deleting everything related to the on-link assumption, > > it may be reasonable to suggest some summary of the problems or that in > > previous versions of the specification, the behaviour was different.. But > > that's likely to be ironed out with IPv6 WG. > > I'm not sure I completely understand the problem you're bringing up. Are > you worried that the conclusion won't make sense once the IPv6 WG updates > Neighbor Discovery with these suggestions? Sorry for being unclear.. wrote up the comments too fast I guess. My point was that as RFC2461 has been Draft Standard since 1998, there are a lot of implementations out there with the previous behaviour. We (probably) can't just go and remove every references to it, like it never existed. We'd probably need to add a very short summary (what has changed, and why) and discussion in ND2461bis and a pointer to this document. What I was saying that we could either spell the issue in more detail at this phase in this document, or wait until IPv6 WG resolves RFC2461bis issue (assuming that'd be done soon), and look what kind of text to copy from there to over here.. > > 5. Security Considerations > > > > VPN case > > > > ==> does this (the cisco vpn issue?) need more elaboration here? > > I don't have objections to elaborating. What do you think would be > useful? First, I was not sure which issue you were referring to. The VPN scenario described in the v6onbydefault document, or something else? In any case, at least a couple of lines would be useful :-) > > For > > example, two systems that are manually configured with global > > addresses while on separate links are then plugged in back-to-back. > > They can still communicate with each other via their global addresses > > because they'll correctly assume that each is on-link. > > > > ==> is there something missing after "while ..." -- I can't quite parse > > this? > > I don't think so. Removing the cosmetic bits in the sentence boils it > down to: "two systems that are configured while on separate links are > then plugged in back-to-back". While they were on separate links, > they were configured. They were then plugged in back-to-back. Ok. Maybe reword the first sentence to: For example, consider the case where two systems on separate links are manually configured with global addresses and are then plugged in back-to-back. maybe that would be a bit easier-to-read sentence? -- 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 Nov 17 17:52:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11118 for ; Mon, 17 Nov 2003 17:52:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALsBA-0001ZY-Nz for v6ops-data@psg.com; Mon, 17 Nov 2003 22:49:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALsAx-0001Yf-5b for v6ops@ops.ietf.org; Mon, 17 Nov 2003 22:48:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHMmq907553; Tue, 18 Nov 2003 00:48:52 +0200 Date: Tue, 18 Nov 2003 00:48:52 +0200 (EET) From: Pekka Savola To: Sebastien Roy cc: v6ops@ops.ietf.org Subject: Re: v6onbydefault-00 comments In-Reply-To: <200311171959.hAHJxVid008399@strat.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for the quick replies, Sebastien. A few additional comments inline to the open issues.. On Mon, 17 Nov 2003, Sebastien Roy wrote: > > Fixing the destination address selection mechanism by adding such a > > rule is only a mitigating factor if applications use standard name > > resolution API's that implement this mechanism, and these > > applications try addresses in the order returned. This may not be an > > acceptable assumption in some cases, as there are applications that > > use hard coded addresses and address search orders (DNS resolver is > > one example), and/or literal addresses passed in from the user. Such > > applications will obviously be subject to whatever connection delays > > are associated with attempting a connection to an unreachable > > destination. This is discussed in more detail in the next few > > sections. > > > > ==> first, destination address selection is done w/ getaddrinfo(), so if > > apps use that (after an added rule), they're OK (so, isn't the meaning of > > the first sentence reversed?) > > What I meant to say was that all bets are off if applications don't use > destination address selection. Is that not how you interpreted the > sentence? Not really.. maybe try rewording to something like: Applications which do not use getaddrinfo() for name resolution would naturally not profit from such rules, but such applications must implement similar mechanisms to get destination address selection in the first place. One special case is the DNS stub resolver. When using a single address, whether obtained from DNS or as a literal address, there is no ordering to be done even if it was possible, and either the session suffers from delays trying to connect to an unreachable destination or it works. This is discussed in more detail in the next few sections. ... might need tuning, but maybe closer how I read that paragraph? > > ==> isn't the DNS resolver implementation itself quite bit of a special case > > here? > > Maybe, and maybe this is the wrong context to be talking about the > resolver's potential problems. In any case, shouldn't the resolver be > doing something more useful with that list of server addresses other > than try them in round-robin fashion? If none of the IPv6 servers are > reachable, should it ever bother trying them? It would certainly make sense to keep some kind of cache about DNS server addresses to avoid timeouts when one of them is out, but that's probably outside of the scope of this document (if I understood you correctly).. > > I'm not sure if I understand the problem correctly: > > > > - if there is an entry in default router list, on-link assumption is not > > done, and all the packets w/o more specifics go to the router, and > > - if there is not an entry in the default router list, but there are more > > specific routes through a router, the on-link assumption is valid for the > > packets which do not match the more specific routes. > > > > This seems like the desired behaviour. Did I miss something? > > That's the desired behaviour, but the ND spec never mentions that more > specific routes should ever be considered by hosts. According to the > conceptual model for hosts in rfc2461, hosts should either consult > their default router list for sending packets off-link, or send > packets on-link. Whoops. OK, maybe it's worth stating here explicitly. Are you subscribed to IPv6 WG list, and would like to file an issue for revising in 2461bis ? > > 6) Transport protocol robustness section has: > > > > It should abort a > > connection in those states when receiving any ICMPv6 Destination > > Unreachable message. It should make this distinction when a > > connection is in any other state. > > > > ==> shouldn't the should in the last sentence actually be "should not" ? > > I don't think so. For example, a connection in ESTABLISHED state > shouldn't be aborted if an ICMPv6 "soft error" is received. So there > _should_ be a distinction between soft and hard errors for states other > than SYN-SENT. Oh. I read the "distinction" differently, referring to the previous sentence. Consider rewording for clarity? > > 7) 3.2.1 Dealing with Poor IPv6 Network Performance > > > > ... one other way to deal with this could be something like: > > > > Another approach could be to restrict IPv6 just to a smaller, better > > working address range, e.g., the internal network or nationally > > interconnected networks, but this can't be a long term solution. > > I'm not sure I completely understand what you mean be "restrict", but > I'll assume for the moment that you mean restrict the addresses > returned by name lookups... Many enterprise networks already have > neutered DNS deployments where the internal servers only answer to > queries for internal records, so your idea might be doable there. How > would this be done in an ISP? DNS-based scoping is one approach.. but probably criticized by many. What I had in mind was that if ICMPv6 unreachable would abort a connection, it would be enough to just not have a default route in the ISP's backbone -- every connection inside the ISP would work just fine, those trying the other addresses would go as far as the backbone, would get an ICMP error, and would get aborted. If I'd have to deploy v6 in "semi-production" fashion inside a v6 enterprise, that's how I'd probabyl do it. Just use v6 for internal communications where it works fine.. > > An example of such a situation is a node which obtains IPv4 > > connectivity natively through an ISP, but whose IPv6 connectivity is > > obtained through a configured tunnel whose other endpoint is > > topologically such that most IPv6 communication is done through > > triangular routes. Operational experience on the 6bone shows that > > > > ==> s/triangular routes/triangular IPv4 topology/ ? > > How about, "triangular IPv4 paths"? The word "topologically" already > exists earlier in the sentence. 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 Mon Nov 17 18:07:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12153 for ; Mon, 17 Nov 2003 18:07:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALsQ0-0002R6-2J for v6ops-data@psg.com; Mon, 17 Nov 2003 23:04:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALsPm-0002QY-J0 for v6ops@ops.ietf.org; Mon, 17 Nov 2003 23:04:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHN4BW08023; Tue, 18 Nov 2003 01:04:11 +0200 Date: Tue, 18 Nov 2003 01:04:11 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639912@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote: > There are some differences between unmanaged and 3gpp. For example the > "gateway" (when it runs NAT) in Unmanaged scenarios puts some restrictions > on the mechanisms that can be used. The same case does not apply to a > 3gpp UE (which is not going to run NAT). So cases which Unmanaged considers > of limited applicability are instead applicable here (e.g. single private > v4 host connected to v6 ISP over a v4-only gateway/connection). IMO we should > qualify the above statement further by saying that the 3gpp scenarios involve > single priv. v4 host + ipv4 gateway cases, therefore some of the solutions > which are recommended in Unmanaged are not equally recommended here. However > on the other hand that seems to be a reason for considering them in the 3gpp > analysis doc in the first place... Note that we're referring to the unmanaged case only in the case where the user's own 3GPP operator does not support v6 at all. I don't think this is something 3GPP analysis should be considering at all, so I'm OK with dropping the references as well. We'll try try to address the more generic 3GPP case below.. Could you suggest text/modifications? > I don't think it is feasible to assume that we can easily set up > configured tunnels in UEs without any user intervention. It would > certainly need some automated mechanism which is probably what you mean > by "easily manage the setup". Yep, that's what I mean. But I disagree that we couldn't make it easy, requiring no user intervention. Really, this shouldn't be any different from e.g. configuring the APN, or some other configuration stuff! > Without having to specify a new one All this might need is some kind of "interface" to help the management and/or someone to figure out the gritty details.. > there > are existing mechanisms for this that can make things easier and more > transparent to users. I think it makes sense to refer to ISATAP as an > existing solution that addresses this problem. I would suggest to add > to the end of the parag above: [...] .. I think ISATAP is definitely an overkill in this specific scenario. After all, this is just a roaming case, when the operator (either local or remote) doesn't support IPv6 PDP context at all, despite the encouragement. Not a majority case in any way -- the less complex we can make it, the better. A simple way to just set up a configured tunnel *) would hit the nail on the head in this specific scenario IMHO. *) the important point for the host is to get the knowledge of the v4 tunnel end-point somehow, and the server to get the IP address of the UE (or the PC behind that). I don't know 3GPP interactions in detail but that should be pretty basic stuff (but maybe still worth spelling out in the document). The rest would be pretty much seamless. -- 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 Nov 17 18:39:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14084 for ; Mon, 17 Nov 2003 18:39:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALsuK-00049R-KL for v6ops-data@psg.com; Mon, 17 Nov 2003 23:35:48 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALsu8-00048f-7s for v6ops@ops.ietf.org; Mon, 17 Nov 2003 23:35:36 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAHNZLY18868; Mon, 17 Nov 2003 15:35:21 -0800 X-mProtect: <200311172335> 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 smtpddOc19U; Mon, 17 Nov 2003 15:35:19 PST Message-ID: <3FB95CE8.3060604@iprg.nokia.com> Date: Mon, 17 Nov 2003 15:42:32 -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: "Karim El-Malki (HF/EAB)" , v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > > > >>there >>are existing mechanisms for this that can make things easier and more >>transparent to users. I think it makes sense to refer to ISATAP as an >>existing solution that addresses this problem. I would suggest to add >>to the end of the parag above: >> >> >[...] > >.. I think ISATAP is definitely an overkill in this specific scenario. > If by "overkill" you mean that it *works better* than the other alternatives, then I agree since ISATAP is more automatic, agile and efficient than the other alternatives. But, this would amount to an attarctive incentive and not a negative as is usually implied by the term "overkill". Otherwise, I have no idea how you could come up with the term "overkill"; perhaps you could explain? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Nov 18 01:02:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24034 for ; Tue, 18 Nov 2003 01:02:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALyr2-000MjQ-7u for v6ops-data@psg.com; Tue, 18 Nov 2003 05:56:48 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALyqq-000Mis-Bb for v6ops@ops.ietf.org; Tue, 18 Nov 2003 05:56:36 +0000 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAI5uSUP019176; Mon, 17 Nov 2003 21:56:29 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with SMTP id hAI5uR7m338766; Mon, 17 Nov 2003 21:56:28 -0800 (PST) Date: Mon, 17 Nov 2003 21:55:14 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Tim Chown Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20031117152157.GA2162@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > We should progress v4 compatible deprecation if this isn't in here. Need to send a comment to ipv6 WG on addr-arch-v4 to get them deprecated. Do you want to do that? Erik From owner-v6ops@ops.ietf.org Tue Nov 18 03:59:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10714 for ; Tue, 18 Nov 2003 03:59:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM1cb-0004e4-Cb for v6ops-data@psg.com; Tue, 18 Nov 2003 08:54:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM1cO-0004dU-On for v6ops@ops.ietf.org; Tue, 18 Nov 2003 08:53:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAI8rj316229; Tue, 18 Nov 2003 10:53:45 +0200 Date: Tue, 18 Nov 2003 10:53:45 +0200 (EET) From: Pekka Savola To: Fred Templin cc: "Karim El-Malki (HF/EAB)" , Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE In-Reply-To: <3FB95CE8.3060604@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Fred Templin wrote: > >.. I think ISATAP is definitely an overkill in this specific scenario. > > If by "overkill" you mean that it *works better* than the other > alternatives, then I agree since ISATAP is more automatic, agile and > efficient than the other alternatives. But, this would amount to an > attarctive incentive and not a negative as is usually implied by the > term "overkill". Yes, in this particular case, ISATAP provides more features than I believe we need (such as, automatic tunneling between ISATAP nodes, prefix delegation support, etc.). Thus, a more simplified mechanism would be better. I'm also not confortable running ISATAP over administrative borders, as has been suggested here. This applies in a similar fashion and to a lesser extent also to the unmanaged case where the ISP is doing NAT but wanting to offer IPv6. -- 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 Nov 18 05:41:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13723 for ; Tue, 18 Nov 2003 05:41:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM3F7-0009j7-MT for v6ops-data@psg.com; Tue, 18 Nov 2003 10:37:57 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM3EG-0009aj-KS for v6ops@ops.ietf.org; Tue, 18 Nov 2003 10:37:04 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIAb2I2000653; Tue, 18 Nov 2003 11:37:02 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 11:36:56 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F563991A@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues Date: Tue, 18 Nov 2003 11:36:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > You could activate pdp contexts in advance or you may do > > that based on app.s and in special cases (above) peer > > addresses. The "in advance" option is attractive but there > > are cases where it doesn't work well: if the application needs > > a pdp context with certain QoS and APN (e.g. corporate) > > characteristics that is not currently active. So I am not > > convinced that we should be making the above point. > > I'm not sure how common those cases are. I'd assume they are not too > common. Therefore, it would seem to clarify better how the > PDP contexts > are typically used. > > Could you care to try to suggest a different reword to clarify the > different considerations with PDP context activation? I would just tag a sentence to the end of the parag you suggested: If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may activate the appropriate PDP context depending on the type of application it has started; it may also make sense to open both PDP contexts in advance, before they are used, because the activation of a context may take a relatively long time. If both PDP Contexts are not opened in advance then it may be necessary for an application to trigger the creation of a new PDP Context when it determines that a communication to an IPv6 peer is required and an IPv6 PDP Context is not available. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 05:50:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13943 for ; Tue, 18 Nov 2003 05:50:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM3PS-000ANS-Uo for v6ops-data@psg.com; Tue, 18 Nov 2003 10:48:38 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM3PH-000AMm-1e for v6ops@ops.ietf.org; Tue, 18 Nov 2003 10:48:27 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA28013 for ; Tue, 18 Nov 2003 10:48:25 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 KAA10627 for ; Tue, 18 Nov 2003 10:48:25 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAIAmPX19439 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 10:48:25 GMT Date: Tue, 18 Nov 2003 10:48:24 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE Message-ID: <20031118104824.GM18738@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <3FB95CE8.3060604@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Nov 18, 2003 at 10:53:45AM +0200, Pekka Savola wrote: > > I'm also not confortable running ISATAP over administrative borders, as > has been suggested here. This applies in a similar fashion and to a > lesser extent also to the unmanaged case where the ISP is doing NAT but > wanting to offer IPv6. OK, so define ESATAP :) I have always viewed ISATAP as an intra-site tool. As such its use does not impact the global architecture in the way that 6to4 or Teredo do, which is a plus point in favour of its adoption... Tim From owner-v6ops@ops.ietf.org Tue Nov 18 05:52:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13993 for ; Tue, 18 Nov 2003 05:52:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM3R3-000AUA-Ot for v6ops-data@psg.com; Tue, 18 Nov 2003 10:50:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM3Qr-000ASC-Da for v6ops@ops.ietf.org; Tue, 18 Nov 2003 10:50:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIAo3N17822; Tue, 18 Nov 2003 12:50:03 +0200 Date: Tue, 18 Nov 2003 12:50:03 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F563991A@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > Could you care to try to suggest a different reword to clarify the > > different considerations with PDP context activation? > > I would just tag a sentence to the end of the parag you suggested: > > If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may > activate the appropriate PDP context depending on the type of > application it has started; it may also make sense to open both PDP > contexts in advance, before they are used, because the activation of > a context may take a relatively long time. If both PDP Contexts are > not opened in advance then it may be necessary for an application > to trigger the creation of a new PDP Context when it determines > that a communication to an IPv6 peer is required and an IPv6 PDP > Context is not available. Ok. The last part is a bit long. I tried to summarize it a bit and make it more generic. How about: If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may activate the appropriate PDP context depending on the type of application it has started; it may also make sense to open both PDP contexts in advance, before they are used, because the activation of a context may take a relatively long time. However, if the appropriate PDP context has not been activated before trying to communicate with a peer, the application may trigger the activation of the required PDP context type. OK or suggest replacement? -- 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 Nov 18 06:08:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14304 for ; Tue, 18 Nov 2003 06:08:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM3gE-000Bba-SG for v6ops-data@psg.com; Tue, 18 Nov 2003 11:05:58 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM3g1-000Bab-OJ for v6ops@ops.ietf.org; Tue, 18 Nov 2003 11:05:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIB2D317971; Tue, 18 Nov 2003 13:02:13 +0200 Date: Tue, 18 Nov 2003 13:02:12 +0200 (EET) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE In-Reply-To: <20031118104824.GM18738@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Tim Chown wrote: > On Tue, Nov 18, 2003 at 10:53:45AM +0200, Pekka Savola wrote: > > > > I'm also not confortable running ISATAP over administrative borders, as > > has been suggested here. This applies in a similar fashion and to a > > lesser extent also to the unmanaged case where the ISP is doing NAT but > > wanting to offer IPv6. > > OK, so define ESATAP :) > > I have always viewed ISATAP as an intra-site tool. As such its use > does not impact the global architecture in the way that 6to4 or Teredo do, > which is a plus point in favour of its adoption... I'll respond, just in case you were serious.. :-) The point of ISATAP (as I see it) to run it as an intra-site tool. It could be rather useful there, especially if there are VPNs and such where you can't use VLANs etc.. However, rather than specifying something similar that runs inter-domain, we should focus on determining what is actually needed when running inter-domain. I.e., start from a clean slate instead of trying to work ISATAP towards being an inter-domain tool. Note: ISATAP however is less intrusive for the global architecture, as it uses the interface ID for its operations, does not require a prefix -- so it's transparent to the rest of the 'net users, rather than 6to4/Teredo. So, it's not IMHO totally fair to compare ISATAP to 6to4/Teredo w/ interdomain architecture. -- 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 Nov 18 06:16:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14600 for ; Tue, 18 Nov 2003 06:16:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM3nw-000C14-79 for v6ops-data@psg.com; Tue, 18 Nov 2003 11:13:56 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM3nk-000Byi-5j for v6ops@ops.ietf.org; Tue, 18 Nov 2003 11:13:44 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA28954 for ; Tue, 18 Nov 2003 11:13:42 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 LAA12132 for ; Tue, 18 Nov 2003 11:13:42 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAIBDgQ20221 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 11:13:42 GMT Date: Tue, 18 Nov 2003 11:13:42 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE Message-ID: <20031118111342.GU18738@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20031118104824.GM18738@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Nov 18, 2003 at 01:02:12PM +0200, Pekka Savola wrote: > > I'll respond, just in case you were serious.. :-) I wasn't :) > The point of ISATAP (as I see it) to run it as an intra-site tool. It > could be rather useful there, especially if there are VPNs and such where > you can't use VLANs etc.. However, rather than specifying something > similar that runs inter-domain, we should focus on determining what is > actually needed when running inter-domain. I agree. VLANs require an amount of administrative configuration, and is more aimed at enabling whole subnets/links, whereas ISATAP is more "opportunistic" and aimed at sparse/scattered hosts in a site. > Note: ISATAP however is less intrusive for the global architecture, as it > uses the interface ID for its operations, does not require a prefix -- so > it's transparent to the rest of the 'net users, rather than 6to4/Teredo. > So, it's not IMHO totally fair to compare ISATAP to 6to4/Teredo w/ > interdomain architecture. True. But we should consider that for any proposal too. I'll add it to the tunneling considerations draft (I propose widening the scope of that draft to general tunneling rather than unmanaged network-specific). Tim From owner-v6ops@ops.ietf.org Tue Nov 18 06:31:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16500 for ; Tue, 18 Nov 2003 06:31:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM42t-000D5P-2J for v6ops-data@psg.com; Tue, 18 Nov 2003 11:29:23 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM42g-000D4c-Pq for v6ops@ops.ietf.org; Tue, 18 Nov 2003 11:29:10 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIBT9I2016036; Tue, 18 Nov 2003 12:29:09 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 12:29:09 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F563991D@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues Date: Tue, 18 Nov 2003 12:28:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Ok. The last part is a bit long. I tried to summarize it > a bit and make > it more generic. How about: > > If the 3GPP network supports both IPv4 and IPv6 PDP > contexts, the UE may > activate the appropriate PDP context depending on the type of > application it has started; it may also make sense to > open both PDP > contexts in advance, before they are used, because the > activation of > a context may take a relatively long time. However, if > the appropriate PDP context has not been activated > before trying to > communicate with a peer, the application may trigger the > activation of > the required PDP context type. > > OK or suggest replacement? OK. From owner-v6ops@ops.ietf.org Tue Nov 18 07:52:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19194 for ; Tue, 18 Nov 2003 07:52:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM5GN-000Hh7-PC for v6ops-data@psg.com; Tue, 18 Nov 2003 12:47:23 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM5G9-000He6-0v for v6ops@ops.ietf.org; Tue, 18 Nov 2003 12:47:09 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAICl7I2010989; Tue, 18 Nov 2003 13:47:07 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 13:47:07 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F563991E@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE Date: Tue, 18 Nov 2003 13:46:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > There are some differences between unmanaged and 3gpp. For > example the > > "gateway" (when it runs NAT) in Unmanaged scenarios puts > some restrictions > > on the mechanisms that can be used. The same case does not > apply to a > > 3gpp UE (which is not going to run NAT). So cases which > Unmanaged considers > > of limited applicability are instead applicable here (e.g. > single private > > v4 host connected to v6 ISP over a v4-only > gateway/connection). IMO we should > > qualify the above statement further by saying that the > 3gpp scenarios involve > > single priv. v4 host + ipv4 gateway cases, therefore some > of the solutions > > which are recommended in Unmanaged are not equally > recommended here. However > > on the other hand that seems to be a reason for > considering them in the 3gpp > > analysis doc in the first place... > > Note that we're referring to the unmanaged case only in the > case where the > user's own 3GPP operator does not support v6 at all. I > don't think this > is something 3GPP analysis should be considering at all, so > I'm OK with > dropping the references as well. OK since I don't think that a comparable scenario is covered in Unmanaged. > > We'll try try to address the more generic 3GPP case below.. > > Could you suggest text/modifications? OK, I'll send something out. > > > I don't think it is feasible to assume that we can easily set up > > configured tunnels in UEs without any user intervention. It would > > certainly need some automated mechanism which is probably > what you mean > > by "easily manage the setup". > > Yep, that's what I mean. But I disagree that we couldn't > make it easy, > requiring no user intervention. Really, this shouldn't be > any different > from e.g. configuring the APN, or some other configuration stuff! In fact the config of the APN etc. has been a problem all along and we should not make it harder by overloading it with more things to configure. > > > there > > are existing mechanisms for this that can make things > easier and more > > transparent to users. I think it makes sense to refer to > ISATAP as an > > existing solution that addresses this problem. I would > suggest to add > > to the end of the parag above: > [...] > > .. I think ISATAP is definitely an overkill in this specific > scenario. > > After all, this is just a roaming case, when the operator > (either local or > remote) doesn't support IPv6 PDP context at all, despite the > encouragement. Not a majority case in any way -- the less > complex we can > make it, the better. A simple way to just set up a > configured tunnel *) > would hit the nail on the head in this specific scenario IMHO. > > *) the important point for the host is to get the knowledge of the v4 > tunnel end-point somehow, and the server to get the IP > address of the UE > (or the PC behind that). I don't know 3GPP interactions in > detail but > that should be pretty basic stuff (but maybe still worth > spelling out in > the document). The rest would be pretty much seamless. Let's look at the requirements so as to clarify the issue once and for all. The required functions of a mechanism to solve this are: 1 - The UE gets the IPv4 tunnel endpoint address in the operator's network 2 - The UE's IPv4 (probably private) tunnel endpoint address is communicated to the network endpoint 3 - The UE gets an IPv6 address known to the network tunnel endpoint The UE and network tunnel endpoint are within the same IP (L3) domain. 2) can't be manually configured (since the UE's address is dynamically assigned for most cases) and for all three functions the least config you have to do in the UE, the better. Taking the ISATAP example: 1) is solved by using DNS or manual config, while 2) and 3) are solved by using the tunneled RA/RS mechanism. This requires little work to implement and satisfies the above. So it looks to me like ISATAP is not an overkill since it does not do more than solve the above and requires little if any config. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 07:52:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19210 for ; Tue, 18 Nov 2003 07:52:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM5It-000Huv-Sw for v6ops-data@psg.com; Tue, 18 Nov 2003 12:49:59 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM5IZ-000Htz-Ct; Tue, 18 Nov 2003 12:49:39 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAICnYSs015888; Tue, 18 Nov 2003 13:49:34 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 13:49:34 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F563991F@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Senthil Sivakumar'" Cc: "'Suresh Satapati'" , "'Randy Bush'" , v6ops@ops.ietf.org Subject: RE: NAT-PT Applicabilty for 3GPP Date: Tue, 18 Nov 2003 13:49:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >My point is that if we say NAT-PT is applicable for SIP then people > >will expect to read RFC 2766 and implement it. If they do that > >they are likely to implement a local pool of v4 addresses and a > >SIP ALG (that does SIP editing). Since SIP folks are not in favour > >of SIP editing I don't think we should say that NAT-PT is applicable > >to the SIP case. It is much cleaner to create a SIP > specific solution > >for this case that is not related to generic NAT-PT and its > problems. > > NAT-PT RFC does not specify anything about how SIP ALG/Proxy > should be > implemented. > That could be a seperate document, if one needs it. If you > want a SIP > ALG/Proxy, you > could implement as per the SIP protocol specification and > make use of the > NAT-PT > header translator functionality to let the media pass through the > translator. The applicability draft says: NA(P)T-PT may be used for header translation of IMS media traffic... That is different IMO from saying that a SIP specific solution may "make use of NAT-PT header translation functionality" as you have above which I could agree with. Also I do not think it is as simple as implementing an external SIP Proxy according to SIP specs as you say above, since some changes to the binding mechanism is needed in the translator and some interactions with other e2e protocols may be needed. Given the discussions so far I would replace the statement in the applicability with: The SIPPING WG will be working on a solution to the 3GPP IMS translation problem which may reuse some functionality from NAT-PT. > So NAT-PT > is applicable there and that is what is noted in the applicability > statement. Re-inventing > something that has already been done seems to be a waste of time. Comments above. The issue is that there are NAT-PT problems that the SIP solution should not be inheriting. But as above, let's solve this with the SIP folks. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 07:59:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19349 for ; Tue, 18 Nov 2003 07:59:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM5QK-000ITl-25 for v6ops-data@psg.com; Tue, 18 Nov 2003 12:57:40 +0000 Received: from [192.11.226.161] (helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM5Pr-000IRC-Cr for v6ops@ops.ietf.org; Tue, 18 Nov 2003 12:57:11 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAICuek28738 for ; Tue, 18 Nov 2003 06:56:46 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Tue, 18 Nov 2003 13:41:31 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502FB7CC7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Pekka Savola , Dave Thaler Cc: v6ops@ops.ietf.org Subject: RE: [ifmib] Re: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.tx t Date: Tue, 18 Nov 2003 13:41:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ dropped ifmib and ipv6 mailing lists] I would think that the v6Ops WG was copied because it did the survey that showed the RFC2667 to be IPv6 unfriendly. Thanks, Bert > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: dinsdag 21 oktober 2003 11:38 > To: Dave Thaler > Cc: ipv6@ietf.org; v6ops@ops.ietf.org; ifmib@ietf.org > Subject: [ifmib] Re: FW: I-D > ACTION:draft-thaler-inet-tunnel-mib-00.txt > > > On Wed, 15 Oct 2003, Dave Thaler wrote: > > Forwarding this announcement to the most relevant WG's... > > > > RFC 2667, entitled "IP Tunnel MIB", only supported > > point-to-point tunnels over IPv4. This draft updates > > RFC 2667 to also support tunnels over IPv6, as well as > > tunnels which aren't just point-to-point (e.g. 6to4). > > It also clarifies the use of the ifRcvAddressTable > > for all tunnels. > > > > It uses the InetAddress types like the other MIBs > > that have been done by the IPv6MIB Design Team. > > Thanks Dave. > > Two very high-level comments. > > An obvious oversight (or intentional one :-) is that I see an IANA > registry being created, but no guidance on how new values > should be added > to it (IETF Consensus, Standards Action, FCFS, etc.) > > Also, it was not clear which WG you intend to run this > through officially. > I'm assuming ifmib. (Just trying to figure out what will be > the role of > v6ops WG in this process..) > > Pekka > > > Title : IP Tunnel MIB > > Author(s) : D. Thaler > > Filename : draft-thaler-inet-tunnel-mib-00.txt > > Pages : 26 > > Date : 2003-10-14 > > > > This memo defines a Management Information Base (MIB) for use with > > network management protocols in the Internet community. In > > particular, it describes managed objects used for managing tunnels > > of any type over IPv4 and IPv6 networks. Extension MIBs may be > > designed for managing protocol-specific objects. Likewise, > > extension MIBs may be designed for managing security-specific > > objects. This MIB does not support tunnels over non-IP networks. > > Management of such tunnels may be supported by other MIBs. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-thaler-inet-tunnel-mib-00.txt [...] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib From owner-v6ops@ops.ietf.org Tue Nov 18 08:02:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19496 for ; Tue, 18 Nov 2003 08:02:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM5SK-000IcX-Hs for v6ops-data@psg.com; Tue, 18 Nov 2003 12:59:44 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM5Rs-000IaY-IF for v6ops@ops.ietf.org; Tue, 18 Nov 2003 12:59:16 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAICxESs018830; Tue, 18 Nov 2003 13:59:14 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 13:59:14 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639920@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" , Tim Chown Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE Date: Tue, 18 Nov 2003 13:58:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A comment on Pekka's answer: > The point of ISATAP (as I see it) to run it as an intra-site > tool. It > could be rather useful there, especially if there are VPNs > and such where > you can't use VLANs etc.. However, rather than specifying something > similar that runs inter-domain, we should focus on > determining what is > actually needed when running inter-domain. > > I.e., start from a clean slate instead of trying to work > ISATAP towards > being an inter-domain tool. ISATAP tunneling in the UE is not for inter-IP-domain. There can be one or more L2 networks between the UE the ISATAP box but the UE and ISATAP box would always be in the same IP domain. Maybe this was a comment in reference to 3gpp roaming? If so I want to point out that it is L2 roaming (not L3 roaming). So there is no crossing of IP domain. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 08:40:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20382 for ; Tue, 18 Nov 2003 08:40:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM62r-000LVo-6d for v6ops-data@psg.com; Tue, 18 Nov 2003 13:37:29 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM62e-000LUk-IC for v6ops@ops.ietf.org; Tue, 18 Nov 2003 13:37:16 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAIDbE604525 for ; Tue, 18 Nov 2003 15:37:14 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Nov 2003 15:37:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Nov 2003 15:36:26 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 18 Nov 2003 15:36:26 +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: 3gpp-analysis: Recommendation on tunneling in the UE Date: Tue, 18 Nov 2003 15:36:25 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE023@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis: Recommendation on tunneling in the UE Thread-Index: AcOt0tbhM8VQyXpiQe63dolESy6nYwAAN5uw From: To: , Cc: X-OriginalArrivalTime: 18 Nov 2003 13:36:26.0126 (UTC) FILETIME=[F6C6A2E0:01C3ADD8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Karim, Pekka and others, trying to catch up this interesting discussion and making some kind of = summary: - not needing to refer to Unman scenarios&analysis - Karim provides text on tunneling (to be updated to revision -08) - Pekka's concerns on ISATAP providing more features than we need =3D> = in that case, we should document which parts of ISATAP are necessary for = the 3GPP case, i.e. making a "subset of ISATAP" may be the solution? = Shall you, Karim, also consider this point when writing your text? Furthermore, I personally don't believe that configured tunnels make a = feasible solution for this specific problem (even though they provide a = good solution for some other scenarios). You must remember the high = number of UEs and dynamic addressing. And any extra configuration effort = isn't nice for the users. If you make the extra configurations using SMS = (like configuring APN settings for different applications), that means = one SMS more. The point is: IPv6 should be as easy as possible. And still: we prefer native IPv6 communication and describe the = "tunneling in the UE" as an *optional* thing (that won't be needed any = more after GPRS networks start to widely support IPv6). That should not = make harm to anybody. Cheers, -Juha- P.S. All this discussion already shows to me that v6ops wg should start = working on transition mechanisms. This wg needs to work on issues that = are relevant for IPv6 deployment and that can help IPv6 getting = deployed. Of course, the scenarios & analysis work is important, but we = have done it already for so long time that we start to see which = mechanisms are relevant (and which aren't). IMHO, getting ISATAP = published as an RFC would be a good step towards that direction. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Karim El-Malki (HF/EAB) Sent: 18 November, 2003 14:47 To: 'Pekka Savola' Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE > On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > There are some differences between unmanaged and 3gpp. For=20 > example the > > "gateway" (when it runs NAT) in Unmanaged scenarios puts=20 > some restrictions > > on the mechanisms that can be used. The same case does not=20 > apply to a > > 3gpp UE (which is not going to run NAT). So cases which=20 > Unmanaged considers > > of limited applicability are instead applicable here (e.g.=20 > single private > > v4 host connected to v6 ISP over a v4-only=20 > gateway/connection). IMO we should > > qualify the above statement further by saying that the=20 > 3gpp scenarios involve > > single priv. v4 host + ipv4 gateway cases, therefore some=20 > of the solutions > > which are recommended in Unmanaged are not equally=20 > recommended here. However > > on the other hand that seems to be a reason for=20 > considering them in the 3gpp > > analysis doc in the first place... >=20 > Note that we're referring to the unmanaged case only in the=20 > case where the > user's own 3GPP operator does not support v6 at all. I=20 > don't think this > is something 3GPP analysis should be considering at all, so=20 > I'm OK with > dropping the references as well. OK since I don't think that a comparable scenario is covered in Unmanaged. >=20 > We'll try try to address the more generic 3GPP case below.. >=20 > Could you suggest text/modifications? OK, I'll send something out. >=20 > > I don't think it is feasible to assume that we can easily set up > > configured tunnels in UEs without any user intervention. It would > > certainly need some automated mechanism which is probably=20 > what you mean > > by "easily manage the setup".=20 >=20 > Yep, that's what I mean. But I disagree that we couldn't=20 > make it easy,=20 > requiring no user intervention. Really, this shouldn't be=20 > any different=20 > from e.g. configuring the APN, or some other configuration stuff! In fact the config of the APN etc. has been a problem all along and we should not make it harder by overloading it with more things to configure. >=20 > > there > > are existing mechanisms for this that can make things=20 > easier and more > > transparent to users. I think it makes sense to refer to=20 > ISATAP as an > > existing solution that addresses this problem. I would=20 > suggest to add > > to the end of the parag above: > [...] >=20 > .. I think ISATAP is definitely an overkill in this specific=20 > scenario. =20 >=20 > After all, this is just a roaming case, when the operator=20 > (either local or > remote) doesn't support IPv6 PDP context at all, despite the > encouragement. Not a majority case in any way -- the less=20 > complex we can > make it, the better. A simple way to just set up a=20 > configured tunnel *) > would hit the nail on the head in this specific scenario IMHO. >=20 > *) the important point for the host is to get the knowledge of the v4 > tunnel end-point somehow, and the server to get the IP=20 > address of the UE > (or the PC behind that). I don't know 3GPP interactions in=20 > detail but > that should be pretty basic stuff (but maybe still worth=20 > spelling out in > the document). The rest would be pretty much seamless. Let's look at the requirements so as to clarify the issue once and for all. The required functions of a mechanism to solve this are: 1 - The UE gets the IPv4 tunnel endpoint address in the operator's network 2 - The UE's IPv4 (probably private) tunnel endpoint address is communicated to the network endpoint 3 - The UE gets an IPv6 address known to the network tunnel endpoint The UE and network tunnel endpoint are within the same IP (L3) domain. 2) can't be manually configured (since the UE's address is dynamically assigned for most cases) and for all three functions the least config you have to do in the UE, the better. Taking the ISATAP example: 1) is solved by using DNS or manual config, while 2) and 3) are solved by using the tunneled RA/RS mechanism. This requires little work to implement and satisfies the above. So it looks to me like ISATAP is not an overkill since it does not do more than solve the above and requires little if any config. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 08:55:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20815 for ; Tue, 18 Nov 2003 08:55:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM6Gm-000MRz-WC for v6ops-data@psg.com; Tue, 18 Nov 2003 13:51:52 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM6GS-000MQU-P1 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 13:51:32 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIDodSs005655; Tue, 18 Nov 2003 14:50:39 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 14:50:39 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639921@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" , Fred Templin Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE Date: Tue, 18 Nov 2003 14:50:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Mon, 17 Nov 2003, Fred Templin wrote: > > >.. I think ISATAP is definitely an overkill in this > specific scenario. > > > > If by "overkill" you mean that it *works better* than the other > > alternatives, then I agree since ISATAP is more automatic, > agile and > > efficient than the other alternatives. But, this would amount to an > > attarctive incentive and not a negative as is usually > implied by the > > term "overkill". > > Yes, in this particular case, ISATAP provides more features > than I believe > we need (such as, automatic tunneling between ISATAP nodes, prefix > delegation support, etc.). Thus, a more simplified > mechanism would be > better. I don't think the above "extra" features are in the current ISATAP spec and agree that it should focus on the basic host-to-router mechanism. Would satisfying the above make it acceptable? I think draft-16 does that. I'll review it myself and hope the wg finds time for that too. > > I'm also not confortable running ISATAP over administrative > borders, as > has been suggested here. This applies in a similar fashion and to a > lesser extent also to the unmanaged case where the ISP is > doing NAT but > wanting to offer IPv6. Comment on this in a previous email. I don't think the 3gpp ue case involves crossing L3 admin borders. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 08:57:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20847 for ; Tue, 18 Nov 2003 08:57:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM6KT-000Mgl-96 for v6ops-data@psg.com; Tue, 18 Nov 2003 13:55:41 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM6KD-000MeX-PQ for v6ops@ops.ietf.org; Tue, 18 Nov 2003 13:55:25 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAIDtOA09683 for ; Tue, 18 Nov 2003 15:55:24 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Nov 2003 15:55:24 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 18 Nov 2003 15:55:24 +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: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] Date: Tue, 18 Nov 2003 15:55:23 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE024@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] Thread-Index: AcOtWfk/FnP+SZG+TzO32hSRA/i3iwAf46nw From: To: , Cc: , , X-OriginalArrivalTime: 18 Nov 2003 13:55:24.0240 (UTC) FILETIME=[9D250D00:01C3ADDB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all! I think there aren't any major open issues considering documenting this = case in 3GPP Analysis - we state clearly, that "dual stack" based solution is not feasible and = a translator is needed as a part of the solution "As the IMS is exclusively IPv6 [3GPP 23.221], translators have to=20 be used in the communication between the IPv6 IMS and legacy IPv4=20 hosts, i.e. making a dual stack based solution is not feasible.=20 This section aims to give a brief overview on how that interworking=20 can be handled." =20 - we document a higher level solution and refer to SIP(PING) wg to make = a generic solution "This section presents higher level details of a solution based on=20 the use of a translator and SIP ALG. [3GPPtr] provides additional=20 information and presents a bit different solution proposal based on=20 SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to=20 solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF=20 SIP wg(s)." - because NAT-PT is the closest possible (=3DPS RFC) solution to be used = in this "Interworking Unit" as a translator, we state: " We call the combined network element on=20 the edge of the IPv6-only IMS an "Interworking Unit" in this=20 document. A SIP-specific translation mechanism, which could e.g.=20 re-use limited subsets of NAT-PT [RFC2766], needs to be specified.=20 The problems related to NAT-PT are discussed in appendix A. " - Finally, I think that documenting this case in 3GPP Analysis is = important and details must not be dropped. Right? Cheers, -Juha- P.S. I still can't understand what can be so horribly bad in NAT-PT, but = let's not start that discussion using this mail thread, because it isn't = a 3GPP-specific problem. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Pekka Savola Sent: 18 November, 2003 00:22 To: Suresh Satapati Cc: Karim El-Malki (HF/EAB); 'Randy Bush'; v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] On Mon, 17 Nov 2003, Suresh Satapati wrote: > > Yes, but then again, you don't need DNS-ALG in the v4<->v4 NAT, = because > > the destination address families are the same. On the other hand, = you >=20 > I am afraid you are *wrong*. >=20 > DNS-ALG is not used *merely* for translation between address families. > DNS-ALG is used to translate addresses contained in PTR queries and = any addresses > in DNS responses (like Answer, Additional RRs). The translation could = be > be replacing a private (rfc 1918) address w/ a public address. Again, it is not required. Many NAT boxes do implement this, but many=20 others do not. IPv4 NAT is fully functional without a DNS ALG. =20 > This has been extended to v6<->v4, where an IPv6 address is being > replaced w/ an IPv4 one. Right, but you cannot implement NAT-PT without DNS-ALG, or something to replace the functionality (whereas with v4 NAT, there is no need for the functionality). =20 > > Instead, we should defer the problem to a SIP working group = (SIPPING?) to > > figure out.. because *they* will be using SIP for interaction, and = they > > know best which kind of solution they'd need (whether based on = NAT-PT or >=20 > No concerns on defering the problem to SIP folks, as long as we agree = what > the problem is. If the problem is figuring out the bindings during SIP > signalling through an external mechanism, then yes I agree. That is = all to > the problem. >=20 > Defining a translator that uses those bindings to do header = translation > has already been defined in RFC2766. SIP wg. should not invent another > one. I'm not sure actually what the problem is. All it is that folks think=20 that an optional mechanism for v6-only SIP <-> IPv4 SIP should be=20 specified. I don't personally care much for the details, but the SIP=20 folks probably know better which kind of tool might solve the problem. = If=20 it's sufficiently close to NAT-PT, why not reuse parts of it and specify = something to create the mappings; if not, maybe it's worth doing = something=20 else. I just don't think this WG is the right place to define that. --=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 Tue Nov 18 09:01:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21131 for ; Tue, 18 Nov 2003 09:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM6Nm-000Mtu-3c for v6ops-data@psg.com; Tue, 18 Nov 2003 13:59:06 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM6Na-000MsH-7w for v6ops@ops.ietf.org; Tue, 18 Nov 2003 13:58:54 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA04191 for ; Tue, 18 Nov 2003 13:58:53 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 NAA21551 for ; Tue, 18 Nov 2003 13:58:52 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAIDwqx23490 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 13:58:52 GMT Date: Tue, 18 Nov 2003 13:58:52 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE Message-ID: <20031118135852.GK22385@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639921@ESEALNT442.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639921@ESEALNT442.al.sw.ericsson.se> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Nov 18, 2003 at 02:50:13PM +0100, Karim El-Malki (HF/EAB) wrote: > > I don't think the above "extra" features are in the current ISATAP > spec and agree that it should focus on the basic host-to-router > mechanism. Would satisfying the above make it acceptable? > I think draft-16 does that. I'll review it myself and hope the wg > finds time for that too. I would agree with that. Tim From owner-v6ops@ops.ietf.org Tue Nov 18 09:01:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21157 for ; Tue, 18 Nov 2003 09:01:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM6O0-000Mvq-Fj for v6ops-data@psg.com; Tue, 18 Nov 2003 13:59:20 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM6Nn-000MuD-RN for v6ops@ops.ietf.org; Tue, 18 Nov 2003 13:59:08 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIDx5I2007123; Tue, 18 Nov 2003 14:59:06 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 14:59:05 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639922@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'juha.wiljakka@nokia.com'" , pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE Date: Tue, 18 Nov 2003 14:58:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > trying to catch up this interesting discussion and making > some kind of summary: > - not needing to refer to Unman scenarios&analysis > - Karim provides text on tunneling (to be updated to revision -08) > - Pekka's concerns on ISATAP providing more features than we > need => in that case, we should document which parts of > ISATAP are necessary for the 3GPP case, i.e. making a > "subset of ISATAP" may be the solution? Shall you, Karim, > also consider this point when writing your text? Makes sense. I will review the latest spec (draft-16) and do that but I think it does not contain those extra features. > > Furthermore, I personally don't believe that configured > tunnels make a feasible solution for this specific problem > (even though they provide a good solution for some other > scenarios). You must remember the high number of UEs and > dynamic addressing. And any extra configuration effort isn't > nice for the users. If you make the extra configurations > using SMS (like configuring APN settings for different > applications), that means one SMS more. The point is: IPv6 > should be as easy as possible. Fully agree. > > And still: we prefer native IPv6 communication and describe > the "tunneling in the UE" as an *optional* thing (that won't > be needed any more after GPRS networks start to widely > support IPv6). That should not make harm to anybody. Again agree. > P.S. All this discussion already shows to me that v6ops wg > should start working on transition mechanisms. This wg needs > to work on issues that are relevant for IPv6 deployment and > that can help IPv6 getting deployed. Of course, the > scenarios & analysis work is important, but we have done it > already for so long time that we start to see which > mechanisms are relevant (and which aren't). IMHO, getting > ISATAP published as an RFC would be a good step towards that > direction. That is my opinion as well. We need to have stable specs for implementation/deployment now that we are wrapping up the last details on 3gpp analysis. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 09:19:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21696 for ; Tue, 18 Nov 2003 09:19:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM6ev-000ON8-0b for v6ops-data@psg.com; Tue, 18 Nov 2003 14:16:49 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM6eg-000OLc-Kt for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:16:34 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAIEGVA10334 for ; Tue, 18 Nov 2003 16:16:32 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Nov 2003 16:16:31 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 18 Nov 2003 16:16:30 +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: 3gpp-analysis: DNS over v4 if availablen Date: Tue, 18 Nov 2003 16:16:29 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE025@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis: DNS over v4 if availablen Thread-Index: AcOs/PThG7nkAZkZSe+WzrSMFhTlIwA3sJWw From: To: , X-OriginalArrivalTime: 18 Nov 2003 14:16:30.0880 (UTC) FILETIME=[901EFA00:01C3ADDE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka,=20 I don't think that making that statement adds any value. Just because = IPv4 and IPv6 PDP contexts are separate and we don't assume that both of = them are simultaneously used by an application. E.g. keeping IPv4 PDP = context always activated (just in case, if DNS queries are needed) is = not good usage of nw resources. A basic application (for example HTTP browsing) uses only one PDP = context (v4 or v6), but there will be applications using more than one = PDP context (both primary and secondary contexts), but that's another = story... Cheers, -Juha- -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Pekka Savola Sent: 17 November, 2003 13:18 To: v6ops@ops.ietf.org Subject: 3gpp-analysis: DNS over v4 if availablen Hi, Relating to the previous "Need for UE <-> 3GPP configuration"=20 configuration issue (closed now), I'd maybe augment the text: DNS server addresses typically also need to be configured in the UE. In the case of IPv4 type PDP context, the (IPv4) DNS server addresses can be received in the PDP context activation (a control plane mechanism). Same kind of mechanism is also available for IPv6: so-called Protocol Configuration Options Information Element (PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible to use [DHCPv6-SL] or [RFC3315] and [DHCP-DNS] for receiving DNS server addresses. The authors note that the general IPv6 DNS discovery problem is being solved by the IETF dnsop Working Group. The DNS server addresses can also be received over the air (using SMS), or typed in manually in the UE. .. by adding a sentence at the end: Note that as long as IPv4 PDP context is active, DNS lookups can also be done over IPv4 transport. .. just to highlight the fact that w/ dual-stack UE deployment, not = having v6 DNS is not necessary a big deal (yet!) --=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 Tue Nov 18 09:32:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22123 for ; Tue, 18 Nov 2003 09:32:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM6rW-000PUf-Nx for v6ops-data@psg.com; Tue, 18 Nov 2003 14:29:50 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM6rK-000PTS-74 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:29:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIETZm20957; Tue, 18 Nov 2003 16:29:35 +0200 Date: Tue, 18 Nov 2003 16:29:35 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: DNS over v4 if availablen In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE025@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003 juha.wiljakka@nokia.com wrote: > I don't think that making that statement adds any value. Just because > IPv4 and IPv6 PDP contexts are separate and we don't assume that both of > them are simultaneously used by an application. E.g. keeping IPv4 PDP > context always activated (just in case, if DNS queries are needed) is > not good usage of nw resources. It certainly adds value if you don't want to implement a mechanisms to autoconfigure v6 DNS resolvers, or don't know which way to adapt to do so. So, IMHO, it's clearly useful to state that as long as both PDP contexts are open, DNS lookups for v6 addresses work just fine. I'm not sure whether any vendor or operator would like to go down that route, but it seems like a possible alternative. -- 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 Nov 18 09:42:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22348 for ; Tue, 18 Nov 2003 09:42:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM71T-0000JI-DI for v6ops-data@psg.com; Tue, 18 Nov 2003 14:40:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM71G-0000HW-MB for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:39:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIEdqi21101; Tue, 18 Nov 2003 16:39:52 +0200 Date: Tue, 18 Nov 2003 16:39:52 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F563991E@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > Let's look at the requirements so as to clarify the issue > once and for all. The required functions of a mechanism to solve > this are: > > 1 - The UE gets the IPv4 tunnel endpoint address in the operator's > network > 2 - The UE's IPv4 (probably private) tunnel endpoint address is > communicated to the network endpoint > 3 - The UE gets an IPv6 address known to the network tunnel endpoint The last part is always a non-issue, as the UE can learn its address by a simple RA/RS mechanism, like any other IPv6 interface, so it could be dropped from the comparison. > The UE and network tunnel endpoint are within the same IP (L3) domain. Yes, they are, but they're in different administrative domains. The 3GPP operator must treat the UE as a "hostile" host. This is entirely different from e.g. normal enterprise networks, and which is why ISATAP is not very well suited to *this* particular task. > 2) can't be manually configured (since the UE's address is dynamically > assigned for most cases) Why not? The 3GPP network has to know the address, because it assigns it to the UE. Why couldn't it communicate it to the IPv6 box somehow? Or where is this information stored, maybe it is retrievable? > Taking the ISATAP example: 1) is solved by using DNS or manual config, > while 2) and 3) are solved by using the tunneled RA/RS mechanism. This > requires little work to implement and satisfies the above. It seems to make that configured tunnels has about equal config for 1) and 3), and making 2) easier should be easily possible because the 3GPP network must know the addresses of every user involved anyway. > So it looks to me like ISATAP is not an overkill since it does not > do more than solve the above and requires little if any config. This is not accurate, but I'll respond to it in a separate 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 Tue Nov 18 09:44:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22442 for ; Tue, 18 Nov 2003 09:44:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM73p-0000Ww-8k for v6ops-data@psg.com; Tue, 18 Nov 2003 14:42:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM73d-0000Vs-2J for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:42:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIEgDf21143; Tue, 18 Nov 2003 16:42:13 +0200 Date: Tue, 18 Nov 2003 16:42:13 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: Tim Chown , Subject: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639920@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > ISATAP tunneling in the UE is not for inter-IP-domain. There can be one > or more L2 networks between the UE the ISATAP box but the UE and ISATAP > box would always be in the same IP domain. Maybe this was a comment in > reference to 3gpp roaming? If so I want to point out that it is L2 > roaming (not L3 roaming). So there is no crossing of IP domain. I was talking about administrative domains, not IP domains. (Sorry for confusion.) The 3GPP operator cannot trust the UE or the user. They must be treated as "hostile". This is very, very different from e.g. most enterprise networks where ISATAP was originally more or less envisioned for. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Nov 18 09:50:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22867 for ; Tue, 18 Nov 2003 09:50:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM79M-0001BX-2W for v6ops-data@psg.com; Tue, 18 Nov 2003 14:48:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM799-0001Ak-63 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:48:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIElul21222; Tue, 18 Nov 2003 16:47:56 +0200 Date: Tue, 18 Nov 2003 16:47:56 +0200 (EET) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org, Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE In-Reply-To: <20031118135852.GK22385@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Tim Chown wrote: > On Tue, Nov 18, 2003 at 02:50:13PM +0100, Karim El-Malki (HF/EAB) wrote: > > I don't think the above "extra" features are in the current ISATAP > > spec and agree that it should focus on the basic host-to-router > > mechanism. Would satisfying the above make it acceptable? > > I think draft-16 does that. I'll review it myself and hope the wg > > finds time for that too. > > I would agree with that. Please read the draft. Only, the facts do not change: ISATAP does provide these features (and more besides!) which are completely unnecessary and even counter-productive in this scenario. ISATAP simply is *not* a simple host-to-router mechanism. (Of course, "simple" is subjective, but at least it's much more complicated than you thought.) (I reviewed isatap-15 in detail, and I don't think -16 changed much in this regard.) -- 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 Nov 18 09:53:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22988 for ; Tue, 18 Nov 2003 09:53:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7CL-0001Sd-2F for v6ops-data@psg.com; Tue, 18 Nov 2003 14:51:21 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7Bz-0001QI-TK for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:51:00 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA05857 for ; Tue, 18 Nov 2003 14:50:55 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 OAA23936 for ; Tue, 18 Nov 2003 14:50:55 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAIEotM24653 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:50:55 GMT Date: Tue, 18 Nov 2003 14:50:55 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE Message-ID: <20031118145055.GS22385@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20031118135852.GK22385@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Nov 18, 2003 at 04:47:56PM +0200, Pekka Savola wrote: > On Tue, 18 Nov 2003, Tim Chown wrote: > > On Tue, Nov 18, 2003 at 02:50:13PM +0100, Karim El-Malki (HF/EAB) wrote: > > > I don't think the above "extra" features are in the current ISATAP > > > spec and agree that it should focus on the basic host-to-router > > > mechanism. Would satisfying the above make it acceptable? > > > I think draft-16 does that. I'll review it myself and hope the wg > > > finds time for that too. > > > > I would agree with that. > > ISATAP simply is *not* a simple host-to-router mechanism. (Of course, > "simple" is subjective, but at least it's much more complicated than you > thought.) Sorry Pekka, I was agreeing that it would be easier to adopt formally if it was a simple host-to-router mechanism. Tim From owner-v6ops@ops.ietf.org Tue Nov 18 09:54:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23024 for ; Tue, 18 Nov 2003 09:53:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7Ce-0001Ud-9Q for v6ops-data@psg.com; Tue, 18 Nov 2003 14:51:40 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7CA-0001RN-K5; Tue, 18 Nov 2003 14:51:10 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIEp0Ss025696; Tue, 18 Nov 2003 15:51:00 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 15:50:59 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639924@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'juha.wiljakka@nokia.com'" , pekkas@netcore.fi, satapati@cisco.com Cc: randy@psg.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP] Date: Tue, 18 Nov 2003 15:50:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk As you pointed out the 3gpp-analysis draft addresses these issues and I have no problems with that. It points to the work to be done in SIPPING and says that such a solution could reuse parts of NAT-PT. IMO this discussion concerns the nat-pt applicability draft. The outstanding issue is the understanding behind the NAT-PT applicability draft which contains different wording. I proposed to solve it by putting in alternative wording (in the nat-pt draft) referring to the work that will be done in SIPPING which, as you write below, could reuse parts of NAT-PT. That would make the IMS parts of the nat-pt applicability draft more similar to the 3gpp-analysis draft. /Karim > I think there aren't any major open issues considering > documenting this case in 3GPP Analysis > > - we state clearly, that "dual stack" based solution is not > feasible and a translator is needed as a part of the solution > > "As the IMS is exclusively IPv6 [3GPP 23.221], > translators have to > be used in the communication between the IPv6 IMS and > legacy IPv4 > hosts, i.e. making a dual stack based solution is not feasible. > This section aims to give a brief overview on how that > interworking > can be handled." > > - we document a higher level solution and refer to SIP(PING) > wg to make a generic solution > > "This section presents higher level details of a > solution based on > the use of a translator and SIP ALG. [3GPPtr] provides > additional > information and presents a bit different solution > proposal based on > SIP Edge Proxy and IP Address/Port Mapper. The authors > recommend to > solve the general SIP/SDP IPv4/IPv6 transition problem > in the IETF > SIP wg(s)." > > - because NAT-PT is the closest possible (=PS RFC) solution > to be used in this "Interworking Unit" as a translator, we state: > > " We call the combined network element on > the edge of the IPv6-only IMS an "Interworking Unit" in this > document. A SIP-specific translation mechanism, which could e.g. > re-use limited subsets of NAT-PT [RFC2766], needs to be > specified. > The problems related to NAT-PT are discussed in appendix A. " > > - Finally, I think that documenting this case in 3GPP > Analysis is important and details must not be dropped. > > Right? > > Cheers, > -Juha- > > P.S. I still can't understand what can be so horribly bad in > NAT-PT, but let's not start that discussion using this mail > thread, because it isn't a 3GPP-specific problem. > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Pekka Savola > Sent: 18 November, 2003 00:22 > To: Suresh Satapati > Cc: Karim El-Malki (HF/EAB); 'Randy Bush'; v6ops@ops.ietf.org > Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT > Applicabilty > for 3GPP] > > > On Mon, 17 Nov 2003, Suresh Satapati wrote: > > > Yes, but then again, you don't need DNS-ALG in the > v4<->v4 NAT, because > > > the destination address families are the same. On the > other hand, you > > > > I am afraid you are *wrong*. > > > > DNS-ALG is not used *merely* for translation between > address families. > > DNS-ALG is used to translate addresses contained in PTR > queries and any addresses > > in DNS responses (like Answer, Additional RRs). The > translation could be > > be replacing a private (rfc 1918) address w/ a public address. > > Again, it is not required. Many NAT boxes do implement > this, but many > others do not. IPv4 NAT is fully functional without a DNS ALG. > > > This has been extended to v6<->v4, where an IPv6 address is being > > replaced w/ an IPv4 one. > > Right, but you cannot implement NAT-PT without DNS-ALG, or > something to > replace the functionality (whereas with v4 NAT, there is no > need for the > functionality). > > > > Instead, we should defer the problem to a SIP working > group (SIPPING?) to > > > figure out.. because *they* will be using SIP for > interaction, and they > > > know best which kind of solution they'd need (whether > based on NAT-PT or > > > > No concerns on defering the problem to SIP folks, as long > as we agree what > > the problem is. If the problem is figuring out the > bindings during SIP > > signalling through an external mechanism, then yes I > agree. That is all to > > the problem. > > > > Defining a translator that uses those bindings to do > header translation > > has already been defined in RFC2766. SIP wg. should not > invent another > > one. > > I'm not sure actually what the problem is. All it is that > folks think > that an optional mechanism for v6-only SIP <-> IPv4 SIP should be > specified. I don't personally care much for the details, > but the SIP > folks probably know better which kind of tool might solve > the problem. If > it's sufficiently close to NAT-PT, why not reuse parts of it > and specify > something to create the mappings; if not, maybe it's worth > doing something > else. I just don't think this WG is the right place to define 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 Tue Nov 18 09:57:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23177 for ; Tue, 18 Nov 2003 09:57:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7Fr-0001kW-RO for v6ops-data@psg.com; Tue, 18 Nov 2003 14:54:59 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7Ff-0001jC-0J for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:54:47 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIEshSs027068; Tue, 18 Nov 2003 15:54:44 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 15:54:43 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639925@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: Tim Chown , v6ops@ops.ietf.org Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] Date: Tue, 18 Nov 2003 15:54:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > ISATAP tunneling in the UE is not for inter-IP-domain. > There can be one > > or more L2 networks between the UE the ISATAP box but the > UE and ISATAP > > box would always be in the same IP domain. Maybe this was > a comment in > > reference to 3gpp roaming? If so I want to point out that it is L2 > > roaming (not L3 roaming). So there is no crossing of IP domain. > > I was talking about administrative domains, not IP domains. > (Sorry for > confusion.) > > The 3GPP operator cannot trust the UE or the user. They > must be treated > as "hostile". This is very, very different from e.g. most > enterprise > networks where ISATAP was originally more or less envisioned for. They are not considered hostile since they have authenticated to the home network using the SIM card. The 3gpp operator's network relies on this security. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 09:58:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23205 for ; Tue, 18 Nov 2003 09:58:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7HK-0001v9-Q6 for v6ops-data@psg.com; Tue, 18 Nov 2003 14:56:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7H2-0001sc-9z for v6ops@ops.ietf.org; Tue, 18 Nov 2003 14:56:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIEu9821424; Tue, 18 Nov 2003 16:56:09 +0200 Date: Tue, 18 Nov 2003 16:56:09 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: karim.el-malki@ericsson.com, Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE023@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003 juha.wiljakka@nokia.com wrote: > trying to catch up this interesting discussion and making some kind of summary: > - not needing to refer to Unman scenarios&analysis > - Karim provides text on tunneling (to be updated to revision -08) To be seen on the list. > - Pekka's concerns on ISATAP providing more features than we need => in > that case, we should document which parts of ISATAP are necessary for > the 3GPP case, i.e. making a "subset of ISATAP" may be the solution? > Shall you, Karim, also consider this point when writing your text? In addition to providing more features than we need, ISATAP is also ill-fit to the "separate administrative domains" -model we have here, see the other thread. > Furthermore, I personally don't believe that configured tunnels make a > feasible solution for this specific problem (even though they provide a > good solution for some other scenarios). You must remember the high > number of UEs and dynamic addressing. And any extra configuration effort > isn't nice for the users. If you make the extra configurations using SMS > (like configuring APN settings for different applications), that means > one SMS more. The point is: IPv6 should be as easy as possible. This may be because of an assumption that the user might actually have to *configure* something. That's not necessarily the case. Setting up configured tunnels could be completely automatic. Let's try to figure out this in the separate thread, "manual config of UE tunnel". > And still: we prefer native IPv6 communication and describe the > "tunneling in the UE" as an *optional* thing (that won't be needed any > more after GPRS networks start to widely support IPv6). That should not > make harm to anybody. Uhh.. doesn't this imply the opposite? Even if optional, we specify that ISATAP may be used, hence all the vendors implement ISATAP? I don't see that as a useful advice. -- 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 Nov 18 10:02:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23415 for ; Tue, 18 Nov 2003 10:02:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7LL-0002JA-5b for v6ops-data@psg.com; Tue, 18 Nov 2003 15:00:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7L8-0002IQ-T2 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:00:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIF0Jj21526; Tue, 18 Nov 2003 17:00:19 +0200 Date: Tue, 18 Nov 2003 17:00:19 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: Tim Chown , Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639925@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > The 3GPP operator cannot trust the UE or the user. They > > must be treated > > as "hostile". This is very, very different from e.g. most > > enterprise > > networks where ISATAP was originally more or less envisioned for. > > They are not considered hostile since they have authenticated to > the home network using the SIM card. The 3gpp operator's network > relies on this security. Even if 3GPP network would rely on it, we at the IETF know better ;-) Seriously, SIM identification means nothing. They sell anonymous, pre-paid SIM cards at kiosks around here which are untraceable. That should be pretty commonplace. There is nothing in the SIM "authentication" which makes the operator trust the user more. It's just a way of getting the billing right (AFAIK). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Nov 18 10:16:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25186 for ; Tue, 18 Nov 2003 10:16:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7Y2-0003iN-Nt for v6ops-data@psg.com; Tue, 18 Nov 2003 15:13:46 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7XS-0003eo-3E for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:13:10 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIFD4Ss003029; Tue, 18 Nov 2003 16:13:08 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 16:13:04 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639926@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: Tim Chown , v6ops@ops.ietf.org Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] Date: Tue, 18 Nov 2003 16:12:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > > The 3GPP operator cannot trust the UE or the user. They > > > must be treated > > > as "hostile". This is very, very different from e.g. most > > > enterprise > > > networks where ISATAP was originally more or less > envisioned for. > > > > They are not considered hostile since they have authenticated to > > the home network using the SIM card. The 3gpp operator's network > > relies on this security. > > Even if 3GPP network would rely on it, we at the IETF know better ;-) > > Seriously, SIM identification means nothing. They sell anonymous, > pre-paid SIM cards at kiosks around here which are untraceable. That > should be pretty commonplace. There is nothing in the SIM > "authentication" which makes the operator trust the user > more. It's just > a way of getting the billing right (AFAIK). I think it is out of scope for us to start discussing changes to 3gpp architecture. Using the SIM a user can roam to another network and send packets back to its home network. So from the 3gpp point of view the user can access basic "home" services (e.g. ISATAP) in the same way while roaming as if the user was actually at home. That fits the ISATAP scenario. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 10:18:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25445 for ; Tue, 18 Nov 2003 10:18:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7av-0003zl-Lp for v6ops-data@psg.com; Tue, 18 Nov 2003 15:16:45 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7ah-0003yT-UG for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:16:32 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIFGTI2004015; Tue, 18 Nov 2003 16:16:29 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 16:16:29 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639927@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Tue, 18 Nov 2003 16:15:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > Let's look at the requirements so as to clarify the issue > > once and for all. The required functions of a mechanism to solve > > this are: > > > > 1 - The UE gets the IPv4 tunnel endpoint address in the operator's > > network > > 2 - The UE's IPv4 (probably private) tunnel endpoint address is > > communicated to the network endpoint > > 3 - The UE gets an IPv6 address known to the network > tunnel endpoint > > The last part is always a non-issue, as the UE can learn its > address by > a simple RA/RS mechanism, like any other IPv6 interface, so > it could be > dropped from the comparison. > > > The UE and network tunnel endpoint are within the same IP > (L3) domain. > > Yes, they are, but they're in different administrative > domains. The 3GPP > operator must treat the UE as a "hostile" host. This is entirely > different from e.g. normal enterprise networks, and which is > why ISATAP is > not very well suited to *this* particular task. See previous email. > > > 2) can't be manually configured (since the UE's address is > dynamically > > assigned for most cases) > > Why not? The 3GPP network has to know the address, because > it assigns it > to the UE. Why couldn't it communicate it to the IPv6 box > somehow? Or > where is this information stored, maybe it is retrievable? We don't want to go there (likely to get stuck in complex GGSN and 3gpp network internals). > > > Taking the ISATAP example: 1) is solved by using DNS or > manual config, > > while 2) and 3) are solved by using the tunneled RA/RS > mechanism. This > > requires little work to implement and satisfies the above. > > It seems to make that configured tunnels has about equal > config for 1) and > 3), and making 2) easier should be easily possible because the 3GPP > network must know the addresses of every user involved anyway. See above. This can only make things very complex. 2) should not rely on special mechanisms in the 3gpp network. It is no point to have a solution that requires changes to 3gpp nodes since they might as well be upgraded to support v6! /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 10:26:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25657 for ; Tue, 18 Nov 2003 10:26:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7hz-0004bS-3T for v6ops-data@psg.com; Tue, 18 Nov 2003 15:24:03 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7he-0004Z6-JQ for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:23:42 +0000 Received: from fakat.com (pc5205203.nac.telia.se [131.115.205.203]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id hAIFOawN027794 for ; Tue, 18 Nov 2003 16:24:37 +0100 (CET) (envelope-from jasko@fakat.com) Message-ID: <3FBA397C.5010900@fakat.com> Date: Tue, 18 Nov 2003 16:23:40 +0100 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP] References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639924@ESEALNT442.al.sw.ericsson.se> In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639924@ESEALNT442.al.sw.ericsson.se> X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > As you pointed out the 3gpp-analysis draft addresses these > issues and I have no problems with that. It points to the > work to be done in SIPPING and says that such a solution > could reuse parts of NAT-PT. > i have a question to the wg chairs and/or ad:s: do you plan to deprecate nat-pt before the work (ims-translator) has been finished in the sipping wg? thanx! jasminko From owner-v6ops@ops.ietf.org Tue Nov 18 10:33:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25904 for ; Tue, 18 Nov 2003 10:33:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM7pD-0005Ah-1i for v6ops-data@psg.com; Tue, 18 Nov 2003 15:31:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM7p0-00059r-Rk for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:31:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIFVF522140; Tue, 18 Nov 2003 17:31:15 +0200 Date: Tue, 18 Nov 2003 17:31:15 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639926@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > I think it is out of scope for us to start discussing changes to 3gpp > architecture. Totally agree, but I don't think I was even starting that discussion. > Using the SIM a user can roam to another network and send > packets back to its home network. That doesn't mean the operator trusts the user at all; in this case, it seems like a way to identify what is the home network to send the packets to. > So from the 3gpp point of view the user can access basic "home" > services (e.g. ISATAP) in the same way while roaming as if the user > was actually at home. That fits the ISATAP scenario. You made an assumption that using ISATAP at home network would be OK, and therefore using it on the remote network would be equally OK. I don't make either. I don't think ISATAP should be used at the home network either, due to the reasons described: it doesn't fit well to a model of crossing administrative borders. -- 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 Nov 18 10:45:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26530 for ; Tue, 18 Nov 2003 10:45:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM80S-0005ud-NR for v6ops-data@psg.com; Tue, 18 Nov 2003 15:43:08 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM80G-0005tA-IE for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:42:56 +0000 Received: from fakat.com (pc5205203.nac.telia.se [131.115.205.203]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id hAIFhnwN027855; Tue, 18 Nov 2003 16:43:49 +0100 (CET) (envelope-from jasko@fakat.com) Message-ID: <3FBA3DFC.8030300@fakat.com> Date: Tue, 18 Nov 2003 16:42:52 +0100 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Karim El-Malki (HF/EAB)" CC: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: Re: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639927@ESEALNT442.al.sw.ericsson.se> In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639927@ESEALNT442.al.sw.ericsson.se> X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Why not? The 3GPP network has to know the address, because > > it assigns it > > to the UE. Why couldn't it communicate it to the IPv6 box > > somehow? Or > > where is this information stored, maybe it is retrievable? > > We don't want to go there (likely to get stuck in complex GGSN > and 3gpp network internals). > <....> > > See above. This can only make things very complex. > 2) should not rely on special mechanisms in the 3gpp network. > It is no point to have a solution that requires changes to 3gpp > nodes since they might as well be upgraded to support v6! > which case are we trying to solve here? operators do wanna or do not wanna support ipv6? completely lost in the discussion... jasminko From owner-v6ops@ops.ietf.org Tue Nov 18 10:48:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26607 for ; Tue, 18 Nov 2003 10:48:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM83d-0006Av-Uw for v6ops-data@psg.com; Tue, 18 Nov 2003 15:46:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM83N-00069z-Ky for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:46:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIFk3e22392; Tue, 18 Nov 2003 17:46:03 +0200 Date: Tue, 18 Nov 2003 17:46:03 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org, Jasminko Mulahusic Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639927@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Combining two answers: [Jasko:] > which case are we trying to solve here? operators do wanna or do not > wanna support ipv6? completely lost in the discussion... The cases: 1) your home operator doesn't support v6 PDP contexts, but would like to offer some v6 service, or 2) your home operator may support either v6 PDP contexts or some other v6 mechanisms, but the operator where you roam to doesn't The case where the home operators supports nothing at all is out of scope (I think). Hope this clarifies.. More inline.. On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > Why not? The 3GPP network has to know the address, because > > it assigns it > > to the UE. Why couldn't it communicate it to the IPv6 box > > somehow? Or > > where is this information stored, maybe it is retrievable? > > We don't want to go there (likely to get stuck in complex GGSN > and 3gpp network internals). We don't know until this has been analyzed. This could really be no more complicated than sending a "I want to use IPv6 using a tunnel" SMS (or something like that), and then your phone and the tunnel endpoint would be configured automatically. > > It seems to make that configured tunnels has about equal > > config for 1) and > > 3), and making 2) easier should be easily possible because the 3GPP > > network must know the addresses of every user involved anyway. > > See above. This can only make things very complex. > 2) should not rely on special mechanisms in the 3gpp network. > It is no point to have a solution that requires changes to 3gpp > nodes since they might as well be upgraded to support v6! Would a modification be required? I'm not so sure of that. There must be some mechanisms to retrieve this information, either e.g. SNMP query or access to a database, or something. That should be pretty much all you need. -- 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 Nov 18 10:54:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26923 for ; Tue, 18 Nov 2003 10:54:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM890-0006fm-Lo for v6ops-data@psg.com; Tue, 18 Nov 2003 15:51:58 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM88o-0006ex-G2 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:51:46 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIFpiI2015313; Tue, 18 Nov 2003 16:51:45 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 16:51:44 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639928@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] Date: Tue, 18 Nov 2003 16:51:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Using the SIM a user can roam to another network and send > > packets back to its home network. > > That doesn't mean the operator trusts the user at all; in this case, > it seems like a way to identify what is the home network to send the > packets to. I don't understand what you mean? The user gets charged and is able to access services (e.g. internet access). That's the 3gpp model and ISATAP can be just one of those services. > > > So from the 3gpp point of view the user can access basic "home" > > services (e.g. ISATAP) in the same way while roaming as if the user > > was actually at home. That fits the ISATAP scenario. > > You made an assumption that using ISATAP at home network > would be OK, > and therefore using it on the remote network would be equally OK. > > I don't make either. > > I don't think ISATAP should be used at the home network either, due > to the reasons described: it doesn't fit well to a model of crossing > administrative borders. I lost you here. What are the admin domains when the user is at home? Anyway we seem to have come full circle again. But please take note that there are people on this list who would like to stop discussing and start finishing off those specs now pending for years. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 11:03:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27333 for ; Tue, 18 Nov 2003 11:03:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM8G8-0007CS-2s for v6ops-data@psg.com; Tue, 18 Nov 2003 15:59:20 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM8Fv-0007Bm-J5 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 15:59:07 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIFx5Ss016211; Tue, 18 Nov 2003 16:59:05 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 16:59:05 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639929@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org, Jasminko Mulahusic Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Tue, 18 Nov 2003 16:58:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > We don't want to go there (likely to get stuck in complex GGSN > > and 3gpp network internals). > > We don't know until this has been analyzed. > > This could really be no more complicated than sending a "I want to > use IPv6 using a tunnel" SMS (or something like that), and then your > phone and the tunnel endpoint would be configured automatically. Pls see Juha's email on the complexity of doing these configs. It makes things MORE complicated. > > > > It seems to make that configured tunnels has about equal > > > config for 1) and > > > 3), and making 2) easier should be easily possible > because the 3GPP > > > network must know the addresses of every user involved anyway. > > > > See above. This can only make things very complex. > > 2) should not rely on special mechanisms in the 3gpp network. > > It is no point to have a solution that requires changes to 3gpp > > nodes since they might as well be upgraded to support v6! > > Would a modification be required? I'm not so sure of that. There > must be some mechanisms to retrieve this information, either > e.g. SNMP > query or access to a database, or something. That should be pretty > much all you need. That makes certain assumptions about implementations. Seriously, it is not feasible. Also I can't understand why you think digging info from a database is simpler than just using ISATAP. Anyway, enough emails on this subject for me since we're not getting anywhere. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 11:20:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28270 for ; Tue, 18 Nov 2003 11:20:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM8Xp-0008S3-Dx for v6ops-data@psg.com; Tue, 18 Nov 2003 16:17:37 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM8Xc-0008Qe-Tx for v6ops@ops.ietf.org; Tue, 18 Nov 2003 16:17:24 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 08:25:38 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAIGHMtg002783; Tue, 18 Nov 2003 08:17:22 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR44582; Tue, 18 Nov 2003 08:17:21 -0800 (PST) Date: Tue, 18 Nov 2003 08:17:21 -0800 (PST) From: Suresh Satapati To: "Karim El-Malki (HF/EAB)" cc: "'Senthil Sivakumar'" , "'Randy Bush'" , v6ops@ops.ietf.org Subject: RE: NAT-PT Applicabilty for 3GPP In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F563991F@ESEALNT442.al.sw.ericsson.se> Message-ID: References: <37FB7AA6F5F9814FB634A7BF4C35A6F563991F@ESEALNT442.al.sw.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Karim, > above which I could agree with. Also I do not think it is as simple > as implementing an external SIP Proxy according to SIP specs as you > say above, since some changes to the binding mechanism is needed in > the translator and some interactions with other e2e protocols may be > needed. Given the discussions so far I would replace the statement Please spell out "some changes to the binding mechanism", and the "interactions needed with other e2e protocols". Then we can debate. Until then, my stance doesn't change as far as Applicability is concerned. > in the applicability with: > > The SIPPING WG will be working on a solution to the 3GPP IMS > translation problem which may reuse some functionality from NAT-PT. > > > So NAT-PT > > is applicable there and that is what is noted in the applicability > > statement. Re-inventing > > something that has already been done seems to be a waste of time. > > Comments above. The issue is that there are NAT-PT problems that the > SIP solution should not be inheriting. But as above, let's solve this > with the SIP folks. See above. -- Suresh From owner-v6ops@ops.ietf.org Tue Nov 18 11:33:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28822 for ; Tue, 18 Nov 2003 11:33:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM8l2-0009L4-Uw for v6ops-data@psg.com; Tue, 18 Nov 2003 16:31:16 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM8kq-0009Jy-3D for v6ops@ops.ietf.org; Tue, 18 Nov 2003 16:31:04 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAIGV1iN018330; Tue, 18 Nov 2003 08:31:01 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR45851; Tue, 18 Nov 2003 08:31:00 -0800 (PST) Date: Tue, 18 Nov 2003 08:31:00 -0800 (PST) From: Suresh Satapati To: juha.wiljakka@nokia.com cc: pekkas@netcore.fi, karim.el-malki@ericsson.com, randy@psg.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE024@esebe005.ntc.nokia.com> Message-ID: References: <245DBCAEEC4F074CB77B3F984FF9834F020CE024@esebe005.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Juha, > I think there aren't any major open issues considering documenting this case in 3GPP Analysis > > - we state clearly, that "dual stack" based solution is not feasible and a translator is needed as a part of the solution > > "As the IMS is exclusively IPv6 [3GPP 23.221], translators have to > be used in the communication between the IPv6 IMS and legacy IPv4 > hosts, i.e. making a dual stack based solution is not feasible. > This section aims to give a brief overview on how that interworking > can be handled." Agreed. > > - we document a higher level solution and refer to SIP(PING) wg to make a generic solution > > "This section presents higher level details of a solution based on > the use of a translator and SIP ALG. [3GPPtr] provides additional > information and presents a bit different solution proposal based on > SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to > solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF > SIP wg(s)." Consider a slight rewording here. s/"general SIP/SDP IPv4/IPv6 transition"/"SIP/SDP signalling"/ And add: NAT-PT header translation mechanism may be used in conjunction with the [3GPPtr] mechanism. NAT(P)T-PT will perform header translation, using the binding supplied by [3GPPtr]. > > - because NAT-PT is the closest possible (=PS RFC) solution to be used in this "Interworking Unit" as a translator, we state: > > " We call the combined network element on > the edge of the IPv6-only IMS an "Interworking Unit" in this > document. A SIP-specific translation mechanism, which could e.g. > re-use limited subsets of NAT-PT [RFC2766], needs to be specified. > The problems related to NAT-PT are discussed in appendix A. " Replace A SIP-specific translation mechanism, which could e.g. re-use limited subsets of NAT-PT [RFC2766], needs to be specified. with A SIP-specific mechanism to handle signalling traffic, that would work in conjunction with NAT-PT [RFC2766], needs to be specified. > > - Finally, I think that documenting this case in 3GPP Analysis is important and details must not be dropped. > > Right? Yep ! > > P.S. I still can't understand what can be so horribly bad in NAT-PT, but let's not start that discussion using this mail thread, because it isn't a 3GPP-specific problem. Same here.. Thanks Suresh > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Pekka Savola > Sent: 18 November, 2003 00:22 > To: Suresh Satapati > Cc: Karim El-Malki (HF/EAB); 'Randy Bush'; v6ops@ops.ietf.org > Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty > for 3GPP] > > > On Mon, 17 Nov 2003, Suresh Satapati wrote: > > > Yes, but then again, you don't need DNS-ALG in the v4<->v4 NAT, because > > > the destination address families are the same. On the other hand, you > > > > I am afraid you are *wrong*. > > > > DNS-ALG is not used *merely* for translation between address families. > > DNS-ALG is used to translate addresses contained in PTR queries and any addresses > > in DNS responses (like Answer, Additional RRs). The translation could be > > be replacing a private (rfc 1918) address w/ a public address. > > Again, it is not required. Many NAT boxes do implement this, but many > others do not. IPv4 NAT is fully functional without a DNS ALG. > > > This has been extended to v6<->v4, where an IPv6 address is being > > replaced w/ an IPv4 one. > > Right, but you cannot implement NAT-PT without DNS-ALG, or something to > replace the functionality (whereas with v4 NAT, there is no need for the > functionality). > > > > Instead, we should defer the problem to a SIP working group (SIPPING?) to > > > figure out.. because *they* will be using SIP for interaction, and they > > > know best which kind of solution they'd need (whether based on NAT-PT or > > > > No concerns on defering the problem to SIP folks, as long as we agree what > > the problem is. If the problem is figuring out the bindings during SIP > > signalling through an external mechanism, then yes I agree. That is all to > > the problem. > > > > Defining a translator that uses those bindings to do header translation > > has already been defined in RFC2766. SIP wg. should not invent another > > one. > > I'm not sure actually what the problem is. All it is that folks think > that an optional mechanism for v6-only SIP <-> IPv4 SIP should be > specified. I don't personally care much for the details, but the SIP > folks probably know better which kind of tool might solve the problem. If > it's sufficiently close to NAT-PT, why not reuse parts of it and specify > something to create the mappings; if not, maybe it's worth doing something > else. I just don't think this WG is the right place to define 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 Tue Nov 18 11:37:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29210 for ; Tue, 18 Nov 2003 11:37:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM8on-0009cz-8i for v6ops-data@psg.com; Tue, 18 Nov 2003 16:35:09 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM8oY-0009b1-9X for v6ops@ops.ietf.org; Tue, 18 Nov 2003 16:34:54 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2003 08:35:07 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIGYpw5004581; Tue, 18 Nov 2003 08:34:51 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR46245; Tue, 18 Nov 2003 08:34:50 -0800 (PST) Date: Tue, 18 Nov 2003 08:34:50 -0800 (PST) From: Suresh Satapati To: juha.wiljakka@nokia.com cc: pekkas@netcore.fi, karim.el-malki@ericsson.com, randy@psg.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE024@esebe005.ntc.nokia.com> Message-ID: References: <245DBCAEEC4F074CB77B3F984FF9834F020CE024@esebe005.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Juha, One more thing. You can drop: > The problems related to NAT-PT are discussed in appendix A. " Since you are refering to Applicability, the above is not needed. -- Suresh > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Pekka Savola > Sent: 18 November, 2003 00:22 > To: Suresh Satapati > Cc: Karim El-Malki (HF/EAB); 'Randy Bush'; v6ops@ops.ietf.org > Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty > for 3GPP] > > > On Mon, 17 Nov 2003, Suresh Satapati wrote: > > > Yes, but then again, you don't need DNS-ALG in the v4<->v4 NAT, because > > > the destination address families are the same. On the other hand, you > > > > I am afraid you are *wrong*. > > > > DNS-ALG is not used *merely* for translation between address families. > > DNS-ALG is used to translate addresses contained in PTR queries and any addresses > > in DNS responses (like Answer, Additional RRs). The translation could be > > be replacing a private (rfc 1918) address w/ a public address. > > Again, it is not required. Many NAT boxes do implement this, but many > others do not. IPv4 NAT is fully functional without a DNS ALG. > > > This has been extended to v6<->v4, where an IPv6 address is being > > replaced w/ an IPv4 one. > > Right, but you cannot implement NAT-PT without DNS-ALG, or something to > replace the functionality (whereas with v4 NAT, there is no need for the > functionality). > > > > Instead, we should defer the problem to a SIP working group (SIPPING?) to > > > figure out.. because *they* will be using SIP for interaction, and they > > > know best which kind of solution they'd need (whether based on NAT-PT or > > > > No concerns on defering the problem to SIP folks, as long as we agree what > > the problem is. If the problem is figuring out the bindings during SIP > > signalling through an external mechanism, then yes I agree. That is all to > > the problem. > > > > Defining a translator that uses those bindings to do header translation > > has already been defined in RFC2766. SIP wg. should not invent another > > one. > > I'm not sure actually what the problem is. All it is that folks think > that an optional mechanism for v6-only SIP <-> IPv4 SIP should be > specified. I don't personally care much for the details, but the SIP > folks probably know better which kind of tool might solve the problem. If > it's sufficiently close to NAT-PT, why not reuse parts of it and specify > something to create the mappings; if not, maybe it's worth doing something > else. I just don't think this WG is the right place to define 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 Tue Nov 18 12:39:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03266 for ; Tue, 18 Nov 2003 12:39:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM9lu-000Ez5-I3 for v6ops-data@psg.com; Tue, 18 Nov 2003 17:36:14 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM9lf-000Exb-8m; Tue, 18 Nov 2003 17:35:59 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIHZVSs013612; Tue, 18 Nov 2003 18:35:31 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 18:35:31 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F563992A@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Suresh Satapati'" Cc: "'Senthil Sivakumar'" , "'Randy Bush'" , v6ops@ops.ietf.org Subject: RE: NAT-PT Applicabilty for 3GPP Date: Tue, 18 Nov 2003 18:35:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > above which I could agree with. Also I do not think it is as simple > > as implementing an external SIP Proxy according to SIP specs as you > > say above, since some changes to the binding mechanism is needed in > > the translator and some interactions with other e2e > protocols may be > > needed. Given the discussions so far I would replace the statement > > Please spell out "some changes to the binding mechanism", and the > "interactions needed with other e2e protocols". Then we can debate. > Until then, my stance doesn't change as far as Applicability > is concerned. Have a look at the 3gpp-translator draft and the past emails. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 12:40:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03290 for ; Tue, 18 Nov 2003 12:40:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM9nc-000F7o-UW for v6ops-data@psg.com; Tue, 18 Nov 2003 17:38:00 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM9n8-000F5C-Od for v6ops@ops.ietf.org; Tue, 18 Nov 2003 17:37:30 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 09:45:45 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIHbSw5003705; Tue, 18 Nov 2003 09:37:28 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR52807; Tue, 18 Nov 2003 09:37:24 -0800 (PST) Date: Tue, 18 Nov 2003 09:37:23 -0800 (PST) From: Suresh Satapati To: Pekka Savola cc: "Karim El-Malki (HF/EAB)" , v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, > Again, it is not required. Many NAT boxes do implement this, but many > others do not. IPv4 NAT is fully functional without a DNS ALG. > > > This has been extended to v6<->v4, where an IPv6 address is being > > replaced w/ an IPv4 one. > > Right, but you cannot implement NAT-PT without DNS-ALG, or something to > replace the functionality (whereas with v4 NAT, there is no need for the > functionality). Just like you can make a v4NAT work, you can make NAT-PT work without a DNS-ALG. The model is the same. > > No concerns on defering the problem to SIP folks, as long as we agree what > > the problem is. If the problem is figuring out the bindings during SIP > > signalling through an external mechanism, then yes I agree. That is all to > > the problem. > > > > Defining a translator that uses those bindings to do header translation > > has already been defined in RFC2766. SIP wg. should not invent another > > one. > > I'm not sure actually what the problem is. All it is that folks think > that an optional mechanism for v6-only SIP <-> IPv4 SIP should be > specified. I don't personally care much for the details, but the SIP Briefly, the problem is SIP-ALG i.e., parsing SIP payload for addresses /ports and replacing them w/ v4/v6 equivalents is not recommended. Folks are calling it "SIP editing". > folks probably know better which kind of tool might solve the problem. If > it's sufficiently close to NAT-PT, why not reuse parts of it and specify > something to create the mappings; if not, maybe it's worth doing something > else. I just don't think this WG is the right place to define that. SIP(ping) folks should just worry about the problem that I stated above, and nothing more. The above tells me that this WG is deliberately letting another WG define "yet another" translator without understanding what the problem is, and use this as means to eventually deprecate RFC2766. From owner-v6ops@ops.ietf.org Tue Nov 18 12:40:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03312 for ; Tue, 18 Nov 2003 12:40:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM9nL-000F6H-VU for v6ops-data@psg.com; Tue, 18 Nov 2003 17:37:43 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM9n8-000F5C-30 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 17:37:30 +0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 09:45:44 -0800 Received: from SSENTHIL-W2K1.cisco.com ([128.107.176.137]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAIHbRAu018907; Tue, 18 Nov 2003 09:37:27 -0800 (PST) Message-Id: <4.3.2.7.2.20031117212517.06a7fbc0@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Nov 2003 21:35:53 -0800 To: Pekka Savola From: Senthil Sivakumar Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] Cc: Suresh Satapati , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >I'm not sure actually what the problem is. All it is that folks think >that an optional mechanism for v6-only SIP <-> IPv4 SIP should be >specified. I don't personally care much for the details, but the SIP >folks probably know better which kind of tool might solve the problem. If >it's sufficiently close to NAT-PT, why not reuse parts of it and specify >something to create the mappings; if not, maybe it's worth doing something >else. I just don't think this WG is the right place to define that. I am not sure what the problem is, either. It is very clear if you have a v4 only application/node/network, talking to a v6 only application/node/network you need a protocol translator. It is a no brainer. Why can't we concede that and move on? The generic protocol translator is a transition mechanism and it belongs in this WG. Senthil >-- >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 Nov 18 12:47:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03496 for ; Tue, 18 Nov 2003 12:47:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM9uB-000FpF-M8 for v6ops-data@psg.com; Tue, 18 Nov 2003 17:44:47 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM9tw-000Fkf-D7; Tue, 18 Nov 2003 17:44:32 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIHhtSs016085; Tue, 18 Nov 2003 18:43:55 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 18:43:55 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F563992B@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Suresh Satapati'" , juha.wiljakka@nokia.com Cc: pekkas@netcore.fi, randy@psg.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP] Date: Tue, 18 Nov 2003 18:43:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > - we document a higher level solution and refer to > SIP(PING) wg to make a generic solution > > > > "This section presents higher level details of a > solution based on > > the use of a translator and SIP ALG. [3GPPtr] provides > additional > > information and presents a bit different solution > proposal based on > > SIP Edge Proxy and IP Address/Port Mapper. The authors > recommend to > > solve the general SIP/SDP IPv4/IPv6 transition problem > in the IETF > > SIP wg(s)." > > Consider a slight rewording here. > > s/"general SIP/SDP IPv4/IPv6 transition"/"SIP/SDP signalling"/ Makes little sense since the SIP WG already has SIP/SDP signalling specs! I think it should stay since the SIP work will be on IPv6/v4 translation. > > And add: > > NAT-PT header translation mechanism may be used in conjunction with > the [3GPPtr] mechanism. NAT(P)T-PT will perform header translation, > using the binding supplied by [3GPPtr]. Disagree as I explained in past emails. > > > > > - because NAT-PT is the closest possible (=PS RFC) > solution to be used in this "Interworking Unit" as a > translator, we state: > > > > " We call the combined network element on > > the edge of the IPv6-only IMS an "Interworking Unit" in this > > document. A SIP-specific translation mechanism, which > could e.g. > > re-use limited subsets of NAT-PT [RFC2766], needs to > be specified. > > The problems related to NAT-PT are discussed in appendix A. " > > Replace > > A SIP-specific translation mechanism, which could e.g. > re-use limited subsets of NAT-PT [RFC2766], needs to be > specified. > > with > > A SIP-specific mechanism to handle signalling traffic, > that would > work in conjunction with NAT-PT [RFC2766], needs to be > specified. Again disagree. The analysis draft IMO is fine as is. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 12:50:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03806 for ; Tue, 18 Nov 2003 12:50:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AM9xh-000GH8-S1 for v6ops-data@psg.com; Tue, 18 Nov 2003 17:48:25 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AM9xP-000GES-EH for v6ops@ops.ietf.org; Tue, 18 Nov 2003 17:48:07 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAIHlwD30810; Tue, 18 Nov 2003 09:47:58 -0800 X-mProtect: <200311181747> 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 smtpds3mqjn; Tue, 18 Nov 2003 09:47:57 PST Message-ID: <3FBA5D02.70707@iprg.nokia.com> Date: Tue, 18 Nov 2003 09:55:14 -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: JORDI PALET MARTINEZ CC: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item References: <0a3901c3aa12$cb266450$83848182@consulintel.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jordi, You can count me as favoring this work going forward, but I'd like to suggest that a NAT that does the proper proto41 forwarding is unlike a NAT in the traditional sense and perhaps in need of a new name. My suggestion is: Network Organizational Translator (NOT) Fred ftemplin@iprg.nokia.com JORDI PALET MARTINEZ wrote: >Hi all, > >In the yesterday meeting, I've presented the latest version of http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-03, the slides are available at http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf58.zip (previous slides from Vienna also at http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf57.zip). > >As nobody provided any new suggestions or objections to this document, during the meeting, my feeling is that it could be accepted as WG item. > >In addition to the comment from Mariana, I got a couple of suggestions off-line that we will like to address in the next few days, so will like to take the opportunity publish the review already as WG item version 00 and keep going with the work. > >Please, let me know if you feel this is acceptable or do you have any objections. > >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 Nov 18 12:56:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03982 for ; Tue, 18 Nov 2003 12:56:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMA2l-000GrP-Sn for v6ops-data@psg.com; Tue, 18 Nov 2003 17:53:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMA1C-000Gej-Aw for v6ops@ops.ietf.org; Tue, 18 Nov 2003 17:52:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIHpul25015; Tue, 18 Nov 2003 19:51:56 +0200 Date: Tue, 18 Nov 2003 19:51:56 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639928@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > That doesn't mean the operator trusts the user at all; in this case, > > it seems like a way to identify what is the home network to send the > > packets to. > > I don't understand what you mean? The user gets charged and is able > to access services (e.g. internet access). That's the 3gpp model and > ISATAP can be just one of those services. Let me try to clarify, as the differences in security properties of different scenarios are clearly not clear. My home xDSL system gets charged as well, and the ISP provides me services as well. That doesn't mean the ISP trusts me to "behave well" in their network. E.g., I can spoof my address, I can send specially crafted packets, I can try to confuse their router with OSPF packets if they haven't disabled the interface, I can harass my neighbor, etc.etc. -- to the ISP (and other users), I'm a "hostile user". Much the same with 3GPP, actually more, because you don't have to have a contract or details where you can be traced, because you can use anonymous SIMs and similar. In a similar fashion, you cannot trust other users, because you cannot trust that the ISP is ensuring that the users cannot harm you (even if that was somehow possible). On the other hand, within an enterprise network, or at least a branch of the enterprise network, typically the assumptions are entirely different: you have to trust the users at least to some degree. You have contracts etc. with them. While some host may be acting weird for some reason, the users are not typically intentionally malicious. So... As it should be obvious, security mechanisms used and assumptions implied when devising a solution to the enterprise network are very probably not adequate for ISP/3GPP scenarios with a different set of requirements. Hence, I have always given significant pushback for re-using the ISATAP model outside of its (original?) scope, the enterprise networks. > > I don't think ISATAP should be used at the home network either, due > > to the reasons described: it doesn't fit well to a model of crossing > > administrative borders. > > I lost you here. What are the admin domains when the user is at home? Between the user and the ISP/3GPP operator, see above for better explanation. > But please take note that there are people on this list who would like > to stop discussing and start finishing off those specs now pending for > years. I'm sure that there are people who would like to do that. On the other hand, that's exactly what we should not do, as even the differences in security properties are not clear enough. We must do what we must do, not necessarily what people would like to do. -- 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 Nov 18 12:56:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03998 for ; Tue, 18 Nov 2003 12:56:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMA3C-000Gv4-1z for v6ops-data@psg.com; Tue, 18 Nov 2003 17:54:06 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMA20-000Gj3-9Q for v6ops@ops.ietf.org; Tue, 18 Nov 2003 17:52:52 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAIHqMQ01501; Tue, 18 Nov 2003 09:52:22 -0800 X-mProtect: <200311181752> 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 smtpdVUwdt2; Tue, 18 Nov 2003 09:52:20 PST Message-ID: <3FBA5E09.3050504@iprg.nokia.com> Date: Tue, 18 Nov 2003 09:59: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: Pekka Savola CC: Tim Chown , v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: Recommendation on tunneling in the UE References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Tue, 18 Nov 2003, Tim Chown wrote: > > >>On Tue, Nov 18, 2003 at 10:53:45AM +0200, Pekka Savola wrote: >> >> >>>I'm also not confortable running ISATAP over administrative borders, as >>>has been suggested here. This applies in a similar fashion and to a >>>lesser extent also to the unmanaged case where the ISP is doing NAT but >>>wanting to offer IPv6. >>> >>> >>OK, so define ESATAP :) >> >>I have always viewed ISATAP as an intra-site tool. As such its use >>does not impact the global architecture in the way that 6to4 or Teredo do, >>which is a plus point in favour of its adoption... >> >> > >I'll respond, just in case you were serious.. :-) > >The point of ISATAP (as I see it) to run it as an intra-site tool. It >could be rather useful there, especially if there are VPNs and such where >you can't use VLANs etc.. However, rather than specifying something >similar that runs inter-domain, we should focus on determining what is >actually needed when running inter-domain. > >I.e., start from a clean slate instead of trying to work ISATAP towards >being an inter-domain tool. > No need; ISATAP is already good-to-go for the inter-domain case. >Note: ISATAP however is less intrusive for the global architecture, as it >uses the interface ID for its operations, does not require a prefix -- so >it's transparent to the rest of the 'net users, rather than 6to4/Teredo. >So, it's not IMHO totally fair to compare ISATAP to 6to4/Teredo w/ >interdomain architecture. > The point is not one of comparison; rather, ISATAP is a complementary piece that completes the package. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Nov 18 12:58:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04070 for ; Tue, 18 Nov 2003 12:58:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMA5L-000H8T-Ii for v6ops-data@psg.com; Tue, 18 Nov 2003 17:56:19 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMA4T-000H3B-B1 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 17:55:25 +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-md50000000032.tmp for ; Tue, 18 Nov 2003 18:56:19 +0100 Message-ID: <0c6101c3adfd$3d0402b0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <0a3901c3aa12$cb266450$83848182@consulintel.es> <3FBA5D02.70707@iprg.nokia.com> Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item Date: Tue, 18 Nov 2003 18:56:04 +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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 18 Nov 2003 18:56:19 +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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Fred, I'm not sure to catch what do you mean and how much is serious in "NOT" = ... Do you mean only some "expensive" (corporate ?) NATs do this ? I tried = with very low cost models, and it works. Of course, actually it worked for me with the bigger networks (I assume = more expensive routers), like the Minnesota airport one when waiting for = my flight ... Regards, Jordi ----- Original Message -----=20 From: "Fred Templin" To: "JORDI PALET MARTINEZ" Cc: Sent: Tuesday, November 18, 2003 6:55 PM Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item > Jordi, >=20 > You can count me as favoring this work going forward, but I'd like to > suggest that a NAT that does the proper proto41 forwarding is unlike > a NAT in the traditional sense and perhaps in need of a new name. My > suggestion is: >=20 > Network Organizational Translator (NOT) >=20 > Fred > ftemplin@iprg.nokia.com >=20 > JORDI PALET MARTINEZ wrote: >=20 > >Hi all, > > > >In the yesterday meeting, I've presented the latest version of = http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-03, = the slides are available at = http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf58.zip = (previous slides from Vienna also at = http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf57.zip). > > > >As nobody provided any new suggestions or objections to this = document, during the meeting, my feeling is that it could be accepted as = WG item. > > > >In addition to the comment from Mariana, I got a couple of = suggestions off-line that we will like to address in the next few days, = so will like to take the opportunity publish the review already as WG = item version 00 and keep going with the work. > > > >Please, let me know if you feel this is acceptable or do you have any = objections. > > > >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. > > > > > > > > =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 Tue Nov 18 13:03:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04280 for ; Tue, 18 Nov 2003 13:03:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMAAJ-000HhZ-PD for v6ops-data@psg.com; Tue, 18 Nov 2003 18:01:27 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMA9j-000Hej-Fx for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:00:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAII0eq25196; Tue, 18 Nov 2003 20:00:40 +0200 Date: Tue, 18 Nov 2003 20:00:40 +0200 (EET) From: Pekka Savola To: Senthil Sivakumar cc: Suresh Satapati , Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] In-Reply-To: <4.3.2.7.2.20031117212517.06a7fbc0@mira-sjcd-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Senthil Sivakumar wrote: > I am not sure what the problem is, either. It is very clear if you > have a v4 only application/node/network, talking to a v6 only > application/node/network you need a protocol translator. Right (for some definition of translator). > It is a no > brainer. Why can't we concede that and move on? The generic protocol > translator is a transition mechanism and it belongs in this WG. The question here is, if we don't want a generic protocol translator, how could we define a translator very specific to achieve the SIP requirements? At some point there may be a decision which way is preferable, augmenting NAT-PT by defining a SIP ALG, or specifying a separate mechanism (which may or may not be using some of NAT-PT concepts). The point is, that we should not lock ourselves out of either possibility at this point, until we see what kind of requirements SIPPING WG has. Note to Karim et al: has SIPPING discussed this issue at "requirements" level rather than "solutions" level? Note that our charter says: If the satisfactory resolution of an operational or security issue requires the standardization of a new, widely-applicable transition mechanism that does not properly fit into any other IETF WG or area, the v6ops WG will standardize a transition mechanism to meet that need. .. the high-order bit for this debate seems to be, "if we need to get a transition mechanism done, try to do it somewhere else (w/ area expertise) first; if it fails, do it 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 Tue Nov 18 13:04:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04318 for ; Tue, 18 Nov 2003 13:04:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMABj-000Hn8-5y for v6ops-data@psg.com; Tue, 18 Nov 2003 18:02:55 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMABT-000Hm6-CC for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:02: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 9-md50000000033.tmp for ; Tue, 18 Nov 2003 19:03:33 +0100 Message-ID: <0c8701c3adfe$3fa60850$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] Date: Tue, 18 Nov 2003 19:03:17 +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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 18 Nov 2003 19:03: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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, I'm not sure if I got what do you mean ... but if you mean that ISATAP = should be used only in enterprise scenarios, I think is wrong. In general, my opinion is that if we can find the best set of transition = tools, that can be deployed everywhere in the network, to be able to = sort-out automatically several possible transition scenarios/situations, = then we got the best chance to help in the transition. And that means to = me that if a transition tool, in your example ISATAP, can be used in = more scenarios that the original scope, then is very good. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "Karim El-Malki (HF/EAB)" Cc: Sent: Tuesday, November 18, 2003 6:51 PM Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: = Recommendatio n on tunneling in the UE] > On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > > That doesn't mean the operator trusts the user at all; in this = case,=20 > > > it seems like a way to identify what is the home network to send = the=20 > > > packets to. > >=20 > > I don't understand what you mean? The user gets charged and is able > > to access services (e.g. internet access). That's the 3gpp model and > > ISATAP can be just one of those services. >=20 > Let me try to clarify, as the differences in security properties of=20 > different scenarios are clearly not clear. >=20 > My home xDSL system gets charged as well, and the ISP provides me=20 > services as well. >=20 > That doesn't mean the ISP trusts me to "behave well" in their network. = =20 > E.g., I can spoof my address, I can send specially crafted packets, I > can try to confuse their router with OSPF packets if they haven't > disabled the interface, I can harass my neighbor, etc.etc. -- to the > ISP (and other users), I'm a "hostile user". >=20 > Much the same with 3GPP, actually more, because you don't have to have = > a contract or details where you can be traced, because you can use=20 > anonymous SIMs and similar. >=20 > In a similar fashion, you cannot trust other users, because you cannot = > trust that the ISP is ensuring that the users cannot harm you (even=20 > if that was somehow possible). >=20 > On the other hand, within an enterprise network, or at least a branch=20 > of the enterprise network, typically the assumptions are entirely=20 > different: you have to trust the users at least to some degree. You=20 > have contracts etc. with them. While some host may be acting weird=20 > for some reason, the users are not typically intentionally malicious. = >=20 > So... >=20 > As it should be obvious, security mechanisms used and assumptions > implied when devising a solution to the enterprise network are very > probably not adequate for ISP/3GPP scenarios with a different set of > requirements. >=20 > Hence, I have always given significant pushback for re-using the=20 > ISATAP model outside of its (original?) scope, the enterprise=20 > networks. >=20 > > > I don't think ISATAP should be used at the home network either, = due=20 > > > to the reasons described: it doesn't fit well to a model of = crossing=20 > > > administrative borders. > >=20 > > I lost you here. What are the admin domains when the user is at = home? >=20 > Between the user and the ISP/3GPP operator, see above for better=20 > explanation. > =20 > > But please take note that there are people on this list who would = like > > to stop discussing and start finishing off those specs now pending = for > > years. >=20 > I'm sure that there are people who would like to do that. On the > other hand, that's exactly what we should not do, as even the > differences in security properties are not clear enough. >=20 > We must do what we must do, not necessarily what people would like to > do. >=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 Tue Nov 18 13:12:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04964 for ; Tue, 18 Nov 2003 13:12:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMAJ8-000IQp-N9 for v6ops-data@psg.com; Tue, 18 Nov 2003 18:10:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMAIu-000IOn-HJ for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:10:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAII9gk25336; Tue, 18 Nov 2003 20:09:42 +0200 Date: Tue, 18 Nov 2003 20:09:42 +0200 (EET) From: Pekka Savola To: Suresh Satapati cc: "Karim El-Malki (HF/EAB)" , Subject: v4 NAT vs NAT-PT models [Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP]] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Suresh Satapati wrote: > > Again, it is not required. Many NAT boxes do implement this, but many > > others do not. IPv4 NAT is fully functional without a DNS ALG. > > > > > This has been extended to v6<->v4, where an IPv6 address is being > > > replaced w/ an IPv4 one. > > > > Right, but you cannot implement NAT-PT without DNS-ALG, or something to > > replace the functionality (whereas with v4 NAT, there is no need for the > > functionality). > > Just like you can make a v4NAT work, you can make NAT-PT work without > a DNS-ALG. The model is the same. I do not know why you insist on that, because it's clearly wrong, or you have a lot of assumptions about what you mean with "make NAT-PT work". If I am behind a v4 NAT without DNS-ALG, and I try to connect to www.google.com, the connection succeeds and it works. If I am behind NAT-PT, without DNS-ALG, have v6-only host, and I try to connect to www.google.com, the connection fails because the NAT-PT cannot find the AAAA record for www.google.com. These models are NOT the same. You probably assume some other mechanism for providing similar mapping than DNS-ALG for NAT-PT. For example, manual assignment could be OK for "inbound" services. But that's completely unspecified. -- 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 Nov 18 13:15:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05072 for ; Tue, 18 Nov 2003 13:15:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMALk-000Iev-BF for v6ops-data@psg.com; Tue, 18 Nov 2003 18:13:16 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMALV-000Ic3-Ca for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:13:01 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAIICp218992; Tue, 18 Nov 2003 10:12:51 -0800 X-mProtect: <200311181812> 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 smtpd1tyjtB; Tue, 18 Nov 2003 10:12:50 PST Message-ID: <3FBA62D7.5090002@iprg.nokia.com> Date: Tue, 18 Nov 2003 10:20:07 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item References: <0a3901c3aa12$cb266450$83848182@consulintel.es> <3FBA5D02.70707@iprg.nokia.com> <0c6101c3adfd$3d0402b0$870a0a0a@consulintel.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jordi, JORDI PALET MARTINEZ wrote: >Hi Fred, > >I'm not sure to catch what do you mean and how much is serious in "NOT" ... > >Do you mean only some "expensive" (corporate ?) NATs do this ? I tried with very low cost models, and it works. > Pardon any misconceptions my message may have imparted. The term "organizational" is just like the term "enterprise" in that it may suggest to some a large, elaborate, expensive, corporate, etc. entity. In networking terms, however, an "organization" or an "enterprise" could constitute anything from the simplest 1-2 node site to the most complex internetwork in the world. So I did indeed intend to cover everything from the least expensive home gateway to the most elaborate corporate router in my blanket statement. Fred ftemplin@iprg.nokia.com >Of course, actually it worked for me with the bigger networks (I assume more expensive routers), like the Minnesota airport one when waiting for my flight ... > >Regards, >Jordi > >----- Original Message ----- >From: "Fred Templin" >To: "JORDI PALET MARTINEZ" >Cc: >Sent: Tuesday, November 18, 2003 6:55 PM >Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item > > > > >>Jordi, >> >>You can count me as favoring this work going forward, but I'd like to >>suggest that a NAT that does the proper proto41 forwarding is unlike >>a NAT in the traditional sense and perhaps in need of a new name. My >>suggestion is: >> >> Network Organizational Translator (NOT) >> >>Fred >>ftemplin@iprg.nokia.com >> >>JORDI PALET MARTINEZ wrote: >> >> >> >>>Hi all, >>> >>>In the yesterday meeting, I've presented the latest version of http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-03, the slides are available at http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf58.zip (previous slides from Vienna also at http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf57.zip). >>> >>>As nobody provided any new suggestions or objections to this document, during the meeting, my feeling is that it could be accepted as WG item. >>> >>>In addition to the comment from Mariana, I got a couple of suggestions off-line that we will like to address in the next few days, so will like to take the opportunity publish the review already as WG item version 00 and keep going with the work. >>> >>>Please, let me know if you feel this is acceptable or do you have any objections. >>> >>>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. >>> >>> >>> >>> >>> >>> >>> >> >> >> > >********************************** >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 Nov 18 13:16:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05109 for ; Tue, 18 Nov 2003 13:16:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMAMp-000Ill-Kx for v6ops-data@psg.com; Tue, 18 Nov 2003 18:14:23 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AMAMc-000Iko-CV for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:14:10 +0000 Received: (qmail 50011 invoked by uid 2502); 18 Nov 2003 18:14:07 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.151259 secs); 18/11/2003 18:14:07 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Nov 2003 18:14:07 -0000 Date: Tue, 18 Nov 2003 18:14:07 +0000 (WET) From: Carlos Friacas To: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item In-Reply-To: <3FBA5D02.70707@iprg.nokia.com> Message-ID: References: <0a3901c3aa12$cb266450$83848182@consulintel.es> <3FBA5D02.70707@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Has the "uniqueness" problem been solved/sorted out? E.g.: If i and Jordi attend the same conference and stay on the same hotel, which only has a nat box, can we both use this "mechanism"? Or should i have to phone Jordi and say: "Hey, can you disconnect for 5 mins, i need to use IPv6!". Is this still true? Is this *clearly* reflected on the current draft version? Regards, Carlos On Tue, 18 Nov 2003, Fred Templin wrote: > Jordi, > > You can count me as favoring this work going forward, but I'd like to > suggest that a NAT that does the proper proto41 forwarding is unlike > a NAT in the traditional sense and perhaps in need of a new name. My > suggestion is: > > Network Organizational Translator (NOT) > > Fred > ftemplin@iprg.nokia.com > > JORDI PALET MARTINEZ wrote: > > >Hi all, > > > >In the yesterday meeting, I've presented the latest version of http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-03, the slides are available at http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf58.zip (previous slides from Vienna also at http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf57.zip). > > > >As nobody provided any new suggestions or objections to this document, during the meeting, my feeling is that it could be accepted as WG item. > > > >In addition to the comment from Mariana, I got a couple of suggestions off-line that we will like to address in the next few days, so will like to take the opportunity publish the review already as WG item version 00 and keep going with the work. > > > >Please, let me know if you feel this is acceptable or do you have any objections. > > > >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 Nov 18 13:21:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05472 for ; Tue, 18 Nov 2003 13:21:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMARv-000JHY-4Q for v6ops-data@psg.com; Tue, 18 Nov 2003 18:19:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMARh-000JGR-Sl for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:19:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIIJMv25532; Tue, 18 Nov 2003 20:19:22 +0200 Date: Tue, 18 Nov 2003 20:19:22 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] In-Reply-To: <0c8701c3adfe$3fa60850$870a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, JORDI PALET MARTINEZ wrote: > I'm not sure if I got what do you mean ... but if you mean that > ISATAP should be used only in enterprise scenarios, I think is > wrong. Pretty close. Remember, our goal is not just to deploy IPv6 as fast as possible, it's also to do it securely, with operationally sound principles, etc. You may be assuming that if we have generic tool which works (to some definition of "works"), that's good -- nobody cares about the security considerations anyway as long as the transition is easy... :-) I'm not saying that we might not want to consider something like ISATAP in some scenarios; it's just that when doing so, we have to be careful to consider the features it provides (whether useful/desirable), the security assumptions it has, etc.etc. -- quite a number of non-trivial issues! The direction we'd develop e.g. ISATAP would probably depend a LOT on which scenarios we want to make it applicable in, which is why we need to figure out the scenarios first before going down the path of specifying mechanisms. > In general, my opinion is that if we can find the best set of > transition tools, that can be deployed everywhere in the network, to > be able to sort-out automatically several possible transition > scenarios/situations, then we got the best chance to help in the > transition. And that means to me that if a transition tool, in your > example ISATAP, can be used in more scenarios that the original > scope, then is very good. A mechanism being usable in more than one scenario would be nice, of course. But such a mechanism must also be suited for those scenarios, e.g. considering its design assumptions, security properties, operational considerations etc. I'm not sure if other than the most basic transition mechanisms such as dual-stack and configured tunneling pass this test. For example, I would not recommend 6to4 to be used by enterprises, ISPs (except for relays) or 3GPP networks. For a number of reasons, mainly based on its unreliability, and such networks requiring better control of the mechanisms ("configured tunnel") than 6to4 can provide. -- 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 Nov 18 13:29:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05795 for ; Tue, 18 Nov 2003 13:29:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMAYh-000JvZ-LE for v6ops-data@psg.com; Tue, 18 Nov 2003 18:26:39 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMAYU-000Juj-4B for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:26:26 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIIQOSs027099; Tue, 18 Nov 2003 19:26:24 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 19:26:24 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F563992C@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] Date: Tue, 18 Nov 2003 19:25:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > I don't understand what you mean? The user gets charged and is able > > to access services (e.g. internet access). That's the 3gpp > model and > > ISATAP can be just one of those services. > > Let me try to clarify, as the differences in security properties of > different scenarios are clearly not clear. > > My home xDSL system gets charged as well, and the ISP provides me > services as well. > > That doesn't mean the ISP trusts me to "behave well" in > their network. > E.g., I can spoof my address, I can send specially crafted packets, I > can try to confuse their router with OSPF packets if they haven't > disabled the interface, I can harass my neighbor, etc.etc. -- to the > ISP (and other users), I'm a "hostile user". OK. There are 3gpp specific mechanisms for this like ggsn spoofing protection. But these are generic issues which are not specific to ISATAP. > > Much the same with 3GPP, actually more, because you don't > have to have > a contract or details where you can be traced, because you can use > anonymous SIMs and similar. > > In a similar fashion, you cannot trust other users, because > you cannot > trust that the ISP is ensuring that the users cannot harm you (even > if that was somehow possible). > > On the other hand, within an enterprise network, or at least > a branch > of the enterprise network, typically the assumptions are entirely > different: you have to trust the users at least to some degree. You > have contracts etc. with them. While some host may be acting weird > for some reason, the users are not typically intentionally > malicious. Not sure I totally agree on this but I see the point. > > So... > > As it should be obvious, security mechanisms used and assumptions > implied when devising a solution to the enterprise network are very > probably not adequate for ISP/3GPP scenarios with a different set of > requirements. > > Hence, I have always given significant pushback for re-using the > ISATAP model outside of its (original?) scope, the enterprise > networks. You have talked above about generic security issues which exist independently of ISATAP. Even if you don't use ISATAP you still have those issues and I think many are addressed in 3gpp. So how can you come to the conclusion to push-back on ISATAP? We've already discussed the ISATAP security issues and I don't see the problem when using it in the 3gpp network. Plus it is only an optional mechanism! > > But please take note that there are people on this list > who would like > > to stop discussing and start finishing off those specs now > pending for > > years. > > I'm sure that there are people who would like to do that. On the > other hand, that's exactly what we should not do, as even the > differences in security properties are not clear enough. > > We must do what we must do, not necessarily what people would like to > do. We must create appropriate solutions to solve problems and not ignore them or generate new ones (like the configured tunnel proposal), otherwise quite naturally people will go off and solve it their own way. I think people want to solve problems they don't just like to do things. Careful reviewing is important but specs being discussed for years when they are implemented and out in commercial products just demonstrates that there is something wrong with the way we are handling things. /Karim From owner-v6ops@ops.ietf.org Tue Nov 18 13:30:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05857 for ; Tue, 18 Nov 2003 13:30:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMAZk-000K0U-Aw for v6ops-data@psg.com; Tue, 18 Nov 2003 18:27:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMAZP-000JyV-Pi for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:27:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIIRJx25681; Tue, 18 Nov 2003 20:27:19 +0200 Date: Tue, 18 Nov 2003 20:27:19 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org, Jasminko Mulahusic Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639929@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > We don't know until this has been analyzed. > > > > This could really be no more complicated than sending a "I want to > > use IPv6 using a tunnel" SMS (or something like that), and then your > > phone and the tunnel endpoint would be configured automatically. > > Pls see Juha's email on the complexity of doing these configs. > It makes things MORE complicated. Do you mean: [Juha W.] > Furthermore, I personally don't believe that configured tunnels make > a feasible solution for this specific problem (even though they > provide a good solution for some other scenarios). You must remember > the high number of UEs and dynamic addressing. And any extra > configuration effort isn't nice for the users. If you make the extra > configurations using SMS (like configuring APN settings for > different applications), that means one SMS more. The point is: > IPv6 should be as easy as possible. There are some assumptions in this paragraph and few technical facts. This needs more elaboration. E.g.: - why exactly would there have to be more than 1 SMS? The address is just 32 bits, 4 characters (out of 160 or so :-). Could be easily compressed in one message. - why exactly should there be any extra config for the user? It could be completely transparent to them. > > Would a modification be required? I'm not so sure of that. There > > must be some mechanisms to retrieve this information, either > > e.g. SNMP > > query or access to a database, or something. That should be pretty > > much all you need. > > That makes certain assumptions about implementations. > Seriously, it is not feasible. Also I can't understand why you think > digging info from a database is simpler than just using ISATAP. > Anyway, enough emails on this subject for me since we're not getting > anywhere. I'd like to hear more of these assumptions. That avoids getting the other features of ISATAP we don't need here, and provide a simpler architecture. I do not believe this possibility has been analyzed well enough to understand it's possibilities (or potential flaws). -- 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 Nov 18 13:33:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06002 for ; Tue, 18 Nov 2003 13:33:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMAcu-000KI3-DU for v6ops-data@psg.com; Tue, 18 Nov 2003 18:31:00 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMAcd-000KGk-Vr for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:30: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 58-md50000000033.tmp for ; Tue, 18 Nov 2003 19:31:38 +0100 Message-ID: <0d0101c3ae02$2b815650$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] Date: Tue, 18 Nov 2003 19:31:21 +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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 18 Nov 2003 19:31:38 +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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I see your point. Of course, when I say "works", I mean with the required security = considerations. I know for sure that we like it or not, the transition mechanisms will = be used in the "wrong" scenarios, same as NAT-PT is used some times for = what it was not designed, and we have a very little chance to change it. = So may be the goal is to make several mechanism to work together in a = single "tool box". Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Tuesday, November 18, 2003 7:19 PM Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: = Recommendatio n on tunneling in the UE] > On Tue, 18 Nov 2003, JORDI PALET MARTINEZ wrote: > > I'm not sure if I got what do you mean ... but if you mean that > > ISATAP should be used only in enterprise scenarios, I think is > > wrong. >=20 > Pretty close. >=20 > Remember, our goal is not just to deploy IPv6 as fast as possible, > it's also to do it securely, with operationally sound principles, etc. >=20 > You may be assuming that if we have generic tool which works (to some > definition of "works"), that's good -- nobody cares about the security > considerations anyway as long as the transition is easy... :-) >=20 > I'm not saying that we might not want to consider something like > ISATAP in some scenarios; it's just that when doing so, we have to be > careful to consider the features it provides (whether > useful/desirable), the security assumptions it has, etc.etc. -- quite > a number of non-trivial issues!=20 >=20 > The direction we'd develop e.g. ISATAP would probably depend a LOT > on which scenarios we want to make it applicable in, which is why we > need to figure out the scenarios first before going down the path of=20 > specifying mechanisms. >=20 > > In general, my opinion is that if we can find the best set of > > transition tools, that can be deployed everywhere in the network, to > > be able to sort-out automatically several possible transition > > scenarios/situations, then we got the best chance to help in the > > transition. And that means to me that if a transition tool, in your > > example ISATAP, can be used in more scenarios that the original > > scope, then is very good. >=20 > A mechanism being usable in more than one scenario would be nice, of > course. >=20 > But such a mechanism must also be suited for those scenarios, e.g.=20 > considering its design assumptions, security properties, operational=20 > considerations etc. >=20 > I'm not sure if other than the most basic transition mechanisms such=20 > as dual-stack and configured tunneling pass this test. >=20 > For example, I would not recommend 6to4 to be used by enterprises, > ISPs (except for relays) or 3GPP networks. For a number of reasons, > mainly based on its unreliability, and such networks requiring better > control of the mechanisms ("configured tunnel") than 6to4 can provide. >=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 Tue Nov 18 13:46:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06441 for ; Tue, 18 Nov 2003 13:46:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMAoY-000LEw-Ka for v6ops-data@psg.com; Tue, 18 Nov 2003 18:43:02 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMAoJ-000LCt-T1 for v6ops@ops.ietf.org; Tue, 18 Nov 2003 18:42: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 12-md50000000034.tmp for ; Tue, 18 Nov 2003 19:43:42 +0100 Message-ID: <0d3501c3ae03$db175460$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <0a3901c3aa12$cb266450$83848182@consulintel.es> <3FBA5D02.70707@iprg.nokia.com> Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item Date: Tue, 18 Nov 2003 19:43:26 +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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 18 Nov 2003 19:43: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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Carlos, I think is indicated by the applicability section that is expected to be = used in SOHO. But you're right, I need to check it and we can complete = more that text to explain this situation. Only happens if both users are = using the same tunnel end point. Actually I expect the hotel to provide native or 6to4, or even use = proto-41 but with a local IPv6 router (a simple PC can do it) providing = IPv6 to all the guest. Actually if you are in the Minnesota airport at the same time, I = provided RA to allow anyone to use my laptop as an IPv6 router ;-) Regards, Jordi ----- Original Message -----=20 From: "Carlos Friacas" To: Sent: Tuesday, November 18, 2003 7:14 PM Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item >=20 > Hello, >=20 > Has the "uniqueness" problem been solved/sorted out? >=20 > E.g.: >=20 > If i and Jordi attend the same conference and stay on the same hotel, > which only has a nat box, can we both use this "mechanism"? > Or should i have to phone Jordi and say: "Hey, can you disconnect for = 5 > mins, i need to use IPv6!". >=20 > Is this still true? Is this *clearly* reflected on the current draft > version? >=20 > Regards, > Carlos >=20 >=20 > On Tue, 18 Nov 2003, Fred Templin wrote: >=20 > > Jordi, > > > > You can count me as favoring this work going forward, but I'd like = to > > suggest that a NAT that does the proper proto41 forwarding is unlike > > a NAT in the traditional sense and perhaps in need of a new name. My > > suggestion is: > > > > Network Organizational Translator (NOT) > > > > Fred > > ftemplin@iprg.nokia.com > > > > JORDI PALET MARTINEZ wrote: > > > > >Hi all, > > > > > >In the yesterday meeting, I've presented the latest version of = http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-03, = the slides are available at = http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf58.zip = (previous slides from Vienna also at = http://www.euro6ix.org/standardization/v6ops-proto41-nat_ietf57.zip). > > > > > >As nobody provided any new suggestions or objections to this = document, during the meeting, my feeling is that it could be accepted as = WG item. > > > > > >In addition to the comment from Mariana, I got a couple of = suggestions off-line that we will like to address in the next few days, = so will like to take the opportunity publish the review already as WG = item version 00 and keep going with the work. > > > > > >Please, let me know if you feel this is acceptable or do you have = any objections. > > > > > >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. > ********************************** 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 Nov 18 14:16:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07782 for ; Tue, 18 Nov 2003 14:16:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMBHx-000NEl-4c for v6ops-data@psg.com; Tue, 18 Nov 2003 19:13:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMBHG-000N8Q-1b for v6ops@ops.ietf.org; Tue, 18 Nov 2003 19:12:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIJCcs26396; Tue, 18 Nov 2003 21:12:38 +0200 Date: Tue, 18 Nov 2003 21:12:38 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] In-Reply-To: <0d0101c3ae02$2b815650$870a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, JORDI PALET MARTINEZ wrote: > I know for sure that we like it or not, the transition mechanisms > will be used in the "wrong" scenarios, same as NAT-PT is used some > times for what it was not designed, and we have a very little chance > to change it. So may be the goal is to make several mechanism to > work together in a single "tool box". .. which is all the more reason for doing the analysis before getting down to the mechanisms. NAT-PT was published before this was clear, and it resulted in some "misuse". We cannot prevent misuse, of course, but we can ensure that by proper documentation, description of the scenarios and analysis of the situation, this becomes clearer to the IPv6 deployers. -- 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 Nov 18 14:38:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09249 for ; Tue, 18 Nov 2003 14:38:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMBd9-000Oc1-HQ for v6ops-data@psg.com; Tue, 18 Nov 2003 19:35:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMBct-000OaI-Ot for v6ops@ops.ietf.org; Tue, 18 Nov 2003 19:35:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIJYvt26761; Tue, 18 Nov 2003 21:34:58 +0200 Date: Tue, 18 Nov 2003 21:34:57 +0200 (EET) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F563992C@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > OK. There are 3gpp specific mechanisms for this like ggsn > spoofing protection. But these are generic issues which are > not specific to ISATAP. Certainly, but the existance (or not) and use (or not) of these mechanisms certainly affect the requirements for the solutions we have. > > As it should be obvious, security mechanisms used and assumptions > > implied when devising a solution to the enterprise network are very > > probably not adequate for ISP/3GPP scenarios with a different set of > > requirements. > > > > Hence, I have always given significant pushback for re-using the > > ISATAP model outside of its (original?) scope, the enterprise > > networks. > > You have talked above about generic security issues which exist > independently of ISATAP. Even if you don't use ISATAP you still > have those issues and I think many are addressed in 3gpp. So how > can you come to the conclusion to push-back on ISATAP? The point is that we know the security issues (or lack thereof) in the simple mechanisms such as configured tunnels. We have not done the rounds of a full analysis of more complex techniques such as ISATAP. Until that is done, I do not believe it is appropriate to consider anything more complicated seriously. > We've already discussed the ISATAP security issues and I don't > see the problem when using it in the 3gpp network. Plus it > is only an optional mechanism! It has been "discussed" (to some definition of "discussed"), but not properly analyzed, AFAICS. > We must create appropriate solutions to solve problems and not > ignore them or generate new ones (like the configured tunnel > proposal), otherwise quite naturally people will go off and solve it > their own way. I think people want to solve problems they don't just > like to do things. This is exactly the reason why I'd like to see more discussion what to do (or not to do), so that people don't need to make their own solutions if they don't need to. > Careful reviewing is important but specs being > discussed for years when they are implemented and out in commercial > products just demonstrates that there is something wrong with the > way we are handling things. So as long as a spec has not been properly analyzed, but is already implemented or to a degree deployed, we should forget about the warts in the specs? Sorry, I don't subscribe to that belief. Maybe the analysis should have happened sooner, or we should have finished the framework to that analysis (scenarios work?) sooner? -- 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 Nov 18 14:40:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09391 for ; Tue, 18 Nov 2003 14:40:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMBgG-000OlM-In for v6ops-data@psg.com; Tue, 18 Nov 2003 19:38:32 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMBg2-000OkZ-MQ for v6ops@ops.ietf.org; Tue, 18 Nov 2003 19:38:19 +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 31-md50000000035.tmp for ; Tue, 18 Nov 2003 20:39:12 +0100 Message-ID: <0dd401c3ae0b$9bf5db00$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] Date: Tue, 18 Nov 2003 20:38: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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 18 Nov 2003 20:39:12 +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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Not sure but then, for this "misuse", I think the scenarios work is not = so useful ... because we will not be able to figure out all the possible = combinations. We are just trying on the other way, isolating a few, when = there are too many, with too many combinations, too much complicated, = too many dependencies, too length process that will not be possible = until all the 4 scenarios are done. Instead we need to put all the possibilities together of were each = transition tool can be used. It seems to me much simpler. If we take = longer and longer, the market will deploy more and more bad transition = tools, and will be worst, less controlled. Just a good description of each transition tool "own scenarios" will be = a better start. Simultaneously, in parallel, we need also to look into a = set of priorities/conflicts document: What order to choose, when several = transition tools are available. Any conflicts among several of them ? Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Tuesday, November 18, 2003 8:12 PM Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: = Recommendatio n on tunneling in the UE] > On Tue, 18 Nov 2003, JORDI PALET MARTINEZ wrote: > > I know for sure that we like it or not, the transition mechanisms > > will be used in the "wrong" scenarios, same as NAT-PT is used some > > times for what it was not designed, and we have a very little chance > > to change it. So may be the goal is to make several mechanism to > > work together in a single "tool box". >=20 > .. which is all the more reason for doing the analysis before getting=20 > down to the mechanisms. NAT-PT was published before this was clear,=20 > and it resulted in some "misuse". >=20 > We cannot prevent misuse, of course, but we can ensure that by proper > documentation, description of the scenarios and analysis of the > situation, this becomes clearer to the IPv6 deployers. >=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 Tue Nov 18 15:13:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11999 for ; Tue, 18 Nov 2003 15:13:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMCAO-00019i-65 for v6ops-data@psg.com; Tue, 18 Nov 2003 20:09:40 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMCAC-00018e-0l for v6ops@ops.ietf.org; Tue, 18 Nov 2003 20:09:28 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11375; Tue, 18 Nov 2003 15:09:15 -0500 (EST) Message-Id: <200311182009.PAA11375@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-ipv4survey-int-03.txt Date: Tue, 18 Nov 2003 15:09:15 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-int-03.txt Pages : 56 Date : 2003-11-18 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-int-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-int-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-18124248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-int-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-int-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-18124248.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Nov 18 15:26:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13239 for ; Tue, 18 Nov 2003 15:26:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMCOT-0002BU-Ou for v6ops-data@psg.com; Tue, 18 Nov 2003 20:24:13 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMCOG-0002Ak-Oe for v6ops@ops.ietf.org; Tue, 18 Nov 2003 20:24:00 +0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 12:32:16 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAIKNvAv012518; Tue, 18 Nov 2003 12:23:58 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR76378; Tue, 18 Nov 2003 12:23:49 -0800 (PST) Date: Tue, 18 Nov 2003 12:23:40 -0800 (PST) From: Suresh Satapati To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: v4 NAT vs NAT-PT models [Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP]] In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka I think you are digressing too much here.. On Tue, 18 Nov 2003, Pekka Savola wrote: > On Tue, 18 Nov 2003, Suresh Satapati wrote: > > > Again, it is not required. Many NAT boxes do implement this, but many > > > others do not. IPv4 NAT is fully functional without a DNS ALG. > > > > > > > This has been extended to v6<->v4, where an IPv6 address is being > > > > replaced w/ an IPv4 one. > > > > > > Right, but you cannot implement NAT-PT without DNS-ALG, or something to > > > replace the functionality (whereas with v4 NAT, there is no need for the > > > functionality). > > > > Just like you can make a v4NAT work, you can make NAT-PT work without > > a DNS-ALG. The model is the same. > > I do not know why you insist on that, because it's clearly wrong, or > you have a lot of assumptions about what you mean with "make NAT-PT > work". > > If I am behind a v4 NAT without DNS-ALG, and I try to connect to > www.google.com, the connection succeeds and it works. > > If I am behind NAT-PT, without DNS-ALG, have v6-only host, and I try > to connect to www.google.com, the connection fails because the NAT-PT > cannot find the AAAA record for www.google.com. > > These models are NOT the same. > > You probably assume some other mechanism for providing similar mapping > than DNS-ALG for NAT-PT. For example, manual assignment could be OK > for "inbound" services. But that's completely unspecified. > I agree it is much simpler in v4NAT to do that, than in v6<->v4. As you mentioned above, the way to do w/o ALG maybe unspecified in the RFC. But then most RFC's are like that. They leave a lot for the implementors. Because something is unspecified doesn't rule out the possibility. I'd request you to stop this and get back to the original thread [Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP]] I'd like to get a sense on where the WG Chairs stand regarding: <---- from my prev. mail ------> Briefly, the problem is SIP-ALG i.e., parsing SIP payload for addresses /ports and replacing them w/ v4/v6 equivalents is not recommended. Folks are calling it "SIP editing". > folks probably know better which kind of tool might solve the problem. If > it's sufficiently close to NAT-PT, why not reuse parts of it and specify > something to create the mappings; if not, maybe it's worth doing something > else. I just don't think this WG is the right place to define that. SIP(ping) folks should just worry about the problem that I stated above, and nothing more. The above tells me that this WG is deliberately letting another WG define "yet another" translator without understanding what the problem is, and use this as means to eventually deprecate RFC2766. From owner-v6ops@ops.ietf.org Tue Nov 18 16:56:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20027 for ; Tue, 18 Nov 2003 16:56:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMDm3-0007Sv-T6 for v6ops-data@psg.com; Tue, 18 Nov 2003 21:52:39 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMDlp-0007Qp-5v for v6ops@ops.ietf.org; Tue, 18 Nov 2003 21:52:25 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAILq3H31787; Tue, 18 Nov 2003 13:52:03 -0800 X-mProtect: <200311182152> 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 smtpdZQISwU; Tue, 18 Nov 2003 13:52:02 PST Message-ID: <3FBA9639.2070701@iprg.nokia.com> Date: Tue, 18 Nov 2003 13:59: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: Pekka Savola CC: "Karim El-Malki (HF/EAB)" , v6ops@ops.ietf.org Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just trying to summarize and respond to what I perceive as Pekka's outstanding concerns: 1) The ISATAP host not being trusted by the 3GPP network: We have the 3GPP PDP context which provides authenticated L2 access. Pekka seems to think this isn't good enough to ensure that the node can be trusted by the operator, but this is exactly the same case whether/not ISATAP is used. This is therefore not an ISATAP issue. 2) ISATAP including mechanisms other than for host<->router interactions: - It is true that mechanisms are provided that allow nodes with the same prefix to talk directly w/o going through an ISATAP router when ISATAP addresses are used. But, this mechanism probably won't be used much (if at all) in practice. Instead, the vast majority of interactions will be host<->router. 3) ISATAP nodes not being trusted by other ISATAP nodes: - ISATAP routers are identified by their FQDN which resolves to a set of AAAA and A RR's. The A record is used to create the ISATAP link-local address of the router, and the AAAA records are host routes that use the link-local address as the IPv6 next-hop. The initail RS causes the router to do a reverse-DNS lookup for the IPv6 source address, which returns a list of AAAA and A records for the initiating host. The returned RA includes routes which are checked against the AAAA and A records the host learned from the DNS. If the routes match what was learned from the DNS, we have mutual authentication since both ISATAP nodes trust the information in the DNS and the end-to-end trust issue is resolved. 4) Crossing administrative boundaries: - If we have a NOT (Network Organizational Translator) in the path, the ISATAP proto41 packets will undergo translation and cross an organizational boundary. But, we have the mutual authentication in 3) to support the end-to-end trust. Some communications SHOULD NOT cross organizational boundaries (e.g., print services, network filesystem, etc.) and these will use IPv6 addresses with appropriate scoping to avoid leakage. Was there anything else, or does this cover it? Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote: > > >>OK. There are 3gpp specific mechanisms for this like ggsn >>spoofing protection. But these are generic issues which are >>not specific to ISATAP. >> >> > >Certainly, but the existance (or not) and use (or not) of these >mechanisms certainly affect the requirements for the solutions we >have. > > > >> > As it should be obvious, security mechanisms used and assumptions >> > implied when devising a solution to the enterprise network are very >> > probably not adequate for ISP/3GPP scenarios with a different set of >> > requirements. >> > >> > Hence, I have always given significant pushback for re-using the >> > ISATAP model outside of its (original?) scope, the enterprise >> > networks. >> >>You have talked above about generic security issues which exist >>independently of ISATAP. Even if you don't use ISATAP you still >>have those issues and I think many are addressed in 3gpp. So how >>can you come to the conclusion to push-back on ISATAP? >> >> > >The point is that we know the security issues (or lack thereof) in the >simple mechanisms such as configured tunnels. > >We have not done the rounds of a full analysis of more complex >techniques such as ISATAP. > >Until that is done, I do not believe it is appropriate to consider >anything more complicated seriously. > > > >>We've already discussed the ISATAP security issues and I don't >>see the problem when using it in the 3gpp network. Plus it >>is only an optional mechanism! >> >> > >It has been "discussed" (to some definition of "discussed"), but not >properly analyzed, AFAICS. > > > >>We must create appropriate solutions to solve problems and not >>ignore them or generate new ones (like the configured tunnel >>proposal), otherwise quite naturally people will go off and solve it >>their own way. I think people want to solve problems they don't just >>like to do things. >> >> > >This is exactly the reason why I'd like to see more discussion what to >do (or not to do), so that people don't need to make their own >solutions if they don't need to. > > > >>Careful reviewing is important but specs being >>discussed for years when they are implemented and out in commercial >>products just demonstrates that there is something wrong with the >>way we are handling things. >> >> > >So as long as a spec has not been properly analyzed, but is already >implemented or to a degree deployed, we should forget about the warts >in the specs? > >Sorry, I don't subscribe to that belief. Maybe the analysis should >have happened sooner, or we should have finished the framework to that >analysis (scenarios work?) sooner? > > > From owner-v6ops@ops.ietf.org Tue Nov 18 18:45:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26161 for ; Tue, 18 Nov 2003 18:45:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMFTG-000DsF-7f for v6ops-data@psg.com; Tue, 18 Nov 2003 23:41:22 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMFT2-000DrM-9c for v6ops@ops.ietf.org; Tue, 18 Nov 2003 23:41:08 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAINeZi20312; Tue, 18 Nov 2003 15:40:35 -0800 X-mProtect: <200311182340> 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 smtpdLYnMfh; Tue, 18 Nov 2003 15:40:34 PST Message-ID: <3FBAAFA8.3000106@iprg.nokia.com> Date: Tue, 18 Nov 2003 15:47:52 -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: Eddie Kohler CC: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues References: <200311180139.hAI1dJIe059714@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eddie, Your opinion is from the perspective of a modern-day expert technologist with specific insight into the problem space, and I have a great deal of respect for that. My opinion brings an historical perspective that I believe also bears consideration: I was very close to "ground-zero" when the current RFC-1191 style Path MTU discovery method took shape. In 1988-1990, I was heading up the team that developed ULTRIX support for Digital's initial FDDI product offering. The initial offering included an FDDI wiring concentrator (i.e., a fancy hub), two host adapters, and an Ethernet-to-FDDI L2 bridge. This latter product presented the interesting problem of how to support path MTU discovery in the presence of bridged media with diverse MTUs. The oft-cited problem case was the "dumbell configuration" in which two FDDI rings were on either side of an Ethernet pipe - in this example, how could hosts A and B on FDDI rings know whether an Ethernet was on the path? Some interesting alternatives were kicked around, including marking L2 packet headers with a bit to indicate that an Ethernet was traversed. But, a vocal minority at that time insisted that the only way to go was to either have the bridge support IPv4 fragmentation, or have it send "fragmentation needed" messages when dropping a packet with the DF bit set. The vocal minority got their way, but the chosen alternatives disqualified the opportunity to support transparent L2 bridging between media with diverse MTUs. Some made valiant attempts to market "brouter" or "transluscent bridge" products, but the vocal minority was easily able to shoot these down with counter- marketing and the advent of L3 routing (i.e., "smart networks") took flight. Since then, we have seen the boom and subsequent bust of the Internet revolution. It would be a far stretch to say that this all came as result of the path MTU discovery decisions, but I do believe it fair to say that a harmful precedent was set: folks started to believe they could engineer the network with no regard for the End-to-End Principle. So, where does this leave us today? We have an unreliable, untrustworthy (and, frankly, noisy) network-based mechanism that only works when forwarding nodes get involved with inspecting IPv4 packet headers. We'd like to be able to hook a dumb 9KB MTU Gbps Ethernet hub to a dumb 1500B MTU 10/100 Ethernet hub and enable the larger MTUs, but we can't because we blew the option out of the water back in the good old days and we have based so many of our architectural decisions on that precedent since. Now, with the emergence of techniques like PLPMTUD, we have the opportunity for healing by allowing new packetization layers, APIs, etc to gracefully supplant the old network-based mechanism. I envision an Internet restored to the End-to-End Principles, with new opportunities for innovation enabled by seamless support for L2 media with diverse MTUs. So, in response to a network that keeps endlessly screaming: "Packet Too Big!" "Fragment Needed!" I say: "Turn Off The Noise!" Fred ftemplin@iprg.nokia.com Eddie Kohler wrote: >Hi Fred, > >* PLPMTUD is useful. >* Designing PMTUD so that it works in the absence of ICMP feedback seems > necessary. > >BUT > >* Suitable ICMP feedback hints might significantly improve the performance > of a transport protocol. >* We can program our transports to react to ICMP as a hint -- i.e., not > trust it, but use it to optimize performance. >* So ICMP should not be "needed", but it might, and probably would, be quite > helpful in some cases. >* For instance, not all packetization layers have as easy a time as TCP > with packet size changes. The smooth ramp-up suggested in PLPMTUD may > require intervention from the application for example. For good > performance, these applications may apply PMTUD in unexpected ways -- > they might start large, for example. ICMP feedback would really help > them. >* ICMP is not a significant cause of Internet congestion and need not ever > become one (mark it less-than-best-effort). > >I still think your overloading of ECN capable as "PLPMTUD capable, don't >send ICMP" is not necessary, a bad idea, and will not fly. > >Eddie > > From owner-v6ops@ops.ietf.org Tue Nov 18 19:56:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28954 for ; Tue, 18 Nov 2003 19:56:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMGa1-000ICD-5l for v6ops-data@psg.com; Wed, 19 Nov 2003 00:52:25 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMGZp-000IBe-NP for v6ops@ops.ietf.org; Wed, 19 Nov 2003 00:52:13 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1AMGZp-000NBT-6X for v6ops@ops.ietf.org; Tue, 18 Nov 2003 16:52:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200311190050.hAJ0obIe068359@coyote.icir.org> In-Reply-To: Message from Fred Templin of "Tue, 18 Nov 2003 15:47:52 PST." <3FBAAFA8.3000106@iprg.nokia.com> To: Fred Templin cc: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues Date: Tue, 18 Nov 2003 16:50:37 -0800 From: Eddie Kohler X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > Since then, we have seen the boom and subsequent bust of the > Internet revolution. It would be a far stretch to say that this all > came as result of the path MTU discovery decisions, but I do > believe it fair to say that a harmful precedent was set: ... > So, where does this leave us today? We have an unreliable, > untrustworthy (and, frankly, noisy) network-based mechanism > that only works when forwarding nodes get involved with > inspecting IPv4 packet headers. ... Well, I wouldn't want to be responsible for any further destruction of the Internet revolution, but most of this seems besides the point. Old-style PMTUD, which *depended* on the delivery of ICMPs, is a far cry from new-style PMTUD, which *can benefit* from the delivery of ICMPs. The problem was the PMTU algorithm, not the idea of ICMPs. And the network isn't full of useless ICMPs. Eddie From owner-v6ops@ops.ietf.org Tue Nov 18 20:24:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29957 for ; Tue, 18 Nov 2003 20:24:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMH3B-000Jvd-Sa for v6ops-data@psg.com; Wed, 19 Nov 2003 01:22:33 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMH2z-000Jus-Hm for v6ops@ops.ietf.org; Wed, 19 Nov 2003 01:22:21 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJ1Lmu04757; Tue, 18 Nov 2003 17:21:48 -0800 X-mProtect: <200311190121> 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 smtpd6YTyvN; Tue, 18 Nov 2003 17:21:46 PST Message-ID: <3FBAC761.3040102@iprg.nokia.com> Date: Tue, 18 Nov 2003 17:29:05 -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: Eddie Kohler CC: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues References: <200311190050.hAJ0obIe068359@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eddie Kohler wrote: >Well, I wouldn't want to be responsible for any further destruction of the >Internet revolution, but most of this seems besides the point. Old-style >PMTUD, which *depended* on the delivery of ICMPs, is a far cry from >new-style PMTUD, which *can benefit* from the delivery of ICMPs. The >problem was the PMTU algorithm, not the idea of ICMPs. And the network >isn't full of useless ICMPs. > Nonetheless, I believe we should keep options open and investigate ways to support L2 devices that don't send ICMPs and don't support IP fragmentation without relegating them to second-class citizens. PLPMTUD gives us one such tool, but does it *really need* the ICMPs? We got this wrong on the first iteration some 15 years ago, and if there is now an opportunity to set things right we should at least give it serious consideration and make the right informed decisions. Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Nov 18 22:01:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02993 for ; Tue, 18 Nov 2003 22:01:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMIWu-000Oc0-0G for v6ops-data@psg.com; Wed, 19 Nov 2003 02:57:20 +0000 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMIWh-000ObO-7u for v6ops@ops.ietf.org; Wed, 19 Nov 2003 02:57:07 +0000 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hAJ2qgdH024370 for ; Wed, 19 Nov 2003 10:52:43 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Wed Nov 19 10:59:45 2003 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 10:59:45 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AE49.2F5B762E" Subject: NAT-PT: DNS ALG question X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 19 Nov 2003 10:59:44 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EC6D@bellnet-mail3.sbell.com.cn> Thread-Topic: NAT-PT: DNS ALG question Thread-Index: AcOuSS4GckTp4u4KTy6IdMKvafU1ng== From: "CTO WEI Renxiang" To: X-OriginalArrivalTime: 19 Nov 2003 02:59:45.0022 (UTC) FILETIME=[2F8E81E0:01C3AE49] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AE49.2F5B762E Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, I wanted to know what would be the correct behavior for the following scenario. Suppose a mix(include both IPv4 and IPv6 host) network with a NAT-PT and = DNS-ALG deployed on the border. An outside IPv4 client host sends a A query, thru NAT-PT, = to a DNS=20 server in this mix network. NAT-PT RFC says that a A need to be = translated into AAAA, but if the host in this mix network been queried is an IPv4-only host, = the result will not be correct. The RFC really doesn't say anything like that. Should DNS-ALG need to query the DNS server in this mix network before = it translates the A to AAAA? Thanks Renxiang ------_=_NextPart_001_01C3AE49.2F5B762E Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable NAT-PT: DNS ALG question

Hi,

I wanted to know what would be the correct behavior for the = following
scenario.

Suppose a = mix(include both IPv4 and IPv6 host) network with a NAT-PT and DNS-ALG = deployed
on the = border. An outside IPv4 client host sends a A query, thru NAT-PT, to = a DNS
server = in this mix network. NAT-PT RFC says that a A need = to be translated into AAAA,
but if the host = in this mix network been queried is an IPv4-only host, the result will = not be correct.
The RFC = really doesn't say anything like that.

Should DNS-ALG = need to query the DNS server in this mix network before it translates = the A to AAAA?

Thanks
Renxiang

------_=_NextPart_001_01C3AE49.2F5B762E-- From owner-v6ops@ops.ietf.org Tue Nov 18 23:03:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04882 for ; Tue, 18 Nov 2003 23:03:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMJUY-0001Wm-CN for v6ops-data@psg.com; Wed, 19 Nov 2003 03:58:58 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMJUJ-0001WG-Fu for v6ops@ops.ietf.org; Wed, 19 Nov 2003 03:58:43 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id C4ED143212D for ; Tue, 18 Nov 2003 22:58:39 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 0791A7DFE1; Tue, 18 Nov 2003 22:58:39 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Wed, 19 Nov 2003 09:28:38 +0530 X-Sasl-Enc: EMGG8bXnutFidAan2lI9Ww 1069214318 Subject: Comments on unmaneval-00 Message-Id: <20031119035839.0791A7DFE1@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Comments in unmaneval-00. Pekka has given comments in the past, but I am feeling too lazy to go through them, and remove duplicates, iron out conflicts.... :-) CP High Level ---------- 0. The document probably needs to be summarized in a table form. The table can have the following columns: a) Case - A, B, C, D b) DNS server discovery - DHCPv4 - DHCPv6 - Static - ..... c) Publishing IP address mechanisms - Manual - DDNS d) Recommended Connectivity mechanism(s) (to the Internet) - 6to4 - native IPv6 - Tunnel - .... e) Prefix delegation method - Static - RA - DHCPv6 f) Type of gateway - router - ND proxy - L2 bridge - v4 only (NAT, with or without proto-41 filters) I know it will be a bit tough to organize all this data in a table form but, IMHO, it will be very beneficial in the future. 1. ,----[ text from unmaneval-00 ] | During the transition phase from IPv4 to IPv6 there will be IPv4 | only, dual stack or IPv6 only nodes. In this document, we make the | hypothesis that the IPv6 only nodes do not need to communicate with | IPv4 only nodes; devices that want to communicate with both IPv4 and | IPv6 nodes are expected to implement both IPv4 and IPv6, i.e. be | dual stack. `---- I don't agree with such an hypothesis. As long as IPv6-only devices are not barred, it is just a matter of time when some IPv6 application proves to be too sexy (for IPv4-only devices) to resist. From the perspective of this document, mechanisms that can be used to bridge IPv4-only and IPv6-only devices should be evaluated. The same comment applies to the text in section 3.2. 2. This document should also consider connectivity and naming requirements for IPv4-only, dual, and IPv6-only internal gateways, and all the hosts that are behind these gateways. 3. ,----[ text from unmaneval-00 ] | To gauge the difference, we consider the case of a host engaging in | Voice over IP: it will maintain its address reachable all the time, | and it will send a large amount of traffic whenever it is engaged in | a conversation. According to classic figures collected by AT&T, the | average duration of a conversation is around 100 seconds, and a | business telephone is likely to be engaged in a conversation about | 10% of the time, which implies starting a conversation on average | every 1000 seconds. The average load sent by a tunnel client to the | tunnel server will be 10% of the average data rate of the client; | assuming a 16kbps codec and 50 packets per second, the data rate of | the client sums up to about 51 kbps, hence an average load on the | tunnel server of 5 kbps. The load sent by the tunnel client to the | tunnel server will be about one exchange of bubble per minute, to | defend the address, plus one bubble exchange at the beginning of | each session with a new peer; adding all headers, the bubble size is | about 144 bytes, which results in about 20 bps of traffic on the | server. In short, the amount of traffic seen by the Teredo server is | 250 times less that the traffic seen by a Teredo client. `---- This text is misleading. a) It does not mention that the traffic that will be seen by Teredo relays (which will equal to the traffic seen by the client). b) VoIP is not the best example. In the initial phases the applications will be p2p or client-server (http). For client server applications most of the traffic will be from the server to client, and in that case the advantage of TEREDO server would not seem to be that great because the servers (e.g. http server) will not be using TEREDO. Considering the number of messages (TEREDO + the VoIP protocol) to be exchanged, VoIP call setup may be too slow. This may be another reason for not using VoIP. 4. ,----[ text from unmaneval-00 ] | The tunnel approach is more expensive to provide, because the tunnel | server will have to carry a much larger amount of traffic. It is | unclear that a tunnel service can be provided as an almost free | "supporting infrastructure", except perhaps if the service was | directly provided by the same ISP that already provides IPv4 | connectivity to the unmanaged network. `---- This text is also mis-leading. For complete IPv6 connectivity Teredo Relays also have to be deployed, and they don't seem to be an almost free "supporting infrastructure". 5. ,----[ text from unmaneval-00 ] | discovery. In short, Teredo is more complex, but the complexity is | not overwhelming. `---- :-) This is very subjective. Probably some statistics about "Lines of Code" or "number of messages" might be a logical comparison criteria. 6. ,----[ text from unmaneval-00 ] | Teredo appears to be a good fit for providing IPv6 connectivity to | hosts behind NAT, in case A of IPv6 deployment. The service is | designed for minimizing the cost of deploying the server, which | matches the requirement of minimizing the cost of the "supporting | infrastructure" for peer-to-peer applications. `---- Mis-leading as discussed above. 7. ,----[ text from unmaneval-00 ] | The most reasonable solution would be to develop a tunnel service | specification that is compatible with Teredo, so that a given host | could be configured to use either Teredo or the tunnel service, | depending on the server configured in the dual stack host. `---- I beg to differ. Tunnel Service works with all kinds of NATs, is simple, and requires a server to talk to all other IPv6 clients. Teredo does not work with all kinds of NATs, is complex, and requires a relay to talk with all other non-TEREDO IPv6 clients. 8. Text regarding naming service should be added in Section 2. 9. ,----[ text from unmaneval-00 ] | The gateway must be able to acquire an IPv6 prefix, delegated by the | ISP. The possible mechanisms are RA proxy and explicit prefix | delegation. `---- Rephrase to ,----[ new text ] | The gateway must be able to acquire an IPv6 prefix, delegated by the | ISP. The possible mechanisms are ND proxy and prefix delegation using | DHCPv6, and RA (gateway is an L2-bridge). `---- Section 3.1.3 for "Gateway as L2 bridge" should be added. Section 5.1.1 will need minor modifications. 10. ,----[ text from unmaneval-00 ] | The principle of RA proxy is simple: the gateway issues a "router | solicitation" message on the serial link, receives a "router | advertisement", learns a network prefix from the advertisement, and | advertises the same prefix on the unmanaged network. `---- Maybe this is how RA proxy was envisaged. But, it is not a complete representation of the functioning of an ND proxy. ,----[ text from unmaneval-00 ] | This sharing has effects on neighbor discovery protocols, and | possibly also on other protocols such as LLMNR that rely on "link | local multicast". These effects need to be carefully studied. `---- Remove. 11. ISATAP does not seem to be a suitable mechanism to be used within an unmanaged network as these networks are so trivial that they will always support native IPv6. In case, you folks feel that ISATAP (within the network) is *really* required, then ISATAP will be applicable to both case B, and C. Parts of section 4.1.3 also need to be modified. Section 4.1.3, last paragraph that talks of usage of ISATAP to provide IPv6 Internet connectivity can be retained. 12. Section 5 seems to be written in a bit of a hurry. :-) There are few things that are missing. a) Mechanisms to provide connectivity to IPv4 networks b) IPv4 address assignment mechanisms. c) Naming mechanisms for IPv4. A read of Section 5.4 (unman-scenarios-03) is needed before re-writing. Semi-editorial -------------- 16. ,----[ text from unmaneval-00 ] | The issues involved are described in the next chapters. This | analysis outlines two types of requirements: connectivity | requirements, i.e. how to ensure that nodes can exchange IP packets, | and naming requirements, i.e. how to ensure that nodes can resolve | each-other's names. `---- Rephrase to ,----[ new text ] | The following sections evaluate various transition mechanisms that may | be used for cases A, B, C, and D (as defined above). There are two | requirements in each case: 1) connectivity requirements i.e. how to | ensure that nodes can exchange IP packets, and 2) naming requirements | i.e. how to ensure that hosts can resolve other names of other nodes | (local, and remote), and publishing their IPv6 addresses on the | Internet. `---- Another paragraph that describes the document organization (Section X describes foo, Section Y describes bar etc) can also be added. 17. Rename section 3.1 to Connectivity. And, within that section explain that the only thing needed for connectivity to the IPv6 Internet in this case (case B) is prefix delegation. 18. Come to think of it, Connectivity means two things - 1) how are addresses assigned (to hosts in the subnet), and 2) what is needed for the actual connection apart from executing IPv6. For case B, only "1)" needs to be answered as the actual connection will happen with native IPv6. For case A, in the description of TEREDO, and "tunnel broker", the address assignment part should be mentioned. The same comment (as for case A) applies for case C. 6to4 mentions address assignment but "Tunnel broker" does not. 19. ,----[ text from unmaneval-00 ] | Just using DHCPv4 will not be an adequate solution for IPv6 only | local hosts. Three solutions have been envisaged for these hosts: | either using DHCPv6 to obtain the address of the DNS server; sending | the DNS requests to a well known IPv6 address; or sending the DNS | requests to the IPv6 address of the gateway itself. `---- Specify why DHCPv4 will not be an adequate solution. Also add a reference to DHCPv4. This paragraph should be moved to section 3.3, and it should be reworded to say that there are four solutions. Each subsection can present the solutions (as it is now) and their pros/cons. 20. ,----[ text from unmaneval-00 ] | Another potential limitation of the technology is the reliance on | publicly accessible "6to4 relay routers" that accept packets from | 6to4 routers and relay them to the "regular" IPv6 Internet. These | relays all listen to the same IPv4 anycast address [6TO4ANYCAST], | which enables gateways to start operating as 6to4 routers without | requiring any explicit configuration. As the deployment of IPv6 | progresses, a growing fraction of the traffic originating from 6to4 | routers will have to be carried through these relays, potentially | leading to severe congestion of the relays. `---- This paragraph can be rephrased to say that a) 6to4 relay routers are needed, and their functions are ..... b) There are two ways to send traffic to a 6to4 relay router. 1) router may support the anycast address as specified in 6TO4ANYCAST. 2) contractual agreements. c) Perils of 1, and 2 d) How to alleviate the perils? The route optimization method (even if it were to be implemented) will not alleviate congestion, and may actually increase congestion in the relay router. e.g. after implementing the route optimization it might turn out that almost all sites send traffic to a small subset of relay routers. If the text is modified, the text corresponding to 6to4 in section 4.1.4 should also be reworded. Editorial --------- 1. ,----[ text from unmaneval-00 ] | TEREDO is a mechanism designed to provide IPv6 connectivity to hosts `---- Add reference to TEREDO. 2. ,----[ text from unmaneval-00 ] | An alternative to TEREDO is to simply establish a tunnel to a | "tunnel broker" outside the unmanaged network; in order to traverse | the NAT, the IPv6 packets would be carried over UDP. This solution | was described in a draft that has now expired, and is also mentioned | as a possible alternative to the bubble mechanism in the TEREDO | specification. `---- Add normative reference to tunnel broker mechanism, and mention in the reference that the draft has expired. If the recommendation is followed then it seems that the draft will be revived. Also, it will be easy for folks like me who haven't been around for that long to locate the draft for review purpose. 3. At various points, the document talks of a dual-stack ISP. I am not too sure if this terminology is standard. Can you add a definition of dual- stack ISP? 4. Section titles to be written in upper case. e.g. s/Meeting case B requirements/Meeting Case B Requirements/ 5. s/make sure/ensure/ 6. In section 3.1.1 s/DHCP /DHCPv6 / 7. ,----[ text from unmaneval-00 ] | Several networks have already started using an explicit prefix | delegation mechanism using DHCPv6. `---- Add reference for DHCPv6. 8. ,----[ text from unmaneval-00 ] | * Dynamic configuration using the standard dynamic DNS protocol; `---- Add reference for the protocol. Rephrase to ,----[ new text ] | * Dynamic configuration using the standard Dynamic DNS (DDNS) | protocol; `---- 9. ,----[ text from unmaneval-00 ] | Manual configuration of stable addresses is not satisfactory in an | unmanaged IPv6 network: the prefix allocated to the gateway may or | may not be stable, and in any case copying long binary addresses | through a manual procedure is error prone. `---- Rephrase to ,----[ new text ] | Manual configuration of stable addresses may not satisfactory in an | unmanaged IPv6 network if the prefix allocated to the gateway is not | stable, and in any case copying long binary addresses through a manual | procedure is error prone. `---- 10. ,----[ text from unmaneval-00 ] | A simplified form of case B occurs is a single host with a global | IPv4 address, i.e. with a direct connection to the IPv4 Internet. | This host will be able to use the same tunneling mechanisms as a | gateway. `---- s/case B/case A and B/ From owner-v6ops@ops.ietf.org Wed Nov 19 01:36:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08671 for ; Wed, 19 Nov 2003 01:36:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMLsU-0009CN-OG for v6ops-data@psg.com; Wed, 19 Nov 2003 06:31:50 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMLsI-0009Bb-N7 for v6ops@ops.ietf.org; Wed, 19 Nov 2003 06:31:38 +0000 Received: from SSENTHIL-W2K1.cisco.com ([10.32.254.218]) by sj-core-3.cisco.com (8.12.6/8.12.6) with SMTP id hAJ6VXrY003823; Tue, 18 Nov 2003 22:31:35 -0800 (PST) Message-Id: <4.3.2.7.2.20031118213635.05541bc8@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Nov 2003 22:31:30 -0800 To: "CTO WEI Renxiang" From: Senthil Sivakumar Subject: Re: NAT-PT: DNS ALG question Cc: In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07205EC6D@bellnet-mail3.sbell .com.cn> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_47882541==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_47882541==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:59 AM 11/19/2003 +0800, CTO WEI Renxiang wrote: >Hi, > >I wanted to know what would be the correct behavior for the following >scenario. > >Suppose a mix(include both IPv4 and IPv6 host) network with a NAT-PT and >DNS-ALG deployed >on the border. An outside IPv4 client host sends a A query, thru NAT-PT, >to a DNS >server in this mix network. NAT-PT RFC says that a A need to be translated >into AAAA, >but if the host in this mix network been queried is an IPv4-only host, the >result will not be correct. >The RFC really doesn't say anything like that. These two v4 devices should have had some means of communicating before NAT-PT, which is probably NAT. And I would assume that they continue to talk to each other using NAT. If you say that the NAT and NAT-PT are running in the same box, then it would become a coexistence and/or implementation issue and you won't find those issues in NAT-PT RFC. >Should DNS-ALG need to query the DNS server in this mix network before it >translates the A to AAAA? > >Thanks >Renxiang --=====================_47882541==_.ALT Content-Type: text/html; charset="us-ascii" At 10:59 AM 11/19/2003 +0800, CTO WEI Renxiang wrote:

Hi,

I wanted to know what would be the correct behavior for the following
scenario.

Suppose a mix(include both IPv4 and IPv6 host) network with a NAT-PT and DNS-ALG deployed
on the border. An outside IPv4 client host sends a A query, thru NAT-PT, to a DNS
server in this mix network. NAT-PT RFC says that a A need to be translated into AAAA,
but if the host in this mix network been queried is an IPv4-only host, the result will not be correct.
The RFC really doesn't say anything like that.

These two v4 devices should have had some means of communicating before NAT-PT, which is
probably NAT. And I would assume that they continue to talk to each other using NAT. If
you say that the NAT and NAT-PT are running in the same box, then it would become a coexistence
and/or implementation issue and you won't find those issues in NAT-PT RFC.

Should DNS-ALG need to query the DNS server in this mix network before it translates the A to AAAA?

Thanks
Renxiang
--=====================_47882541==_.ALT-- From owner-v6ops@ops.ietf.org Wed Nov 19 02:43:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07370 for ; Wed, 19 Nov 2003 02:43:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMMve-000CiV-Ln for v6ops-data@psg.com; Wed, 19 Nov 2003 07:39:10 +0000 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMMv9-000Ch4-Pa for v6ops@ops.ietf.org; Wed, 19 Nov 2003 07:38:45 +0000 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hAJ7XtdH013016 for ; Wed, 19 Nov 2003 15:34:12 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Wed Nov 19 15:40:45 2003 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 15:40:45 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AE70.70B9534E" Subject: re: NAT-PT: DNS ALG question X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 19 Nov 2003 15:40:44 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EC6E@bellnet-mail3.sbell.com.cn> Thread-Topic: NAT-PT: DNS ALG question Thread-Index: AcOuZ5ltvIEBG4pzQLmhwQGqQMzgoAABe9DA From: "CTO WEI Renxiang" To: "Senthil Sivakumar" Cc: X-OriginalArrivalTime: 19 Nov 2003 07:40:45.0451 (UTC) FILETIME=[7127CDB0:01C3AE70] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AE70.70B9534E Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I'm not sure if I got what do you mean. Maybe we can clarify by a = typical sequence: =20 DNS server (D) V4 host(A) NAT-PT v4 host(X) =20 V6 host(B) DNS-ALG =20 =20 1. X sends DNS query to D, which will be intercepted by NAT-PT; 2. NAT-PT modifies the query to AAAA. 3. NAT-PT relay the query to D; 4. D replise that that are no AAAA RR. =20 If NAT is used, it'll function after the DNS query returned by DNS = server. that's after step 4. If we explore some other means of communication before NAT-PT, = modification to the applications will be needed. =20 My suggestion is DNS-ALG query the DNS server before it translates the A = to AAAA. =20 R.G. Renxiang =20 ----- Original ----- Sender: Senthil Sivakumar [mailto:ssenthil@cisco.com] Time: 2003=C4=EA11=D4=C219=C8=D5 14:32 Receiver: CTO WEI Renxiang CC: v6ops@ops.ietf.org Title: Re: NAT-PT: DNS ALG question At 10:59 AM 11/19/2003 +0800, CTO WEI Renxiang wrote: Hi, I wanted to know what would be the correct behavior for the following scenario.=20 Suppose a mix(include both IPv4 and IPv6 host) network with a NAT-PT and = DNS-ALG deployed=20 on the border. An outside IPv4 client host sends a A query, thru NAT-PT, = to a DNS=20 server in this mix network. NAT-PT RFC says that a A need to be = translated into AAAA,=20 but if the host in this mix network been queried is an IPv4-only host, = the result will not be correct.=20 The RFC really doesn't say anything like that.=20 These two v4 devices should have had some means of communicating before = NAT-PT, which is probably NAT. And I would assume that they continue to talk to each = other using NAT. If you say that the NAT and NAT-PT are running in the same box, then it = would become a coexistence and/or implementation issue and you won't find those issues in NAT-PT = RFC.=20 Should DNS-ALG need to query the DNS server in this mix network before = it translates the A to AAAA? Thanks Renxiang ------_=_NextPart_001_01C3AE70.70B9534E Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I'm not sure if I = got what do=20 you mean. Maybe we can clarify by a typical = sequence:
 
DNS server=20 (D)
V4=20 host(A)      NAT-PT    =             &= nbsp;       =20 v4 host(X)  
V6=20 host(B)      DNS-ALG  =20
 
1. X sends DNS = query to D,=20 which will be intercepted by NAT-PT;
2. NAT-PT modifies=20 the query to AAAA.
3. NAT-PT relay the = query to=20 D;
4. D replise = that that are=20 no AAAA RR.
 
If NAT is = used, it'll=20 function after the DNS query returned by DNS server. that's after step=20 4.
If we explore some other means of communication = before=20 NAT-PT, modification to the applications
will be=20 needed.
 
My suggestion is = DNS-ALG query=20 the DNS server before it translates the A to AAAA.
 
R.G.
Renxiang
 
----- Original  -----
 Sender: Senthil = Sivakumar=20 [mailto:ssenthil@cisco.com]
 Time: = 2003=C4=EA11=D4=C219=C8=D5=20 14:32
 Receiver: CTO = WEI=20 Renxiang
 CC:=20 v6ops@ops.ietf.org
 Title: Re: = NAT-PT: DNS ALG=20 question

At 10:59 AM 11/19/2003 +0800, CTO WEI = Renxiang=20 wrote:

Hi,

I wanted = to know=20 what would be the correct behavior for the = following
scenario.=20

Suppose a mix(include both IPv4 and IPv6 = host) network=20 with a NAT-PT and DNS-ALG deployed
on the=20 border. An outside IPv4 client host sends a A query, thru NAT-PT, to a DNS=20
server in this mix = network.=20 NAT-PT RFC says that a A need to be translated = into=20 AAAA,
but if the host in this mix network = been=20 queried is an IPv4-only host, the result will not be correct. =
The RFC really doesn't say anything like = that.=20

These two v4 devices should have had some means = of=20 communicating before NAT-PT, which is
probably NAT. And I would = assume that=20 they continue to talk to each other using NAT. If
you say that the = NAT and=20 NAT-PT are running in the same box, then it would become a=20 coexistence
and/or implementation issue and you won't find those = issues in=20 NAT-PT RFC.

Should DNS-ALG need = to query=20 the DNS server in this mix network before it translates the A to=20 AAAA?

Thanks
Renxiang
------_=_NextPart_001_01C3AE70.70B9534E-- From owner-v6ops@ops.ietf.org Wed Nov 19 03:13:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08220 for ; Wed, 19 Nov 2003 03:13:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMNPv-000Eg2-2T for v6ops-data@psg.com; Wed, 19 Nov 2003 08:10:27 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AMNNO-000EWa-5S for v6ops@ops.ietf.org; Wed, 19 Nov 2003 08:07:50 +0000 Received: (qmail 487 invoked by uid 2502); 19 Nov 2003 08:07:48 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.118993 secs); 19/11/2003 08:07:48 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Nov 2003 08:07:48 -0000 Date: Wed, 19 Nov 2003 08:07:48 +0000 (WET) From: Carlos Friacas To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item In-Reply-To: <0d3501c3ae03$db175460$870a0a0a@consulintel.es> Message-ID: References: <0a3901c3aa12$cb266450$83848182@consulintel.es> <3FBA5D02.70707@iprg.nokia.com> <0d3501c3ae03$db175460$870a0a0a@consulintel.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, JORDI PALET MARTINEZ wrote: > Carlos, > > I think is indicated by the applicability section that is expected to be used > in SOHO. But you're right, I need to check it and we can complete more > that text to explain this situation. Only happens if both users are > using the same tunnel end point. SOHO = Small Office, Home Office Whereas, *not* one-man office, home office. Even for a very smal office (<5 people) i still fail to see this mechanism a a good tool for transition. This "mechanism" only provides v6 connectivity to *one* IPv6 geek inside the SOHO. This is (IMHO) what i wish to fight. IPv6 is not for geeks, IPv6 should be for everyone (without any knowledge about it needed!) > Actually I expect the hotel to provide native or 6to4, or even use proto-41 > but with a local IPv6 router (a simple PC can do it) providing IPv6 to > all the guest. How many hotels will do this on a permanent basis? (adding a PC for the sole purpose of v6 routing). Hotels (and others) only worry about providing IP. The v6 bit will be only provided properly with a minimum requirement: 6to4! > Actually if you are in the Minnesota airport at the same time, I provided RA > to allow anyone to use my laptop as an IPv6 router ;-) If i were in the minnesota airport i had to discard your RAs (if i were in the US, i wouldnt like all the packets going through Spain! --different continent, bigger RTT), and find an appropriate RA, or instead find a tunnel endpoint geographically nearby (which might be an impossible task if you were already making a tunnel to spain using the proto-41 hack). > Regards, > Jordi Regards, Carlos From owner-v6ops@ops.ietf.org Wed Nov 19 03:35:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08761 for ; Wed, 19 Nov 2003 03:35:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMNlU-000G4A-NK for v6ops-data@psg.com; Wed, 19 Nov 2003 08:32:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMNlH-000G1p-0m for v6ops@ops.ietf.org; Wed, 19 Nov 2003 08:32:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJ8WO508279; Wed, 19 Nov 2003 10:32:25 +0200 Date: Wed, 19 Nov 2003 10:32:24 +0200 (EET) From: Pekka Savola To: Chirayu Patel cc: v6ops@ops.ietf.org Subject: Re: Comments on unmaneval-00 In-Reply-To: <20031119035839.0791A7DFE1@server2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Chirayu, Thanks for detailed comments. These and a couple of others should help the unmanaged analysis to get updated and moving on track. Responding to one issue only: On Wed, 19 Nov 2003, Chirayu Patel wrote: > ,----[ text from unmaneval-00 ] > | During the transition phase from IPv4 to IPv6 there will be IPv4 > | only, dual stack or IPv6 only nodes. In this document, we make the > | hypothesis that the IPv6 only nodes do not need to communicate with > | IPv4 only nodes; devices that want to communicate with both IPv4 and > | IPv6 nodes are expected to implement both IPv4 and IPv6, i.e. be > | dual stack. > `---- > > I don't agree with such an hypothesis. As long as IPv6-only devices are > not barred, it is just a matter of time when some IPv6 application proves > to be too sexy (for IPv4-only devices) to resist. > > From the perspective of this document, mechanisms that can be used to > bridge IPv4-only and IPv6-only devices should be evaluated. > > The same comment applies to the text in section 3.2. This has been discussed in the past, and I believe should not be substantially changed. The point is, if we don't require something like this, we'll end up in scenarios where you deploy NAT-PT or something similar internal to an unmanaged network. Moreover, if there are some "too sexy" new IPv6 applications aout there, I'd suppose they're ones that work even work through NAT or NAT-PT. And that's not something we'll want. So, I think it's very reasonable to recommend deploying dual-stack at least as long as you don't have v4 nodes to talk to any more. The other point here is that if some v6 app just proves too sexy to resist, such users/nodes will have an incentive to deploy v6 themselves, not just translation -- and that's what we want. Do you agree with this? (If so, wordsmithing is obviously needed to get the message across properly.. could you try to reword 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 Wed Nov 19 04:19:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09803 for ; Wed, 19 Nov 2003 04:19:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMORh-000Izw-4Y for v6ops-data@psg.com; Wed, 19 Nov 2003 09:16:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMORK-000IyC-TU for v6ops@ops.ietf.org; Wed, 19 Nov 2003 09:15:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJ9F0E08958; Wed, 19 Nov 2003 11:15:00 +0200 Date: Wed, 19 Nov 2003 11:15:00 +0200 (EET) From: Pekka Savola To: Suresh Satapati cc: v6ops@ops.ietf.org Subject: Re: v4 NAT vs NAT-PT models In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Tue, 18 Nov 2003, Suresh Satapati wrote: > > I do not know why you insist on that, because it's clearly wrong, or > > you have a lot of assumptions about what you mean with "make NAT-PT > > work". > > > > If I am behind a v4 NAT without DNS-ALG, and I try to connect to > > www.google.com, the connection succeeds and it works. > > > > If I am behind NAT-PT, without DNS-ALG, have v6-only host, and I try > > to connect to www.google.com, the connection fails because the NAT-PT > > cannot find the AAAA record for www.google.com. > > > > These models are NOT the same. > > > > You probably assume some other mechanism for providing similar mapping > > than DNS-ALG for NAT-PT. For example, manual assignment could be OK > > for "inbound" services. But that's completely unspecified. > > I agree it is much simpler in v4NAT to do that, than in v6<->v4. As > you mentioned above, the way to do w/o ALG maybe unspecified in the RFC. > But then most RFC's are like that. They leave a lot for the implementors. > Because something is unspecified doesn't rule out the possibility. > > I'd request you to stop this and get back to the original thread [...] In turn, I'd request you to stop spreading the gross simplification that NAT-PT is equal to plain old v4 NAT, and NAT-PT works as specified without DNS-ALG. This is definitely not the case. If we refer someone to RFC2766 for translation, there are two options: either implementing DNS-ALG or inventing a replacement on your own; I don't think there exists even an internet-draft describing other possibilities to achieve the same effect. Making such a referral without explicit mention to requirements regarding DNS-ALG or similar behaviour is necessary to avoid causing any more confusion. Of course, vendors are free to deploy any unspecified mechanisms they want. But that doesn't fix the problem for those who haven't developed an unspecified mechanism for achieving the same effect; for all intents and purposes, unless something has been specified or documented, it does not exist. > I'd like to get a sense on where the WG Chairs stand regarding: [...] I take it that you're asking for an "official" standing. Could you clarify what the question is, or would you just want us to comment? I'll add that on our agenda, but the response could take a while.. -- 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 Nov 19 05:30:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11215 for ; Wed, 19 Nov 2003 05:30:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMPYV-000Nac-Jv for v6ops-data@psg.com; Wed, 19 Nov 2003 10:27:27 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMPYJ-000NZq-1Z for v6ops@ops.ietf.org; Wed, 19 Nov 2003 10:27:15 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id C17704335EC; Wed, 19 Nov 2003 05:27:13 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 921A180587; Wed, 19 Nov 2003 05:27:13 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: "Pekka Savola" Date: Wed, 19 Nov 2003 15:57:13 +0530 X-Sasl-Enc: deO1pW6ZjIgJsSpNGJTiQw 1069237633 Cc: v6ops@ops.ietf.org Subject: Re: Comments on unmaneval-00 References: ARRAY(0xa188518) In-Reply-To: ARRAY(0xa3e49f8) Message-Id: <20031119102713.921A180587@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit See below. CP On Wed, 19 Nov 2003 10:32:24 +0200 (EET), "Pekka Savola" said: > > On Wed, 19 Nov 2003, Chirayu Patel wrote: > > ,----[ text from unmaneval-00 ] > > | During the transition phase from IPv4 to IPv6 there will be IPv4 > > | only, dual stack or IPv6 only nodes. In this document, we make > > | the hypothesis that the IPv6 only nodes do not need to > > | communicate with IPv4 only nodes; devices that want to > > | communicate with both IPv4 and IPv6 nodes are expected to > > | implement both IPv4 and IPv6, i.e. be dual stack. > > `---- > > > > I don't agree with such an hypothesis. As long as IPv6-only devices > > are not barred, it is just a matter of time when some IPv6 > > application proves to be too sexy (for IPv4-only devices) to resist. > > > > From the perspective of this document, mechanisms that can be used to > > bridge IPv4-only and IPv6-only devices should be evaluated. > > > > The same comment applies to the text in section 3.2. > > This has been discussed in the past, and I believe should not be > substantially changed. > > The point is, if we don't require something like this, we'll end up in > scenarios where you deploy NAT-PT or something similar internal to an > unmanaged network. Moreover, if there are some "too sexy" new IPv6 > applications aout there, I'd suppose they're ones that work even work > through NAT or NAT-PT. And that's not something we'll want. > > So, I think it's very reasonable to recommend deploying dual-stack at > least as long as you don't have v4 nodes to talk to any more. I agree with the recommendation, and it will be followed initially...but somewhere down the line maintaining IPv4 stack (in dual stack networks) might prove to a burden. (ISP's might not want to support IPv4 as the traffic is too less, global IPv4 addresses are not available, and all the relevant services are accessible over IPv6) This will probably happen when the IPv6 Internet will be much bigger than the IPv4- only Internet. It is then that application translators or NAT-PT solutions will be developed to either access IPv6 application from IPv4 or viceversa. The former seems to be more likely. > The other point here is that if some v6 app just proves too sexy to > resist, such users/nodes will have an incentive to deploy v6 > themselves, not just translation -- and that's what we want. Deploying IPv6 may not be simple in case the ISP does not support IPv6, and the "supporting infrastructure" is not free or efficient. Moreover, the IPv6-only app developers might not want to wait for the potential IPv4 users to deploy IPv6..but rather deploy proxies to attract them. On the surface it might seem that the app developers should probably modify the app to support IPv4...but you never know the logistics. From the unmaneval document perspective, this is the case where an IPv4- only network wants to access IPv6-only applications. The document should mention that the only way to access IPv6 applications would be through external translators (if available). However, the user experience might not be good as certain features of the application might not be available, and it may be slow. (If both the assumptions are false there is not much incentive to deploy IPv6). The document should list the translation services, and give a recommendation (if possible). What do you say? CP From owner-v6ops@ops.ietf.org Wed Nov 19 05:57:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12216 for ; Wed, 19 Nov 2003 05:57:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMPyz-000PXf-AE for v6ops-data@psg.com; Wed, 19 Nov 2003 10:54:49 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMPyC-000PTn-On for v6ops@ops.ietf.org; Wed, 19 Nov 2003 10:54:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJAruk10707; Wed, 19 Nov 2003 12:53:56 +0200 Date: Wed, 19 Nov 2003 12:53:56 +0200 (EET) From: Pekka Savola To: Chirayu Patel cc: v6ops@ops.ietf.org Subject: Re: Comments on unmaneval-00 In-Reply-To: <20031119102713.921A180587@server2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 19 Nov 2003, Chirayu Patel wrote: > I agree with the recommendation, and it will be followed initially...but > somewhere down the line maintaining IPv4 stack (in dual stack networks) > might prove to a burden. (ISP's might not want to support IPv4 as the > traffic is too less, global IPv4 addresses are not available, and all the > relevant services are accessible over IPv6) This will probably happen > when the IPv6 Internet will be much bigger than the IPv4- only Internet. > > It is then that application translators or NAT-PT solutions will be > developed to either access IPv6 application from IPv4 or viceversa. The > former seems to be more likely. There are undoubtedly scenarios in the "end-game" case, maybe in 10 years (if we're lucky!) or more, which are difficult to estimate at this point. I don't think they should be considered at too much depth. > > The other point here is that if some v6 app just proves too sexy to > > resist, such users/nodes will have an incentive to deploy v6 > > themselves, not just translation -- and that's what we want. > > Deploying IPv6 may not be simple in case the ISP does not support IPv6, > and the "supporting infrastructure" is not free or efficient. Moreover, > the IPv6-only app developers might not want to wait for the potential > IPv4 users to deploy IPv6..but rather deploy proxies to attract them. On > the surface it might seem that the app developers should probably modify > the app to support IPv4...but you never know the logistics. I think we have to ensure that IPv6 is easy enough to obtain for the users so that app developers can develop IPv6-only apps. The other approach here is that we don't ensure the "easiness" of IPv6, but recommend that app developers do dual-stack apps, not IPv6-only. Nonetheless, the potential IPv6-only apps (peer-to-peer, etc.) are typically those that do NOT work properly through proxies, translators and such... so it certainly would seem to make sense to either deploy them dual-stack (if generic enough to be useful), or v6-only (uses features of IPv6 which would be munged by the translators anyway). > From the unmaneval document perspective, this is the case where an IPv4- > only network wants to access IPv6-only applications. The document should > mention that the only way to access IPv6 applications would be through > external translators (if available). However, the user experience might > not be good as certain features of the application might not be > available, and it may be slow. (If both the assumptions are false there > is not much incentive to deploy IPv6). The document should list the > translation services, and give a recommendation (if possible). > > What do you say? I'll just have to say I fundamentally disagree with this model. I do not think we must be catering for the case where IPv4 nodes must be able perform functions provided on purpose for IPv6 only; that's where we can assume that the node gets updated. Certainly, this clearly seems to need more justification/text to make the point across better.. On the other hand, the end-game case you mentioned first, going from v6-only to legacy v4 (for e.g. some very special business application coded in the 1970's) may be something we have to consider .. but that's the other way around, and not an urgent matter to consider. -- 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 Nov 19 06:51:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13430 for ; Wed, 19 Nov 2003 06:51:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMQop-0002uu-Jl for v6ops-data@psg.com; Wed, 19 Nov 2003 11:48:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMQob-0002tx-EO for v6ops@ops.ietf.org; Wed, 19 Nov 2003 11:48:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJBm3T11712; Wed, 19 Nov 2003 13:48:03 +0200 Date: Wed, 19 Nov 2003 13:48:03 +0200 (EET) From: Pekka Savola To: Fred Templin cc: "Karim El-Malki (HF/EAB)" , Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] In-Reply-To: <3FBA9639.2070701@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Fred Templin wrote: > Just trying to summarize and respond to what I perceive as Pekka's > outstanding concerns: > > 1) The ISATAP host not being trusted by the 3GPP network: > We have the 3GPP PDP context which provides authenticated > L2 access. Pekka seems to think this isn't good enough to ensure > that the node can be trusted by the operator, but this is exactly > the same case whether/not ISATAP is used. This is therefore > not an ISATAP issue. The main case here was to make the difference between the enterprise deployment and 3GPP environment; i.e., what is built for enterprise, is not typically just a plug-in for 3GPP. There is certainly nothing in L2 (or lower) authentication in 3GPP which should make the operator to trust the user more -- the point is just that the mechanisms used have to be able to be designed to the situation where no such trust exists. Whether or not ISATAP is designed for being used between untrusted peers is an open issue. > 2) ISATAP including mechanisms other than for host<->router > interactions: > - It is true that mechanisms are provided that allow nodes with > the same prefix to talk directly w/o going through an ISATAP > router when ISATAP addresses are used. But, this mechanism > probably won't be used much (if at all) in practice. Instead, > the vast majority of interactions will be host<->router. How come it would not be used? It's still in the spec, and has to be implemented, like a dozen other features which are unnecessary for a simple host-router tunneling. > 3) ISATAP nodes not being trusted by other ISATAP nodes: > - ISATAP routers are identified by their FQDN which resolves > to a set of AAAA and A RR's. The A record is used to create the > ISATAP link-local address of the router, Yes.. > and the AAAA records > are host routes that use the link-local address as the IPv6 next-hop. Not in -16 spec. > The initail RS causes the router to do a reverse-DNS lookup for > the IPv6 source address, which returns a list of AAAA and A records > for the initiating host. Not in -16 spec. > The returned RA includes routes which are > checked against the AAAA and A records the host learned from the > DNS. If the routes match what was learned from the DNS, we have > mutual authentication since both ISATAP nodes trust the information > in the DNS and the end-to-end trust issue is resolved. A part of this is true. You probably have some other ISATAP in mind that what's documented in draft-ietf-ngtrans-isatap-16.txt. Even if these were implemented like you say, one could argue whether DNS lookups (forward & reverse) is the right way to do this. But, the main concerns about ISATAP wrt. to security are: - ISATAP is too much of a moving target. It changes significantly between about each revision. Because it's not stable, it's difficult to review its properties and how they evolve over time. (Naturally, the ISATAP implementations that currently exist have very little to do with draft-ietf-ngtrans-isatap-16.txt; for example, Cisco implements isatap-03 spec AFAIK). Actually the spec could be improved a lot to be more clear, e.g., it doesn't properly describe what happens to IPv6 packets in an ISATAP node in when considering where to forward them (e.g., does the pseudo-interface have a global /64 on-link ISATAP prefix and everything else goes through default routers or what). I.e., maybe a high-view decision tree "if I'm an ISATAP node and I have an IPv6 packet I want to send, this is how I'll do it" could clarify this. - we need to analyze the security from the points of view if IPv4 spoofing is possible (or not) and if IPv6 spoofing is possible (or not) [if v6 was deployed] within the 3GPP network. There are likely to be some differences to be found here. - the biggest problem of ISATAP will probably come from the fact that all IPv6 nodes in an ISATAP site ("all of 3GPP network") are considered to be IPv6-wise "on-link" with each other. This implies being on-link with every other node; this has a huge number of possible threats (SEND). I don't know about you, but this scares me shitless. Worse than that, this is actually a design feature of ISATAP, not just something that happens to be possible if the ISP is lazy and doesn't do the easiest form of IPv4 filtering. (On the other hand, with configured tunneling, you're only on-link with the 3GPP operator's router, unless someone manages to spoof it.) - you mandate the use of IPsec AH for SLLA/TLLA options with ISATAP in the current spec. Are you aware that this probably requires changes to the encapsulating RFC2461 stacks as well, and is probably difficult to deploy in the first place? (this is not trying to be a conclusive list of the problems, but most stem from the fact that ISATAP nodes are on-link with each other.) > 4) Crossing administrative boundaries: > - If we have a NOT (Network Organizational Translator) in the path, > the ISATAP proto41 packets will undergo translation and cross an > organizational boundary. But, we have the mutual authentication in > 3) to support the end-to-end trust. Some communications SHOULD NOT > cross organizational boundaries (e.g., print services, network > filesystem, etc.) and these will use IPv6 addresses with > appropriate scoping to avoid leakage. I'm not sure if I understand your point. There is no NAT in the path in the case of ISATAP. I do not understand what you mean to say about mutual authentication, as ISATAP nodes can communicate directly, being on-link, IPv6-wise. -- 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 Nov 19 07:38:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14532 for ; Wed, 19 Nov 2003 07:38:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMRYQ-00062T-Ra for v6ops-data@psg.com; Wed, 19 Nov 2003 12:35:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMRYE-00060h-GD for v6ops@ops.ietf.org; Wed, 19 Nov 2003 12:35:18 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJCZFU12545; Wed, 19 Nov 2003 14:35:15 +0200 Date: Wed, 19 Nov 2003 14:35:15 +0200 (EET) From: Pekka Savola To: Jasminko Mulahusic cc: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP] In-Reply-To: <3FBA397C.5010900@fakat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Nov 2003, Jasminko Mulahusic wrote: > > As you pointed out the 3gpp-analysis draft addresses these > > issues and I have no problems with that. It points to the > > work to be done in SIPPING and says that such a solution > > could reuse parts of NAT-PT. > > i have a question to the wg chairs and/or ad:s: > > do you plan to deprecate nat-pt before the work (ims-translator) has > been finished in the sipping wg? I believe it's too early to plan either deprecating or embracing NAT-PT. HTH.. -- 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 Nov 19 08:08:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15329 for ; Wed, 19 Nov 2003 08:08:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMS06-0007z5-Nn for v6ops-data@psg.com; Wed, 19 Nov 2003 13:04:06 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMRzj-0007xr-Nm for v6ops@ops.ietf.org; Wed, 19 Nov 2003 13:03:43 +0000 Received: from fakat.com (pc5205203.nac.telia.se [131.115.205.203]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id hAJD4VwN031216; Wed, 19 Nov 2003 14:04:32 +0100 (CET) (envelope-from jasko@fakat.com) Message-ID: <3FBB6A27.4070005@fakat.com> Date: Wed, 19 Nov 2003 14:03:35 +0100 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suresh Satapati CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] References: In-Reply-To: X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit suresh, i really do not understand what your concern is? > I'd like to get a sense on where the WG Chairs stand regarding: > > <---- from my prev. mail ------> > > Briefly, the problem is SIP-ALG i.e., parsing SIP payload for addresses > /ports and replacing them w/ v4/v6 equivalents is not recommended. Folks > are calling it "SIP editing". > <....> > SIP(ping) folks should just worry about the problem that I stated above, > and nothing more. > > The above tells me that this WG is deliberately letting another WG define > "yet another" translator without understanding what the problem is, and > use this as means to eventually deprecate RFC2766. > > have you read draft-elmalki-v6ops-3gpp-translator-00.txt? which part you do not understand/like? the draft is explicit about what i believe is your concern: ------------- As specified in [4] SIP messages may be end-to-end integrity protected, therefore it may not possible to modify them en-route. In general the SIP WG discourages the use of intermediaries which alter the contents of SIP messages. This is a very important consideration for a 3GPP Translator solution. ------------- jasminko From owner-v6ops@ops.ietf.org Wed Nov 19 10:43:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22688 for ; Wed, 19 Nov 2003 10:43:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMUQ5-000IR5-Me for v6ops-data@psg.com; Wed, 19 Nov 2003 15:39:05 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMUPu-000IQd-52 for v6ops@ops.ietf.org; Wed, 19 Nov 2003 15:38:54 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1AMUPt-000Jkz-Cb for v6ops@ops.ietf.org; Wed, 19 Nov 2003 07:38:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200311191421.hAJELXIe072495@coyote.icir.org> In-Reply-To: Message from "Phelan, Tom" of "Tue, 18 Nov 2003 12:15:21 EST." To: "Phelan, Tom" cc: Fred Templin , dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [dccp] PMTU issues Date: Wed, 19 Nov 2003 06:21:33 -0800 From: Eddie Kohler X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > It's also possible for DCCP to get a better initial estimate of the PMTU, > and apparently there are other problems with the current DCCP PMTUD > mechanism (using ICMP "can't fragment" messages). Yes -- The current draft tries to make clear (but fails to) that a new, PLPMTUD-style MTU discovery mechanism is acceptable. There are API problems with such a scheme, but we absolutely allow it. If you can accept an extra RTT or two at connection initiation time, I think you can do pretty well: Request --> <-- Response then, all in 1 RTT: Padded Sync(512 bytes) --> /* actual #s would need to fit CC Padded Sync(1280 bytes) --> mechanism */ Padded Sync(4000 bytes) --> <-- SyncReply(1) /* SyncReplies sent only for those <-- SyncReply(2) packets that got through */ <-- SyncReply(3) > So, my question for the DCCP people, is it worth changing DCCP PMTUD? It's certainly worth describing it better, and perhaps mentioning a set of acceptable procedures. Have you any suggestions for useful procedures here? Eddie From owner-v6ops@ops.ietf.org Wed Nov 19 11:28:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24680 for ; Wed, 19 Nov 2003 11:28:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMV7V-000LGD-NR for v6ops-data@psg.com; Wed, 19 Nov 2003 16:23:57 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMV6t-000LEE-DU for v6ops@ops.ietf.org; Wed, 19 Nov 2003 16:23:19 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2003 08:23:41 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAJGNDjs021529; Wed, 19 Nov 2003 08:23:16 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANS53527; Wed, 19 Nov 2003 08:23:12 -0800 (PST) Date: Wed, 19 Nov 2003 08:23:12 -0800 (PST) From: Suresh Satapati To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: v4 NAT vs NAT-PT models In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > In turn, I'd request you to stop spreading the gross simplification > that NAT-PT is equal to plain old v4 NAT, and NAT-PT works as > specified without DNS-ALG. This is definitely not the case. When I referred to the model, I meant with NAT or NAT-PT, for certain applications (think non-DNS) you need the binding to be setup during signalling. This could be done by an ALG (or your favorite) residing on the same or a different box that does header translation. This would enable subsequent data/media to go through using the bindings. Maybe I wasn't clear about this earlier. > > If we refer someone to RFC2766 for translation, there are two options: > either implementing DNS-ALG or inventing a replacement on your own; I > don't think there exists even an internet-draft describing other > possibilities to achieve the same effect. Making such a referral > without explicit mention to requirements regarding DNS-ALG or similar > behaviour is necessary to avoid causing any more confusion. > > Of course, vendors are free to deploy any unspecified mechanisms they > want. But that doesn't fix the problem for those who haven't > developed an unspecified mechanism for achieving the same effect; > for all intents and purposes, unless something has been specified or > documented, it does not exist. You have combined two arguments, which is actually misleading. model(that i mentioned above) + DNS_ALG being a part of NAT-PT ? We can keep arguing about this and get no where. This will be my last mail on this topic. > > > I'd like to get a sense on where the WG Chairs stand regarding: > [...] > > I take it that you're asking for an "official" standing. Could you > clarify what the question is, or would you just want us to comment? > I'll add that on our agenda, but the response could take a while.. Yep. official standing. That's what I meant. From owner-v6ops@ops.ietf.org Wed Nov 19 11:50:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26179 for ; Wed, 19 Nov 2003 11:50:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMVUO-000Mce-7L for v6ops-data@psg.com; Wed, 19 Nov 2003 16:47:36 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMVUB-000Mby-P2 for v6ops@ops.ietf.org; Wed, 19 Nov 2003 16:47:23 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 Nov 2003 08:47:33 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJGlKw5017633; Wed, 19 Nov 2003 08:47:21 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANS55611; Wed, 19 Nov 2003 08:47:20 -0800 (PST) Date: Wed, 19 Nov 2003 08:47:20 -0800 (PST) From: Suresh Satapati To: Jasminko Mulahusic cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP] In-Reply-To: <3FBB6A27.4070005@fakat.com> Message-ID: References: <3FBB6A27.4070005@fakat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jasminko, I've read the draft. My only concern with the draft is: --------------------------------------------------------------------- 4.1.2 IP Address and Port Mapper (IPAPM) The IPAPM (IP Address and Port Mapper) is needed because the 3GPP IPv6-only host and the IPv4-only host cannot send media traffic to each other due to IP layer incompatibility. The IPAPM will simply perform the IP address mapping for the appropriate IP address, port, protocol tuples on both incoming and outgoing media packets. The SIP Edge Proxy will install and delete this bidirectional state in the IPAPM (see 4.4). It should be noted that the IPAPM operation is similar to that of a bidirectional NA(P)T-PT [16] after having installed state for a particular connection. That is, the translation algorithm (SIIT) is the same, the main difference is the method used to install state in the translator. Hence, if needed, an IPAPM may also operate as a normal NA(P)T-PT for other (non-IMS) traffic for which it does not have an address/port binding. ------------------------------------------------------------------------ IMO the above is nothing but NA(P)T-PT with a fancy name, w/ which the authors and Pekka disagree. On Wed, 19 Nov 2003, Jasminko Mulahusic wrote: > suresh, > > i really do not understand what your concern is? > > > I'd like to get a sense on where the WG Chairs stand regarding: > > > > <---- from my prev. mail ------> > > > > Briefly, the problem is SIP-ALG i.e., parsing SIP payload for addresses > > /ports and replacing them w/ v4/v6 equivalents is not recommended. Folks > > are calling it "SIP editing". > > > > <....> > > > SIP(ping) folks should just worry about the problem that I stated above, > > and nothing more. > > > > The above tells me that this WG is deliberately letting another WG define > > "yet another" translator without understanding what the problem is, and > > use this as means to eventually deprecate RFC2766. > > > > > > have you read draft-elmalki-v6ops-3gpp-translator-00.txt? > > which part you do not understand/like? > > the draft is explicit about what i believe is your concern: > > ------------- > As specified in [4] SIP messages may be end-to-end integrity > protected, therefore it may not possible to modify them en-route. In > general the SIP WG discourages the use of intermediaries which alter > the contents of SIP messages. This is a very important consideration > for a 3GPP Translator solution. > ------------- > > > jasminko > > From owner-v6ops@ops.ietf.org Wed Nov 19 12:36:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28493 for ; Wed, 19 Nov 2003 12:35:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMWCY-000POK-Nw for v6ops-data@psg.com; Wed, 19 Nov 2003 17:33:14 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMWCK-000PNm-Fv for v6ops@ops.ietf.org; Wed, 19 Nov 2003 17:33:00 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAJHWtjq029942; Wed, 19 Nov 2003 09:32:55 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANS61111; Wed, 19 Nov 2003 09:32:54 -0800 (PST) Date: Wed, 19 Nov 2003 09:32:54 -0800 (PST) From: Suresh Satapati To: Chirayu Patel cc: v6ops@ops.ietf.org Subject: Re: Comments on unmaneval-00 In-Reply-To: <20031119102713.921A180587@server2.messagingengine.com> Message-ID: References: ARRAY(0xa188518) <20031119102713.921A180587@server2.messagingengine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Chirayu, We captured this scenario in NAT-PT Applicability. http://www.ietf.org/internet-drafts/draft-satapati-v6ops-natpt-applicability-00.txt The same discussion did take place within "unman" design team, and the initial versions had some text to that effect. Later on, that text was removed for obvious reasons (that you see on this list) ;-) -- Suresh On Wed, 19 Nov 2003, Chirayu Patel wrote: > > See below. > > CP > > On Wed, 19 Nov 2003 10:32:24 +0200 (EET), "Pekka Savola" > said: > > > > On Wed, 19 Nov 2003, Chirayu Patel wrote: > > > ,----[ text from unmaneval-00 ] > > > | During the transition phase from IPv4 to IPv6 there will be IPv4 > > > | only, dual stack or IPv6 only nodes. In this document, we make > > > | the hypothesis that the IPv6 only nodes do not need to > > > | communicate with IPv4 only nodes; devices that want to > > > | communicate with both IPv4 and IPv6 nodes are expected to > > > | implement both IPv4 and IPv6, i.e. be dual stack. > > > `---- > > > > > > I don't agree with such an hypothesis. As long as IPv6-only devices > > > are not barred, it is just a matter of time when some IPv6 > > > application proves to be too sexy (for IPv4-only devices) to resist. > > > > > > From the perspective of this document, mechanisms that can be used to > > > bridge IPv4-only and IPv6-only devices should be evaluated. > > > > > > The same comment applies to the text in section 3.2. > > > > This has been discussed in the past, and I believe should not be > > substantially changed. > > > > The point is, if we don't require something like this, we'll end up in > > scenarios where you deploy NAT-PT or something similar internal to an > > unmanaged network. Moreover, if there are some "too sexy" new IPv6 > > applications aout there, I'd suppose they're ones that work even work > > through NAT or NAT-PT. And that's not something we'll want. > > > > So, I think it's very reasonable to recommend deploying dual-stack at > > least as long as you don't have v4 nodes to talk to any more. > > I agree with the recommendation, and it will be followed initially...but > somewhere down the line maintaining IPv4 stack (in dual stack networks) > might prove to a burden. (ISP's might not want to support IPv4 as the > traffic is too less, global IPv4 addresses are not available, and all the > relevant services are accessible over IPv6) This will probably happen > when the IPv6 Internet will be much bigger than the IPv4- only Internet. > > It is then that application translators or NAT-PT solutions will be > developed to either access IPv6 application from IPv4 or viceversa. The > former seems to be more likely. > > > The other point here is that if some v6 app just proves too sexy to > > resist, such users/nodes will have an incentive to deploy v6 > > themselves, not just translation -- and that's what we want. > > Deploying IPv6 may not be simple in case the ISP does not support IPv6, > and the "supporting infrastructure" is not free or efficient. Moreover, > the IPv6-only app developers might not want to wait for the potential > IPv4 users to deploy IPv6..but rather deploy proxies to attract them. On > the surface it might seem that the app developers should probably modify > the app to support IPv4...but you never know the logistics. > > From the unmaneval document perspective, this is the case where an IPv4- > only network wants to access IPv6-only applications. The document should > mention that the only way to access IPv6 applications would be through > external translators (if available). However, the user experience might > not be good as certain features of the application might not be > available, and it may be slow. (If both the assumptions are false there > is not much incentive to deploy IPv6). The document should list the > translation services, and give a recommendation (if possible). > > What do you say? > > CP > > From owner-v6ops@ops.ietf.org Wed Nov 19 12:48:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29231 for ; Wed, 19 Nov 2003 12:48:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMWOC-000Q0q-6h for v6ops-data@psg.com; Wed, 19 Nov 2003 17:45:16 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMWNw-000PzE-EY for v6ops@ops.ietf.org; Wed, 19 Nov 2003 17:45:00 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJHimX15526; Wed, 19 Nov 2003 09:44:48 -0800 X-mProtect: <200311191744> 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 smtpdL5orb5; Wed, 19 Nov 2003 09:44:46 PST Message-ID: <3FBBADCA.1060001@iprg.nokia.com> Date: Wed, 19 Nov 2003 09:52: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: Pekka Savola CC: "Karim El-Malki (HF/EAB)" , v6ops@ops.ietf.org Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, I don't agree that the items you are citing as "not in draft-16" actually need to be specified there. Also, as to your assertion that ISATAP is a "moving target", the best way to address that would be to either publish it as an RFC now or make it as a v6ops wg item. I prefer the former; we have seen recently how easily RFCs can be (bis)'d so there is no reason to believe that publishing now would amount to casting things in stone. Thanks - Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >On Tue, 18 Nov 2003, Fred Templin wrote: > > >>Just trying to summarize and respond to what I perceive as Pekka's >>outstanding concerns: >> >> 1) The ISATAP host not being trusted by the 3GPP network: >> We have the 3GPP PDP context which provides authenticated >> L2 access. Pekka seems to think this isn't good enough to ensure >> that the node can be trusted by the operator, but this is exactly >> the same case whether/not ISATAP is used. This is therefore >> not an ISATAP issue. >> >> > >The main case here was to make the difference between the enterprise >deployment and 3GPP environment; i.e., what is built for enterprise, >is not typically just a plug-in for 3GPP. There is certainly nothing >in L2 (or lower) authentication in 3GPP which should make the operator >to trust the user more -- the point is just that the mechanisms used >have to be able to be designed to the situation where no such trust >exists. > >Whether or not ISATAP is designed for being used between untrusted >peers is an open issue. > > > >> 2) ISATAP including mechanisms other than for host<->router >> interactions: >> - It is true that mechanisms are provided that allow nodes with >> the same prefix to talk directly w/o going through an ISATAP >> router when ISATAP addresses are used. But, this mechanism >> probably won't be used much (if at all) in practice. Instead, >> the vast majority of interactions will be host<->router. >> >> > >How come it would not be used? > >It's still in the spec, and has to be implemented, like a dozen other >features which are unnecessary for a simple host-router tunneling. > > > >> 3) ISATAP nodes not being trusted by other ISATAP nodes: >> - ISATAP routers are identified by their FQDN which resolves >> to a set of AAAA and A RR's. The A record is used to create the >> ISATAP link-local address of the router, >> >> > >Yes.. > > > >> and the AAAA records >> are host routes that use the link-local address as the IPv6 next-hop. >> >> > >Not in -16 spec. > > > >> The initail RS causes the router to do a reverse-DNS lookup for >> the IPv6 source address, which returns a list of AAAA and A records >> for the initiating host. >> >> > >Not in -16 spec. > > > >>The returned RA includes routes which are >> checked against the AAAA and A records the host learned from the >> DNS. If the routes match what was learned from the DNS, we have >> mutual authentication since both ISATAP nodes trust the information >> in the DNS and the end-to-end trust issue is resolved. >> >> > >A part of this is true. > >You probably have some other ISATAP in mind that what's documented in >draft-ietf-ngtrans-isatap-16.txt. > >Even if these were implemented like you say, one could argue whether >DNS lookups (forward & reverse) is the right way to do this. > >But, the main concerns about ISATAP wrt. to security are: > > - ISATAP is too much of a moving target. It changes significantly >between about each revision. Because it's not stable, it's difficult >to review its properties and how they evolve over time. (Naturally, >the ISATAP implementations that currently exist have very little to do >with draft-ietf-ngtrans-isatap-16.txt; for example, Cisco implements >isatap-03 spec AFAIK). > >Actually the spec could be improved a lot to be more clear, e.g., it >doesn't properly describe what happens to IPv6 packets in an ISATAP >node in when considering where to forward them (e.g., does the >pseudo-interface have a global /64 on-link ISATAP prefix and >everything else goes through default routers or what). I.e., maybe a >high-view decision tree "if I'm an ISATAP node and I have an IPv6 >packet I want to send, this is how I'll do it" could clarify this. > > - we need to analyze the security from the points of view if IPv4 >spoofing is possible (or not) and if IPv6 spoofing is possible (or >not) [if v6 was deployed] within the 3GPP network. There are likely >to be some differences to be found here. > > - the biggest problem of ISATAP will probably come from the fact that >all IPv6 nodes in an ISATAP site ("all of 3GPP network") are >considered to be IPv6-wise "on-link" with each other. This implies >being on-link with every other node; this has a huge number of >possible threats (SEND). I don't know about you, but this scares me >shitless. Worse than that, this is actually a design feature of >ISATAP, not just something that happens to be possible if the ISP is >lazy and doesn't do the easiest form of IPv4 filtering. (On the other >hand, with configured tunneling, you're only on-link with the 3GPP >operator's router, unless someone manages to spoof it.) > > - you mandate the use of IPsec AH for SLLA/TLLA options with ISATAP >in the current spec. Are you aware that this probably requires >changes to the encapsulating RFC2461 stacks as well, and is probably >difficult to deploy in the first place? > >(this is not trying to be a conclusive list of the problems, but most >stem from the fact that ISATAP nodes are on-link with each other.) > > > >> 4) Crossing administrative boundaries: >> - If we have a NOT (Network Organizational Translator) in the path, >> the ISATAP proto41 packets will undergo translation and cross an >> organizational boundary. But, we have the mutual authentication in >> 3) to support the end-to-end trust. Some communications SHOULD NOT >> cross organizational boundaries (e.g., print services, network >> filesystem, etc.) and these will use IPv6 addresses with >> appropriate scoping to avoid leakage. >> >> > >I'm not sure if I understand your point. There is no NAT in the path >in the case of ISATAP. I do not understand what you mean to say about >mutual authentication, as ISATAP nodes can communicate directly, >being on-link, IPv6-wise. > > > From owner-v6ops@ops.ietf.org Wed Nov 19 13:25:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01403 for ; Wed, 19 Nov 2003 13:25:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMWyL-0002TP-9i for v6ops-data@psg.com; Wed, 19 Nov 2003 18:22:37 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMWy8-0002SX-Vq for v6ops@ops.ietf.org; Wed, 19 Nov 2003 18:22:25 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJILmP19161; Wed, 19 Nov 2003 10:21:48 -0800 X-mProtect: <200311191821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ7MgF4; Wed, 19 Nov 2003 10:21:46 PST Message-ID: <3FBBB658.7000108@iprg.nokia.com> Date: Wed, 19 Nov 2003 10:28:40 -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: Eddie Kohler CC: "Phelan, Tom" , dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [dccp] PMTU issues References: <200311191421.hAJELXIe072495@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eddie, Yes, I agree with the idea of initially "plumbing" the path MTU when a connection starts up. If the application has lots of data to send, it might initially try to plumb out to the largest possible MTU; if only a little, it might be less aggressive during startup. It might also be desireable to piggyback the plumbing process onto other messages that require a RTT before the connection can be tried. For example, IPv6 neighbor discovery messages (e.g., Router Solicitations) can be null-padded to any length out to 64KB when they are sent over an IPv6-in-IPv4 tunnel interface. See the next to last paragraph in section 3.6 of: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt Thanks - Fred ftemplin@iprg.nokia.com Eddie Kohler wrote: >>It's also possible for DCCP to get a better initial estimate of the PMTU, >>and apparently there are other problems with the current DCCP PMTUD >>mechanism (using ICMP "can't fragment" messages). >> >> > >Yes -- The current draft tries to make clear (but fails to) that a new, >PLPMTUD-style MTU discovery mechanism is acceptable. There are API problems >with such a scheme, but we absolutely allow it. > >If you can accept an extra RTT or two at connection initiation time, I >think you can do pretty well: > > Request --> > <-- Response > then, all in 1 RTT: > Padded Sync(512 bytes) --> /* actual #s would need to fit CC > Padded Sync(1280 bytes) --> mechanism */ > Padded Sync(4000 bytes) --> > <-- SyncReply(1) /* SyncReplies sent only for those > <-- SyncReply(2) packets that got through */ > <-- SyncReply(3) > > > >>So, my question for the DCCP people, is it worth changing DCCP PMTUD? >> >> > >It's certainly worth describing it better, and perhaps mentioning a set of >acceptable procedures. Have you any suggestions for useful procedures >here? > >Eddie > > From owner-v6ops@ops.ietf.org Wed Nov 19 13:34:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01862 for ; Wed, 19 Nov 2003 13:34:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMX6E-0002vI-M1 for v6ops-data@psg.com; Wed, 19 Nov 2003 18:30:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMX60-0002uT-Dp for v6ops@ops.ietf.org; Wed, 19 Nov 2003 18:30:32 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJITfb19176; Wed, 19 Nov 2003 20:29:41 +0200 Date: Wed, 19 Nov 2003 20:29:41 +0200 (EET) From: Pekka Savola To: Eddie Kohler cc: "Phelan, Tom" , Fred Templin , , , , Subject: Re: [dccp] PMTU issues In-Reply-To: <200311191421.hAJELXIe072495@coyote.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Everyone, Please discontinue this discussion at v6ops@ops.ietf.org list. Thanks, Pekka writing as v6-ops co-chair On Wed, 19 Nov 2003, Eddie Kohler wrote: > > It's also possible for DCCP to get a better initial estimate of the PMTU, > > and apparently there are other problems with the current DCCP PMTUD > > mechanism (using ICMP "can't fragment" messages). > > Yes -- The current draft tries to make clear (but fails to) that a new, > PLPMTUD-style MTU discovery mechanism is acceptable. There are API problems > with such a scheme, but we absolutely allow it. > > If you can accept an extra RTT or two at connection initiation time, I > think you can do pretty well: > > Request --> > <-- Response > then, all in 1 RTT: > Padded Sync(512 bytes) --> /* actual #s would need to fit CC > Padded Sync(1280 bytes) --> mechanism */ > Padded Sync(4000 bytes) --> > <-- SyncReply(1) /* SyncReplies sent only for those > <-- SyncReply(2) packets that got through */ > <-- SyncReply(3) > > > So, my question for the DCCP people, is it worth changing DCCP PMTUD? > > It's certainly worth describing it better, and perhaps mentioning a set of > acceptable procedures. Have you any suggestions for useful procedures > here? > > Eddie > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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 Nov 19 13:44:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02697 for ; Wed, 19 Nov 2003 13:44:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMXGs-0003m6-1j for v6ops-data@psg.com; Wed, 19 Nov 2003 18:41:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMXGf-0003lR-Cu for v6ops@ops.ietf.org; Wed, 19 Nov 2003 18:41:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJIfRX19471; Wed, 19 Nov 2003 20:41:27 +0200 Date: Wed, 19 Nov 2003 20:41:26 +0200 (EET) From: Pekka Savola To: Fred Templin cc: "Karim El-Malki (HF/EAB)" , Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] In-Reply-To: <3FBBADCA.1060001@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 19 Nov 2003, Fred Templin wrote: > I don't agree that the items you are citing as "not in draft-16" > actually need to be specified there. If you want to say ISATAP does (foo), it has to be specified to do (foo). If it isn't specified, it ain't there.. > Also, as to your assertion that ISATAP is a "moving target", > the best way to address that would be to either publish it as > an RFC now or make it as a v6ops wg item. I prefer the > former; we have seen recently how easily RFCs can be > (bis)'d so there is no reason to believe that publishing now > would amount to casting things in stone. I have an entirely different opinion (about publishing as RFC). There is little use documenting a snapshot of a "moving target". That'd clearly show that the moving target has not been specified well enough, had its applicability considered at enough length, etc. -- because otherwise it would not be moving any more. On the other hand, when a mechanism does not change substantially any more, it's either because (1) people lost interest, or (2) the mechanism is clear enough (from every angle) that there is no more NEED to substantially refine it further. When there are still substantial issues to be ironed out, about the only way to generate a revision of the spec would be creating a non-interoperable new version using a new suffix. I'm not sure if that'd be warranted 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 Wed Nov 19 14:01:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03712 for ; Wed, 19 Nov 2003 14:01:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMXX6-00059A-NI for v6ops-data@psg.com; Wed, 19 Nov 2003 18:58:32 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMXWk-00058O-Tk for v6ops@ops.ietf.org; Wed, 19 Nov 2003 18:58:10 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJIvxi21870; Wed, 19 Nov 2003 10:57:59 -0800 X-mProtect: <200311191857> 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 smtpdMgdpTb; Wed, 19 Nov 2003 10:57:58 PST Message-ID: <3FBBBEF2.1020304@iprg.nokia.com> Date: Wed, 19 Nov 2003 11:05:22 -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: "Karim El-Malki (HF/EAB)" , v6ops@ops.ietf.org Subject: Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Wed, 19 Nov 2003, Fred Templin wrote: > > >>I don't agree that the items you are citing as "not in draft-16" >>actually need to be specified there. >> >> > >If you want to say ISATAP does (foo), it has to be specified to do >(foo). If it isn't specified, it ain't there.. > That's not what I'm saying; ISATAP is an IPv6-over-(foo) document whose sole purpose is to specify the operation of IPv6 neighbor discovery over a particular link type. As such, it doesn't have any business specifying things that might be happening further up the stack. ISATAP is a substrate on top of which other mechanisms might be layered, but that does NOT mean specifications for those other mechanisms belong in the ISATAP spec. >>Also, as to your assertion that ISATAP is a "moving target", >>the best way to address that would be to either publish it as >>an RFC now or make it as a v6ops wg item. I prefer the >>former; we have seen recently how easily RFCs can be >>(bis)'d so there is no reason to believe that publishing now >>would amount to casting things in stone. >> >> > >I have an entirely different opinion (about publishing as RFC). >There is little use documenting a snapshot of a "moving target". >That'd clearly show that the moving target has not been specified well >enough, had its applicability considered at enough length, etc. -- >because otherwise it would not be moving any more. > Actually, I should have more strongly disagreed with your assertion; ISATAP is NOT a moving target. ISATAP is stabilized, and I have not received any input to the contrary. >On the other hand, when a mechanism does not change substantially any >more, it's either because (1) people lost interest, or (2) the >mechanism is clear enough (from every angle) that there is no more >NEED to substantially refine it further. > (2) above best describes the case for ISATAP as I understand it. >When there are still substantial issues to be ironed out, about the >only way to generate a revision of the spec would be creating a >non-interoperable new version using a new suffix. I'm not sure if >that'd be warranted either. > Not warranted in my view as there are not still substantial issues to be ironed out to my knowlege. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Nov 19 20:30:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28426 for ; Wed, 19 Nov 2003 20:30:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMda3-0001xd-EH for v6ops-data@psg.com; Thu, 20 Nov 2003 01:25:59 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMdZp-0001x1-Gj for v6ops@ops.ietf.org; Thu, 20 Nov 2003 01:25:45 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAK1Pfm03267; Wed, 19 Nov 2003 17:25:41 -0800 X-mProtect: <200311200125> 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 smtpd45VBZc; Wed, 19 Nov 2003 17:25:40 PST Message-ID: <3FBC19D1.1070807@iprg.nokia.com> Date: Wed, 19 Nov 2003 17:33:05 -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: Fred Templin , v6ops@ops.ietf.org Subject: Re: transmech MTU comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, I would like to discuss some aspects of the current text in [MECH], section 3: >3.2.1. Static Tunnel MTU > > A node using a static tunnel MTU MUST limit the size of the IPv6 > packets it tunnels to 1280 bytes i.e., treat the tunnel interface as > having a fixed interface MTU of 1280 bytes. An implementation MAY > have a configuration knob which can be used to set a larger value of > the tunnel MTU than 1280 bytes, but if so the default MUST be 1280 > bytes. A larger fixed MTU should not be configured unless it has > been administratively ensured that the decapsulator can reassemble > packets of that size. Care should be taken when manually configuring > large tunnel MTUs to only do so when the MTU of the IPv4 path to the > tunnel endpoint is large to avoid causing excessive fragmentation. > > When using the static tunnel MTU the Don't Fragment bit MUST NOT be > set in the encapsulating IPv4 header. As a result the encapsulator > should not receive any ICMPv4 "packet too big" message as a result of > the packets it has encapsulated. > The latter paragraph implies that either all links on the path will be at least as large as the static MTU, or that nodes with constricting links will use IPv4 fragmentation to split the packet into pieces small enough to traverse the constricting link. The former case will not be true in general, because certain bandwidth constrained links will choose smaller-than-1280-byte MTUs for their IPv4 interfaces if BCP 48, 50, and 71 recommendations are followed. Also, we cannot be assured that all forwarding nodes will correctly implement IPv4 fragmentation. So, we have a very real possibility for black holes here. >3.2.2. Dynamic Tunnel MTU > > The dynamic MTU determination is OPTIONAL. However, if it is > implemented, it SHOULD have the behavior described in this document. > > The fragmentation inside the tunnel can be reduced to a minimum by > having the encapsulator track the IPv4 Path MTU across the tunnel, > using the IPv4 Path MTU Discovery Protocol [RFC1191] and recording > the resulting path MTU. The IPv6 layer in the encapsulator can then > view a tunnel as a link layer with an MTU equal to the IPv4 path MTU, > minus the size of the encapsulating IPv4 header. > > Note that this does not eliminate IPv4 fragmentation in the case when > the IPv4 path MTU would result in an IPv6 MTU less than 1280 bytes. > (Any link layer used by IPv6 has to have an MTU of at least 1280 > bytes [RFC2460].) In this case the IPv6 layer has to "see" a link > layer with an MTU of 1280 bytes and the encapsulator has to use IPv4 > fragmentation in order to forward the 1280 byte IPv6 packets. > But, shouldn't the encapsulator send a "packet too big" to the source in this case even if the MTU it reports is less than 1280 bytes? In response, the source should then include a fragment header in the packets it sends as a signal to the encapsulator that IPv4 fragmentation is permissible (see RFC 2460, section 5). More discussion on this below: > The encapsulator SHOULD employ the following algorithm to determine > when to forward an IPv6 packet that is larger than the tunnel's path > MTU using IPv4 fragmentation, and when to return an IPv6 ICMP "packet > too big" message per [RFC1981]: > > if (IPv4 path MTU - 20) is less than 1280 > if packet is larger than 1280 bytes > Send IPv6 ICMP "packet too big" with MTU = 1280. > Drop packet. > else > Encapsulate but do not set the Don't Fragment > flag in the IPv4 header. The resulting IPv4 > packet might be fragmented by the IPv4 layer on > the encapsulator or by some router along > the IPv4 path. > endif > I believe the above "else" case should be re-worded as follows: else if packet does not contain a fragment header Send IPv6 ICMP "packet too big" with MTU = (IPv4 path MTU - 20). Drop packet. else Encapsulate and fragment the packet using IPv4 fragmentation with a maximum fragment size of (IPv4 path MTU - 20). The lower 16 bits of the Identification field in the fragment header is used as the Identification field for each IPv4 fragment header, and the Don't Fragment field is not set. endif endif First, about sending the "packet too big" with an MTU size less than 1280, this seems to me to be consistent with the expectation specified in RFC 2460, section 5. This is what an "IPv6-to-IPv4 translator" is supposed to do, and from the perspective of the original IPv6 host it makes no difference whether the node that sends the packet too big is a translator or an IPv6-in-IPv4 tunnel endpoint. As to fragmenting the packet in the enapsulator instead of just sending it with the DF bit not set, the encapsulator has no way of knowing whether there are forwarding nodes in the IPv4 path with broken, non-existent, or slow-path IPv4 fragmentation implementations and so the only safe option is for the tunnel encapsulator itself to do the fragmentation. As to the setting of the fragment ID field, my suggested text above reflects my best understanding of the normative ref's, but I believe we have the following problem. What if the original IPv6 source wanted to do host-based IPv6 fragmentation (e.g., for large UDP packets) even though the IPv6 path MTU was less than 1280 bytes? The source would send a series of N IPv6 fragments, each of which would have the same value in the fragment ID field. But then, the tunnel encapsulator would use IPv4 fragmentation to split each of the N IPv6 fragments into M IPv4 fragments again using the *same* fragment ID value! We would then have a collision in the decapsulator's IPv4 reassembly buffer, since there would be no way of knowing to which one of the N IPv6 fragments a particular IPv4 fragment belonged! So, either my understanding of the normative references is wrong, or the normative references themselves are wrong. Can you help? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Nov 20 02:50:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21575 for ; Thu, 20 Nov 2003 02:50:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMjU0-000H3C-KE for v6ops-data@psg.com; Thu, 20 Nov 2003 07:44:08 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMjTn-000H2c-El for v6ops@ops.ietf.org; Thu, 20 Nov 2003 07:43:55 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 6878F4338A0; Thu, 20 Nov 2003 02:43:49 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 3D2F2800BE; Thu, 20 Nov 2003 02:43:49 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Thu, 20 Nov 2003 13:13:49 +0530 X-Sasl-Enc: A0alRSLWDngpnataJcEEbQ 1069314229 Cc: "Fred Templin" , "Fred Templin" , "Erik Nordmark" Subject: Re: transmech MTU comments References: ARRAY(0xa1a1644) In-Reply-To: ARRAY(0xa1a1680) Message-Id: <20031120074349.3D2F2800BE@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 19 Nov 2003 17:33:05 -0800, "Fred Templin" said: > As to the setting of the fragment ID field, my suggested text above > reflects my best understanding of the normative ref's, but I believe we > have the following problem. What if the original IPv6 source wanted to > do host-based IPv6 fragmentation (e.g., for large UDP packets) even > though the IPv6 path MTU was less than 1280 bytes? > > The source would send a series of N IPv6 fragments, each of which would > have the same value in the fragment ID field. But then, the tunnel > encapsulator would use IPv4 fragmentation to split each of the N IPv6 > fragments into M IPv4 fragments again using the *same* fragment ID > value! We would then have a collision in the decapsulator's See the text below from 2460. The word used is "suitable", and not "same". In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. > IPv4 reassembly buffer, since there would be no way of knowing to which > one of the N IPv6 fragments a particular IPv4 fragment belonged! From owner-v6ops@ops.ietf.org Thu Nov 20 02:54:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21820 for ; Thu, 20 Nov 2003 02:54:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMjbM-000HXe-FB for v6ops-data@psg.com; Thu, 20 Nov 2003 07:51:44 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMjb1-000HVg-9Z for v6ops@ops.ietf.org; Thu, 20 Nov 2003 07:51:23 +0000 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 85CD6436C1A; Thu, 20 Nov 2003 02:51:22 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 6438175EE6; Thu, 20 Nov 2003 02:51:22 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Thu, 20 Nov 2003 13:21:22 +0530 X-Sasl-Enc: Oe11EV2zQvg91vtUSK0oZQ 1069314682 Cc: "Fred Templin" , "Fred Templin" , "Erik Nordmark" Subject: Re: transmech MTU comments Message-Id: <20031120075122.6438175EE6@server2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 19 Nov 2003 17:33:05 -0800, "Fred Templin" said: > As to the setting of the fragment ID field, my suggested text above > reflects my best understanding of the normative ref's, but I believe we > have the following problem. What if the original IPv6 source wanted to > do host-based IPv6 fragmentation (e.g., for large UDP packets) even > though the IPv6 path MTU was less than 1280 bytes? > > The source would send a series of N IPv6 fragments, each of which would > have the same value in the fragment ID field. But then, the tunnel > encapsulator would use IPv4 fragmentation to split each of the N IPv6 > fragments into M IPv4 fragments again using the *same* fragment ID > value! We would then have a collision in the decapsulator's See the text below from 2460. The word used is "suitable", and not "same". In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. Also from mech-v2-01. Identification: Generated uniquely as for any IPv4 packet transmitted by the system. Is there any other doc that specifies "same"? I believe it is an error if it does. CP > IPv4 reassembly buffer, since there would be no way of knowing to which > one of the N IPv6 fragments a particular IPv4 fragment belonged! From owner-v6ops@ops.ietf.org Thu Nov 20 07:57:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02501 for ; Thu, 20 Nov 2003 07:57:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMoJD-0006Ww-Dp for v6ops-data@psg.com; Thu, 20 Nov 2003 12:53:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMoJ0-0006Vt-6h for v6ops@ops.ietf.org; Thu, 20 Nov 2003 12:53:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAKCqx804105; Thu, 20 Nov 2003 14:52:59 +0200 Date: Thu, 20 Nov 2003 14:52:59 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: ISATAP spec stability [Re: ISATAP and admin/IP domains] In-Reply-To: <3FBBBEF2.1020304@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Whether or not ISATAP is stable or not is beside the original point, so I don't think I'll continue this thread.. On Wed, 19 Nov 2003, Fred Templin wrote: > That's not what I'm saying; ISATAP is an IPv6-over-(foo) document > whose sole purpose is to specify the operation of IPv6 neighbor > discovery over a particular link type. Right.. > As such, it doesn't have any > business specifying things that might be happening further up the > stack. ISATAP is a substrate on top of which other mechanisms > might be layered, but that does NOT mean specifications for > those other mechanisms belong in the ISATAP spec. That's fine, just don't describe that as ISATAP behaviour then (as you did, in the original thread, a few messages back). > Actually, I should have more strongly disagreed with your assertion; > ISATAP is NOT a moving target. ISATAP is stabilized, and I have > not received any input to the contrary. I have to disagree here. Let's have a look at when different versions of the ISATAP spec were published: draft-templin-ngtrans-v6v4compat-00.txt: Mar 2000 draft-templin-ngtrans-v6v4compat-01.txt: Sep 2000 draft-ietf-ngtrans-isatap-00.txt: Mar 2001 draft-ietf-ngtrans-isatap-01.txt: May 2001 draft-ietf-ngtrans-isatap-02.txt: Nov 2001 draft-ietf-ngtrans-isatap-03.txt: Jan 2002 draft-ietf-ngtrans-isatap-04.txt: Apr 2002 draft-ietf-ngtrans-isatap-05.txt: Oct 2002 draft-ietf-ngtrans-isatap-06.txt: Oct 2002 draft-ietf-ngtrans-isatap-07.txt: Dec 2002 draft-ietf-ngtrans-isatap-08.txt: Dec 2002 draft-ietf-ngtrans-isatap-09.txt: Dec 2002 draft-ietf-ngtrans-isatap-10.txt: Jan 2003 draft-ietf-ngtrans-isatap-11.txt: Jan 2003 draft-ietf-ngtrans-isatap-12.txt: Jan 2003 draft-ietf-ngtrans-isatap-13.txt: Mar 2003 draft-ietf-ngtrans-isatap-14.txt: Aug 2003 draft-ietf-ngtrans-isatap-15.txt: Sep 2003 draft-ietf-ngtrans-isatap-16.txt: Oct 2003 .. seems to have been very much of a moving target to me :-). Of course, you'd argue that it *has* been a moving target, but now is frozen. Looking at the spec (there are a large number of things to fix) and its past change history does not convince me. (But of course, this is a fundamental problem caused by the fact that there is no clear goal for ISATAP, no clear objective; it has tried to be "little everything for everybody"; when new uses for it have come up, it has been modified to fit. If there was a clear goal where to apply ISATAP and which direction to develop it, I guess the need for fundamental changes would have gone down a long time ago.) > >On the other hand, when a mechanism does not change substantially any > >more, it's either because (1) people lost interest, or (2) the > >mechanism is clear enough (from every angle) that there is no more > >NEED to substantially refine it further. > > (2) above best describes the case for ISATAP as I understand it. I don't agree. -- 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 Nov 20 09:37:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06272 for ; Thu, 20 Nov 2003 09:37:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMps9-000Bgq-VG for v6ops-data@psg.com; Thu, 20 Nov 2003 14:33:29 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMpry-000BgR-1n for v6ops@ops.ietf.org; Thu, 20 Nov 2003 14:33:18 +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 hAKEX2xA017322; Thu, 20 Nov 2003 06:33:03 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAKEX0Q12870; Thu, 20 Nov 2003 15:33:00 +0100 (MET) Date: Thu, 20 Nov 2003 06:31:44 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: transmech MTU comments To: Fred Templin Cc: Erik Nordmark , Fred Templin , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3FBC19D1.1070807@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The latter paragraph implies that either all links on the path will > be at least as large as the static MTU, or that nodes with constricting > links will use IPv4 fragmentation to split the packet into pieces small > enough to traverse the constricting link. The former case will not be > true in general, because certain bandwidth constrained links will choose > smaller-than-1280-byte MTUs for their IPv4 interfaces if BCP 48, 50, > and 71 recommendations are followed. Agreed that there might be IPv4 fragmentation in this case. > Also, we cannot be assured that > all forwarding nodes will correctly implement IPv4 fragmentation. > So, we have a very real possibility for black holes here. Huh? If we can't assume that IPv4 fragmentation works we might as well assume that IP routing doesn't work and we should be using the postal service to have this discussion instead of email. > But, shouldn't the encapsulator send a "packet too big" to the source > in this case even if the MTU it reports is less than 1280 bytes? In > response, > the source should then include a fragment header in the packets it sends > as a signal to the encapsulator that IPv4 fragmentation is permissible > (see RFC 2460, section 5). More discussion on this below: IPv4 fragmentation is always permissible. The text you are referring to in RFC 2460 is to enable SIIT (and NAT-PT?) to operate over IPv4 paths with a path MTU less than 1280 bytes without having to make up IPv4 fragment IDs on the fly. RFC 2460 says "undergoes translation" as the motivation. Thus this has nothing to do with encapsulation. Erik From owner-v6ops@ops.ietf.org Thu Nov 20 09:58:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07082 for ; Thu, 20 Nov 2003 09:58:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMqCu-000Cs5-Iz for v6ops-data@psg.com; Thu, 20 Nov 2003 14:54:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMqCf-000Cr0-N2 for v6ops@ops.ietf.org; Thu, 20 Nov 2003 14:54:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAKEsew06267 for ; Thu, 20 Nov 2003 16:54:40 +0200 Date: Thu, 20 Nov 2003 16:54:40 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: [dnsop] thoughts about dnsop-ipv6-dns-issues document (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, As concerns were raised whether DNS operational issues have been considered well enough, and some generic work would be needed, the following what I proposed as a tentative outline for the document. Any omissions? Thoughts? Comments? ---------- Forwarded message ---------- Date: Thu, 20 Nov 2003 13:00:26 +0200 (EET) From: Pekka Savola To: dnsop@cafax.se Subject: [dnsop] thoughts about dnsop-ipv6-dns-issues document Hi, I had some conversation with Rob and Alain on how I felt draft-ietf-dnsop-ipv6-dns-issues-xx document (or something else) should be updated. I've included a possible ToC below (note that it has been updated based on Rob's comments below). I'd think that the document could, in many cases, just summarize and point to issues described in other documents, but might be useful as a place to bring together the issues and considerations that should be considered by DNS folks. Feedback, ideas, etc. welcome! NEW === Operational Considerations and Issues with IPv6 DNS 1. Introduction 1.1. Representing IPv6 addresses in DNS records 1.2. Difference of IPv6 DNS Transport and DNS Records 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation 1.4. 3. DNS Considerations about Special IPv6 Addresses 3.1. Limited-scope addresses 3.2. Privacy (RFC3041) addresses 3.3. 6to4 addresses * other transmech's (e.g. teredo, isatap) don't require special considerations 4. Observed DNS Implementation Misbehaviour 4.1. Misbehaviour of DNS servers and load-balancers 4.1.1. Against AAAA * (just summary and a pointer) 4.2. Misbehaviour of DNS resolvers 5. Recommendations for Service Provisioning using DNS 5.1. Use of Service Names instead of Node Names 5.2. Adding the Records only when Fully IPv6-enabled 5.2.1. Consequences of Poor IPv6 Performance 5.3. IPv6 Transport Guidelines for DNS servers * (just summary and a pointer) 6. Recommendations for DNS Resolver IPv6 Support 6.1. DNS Lookups May Query IPv6 Records Prematurely 6.1.1. Increased Latency 6.1.2. Address Selection with Multiple Addresses 6.2. Recursive DNS Server Discovery 6.3. IPv6 Transport Guidelines for Resolvers * (just summary and a pointer) 7. Considerations about Forward DNS Updating 7.1. Manual or Custom DNS updates 7.2. DDNS with Stateless Address Autoconfiguration 7.3. DDNS with DHCP 7.4. DDNS with Dynamic Prefix Delegation 8. Considerations about Reverse DNS Updating 8.1. Applicability of Reverse DNS 8.2. Manual or Custom DNS updates 8.2.1. Reverse DNS with Wildcard Records 8.3. DDNS with Stateless Address Autoconfiguration 8.4. DDNS with DHCP 8.5. DDNS with Dynamic Prefix Delegation 9. Miscellaneous DNS Considerations 9.1. NAT-PT with DNS-ALG 9.2. Renumbering Procedures 9.2.1. Applications Using Addresses Beyond Their TTL Appendix A: Site-local Addressing considerations for DNS OLD === IPv6 DNS transition issues 1. Representing IPv6 addresses in DNS records 2. IPv4/IPv6 name space 2.1 Terminology 2.2. Introduction to the problem of name space fragmentation: 2.3 Policy based avoidance of name space fragmentation. 3. Local Scope addresses. 3.1 Link local addresses 3.2 Site local addresses 3.3 Reverse path DNS for site local addresses. 4. Automatic population of the Reverse path DNS 5. Privacy extension addresses 6. 6to4 7. Recursive DNS server discovery 8. DNSsec On Wed, 19 Nov 2003, Rob Austein wrote: > a) you should include my co-chair in this discussion. you might even > want to ask the wg, this being a wg project :) Ok, will send. > b) current doc duplicates some text in the transport guidelines doc > (more precisely: transport guidelines started out as a separate > doc, which was merged into this one, then extracted from this one, > but the merged text is still present, so the merged text needs to > be removed). > > am not sure to what extent the doc you're proposing would need to > talk about the transport guidelines stuff given the existance of > the separate doc. summary and pointer, perhaps. I was thinking of summary and pointer. > c) 6to4 addresss => ipv6 addresses containing embedded ipv4 stuff ? > ie, not just 6to4, also terado. subsections on each ok. others? > given that terado has already shipped, we probably can't ignore it, > this is operations, we deal with what's there, not with what we > wish were there. 6to4 is a special case because it embeds the network. Just embedding the host address might also be fine, but ISATAP is the only thing that does that, and it's not interesting from this point of view. Teredo identifies host *and* a UDP port. So teredo is not useful for this context. > d) section (5) seems to beg for a corresponding section about > misbehaving resolvers viewed from the name server side. this > overlaps with existing work (the larson/barber doc). some > question of the degree to which either of these is really ipv6 > specific, see ongoing mailing list discussion. yep, but as these seem to bite you really hard with v6, I think they deserve to be mentioned explicitly. > might end up as another case of a seperate document (or documents) > with summary and pointer in this document. yep. > e) having some serious thought about dynamic update is very good. > don't want to tie it too closely to the reverse tree population > thing, since that's basicly an implementation botch in existing > software (an annoying one, to be sure, but we already know what the > long term fix is -- update all the whacky software that breaks when > there's no reverse tree -- no matter what else is going on, > breaking when the reverse tree isn't present is just plain wrong, > no matter how many os vendors have been shipping code that does > that for how many years). Agreed, I was first thinking of separating forward/reverse updates, but there would probably have been overlap. Maybe it would make sense because the problem spaces may be vastly different.. > so anyway: am not sure whether this outline covers the update > space, but am very glad to see a start at it. update in the > presence of dhcp address assignment is pretty much a no brainer. yep > update in the case of stateless addrconf is hard because it's very > unclear who "owns" the addresses -- one can locate the name server > that owns the dns subtree corresponding to the prefix, but the > trust model between that server and the entity that's using an > address is very shakey. the send wg's work might help here. yep . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-v6ops@ops.ietf.org Thu Nov 20 11:09:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11005 for ; Thu, 20 Nov 2003 11:09:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMrJc-000HJs-OU for v6ops-data@psg.com; Thu, 20 Nov 2003 16:05:56 +0000 Received: from [66.218.79.75] (helo=web80505.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AMrJI-000HHw-BJ for v6ops@ops.ietf.org; Thu, 20 Nov 2003 16:05:36 +0000 Message-ID: <20031120160536.79104.qmail@web80505.mail.yahoo.com> Received: from [63.197.18.101] by web80505.mail.yahoo.com via HTTP; Thu, 20 Nov 2003 08:05:36 PST Date: Thu, 20 Nov 2003 08:05:36 -0800 (PST) From: Fred Templin Subject: Re: transmech MTU comments To: Erik Nordmark Cc: Fred Templin , ftemplin@iprg.nokia.com, v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2014412792-1069344336=:78234" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-2014412792-1069344336=:78234 Content-Type: text/plain; charset=us-ascii Erik, I appreciate the humor, but this is a critical design point that needs to be resolved: Should we have as a goal the ability to support L2 bridges, switches, hubs, etc. that join media with dissimilar MTUs, but do not support IPv4 fragmentation and do not send "packet too big" ICMPs? We answered "NO" to this 15 years ago when we allowed the approach now specified in RFC 1191 to go forward, and that decision took a viable design alternative off the table which had a profound effect on the shaping of the industry. We're not going to fix this overnight by anything we do here, but allowing for generality (i.e., not expecting any IPv4 fragmentation support along the forwarding path) would be an important step toward restoring a level playing field. Let's not blow it again, given new opportunities to get things right. Fred Templin osprey67@yahoo.com Erik Nordmark wrote: > Also, we cannot be assured that > all forwarding nodes will correctly implement IPv4 fragmentation. > So, we have a very real possibility for black holes here. Huh? If we can't assume that IPv4 fragmentation works we might as well assume that IP routing doesn't work and we should be using the postal service to have this discussion instead of email. --0-2014412792-1069344336=:78234 Content-Type: text/html; charset=us-ascii
Erik,
 
I appreciate the humor, but this is a critical design point that needs
to be resolved:
 
Should we have as a goal the ability to support L2 bridges, switches,
hubs, etc. that join media with dissimilar MTUs, but do not support
IPv4 fragmentation and do not send "packet too big" ICMPs?
 
We answered "NO" to this 15 years ago when we allowed the
approach now specified in RFC 1191 to go forward, and that
decision took a viable design alternative off the table which had
a profound effect on the shaping of the industry.
 
We're not going to fix this overnight by anything we do here, but
allowing for generality (i.e., not expecting any IPv4 fragmentation
support along the forwarding path) would be an important step
toward restoring a level playing field. Let's not blow it again,
given new opportunities to get things right.
 
Fred Templin
osprey67@yahoo.com   

Erik Nordmark <Erik.Nordmark@sun.com> wrote:
> Also, we cannot be assured that
> all forwarding nodes will correctly implement IPv4 fragmentation.
> So, we have a very real possibility for black holes here.

Huh? If we can't assume that IPv4 fragmentation works we might as well
assume that IP routing doesn't work and we should be using the postal
service to have this discussion instead of email.
--0-2014412792-1069344336=:78234-- From owner-v6ops@ops.ietf.org Thu Nov 20 12:11:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13869 for ; Thu, 20 Nov 2003 12:11:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMsHF-000LHx-P5 for v6ops-data@psg.com; Thu, 20 Nov 2003 17:07:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMsGy-000LGm-6y for v6ops@ops.ietf.org; Thu, 20 Nov 2003 17:07:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAKH6wR09082; Thu, 20 Nov 2003 19:06:59 +0200 Date: Thu, 20 Nov 2003 19:06:58 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Erik Nordmark , , Subject: Re: transmech MTU comments In-Reply-To: <20031120160536.79104.qmail@web80505.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, 20 Nov 2003, Fred Templin wrote: > Should we have as a goal the ability to support L2 bridges, switches, > hubs, etc. that join media with dissimilar MTUs, but do not support > IPv4 fragmentation and do not send "packet too big" ICMPs? > > We answered "NO" to this 15 years ago when we allowed the > approach now specified in RFC 1191 to go forward, and that > decision took a viable design alternative off the table which had > a profound effect on the shaping of the industry. > > We're not going to fix this overnight by anything we do here, but > allowing for generality (i.e., not expecting any IPv4 fragmentation > support along the forwarding path) would be an important step > toward restoring a level playing field. Let's not blow it again, > given new opportunities to get things right. Fred, I appreciate your concern about creating a robust and optimal Path MTU Discovery mechanism, but IMHO this document -- which we're moving towards DS -- just simply doesn't seem to be the right time and place to do so. There is little we can do to fix IPv4 at this point; IPv6 already doesn't include fragmentation support along the path, and might be enhanceable, in future, to support new methods. We'll need to live with what we have. -- 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 Nov 20 12:32:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14791 for ; Thu, 20 Nov 2003 12:32:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMscr-000MbL-Ru for v6ops-data@psg.com; Thu, 20 Nov 2003 17:29:53 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMsce-000Ma9-K9 for v6ops@ops.ietf.org; Thu, 20 Nov 2003 17:29:40 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKHTWr11966; Thu, 20 Nov 2003 09:29:32 -0800 X-mProtect: <200311201729> 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 smtpdAmSUwV; Thu, 20 Nov 2003 09:29:31 PST Message-ID: <3FBCFBBC.6090001@iprg.nokia.com> Date: Thu, 20 Nov 2003 09:37:00 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: ISATAP spec stability [Re: ISATAP and admin/IP domains] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, You can pull a similar sort of revision history for any number of documents that are now RFCs or soon will be. Your message is what once would have been referred to as "yellow journalism" and not befitting a dedicated technologist such as yourself. Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >Whether or not ISATAP is stable or not is beside the original point, >so I don't think I'll continue this thread.. > >On Wed, 19 Nov 2003, Fred Templin wrote: > > >>That's not what I'm saying; ISATAP is an IPv6-over-(foo) document >>whose sole purpose is to specify the operation of IPv6 neighbor >>discovery over a particular link type. >> >> > >Right.. > > > >>As such, it doesn't have any >>business specifying things that might be happening further up the >>stack. ISATAP is a substrate on top of which other mechanisms >>might be layered, but that does NOT mean specifications for >>those other mechanisms belong in the ISATAP spec. >> >> > >That's fine, just don't describe that as ISATAP behaviour then (as >you did, in the original thread, a few messages back). > > > >>Actually, I should have more strongly disagreed with your assertion; >>ISATAP is NOT a moving target. ISATAP is stabilized, and I have >>not received any input to the contrary. >> >> > >I have to disagree here. > >Let's have a look at when different versions of the ISATAP spec were >published: > >draft-templin-ngtrans-v6v4compat-00.txt: Mar 2000 >draft-templin-ngtrans-v6v4compat-01.txt: Sep 2000 >draft-ietf-ngtrans-isatap-00.txt: Mar 2001 >draft-ietf-ngtrans-isatap-01.txt: May 2001 >draft-ietf-ngtrans-isatap-02.txt: Nov 2001 >draft-ietf-ngtrans-isatap-03.txt: Jan 2002 >draft-ietf-ngtrans-isatap-04.txt: Apr 2002 > > > >draft-ietf-ngtrans-isatap-05.txt: Oct 2002 >draft-ietf-ngtrans-isatap-06.txt: Oct 2002 >draft-ietf-ngtrans-isatap-07.txt: Dec 2002 >draft-ietf-ngtrans-isatap-08.txt: Dec 2002 >draft-ietf-ngtrans-isatap-09.txt: Dec 2002 >draft-ietf-ngtrans-isatap-10.txt: Jan 2003 >draft-ietf-ngtrans-isatap-11.txt: Jan 2003 >draft-ietf-ngtrans-isatap-12.txt: Jan 2003 >draft-ietf-ngtrans-isatap-13.txt: Mar 2003 >draft-ietf-ngtrans-isatap-14.txt: Aug 2003 >draft-ietf-ngtrans-isatap-15.txt: Sep 2003 >draft-ietf-ngtrans-isatap-16.txt: Oct 2003 > >.. seems to have been very much of a moving target to me :-). Of >course, you'd argue that it *has* been a moving target, but now is >frozen. Looking at the spec (there are a large number of things to >fix) and its past change history does not convince me. > >(But of course, this is a fundamental problem caused by the fact that >there is no clear goal for ISATAP, no clear objective; it has tried to >be "little everything for everybody"; when new uses for it have come >up, it has been modified to fit. If there was a clear goal where to >apply ISATAP and which direction to develop it, I guess the need for >fundamental changes would have gone down a long time ago.) > > > >>>On the other hand, when a mechanism does not change substantially any >>>more, it's either because (1) people lost interest, or (2) the >>>mechanism is clear enough (from every angle) that there is no more >>>NEED to substantially refine it further. >>> >>> >>(2) above best describes the case for ISATAP as I understand it. >> >> > >I don't agree. > > > From owner-v6ops@ops.ietf.org Thu Nov 20 12:41:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15082 for ; Thu, 20 Nov 2003 12:41:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMslR-000NC2-Ov for v6ops-data@psg.com; Thu, 20 Nov 2003 17:38:45 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMsl8-000NAT-4B for v6ops@ops.ietf.org; Thu, 20 Nov 2003 17:38:26 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 61-md50000000109.tmp for ; Thu, 20 Nov 2003 18:39:24 +0100 Message-ID: <079501c3af8d$2f562490$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <3FBCFBBC.6090001@iprg.nokia.com> Subject: Re: ISATAP spec stability [Re: ISATAP and admin/IP domains] Date: Thu, 20 Nov 2003 18:38:59 +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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 20 Nov 2003 18:39:24 +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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, Sorry to say this, but I completely agree with Fred. Do you want a few = examples ? I think is not fair this type of messages from a chair. You should be = very neutral (unless you clearly state "hat off"). Regards, Jordi ----- Original Message -----=20 From: "Fred Templin" To: "Pekka Savola" Cc: Sent: Thursday, November 20, 2003 6:37 PM Subject: Re: ISATAP spec stability [Re: ISATAP and admin/IP domains] > Pekka, >=20 > You can pull a similar sort of revision history for any number > of documents that are now RFCs or soon will be. Your message > is what once would have been referred to as "yellow journalism" > and not befitting a dedicated technologist such as yourself. >=20 > Fred > ftemplin@iprg.nokia.com >=20 > Pekka Savola wrote: >=20 > >Whether or not ISATAP is stable or not is beside the original point, > >so I don't think I'll continue this thread.. > > > >On Wed, 19 Nov 2003, Fred Templin wrote: > > > > > >>That's not what I'm saying; ISATAP is an IPv6-over-(foo) document > >>whose sole purpose is to specify the operation of IPv6 neighbor > >>discovery over a particular link type. > >> > >> > > > >Right.. > > > > > > > >>As such, it doesn't have any > >>business specifying things that might be happening further up the > >>stack. ISATAP is a substrate on top of which other mechanisms > >>might be layered, but that does NOT mean specifications for > >>those other mechanisms belong in the ISATAP spec. > >> > >> > > > >That's fine, just don't describe that as ISATAP behaviour then (as > >you did, in the original thread, a few messages back). > > > > > > > >>Actually, I should have more strongly disagreed with your = assertion; > >>ISATAP is NOT a moving target. ISATAP is stabilized, and I have > >>not received any input to the contrary. > >> > >> > > > >I have to disagree here. > > > >Let's have a look at when different versions of the ISATAP spec were > >published: > > > >draft-templin-ngtrans-v6v4compat-00.txt: Mar 2000 > >draft-templin-ngtrans-v6v4compat-01.txt: Sep 2000 > >draft-ietf-ngtrans-isatap-00.txt: Mar 2001 > >draft-ietf-ngtrans-isatap-01.txt: May 2001 > >draft-ietf-ngtrans-isatap-02.txt: Nov 2001 > >draft-ietf-ngtrans-isatap-03.txt: Jan 2002 > >draft-ietf-ngtrans-isatap-04.txt: Apr 2002 > > > > > > > >draft-ietf-ngtrans-isatap-05.txt: Oct 2002 > >draft-ietf-ngtrans-isatap-06.txt: Oct 2002 > >draft-ietf-ngtrans-isatap-07.txt: Dec 2002 > >draft-ietf-ngtrans-isatap-08.txt: Dec 2002 > >draft-ietf-ngtrans-isatap-09.txt: Dec 2002 > >draft-ietf-ngtrans-isatap-10.txt: Jan 2003 > >draft-ietf-ngtrans-isatap-11.txt: Jan 2003 > >draft-ietf-ngtrans-isatap-12.txt: Jan 2003 > >draft-ietf-ngtrans-isatap-13.txt: Mar 2003 > >draft-ietf-ngtrans-isatap-14.txt: Aug 2003 > >draft-ietf-ngtrans-isatap-15.txt: Sep 2003 > >draft-ietf-ngtrans-isatap-16.txt: Oct 2003 > > > >.. seems to have been very much of a moving target to me :-). Of > >course, you'd argue that it *has* been a moving target, but now is > >frozen. Looking at the spec (there are a large number of things to > >fix) and its past change history does not convince me. > > > >(But of course, this is a fundamental problem caused by the fact = that > >there is no clear goal for ISATAP, no clear objective; it has tried = to > >be "little everything for everybody"; when new uses for it have come > >up, it has been modified to fit. If there was a clear goal where to > >apply ISATAP and which direction to develop it, I guess the need for > >fundamental changes would have gone down a long time ago.) > > > > > > > >>>On the other hand, when a mechanism does not change substantially = any > >>>more, it's either because (1) people lost interest, or (2) the > >>>mechanism is clear enough (from every angle) that there is no more > >>>NEED to substantially refine it further. > >>> > >>> > >>(2) above best describes the case for ISATAP as I understand it. > >> > >> > > > >I don't agree. > > > > > > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Nov 20 13:34:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17675 for ; Thu, 20 Nov 2003 13:34:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMtZi-0000Fl-GP for v6ops-data@psg.com; Thu, 20 Nov 2003 18:30:42 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMtZU-0000Em-2p for v6ops@ops.ietf.org; Thu, 20 Nov 2003 18:30:28 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKIUIN14196; Thu, 20 Nov 2003 10:30:18 -0800 X-mProtect: <200311201830> 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 smtpdmaK7bO; Thu, 20 Nov 2003 10:30:17 PST Message-ID: <3FBD09FB.4020405@iprg.nokia.com> Date: Thu, 20 Nov 2003 10:37:47 -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 , Erik Nordmark , v6ops@ops.ietf.org Subject: Re: transmech MTU comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Your message was a cop-out, Pekka. Please address the question: Do we, or do we not want to allow for the possibility of future L2 bridges, switches, hubs etc. that connect media with dissimilar MTUs but that don't get involved with L3 functions like IPv4 fragmentation and sending "packet too big" ICMPs? Let's look at a real-world example of where our failure to support such L2 devices is currently hurting us. Look at the interface MTU for your 802.11 card under your favorite host OS (e.g., Microsoft, Linux, etc.) and you will see that it says 1500 Bytes. Next, go to the IEEE specs and you will see that 802.11 frames can support a body of 2312 bytes. So, why can't we set the MTU of our 802.11 interfaces to 2312 and take immediate advantage of the 35% gain in efficiency? Because there might be an 802.11/Ethernet L2 bridge somewhere on the path and IPv4 path MTU discovery would break! The current IPv4 path MTU discovery scheme is limiting potential growth and precluding legitimate solution alternatives. While we can't fix it all in one fell swoop, we can start making informed decisions (e.g., non-assumption of IPv4 fragmentation, support for packetization-layer path MTU discovery that does not require ICMPs, etc.) that will eventually bring about healing and new growth opportunities. Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >Hi, > >On Thu, 20 Nov 2003, Fred Templin wrote: > > >>Should we have as a goal the ability to support L2 bridges, switches, >>hubs, etc. that join media with dissimilar MTUs, but do not support >>IPv4 fragmentation and do not send "packet too big" ICMPs? >> >>We answered "NO" to this 15 years ago when we allowed the >>approach now specified in RFC 1191 to go forward, and that >>decision took a viable design alternative off the table which had >>a profound effect on the shaping of the industry. >> >>We're not going to fix this overnight by anything we do here, but >>allowing for generality (i.e., not expecting any IPv4 fragmentation >>support along the forwarding path) would be an important step >>toward restoring a level playing field. Let's not blow it again, >>given new opportunities to get things right. >> >> > >Fred, I appreciate your concern about creating a robust and optimal >Path MTU Discovery mechanism, but IMHO this document -- which we're >moving towards DS -- just simply doesn't seem to be the right time and >place to do so. > >There is little we can do to fix IPv4 at this point; IPv6 already >doesn't include fragmentation support along the path, and might be >enhanceable, in future, to support new methods. We'll need to live >with what we have. > > > > From owner-v6ops@ops.ietf.org Thu Nov 20 13:41:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17858 for ; Thu, 20 Nov 2003 13:41:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMtiF-0000kb-Mk for v6ops-data@psg.com; Thu, 20 Nov 2003 18:39:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMti2-0000jk-CF for v6ops@ops.ietf.org; Thu, 20 Nov 2003 18:39:18 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAKId6u11057; Thu, 20 Nov 2003 20:39:06 +0200 Date: Thu, 20 Nov 2003 20:39:06 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Fred Templin , Erik Nordmark , Subject: Re: transmech MTU comments In-Reply-To: <3FBD09FB.4020405@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 20 Nov 2003, Fred Templin wrote: > Your message was a cop-out, Pekka. Please address the question: Ok.. > Do we, or do we not want to allow for the possibility of > future L2 bridges, switches, hubs etc. that connect media > with dissimilar MTUs but that don't get involved with > L3 functions like IPv4 fragmentation and sending > "packet too big" ICMPs? No, I don't believe this is an immediate goal. > So, why can't we set the MTU of our 802.11 interfaces to > 2312 and take immediate advantage of the 35% gain in > efficiency? Because there might be an 802.11/Ethernet > L2 bridge somewhere on the path and IPv4 path MTU > discovery would break! > > The current IPv4 path MTU discovery scheme is limiting > potential growth and precluding legitimate solution alternatives. > While we can't fix it all in one fell swoop, we can start making > informed decisions (e.g., non-assumption of IPv4 fragmentation, > support for packetization-layer path MTU discovery that does > not require ICMPs, etc.) that will eventually bring about healing > and new growth opportunities. I agree that this may be an interesting direction to explore, but there does not yet seem to be a general agreement about whether the IETF will be moving to this direction or not. (Not sure if people even agree about a problem statement?) When such mechanisms have not been even fully? specified(?) for IPv4, it would seem to be premature to do it for IPv6-over-IPv4, especially considering the stage where we're at now. (I don't have full knowledge of the situation where this stands at the moment, but this is my impression..) This seems to be close to a pre-engineering/research question at the moment; not something I think is suitable for inserting into a specification moving towards Draft Standard. -- 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 Nov 20 13:49:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18299 for ; Thu, 20 Nov 2003 13:49:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMtpQ-0001CH-GX for v6ops-data@psg.com; Thu, 20 Nov 2003 18:46:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMtor-00019x-Np for v6ops@ops.ietf.org; Thu, 20 Nov 2003 18:46:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAKIkIa11203; Thu, 20 Nov 2003 20:46:18 +0200 Date: Thu, 20 Nov 2003 20:46:18 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: ISATAP spec stability [Re: ISATAP and admin/IP domains] In-Reply-To: <079501c3af8d$2f562490$870a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 20 Nov 2003, JORDI PALET MARTINEZ wrote: > Sorry to say this, but I completely agree with Fred. Do you want a > few examples ? Sorry for the statistics; maybe they didn't convey enough information. Of course, there is no problem issuing drafts when things get fixed. However, having reviewed the document a couple of times, The changes seem to be mostly rather substantial. (Each time I look at the draft, I keep wondering why there are more issues to fix than after the previous time I sent in comments.) If you want to have another angle at it, maybe a wdiff output about changes in the words might help: draft-templin-ngtrans-v6v4compat-01.txt: 4628 words 2231 48% common 334 7% inserted 2063 44% changed draft-ietf-ngtrans-isatap-00.txt: 4863 words 3516 72% common 415 8% inserted 932 19% changed draft-ietf-ngtrans-isatap-01.txt: 4220 words 3079 72% common 281 6% inserted 860 20% changed draft-ietf-ngtrans-isatap-02.txt: 4295 words 3730 86% common 212 4% inserted 353 8% changed draft-ietf-ngtrans-isatap-03.txt: 4090 words 977 23% common 804 19% inserted 2309 56% changed draft-ietf-ngtrans-isatap-04.txt: 4196 words 3499 83% common 267 6% inserted 430 10% changed draft-ietf-ngtrans-isatap-05.txt: 5082 words 3605 70% common 868 17% inserted 609 11% changed draft-ietf-ngtrans-isatap-06.txt: 4514 words 4060 89% common 241 5% inserted 213 4% changed draft-ietf-ngtrans-isatap-07.txt: 5912 words 3157 53% common 446 7% inserted 2309 39% changed draft-ietf-ngtrans-isatap-08.txt: 6435 words 5273 81% common 877 13% inserted 285 4% changed draft-ietf-ngtrans-isatap-09.txt: 6459 words 3987 61% common 579 8% inserted 1893 29% changed draft-ietf-ngtrans-isatap-10.txt: 6786 words 5286 77% common 431 6% inserted 1069 15% changed draft-ietf-ngtrans-isatap-11.txt: 6309 words 4280 67% common 506 8% inserted 1523 24% changed draft-ietf-ngtrans-isatap-12.txt: 7038 words 5302 75% common 857 12% inserted 879 12% changed draft-ietf-ngtrans-isatap-13.txt: 4430 words 3621 81% common 194 4% inserted 615 13% changed draft-ietf-ngtrans-isatap-14.txt: 4510 words 3635 80% common 366 8% inserted 509 11% changed draft-ietf-ngtrans-isatap-15.txt: 4740 words 3759 79% common 395 8% inserted 586 12% changed draft-ietf-ngtrans-isatap-16.txt: 4892 words 2388 48% common 327 6% inserted 2177 44% changed Now, let's compare that to something else that has been completed, e.g., 6to4; (I didn't find the previous personal submissions anywhere): draft-ietf-ngtrans-6to4-01.txt: 3850 words 2287 59% common 761 19% inserted 802 20% changed draft-ietf-ngtrans-6to4-02.txt: 5286 words 3390 64% common 766 14% inserted 1130 21% changed draft-ietf-ngtrans-6to4-03.txt: 5784 words 4237 73% common 953 16% inserted 594 10% changed draft-ietf-ngtrans-6to4-04.txt: 7033 words 5030 71% common 527 7% inserted 1476 20% changed draft-ietf-ngtrans-6to4-05.txt: 6980 words 6450 92% common 387 5% inserted 143 2% changed draft-ietf-ngtrans-6to4-06.txt: 6962 words 6851 98% common 22 0% inserted 89 1% changed draft-ietf-ngtrans-6to4-07.txt: 7643 words 5974 78% common 580 7% inserted 1089 14% changed rfc3056.txt: 7595 words 6987 91% common 347 4% inserted 261 3% changed Take it as you may. The diffs are against the previous version. > I think is not fair this type of messages from a chair. You should > be very neutral (unless you clearly state "hat off"). Unless explicitly stated otherwise, I do not wear a hat. When they made me a co-chair, I didn't agree to be silenced.. otherwise I would have refused :-). -- 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 Nov 20 13:52:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18380 for ; Thu, 20 Nov 2003 13:52:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMtsl-0001TD-9u for v6ops-data@psg.com; Thu, 20 Nov 2003 18:50:23 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMtsY-0001Rv-Eq for v6ops@ops.ietf.org; Thu, 20 Nov 2003 18:50:10 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKInwG21047; Thu, 20 Nov 2003 10:49:58 -0800 X-mProtect: <200311201849> 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 smtpdXyEIEy; Thu, 20 Nov 2003 10:49:57 PST Message-ID: <3FBD0E96.1050105@iprg.nokia.com> Date: Thu, 20 Nov 2003 10:57: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 , Erik Nordmark , v6ops@ops.ietf.org Subject: Re: transmech MTU comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Thu, 20 Nov 2003, Fred Templin wrote: > > >> Do we, or do we not want to allow for the possibility of >> future L2 bridges, switches, hubs etc. that connect media >> with dissimilar MTUs but that don't get involved with >> L3 functions like IPv4 fragmentation and sending >> "packet too big" ICMPs? >> >> > >No, I don't believe this is an immediate goal. > "Immediate goal" was not the question; "allow for the future possibility of" was the question. I would have a hard time believing any one of us could honestly answer "no" to the latter. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Nov 20 14:00:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18742 for ; Thu, 20 Nov 2003 14:00:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMu0Q-0002EJ-NO for v6ops-data@psg.com; Thu, 20 Nov 2003 18:58:18 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMu0D-0002DN-Ry for v6ops@ops.ietf.org; Thu, 20 Nov 2003 18:58:05 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKIvwt25884; Thu, 20 Nov 2003 10:57:58 -0800 X-mProtect: <200311201857> 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 smtpdxXQUbc; Thu, 20 Nov 2003 10:57:57 PST Message-ID: <3FBD1075.3050804@iprg.nokia.com> Date: Thu, 20 Nov 2003 11:05:25 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: ISATAP spec stability [Re: ISATAP and admin/IP domains] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm sorry, Pekka, but using a one-off example does absolutely nothing to support your case. If you want to compare against all 3500+ RFCs in the repository, that's perhaps a different thing - but, throwing a one-off example in our face is, frankly, immature. Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >On Thu, 20 Nov 2003, JORDI PALET MARTINEZ wrote: > > >>Sorry to say this, but I completely agree with Fred. Do you want a >>few examples ? >> >> > >Sorry for the statistics; maybe they didn't convey enough information. >Of course, there is no problem issuing drafts when things get fixed. > >However, having reviewed the document a couple of times, The changes >seem to be mostly rather substantial. (Each time I look at the draft, >I keep wondering why there are more issues to fix than after the >previous time I sent in comments.) > >If you want to have another angle at it, maybe a wdiff output about >changes in the words might help: > >draft-templin-ngtrans-v6v4compat-01.txt: 4628 words 2231 48% common 334 7% inserted 2063 44% changed >draft-ietf-ngtrans-isatap-00.txt: 4863 words 3516 72% common 415 8% inserted 932 19% changed >draft-ietf-ngtrans-isatap-01.txt: 4220 words 3079 72% common 281 6% inserted 860 20% changed >draft-ietf-ngtrans-isatap-02.txt: 4295 words 3730 86% common 212 4% inserted 353 8% changed >draft-ietf-ngtrans-isatap-03.txt: 4090 words 977 23% common 804 19% inserted 2309 56% changed >draft-ietf-ngtrans-isatap-04.txt: 4196 words 3499 83% common 267 6% inserted 430 10% changed >draft-ietf-ngtrans-isatap-05.txt: 5082 words 3605 70% common 868 17% inserted 609 11% changed >draft-ietf-ngtrans-isatap-06.txt: 4514 words 4060 89% common 241 5% inserted 213 4% changed >draft-ietf-ngtrans-isatap-07.txt: 5912 words 3157 53% common 446 7% inserted 2309 39% changed >draft-ietf-ngtrans-isatap-08.txt: 6435 words 5273 81% common 877 13% inserted 285 4% changed >draft-ietf-ngtrans-isatap-09.txt: 6459 words 3987 61% common 579 8% inserted 1893 29% changed >draft-ietf-ngtrans-isatap-10.txt: 6786 words 5286 77% common 431 6% inserted 1069 15% changed >draft-ietf-ngtrans-isatap-11.txt: 6309 words 4280 67% common 506 8% inserted 1523 24% changed >draft-ietf-ngtrans-isatap-12.txt: 7038 words 5302 75% common 857 12% inserted 879 12% changed >draft-ietf-ngtrans-isatap-13.txt: 4430 words 3621 81% common 194 4% inserted 615 13% changed >draft-ietf-ngtrans-isatap-14.txt: 4510 words 3635 80% common 366 8% inserted 509 11% changed >draft-ietf-ngtrans-isatap-15.txt: 4740 words 3759 79% common 395 8% inserted 586 12% changed >draft-ietf-ngtrans-isatap-16.txt: 4892 words 2388 48% common 327 6% inserted 2177 44% changed > >Now, let's compare that to something else that has been completed, >e.g., 6to4; (I didn't find the previous personal submissions >anywhere): > >draft-ietf-ngtrans-6to4-01.txt: 3850 words 2287 59% common 761 19% inserted 802 20% changed >draft-ietf-ngtrans-6to4-02.txt: 5286 words 3390 64% common 766 14% inserted 1130 21% changed >draft-ietf-ngtrans-6to4-03.txt: 5784 words 4237 73% common 953 16% inserted 594 10% changed >draft-ietf-ngtrans-6to4-04.txt: 7033 words 5030 71% common 527 7% inserted 1476 20% changed >draft-ietf-ngtrans-6to4-05.txt: 6980 words 6450 92% common 387 5% inserted 143 2% changed >draft-ietf-ngtrans-6to4-06.txt: 6962 words 6851 98% common 22 0% inserted 89 1% changed >draft-ietf-ngtrans-6to4-07.txt: 7643 words 5974 78% common 580 7% inserted 1089 14% changed >rfc3056.txt: 7595 words 6987 91% common 347 4% inserted 261 3% changed > >Take it as you may. The diffs are against the previous version. > > > >>I think is not fair this type of messages from a chair. You should >>be very neutral (unless you clearly state "hat off"). >> >> > >Unless explicitly stated otherwise, I do not wear a hat. > >When they made me a co-chair, I didn't agree to be silenced.. >otherwise I would have refused :-). > > > From owner-v6ops@ops.ietf.org Thu Nov 20 14:05:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18888 for ; Thu, 20 Nov 2003 14:05:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMu4d-0002Xa-Hv for v6ops-data@psg.com; Thu, 20 Nov 2003 19:02:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMu4R-0002WQ-6X for v6ops@ops.ietf.org; Thu, 20 Nov 2003 19:02:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAKJ2IC11603; Thu, 20 Nov 2003 21:02:18 +0200 Date: Thu, 20 Nov 2003 21:02:18 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Fred Templin , Erik Nordmark , Subject: Re: transmech MTU comments In-Reply-To: <3FBD0E96.1050105@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 20 Nov 2003, Fred Templin wrote: > >On Thu, 20 Nov 2003, Fred Templin wrote: > > > > > >> Do we, or do we not want to allow for the possibility of > >> future L2 bridges, switches, hubs etc. that connect media > >> with dissimilar MTUs but that don't get involved with > >> L3 functions like IPv4 fragmentation and sending > >> "packet too big" ICMPs? > >> > >> > > > >No, I don't believe this is an immediate goal. > > "Immediate goal" was not the question; "allow for the > future possibility of" was the question. I would have a > hard time believing any one of us could honestly > answer "no" to the latter. Ok, trying to clarify what I said. No, I don't believe it's an immediate goal to provide future possibility of [...]. That doesn't mean we may want to start building that future extensibility in a couple of years (for example), but providing that future extensibility does not seem a requirement *at the moment*. There's just no way to provide future extensibility possibility for every possible future, while staying robust and simple for the mechanisms and methods that exist today. Future extensibility is a tradeoff just like any other.. -- 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 Nov 20 14:21:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19517 for ; Thu, 20 Nov 2003 14:21:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMuK3-0003iS-Ga for v6ops-data@psg.com; Thu, 20 Nov 2003 19:18:35 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMuJp-0003ha-G0 for v6ops@ops.ietf.org; Thu, 20 Nov 2003 19:18:21 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id hAKJJj126125; Thu, 20 Nov 2003 11:19:45 -0800 From: bill Message-Id: <200311201919.hAKJJj126125@karoshi.com> Subject: Re: transmech MTU comments To: pekkas@netcore.fi (Pekka Savola) Date: Thu, 20 Nov 2003 11:19:45 -0800 (PST) Cc: ftemplin@iprg.nokia.com (Fred Templin), osprey67@yahoo.com (Fred Templin), Erik.Nordmark@sun.com (Erik Nordmark), v6ops@ops.ietf.org In-Reply-To: from "Pekka Savola" at Nov 20, 2003 08:39:06 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Do we, or do we not want to allow for the possibility of > > future L2 bridges, switches, hubs etc. that connect media > > with dissimilar MTUs but that don't get involved with > > L3 functions like IPv4 fragmentation and sending > > "packet too big" ICMPs? > > No, I don't believe this is an immediate goal. Hum... lost knowledge. anyone here still remember the MTU mismatches btwn 802.3, 802.5 and FDDI? there were any number of L2 bridges that did the negotiation to LCD-MTU w/o mucking w/ L3 functions... (to the extent possible) > > So, why can't we set the MTU of our 802.11 interfaces to > > 2312 and take immediate advantage of the 35% gain in > > efficiency? Because there might be an 802.11/Ethernet > > L2 bridge somewhere on the path and IPv4 path MTU > > discovery would break! > > > This seems to be close to a pre-engineering/research question at the > moment; not something I think is suitable for inserting into a > specification moving towards Draft Standard. see above. why is a problem solved more than a decade ago now a research topic? > Pekka Savola "You each name yourselves king, yet the --bill From owner-v6ops@ops.ietf.org Thu Nov 20 14:29:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19751 for ; Thu, 20 Nov 2003 14:29:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMuS8-0004I1-Gf for v6ops-data@psg.com; Thu, 20 Nov 2003 19:26:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMuRu-0004Gt-ST for v6ops@ops.ietf.org; Thu, 20 Nov 2003 19:26:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAKJQMf12078; Thu, 20 Nov 2003 21:26:22 +0200 Date: Thu, 20 Nov 2003 21:26:22 +0200 (EET) From: Pekka Savola To: bill cc: Fred Templin , Fred Templin , Erik Nordmark , Subject: Re: transmech MTU comments In-Reply-To: <200311201919.hAKJJj126125@karoshi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 20 Nov 2003, bill wrote: > Hum... lost knowledge. anyone here still remember the > MTU mismatches btwn 802.3, 802.5 and FDDI? there were > any number of L2 bridges that did the negotiation to > LCD-MTU w/o mucking w/ L3 functions... (to the extent > possible) Sure, but ... > > > So, why can't we set the MTU of our 802.11 interfaces to > > > 2312 and take immediate advantage of the 35% gain in > > > efficiency? Because there might be an 802.11/Ethernet > > > L2 bridge somewhere on the path and IPv4 path MTU > > > discovery would break! > > > > > This seems to be close to a pre-engineering/research question at the > > moment; not something I think is suitable for inserting into a > > specification moving towards Draft Standard. > > see above. why is a problem solved more than a decade ago > now a research topic? As far as I understand, the proposition was to solve the problem at the IP layer, not L2 what was the case (AFAIK) a decade ago. I have nothing against L2 solutions as long as they're transparent to IP, and that's certainly not a research topic :-). -- 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 Nov 20 15:00:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21434 for ; Thu, 20 Nov 2003 15:00:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMuv1-0006Dx-2a for v6ops-data@psg.com; Thu, 20 Nov 2003 19:56:47 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMuup-0006DB-93 for v6ops@ops.ietf.org; Thu, 20 Nov 2003 19:56:35 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id hAKJvuW26490; Thu, 20 Nov 2003 11:57:56 -0800 From: bill Message-Id: <200311201957.hAKJvuW26490@karoshi.com> Subject: Re: transmech MTU comments To: pekkas@netcore.fi (Pekka Savola) Date: Thu, 20 Nov 2003 11:57:56 -0800 (PST) Cc: bmanning@karoshi.com (bill), ftemplin@iprg.nokia.com (Fred Templin), osprey67@yahoo.com (Fred Templin), Erik.Nordmark@sun.com (Erik Nordmark), v6ops@ops.ietf.org In-Reply-To: from "Pekka Savola" at Nov 20, 2003 09:26:22 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > > So, why can't we set the MTU of our 802.11 interfaces to > > > > 2312 and take immediate advantage of the 35% gain in > > > > efficiency? Because there might be an 802.11/Ethernet > > > > L2 bridge somewhere on the path and IPv4 path MTU > > > > discovery would break! > > > > > > > This seems to be close to a pre-engineering/research question at the > > > moment; not something I think is suitable for inserting into a > > > specification moving towards Draft Standard. > > > > see above. why is a problem solved more than a decade ago > > now a research topic? > > As far as I understand, the proposition was to solve the problem at > the IP layer, not L2 what was the case (AFAIK) a decade ago. > > I have nothing against L2 solutions as long as they're transparent to > IP, and that's certainly not a research topic :-). read Freds note carefully. "...might be an 802.11/Ethernet L2 bridge..." which clearly calls out a L2 device. The kicker is that pesky 802.3 spec that calls for a 1500 mtu. darn that pesky ethernet replacement spec that everyone trys to use as a default for transit infrastructure... --bill From owner-v6ops@ops.ietf.org Thu Nov 20 15:32:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24435 for ; Thu, 20 Nov 2003 15:32:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMvR7-00088k-Ac for v6ops-data@psg.com; Thu, 20 Nov 2003 20:29:57 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMvQa-00086n-H5 for v6ops@ops.ietf.org; Thu, 20 Nov 2003 20:29:25 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24120; Thu, 20 Nov 2003 15:29:09 -0500 (EST) Message-Id: <200311202029.PAA24120@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-ipv4survey-intro-05.txt Date: Thu, 20 Nov 2003 15:29:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-intro-05.txt Pages : 0 Date : 2003-11-20 This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in currently deployed IETF documented standards. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which type of RFCs that has been documented, and a concatenated summary of results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-05.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-ipv4survey-intro-05.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-ipv4survey-intro-05.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: <2003-11-20154419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-intro-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-20154419.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Nov 20 16:13:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27058 for ; Thu, 20 Nov 2003 16:13:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMw3Z-000Aoc-Ef for v6ops-data@psg.com; Thu, 20 Nov 2003 21:09:41 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMw3M-000Anc-OM for v6ops@ops.ietf.org; Thu, 20 Nov 2003 21:09:28 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA24655 for ; Thu, 20 Nov 2003 21:09:27 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 VAA05571 for ; Thu, 20 Nov 2003 21:09:27 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAKL9Qn12851 for v6ops@ops.ietf.org; Thu, 20 Nov 2003 21:09:26 GMT Date: Thu, 20 Nov 2003 21:09:26 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: ISATAP spec stability [Re: ISATAP and admin/IP domains] Message-ID: <20031120210926.GH12489@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <079501c3af8d$2f562490$870a0a0a@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Nov 20, 2003 at 08:46:18PM +0200, Pekka Savola wrote: > On Thu, 20 Nov 2003, JORDI PALET MARTINEZ wrote: > > Sorry to say this, but I completely agree with Fred. Do you want a > > few examples ? > > Sorry for the statistics; maybe they didn't convey enough information. > Of course, there is no problem issuing drafts when things get fixed. Hi Pekka, Fair point. Any chance you could re-forward your most recent analysis of ISATAP? (Even if it has changed 44% since :) Thanks, Tim From owner-v6ops@ops.ietf.org Thu Nov 20 17:07:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02464 for ; Thu, 20 Nov 2003 17:07:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMwuF-000DbO-7Z for v6ops-data@psg.com; Thu, 20 Nov 2003 22:04:07 +0000 Received: from [212.153.235.109] (helo=gw-nl5.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMwtr-000DaS-S7 for v6ops@ops.ietf.org; Thu, 20 Nov 2003 22:03:44 +0000 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 448BC54C6B for ; Thu, 20 Nov 2003 23:03:42 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id C9A9819C55 for ; Thu, 20 Nov 2003 23:03:41 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 7093E19C54 for ; Thu, 20 Nov 2003 23:03:41 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id XAA18036 for ; Thu, 20 Nov 2003 23:03:41 +0100 (MET) From: mariana.nikolova@philips.com To: v6ops@ops.ietf.org Subject: Re: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 20 Nov 2003 14:02:59 -0800 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 20/11/2003 23:03:02, Serialize complete at 20/11/2003 23:03:02 Content-Type: multipart/alternative; boundary="=_alternative 0079386188256DE4_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_01,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 0079386188256DE4_= Content-Type: text/plain; charset="us-ascii" I do agree with many points in the Christian's e-mail and I do think that the WG should give a green line to ISATAP, DSTM, Teredo and Proto-41 before it is hopelessly late. This could happen in parallel with the analysis and scenarios work which is highly valuable as well. Mariana --------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- --=_alternative 0079386188256DE4_= Content-Type: text/html; charset="us-ascii"
I do agree with many points in the Christian's e-mail and I do think that the WG should give a green line to ISATAP, DSTM, Teredo and Proto-41 before it is hopelessly late. This could happen in parallel with the analysis and scenarios work which is highly valuable as well.

Mariana
---------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
----------------------------------------------------------------------------------------------------------------- --=_alternative 0079386188256DE4_=-- From owner-v6ops@ops.ietf.org Thu Nov 20 17:30:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03525 for ; Thu, 20 Nov 2003 17:30:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMxFm-000Ege-LA for v6ops-data@psg.com; Thu, 20 Nov 2003 22:26:22 +0000 Received: from [212.153.190.6] (helo=gw-nl4.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMxFP-000Efg-Gb for v6ops@ops.ietf.org; Thu, 20 Nov 2003 22:25:59 +0000 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id 84C062B2B0; Thu, 20 Nov 2003 23:25:58 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 23F2D19C48; Thu, 20 Nov 2003 23:25:58 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id CA86D19C45; Thu, 20 Nov 2003 23:25:57 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id XAA23193; Thu, 20 Nov 2003 23:25:57 +0100 (MET) From: mariana.nikolova@philips.com To: Fred Templin Cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 20 Nov 2003 14:25:15 -0800 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 20/11/2003 23:25:18, Serialize complete at 20/11/2003 23:25:18 Content-Type: multipart/alternative; boundary="=_alternative 007B420B88256DE4_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 007B420B88256DE4_= Content-Type: text/plain; charset="us-ascii" >I'd like to suggest that a NAT that does the proper proto41 forwarding is unlike a NAT > in the traditional sense and perhaps in need of a new name. >My suggestion is:Network Organizational Translator (NOT) Fred, technically speaking NAT for forwarding packets with protocol field 41 is the same as NAT for forwarding packets with protocol field 6 (TCP) and 17 (UDP). Well, the entities in the NAT table are different, e.g. for 41 it's (source IP address, target IP address, IP protocol) whereas for 6 and 17 it's (source IP address, source TCP/UDP port, target IP address, target TCP/UDP port) but the principle of address translation is the same. The difference in the entity comes from the fact that 41 forwarding happen on IP layer whereas the 6 and 17 forwarding happen on TCP/UDP layer, taking into accoun the ports numbers as well. Frankly speakning I do not see any reason to go for another name. Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- --=_alternative 007B420B88256DE4_= Content-Type: text/html; charset="us-ascii"
>I'd like to suggest that a NAT that does the proper proto41 forwarding is unlike a NAT
> in the traditional sense and perhaps in need of a new name.
>My suggestion is:Network Organizational Translator (NOT)

Fred, technically speaking NAT for forwarding packets with protocol field 41 is the same as NAT for forwarding packets with protocol field 6 (TCP) and 17 (UDP). Well, the entities in the NAT table are different, e.g. for 41 it's
 (source IP address, target IP address, IP protocol)
whereas for 6 and 17 it's
(source IP address, source TCP/UDP port, target IP address, target TCP/UDP port)
but the principle of address translation is the same. The difference in the entity comes from the fact that 41 forwarding happen on IP layer  whereas the 6 and 17 forwarding happen on TCP/UDP layer, taking into accoun the ports numbers as well.
 
Frankly speakning I do not see any reason to go for another name.

Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
----------------------------------------------------------------------------------------------------------------- --=_alternative 007B420B88256DE4_=-- From owner-v6ops@ops.ietf.org Thu Nov 20 17:43:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04088 for ; Thu, 20 Nov 2003 17:43:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMxSA-000FMY-Ac for v6ops-data@psg.com; Thu, 20 Nov 2003 22:39:10 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMxRp-000FL2-I4 for v6ops@ops.ietf.org; Thu, 20 Nov 2003 22:38:49 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKMckD21065; Thu, 20 Nov 2003 14:38:46 -0800 X-mProtect: <200311202238> 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 smtpdQFw3SO; Thu, 20 Nov 2003 14:38:45 PST Message-ID: <3FBD4437.3070808@iprg.nokia.com> Date: Thu, 20 Nov 2003 14:46:15 -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: mariana.nikolova@philips.com CC: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit mariana.nikolova@philips.com wrote: > > >I'd like to suggest that a NAT that does the proper proto41 > forwarding is unlike a NAT > > in the traditional sense and perhaps in need of a new name. > >My suggestion is:Network Organizational Translator (NOT) > > > Fred, technically speaking NAT for forwarding packets with protocol > field 41 is the same as NAT for forwarding packets with protocol field > 6 (TCP) and 17 (UDP). Well, the entities in the NAT table are > different, e.g. for 41 it's > (source IP address, target IP address, IP protocol) Perhaps it should be: (source IP address, target IP address, IP protocol, IPv6 flow_label) ? > whereas for 6 and 17 it's > (source IP address, source TCP/UDP port, target IP address, target > TCP/UDP port) > but the principle of address translation is the same. The difference > in the entity comes from the fact that 41 forwarding happen on IP > layer whereas the 6 and 17 forwarding happen on TCP/UDP layer, taking > into accoun the ports numbers as well. > > Frankly speakning I do not see any reason to go for another name. I won't push hard for another name. We already have enough confusing TLAs runnining around for the forseeable future. Thanks - Fred ftemplin@iprg.nokia.com > Mariana > ----------------------------------------------------------------------------------------------------------------- > Dr. Mariana Nikolova > Philips Research Laboratories Eindhoven (IST/SwA/DS) > Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands > room: WDC 1.35, phone: +31-40-27-45455 > e-mail: mariana.nikolova@philips.com > ----------------------------------------------------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Thu Nov 20 18:37:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08073 for ; Thu, 20 Nov 2003 18:37:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMyJN-000I78-AN for v6ops-data@psg.com; Thu, 20 Nov 2003 23:34:09 +0000 Received: from [212.153.235.109] (helo=gw-nl5.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMyIw-000I4z-3S for v6ops@ops.ietf.org; Thu, 20 Nov 2003 23:33:42 +0000 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 7373D555AA; Fri, 21 Nov 2003 00:33:41 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 0C05419C4B; Fri, 21 Nov 2003 00:33:41 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id AD77819C46; Fri, 21 Nov 2003 00:33:40 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id AAA07994; Fri, 21 Nov 2003 00:33:40 +0100 (MET) From: mariana.nikolova@philips.com To: Carlos Friacas Cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-03 as WG item MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 20 Nov 2003 15:32:57 -0800 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 21/11/2003 00:33:01, Serialize complete at 21/11/2003 00:33:01 Content-Type: multipart/alternative; boundary="=_alternative 008174F488256DE4_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 008174F488256DE4_= Content-Type: text/plain; charset="us-ascii" >Has the "uniqueness" problem been solved/sorted out? E.g.: >If i and Jordi attend the same conference and stay on the same hotel, >which only has a nat box, can we both use this "mechanism"? >Or should i have to phone Jordi and say: "Hey, can you disconnect for 5 >mins, i need to use IPv6!". If a site (e.g. your hotel, Carlos) prefers to keep working with a proto41 IPv4-only NAT router instead of buying a 6to4 or even IPv6 router with native IPv6 external connectivity, then all incoming IPv4 packets with PF=41 will be routed to a fixed IPv6/IPv4 device which has to play the role of IPv6 router. This is a typical example of distribution of router functionality, i.e., functionality conceptually belonging to one IPv6/IPv4 router, e.g. 6to4 router, are split now between two nodes - the first is the IPv4-only router whereas the second is an IPv6/IPv4 host with embedded IPv6 functionality. Summing up, in this case the missing IPv6 functionality in the IPv4-only NAT router should be compensate in another place - either embedded in an IPv6/IPv4 host or deployed in a separate (second) IPv6 router. Another alternative is Teredo. So, if the hotel does this, you, Carlos, should not call Jordi for getting IPv6 connectivity, although you may call him for having a cup of coffee together :-)! By the way, choosing for proto41 IPv4-only NAT router can happen due to whatever reasons, mostly financial, e.g. consider a router with an integrated access modem (i.e. an integrated solution) that costs ~250 euro instead of 50 euro for a simpler IPv4 routers. If there is no IPv6 firmware upgrade for this integrated solution (and usually there is no) then everybody starts thinking twice before buying a new IPv6/IPv4 router. Solution like proto41 may be a quick "patch" then. >Is this still true? Is this *clearly* reflected on the current draft version? Jordi, according to me it is not clearly written in the draft. This is certainly point for improvement. Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- --=_alternative 008174F488256DE4_= Content-Type: text/html; charset="us-ascii"
>Has the "uniqueness" problem been solved/sorted out? E.g.:

>If i and Jordi attend the same conference and stay on the same hotel,
>which only has a nat box, can we both use this "mechanism"?
>Or should i have to phone Jordi and say: "Hey, can you disconnect for 5
>mins, i need to use IPv6!".

If a site (e.g. your hotel, Carlos) prefers to keep working with a proto41 IPv4-only NAT router instead of buying a 6to4 or even  IPv6 router with native IPv6 external connectivity, then all  incoming IPv4 packets with PF=41 will be routed to a fixed IPv6/IPv4 device which has to play the role of IPv6 router.

This is a typical example of distribution of router functionality, i.e., functionality conceptually belonging to one IPv6/IPv4 router, e.g. 6to4 router, are split now between two nodes - the first is the IPv4-only router whereas the second is an IPv6/IPv4 host with embedded IPv6 functionality.
Summing up,  in this case the missing IPv6 functionality in the IPv4-only NAT router should be compensate in another place - either embedded in an IPv6/IPv4 host or deployed in a separate (second) IPv6 router. Another alternative is Teredo.

So, if the hotel does this, you, Carlos, should not call Jordi for getting IPv6 connectivity, although you may call him for having a cup of coffee together :-)!

By the way, choosing for proto41 IPv4-only NAT router can happen due to whatever reasons, mostly financial, e.g. consider a router with an integrated access modem (i.e. an integrated solution) that costs ~250 euro instead of 50 euro for a simpler IPv4 routers. If there is no IPv6  firmware upgrade for this integrated solution  (and usually there is no) then everybody starts thinking twice before buying a new IPv6/IPv4 router. Solution like proto41 may be a quick "patch" then.

>Is this still true? Is this *clearly* reflected on the current draft version?

Jordi, according to me it is not clearly written in the draft. This is certainly point for improvement.

Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
----------------------------------------------------------------------------------------------------------------- --=_alternative 008174F488256DE4_=-- From owner-v6ops@ops.ietf.org Thu Nov 20 21:23:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14109 for ; Thu, 20 Nov 2003 21:23:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AN0rX-0000rj-5r for v6ops-data@psg.com; Fri, 21 Nov 2003 02:17:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AN0q6-0000m5-E5 for v6ops@ops.ietf.org; Fri, 21 Nov 2003 02:16:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAL2G4E20043 for ; Fri, 21 Nov 2003 04:16:05 +0200 Date: Fri, 21 Nov 2003 04:16:04 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: I-D: Simple Configured Tunnel Setup Procedure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Based on the "simplified ISATAP" discussions and prior to that, my desire to show that setting up configured tunnels in the 3GPP scenario can be pretty simple, I banged the keyboard a bit and produced a "proof-of-concept" draft: A Simple IPv6-in-IPv4 Configured Tunnel Set-Up Procedure Abstract This memo describes a set of operational procedures and one implementation mechanism to provide a very simple and straightforward way to easily manage IPv6-over-IPv4 configured tunnels between an ISP and a customer. The configured tunnels work even if the IPv4 addresses change dynamically, or are private addresses; the procedure provides at least a /64 prefix per customer and requires no administrative set-up. Support for NAT Traversal is currently out of scope. I just sent it to the I-D repository, so in the meantime, it's available (less than 10 pages of content) at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-setup-00.txt Comments, etc. are welcome, of course. (note, section 5.5.1 should have been 5.6 but no matter..) -- 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 Nov 21 03:45:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05421 for ; Fri, 21 Nov 2003 03:45:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AN6oZ-000IUS-Ed for v6ops-data@psg.com; Fri, 21 Nov 2003 08:38:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AN6oN-000ITP-6W for v6ops@ops.ietf.org; Fri, 21 Nov 2003 08:38:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAL8cTE25009; Fri, 21 Nov 2003 10:38:29 +0200 Date: Fri, 21 Nov 2003 10:38:28 +0200 (EET) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org Subject: Re: I-D: Simple Configured Tunnel Setup Procedure In-Reply-To: <266710000.1069386203@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for the comments. (Btw, you might want to resubscribe with the address you use because the mails bounce to the list admin.) On Thu, 20 Nov 2003, Marc Blanchet wrote: > my reading is that: > - good idea. > - if you go more into the details which makes a complete solution, you will > end up redoing either tunnel broker or tunnel broker with TSP. > - TSP automates the creation of tunnels with no complexity or overhead. and > it manages the delegation of prefixes, the mobility of the v4 side (i.e. > change of v4 address), can be part of a boot sequence of a node or router, > etc... > - basically, you need a signaling protocol of some sort to help the two > parties involved to setup the tunnel (and the various additional needed > info, such as prefix allocation, ...) I do not believe there is a need for signaling protocol at all, and I think the memo tries to proof-of-concept this. You can manage the change of v4 address without a protocol; there are already protocols for prefix delegation and they can be reused, etc. (Obviously, if there is a need for a simpler prefix delegation mechanism than DHCPv6, that's a separate issue on its own.) I considered TSP before starting to write this, but I could not justify the signaling protocol overhead and complexity to myself, as there clearly didn't seem to be a need for one. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Nov 21 03:55:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05787 for ; Fri, 21 Nov 2003 03:55:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AN71s-000JK2-W4 for v6ops-data@psg.com; Fri, 21 Nov 2003 08:52:40 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AN2H9-00058f-C9 for v6ops@ops.ietf.org; Fri, 21 Nov 2003 03:48:07 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id hAL3iJ4G017761; Thu, 20 Nov 2003 22:44:20 -0500 (EST) Date: Thu, 20 Nov 2003 22:43:23 -0500 From: Marc Blanchet To: Pekka Savola , v6ops@ops.ietf.org Subject: Re: I-D: Simple Configured Tunnel Setup Procedure Message-ID: <266710000.1069386203@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit my reading is that: - good idea. - if you go more into the details which makes a complete solution, you will end up redoing either tunnel broker or tunnel broker with TSP. - TSP automates the creation of tunnels with no complexity or overhead. and it manages the delegation of prefixes, the mobility of the v4 side (i.e. change of v4 address), can be part of a boot sequence of a node or router, etc... - basically, you need a signaling protocol of some sort to help the two parties involved to setup the tunnel (and the various additional needed info, such as prefix allocation, ...) Marc. -- Friday, November 21, 2003 04:16:04 +0200 Pekka Savola wrote/a ecrit: > Hi, > > Based on the "simplified ISATAP" discussions and prior to that, my > desire to show that setting up configured tunnels in the 3GPP scenario > can be pretty simple, I banged the keyboard a bit and produced a > "proof-of-concept" draft: > > A Simple IPv6-in-IPv4 Configured Tunnel Set-Up Procedure > > Abstract > > This memo describes a set of operational procedures and one > implementation mechanism to provide a very simple and straightforward > way to easily manage IPv6-over-IPv4 configured tunnels between an ISP > and a customer. The configured tunnels work even if the IPv4 > addresses change dynamically, or are private addresses; the procedure > provides at least a /64 prefix per customer and requires no > administrative set-up. Support for NAT Traversal is currently out of > scope. > > I just sent it to the I-D repository, so in the meantime, it's > available (less than 10 pages of content) at: > > http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-setup-00.txt > > Comments, etc. are welcome, of course. > > (note, section 5.5.1 should have been 5.6 but no matter..) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Fri Nov 21 06:07:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09903 for ; Fri, 21 Nov 2003 06:07:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AN94N-0000TI-I0 for v6ops-data@psg.com; Fri, 21 Nov 2003 11:03:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AN94B-0000SZ-7R for v6ops@ops.ietf.org; Fri, 21 Nov 2003 11:03:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hALB3AK27250 for ; Fri, 21 Nov 2003 13:03:10 +0200 Date: Fri, 21 Nov 2003 13:03:10 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: I-D: Simple Configured Tunnel Setup Procedure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi again, After sleeping on the idea, I extended it a bit to include a limited form of NAT traversal, and beefed it up otherwise as well (e.g., by including an "out of scope for this draft" subsection). Available at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-setup-01.txt Comments, etc. are of course still welcome :-) Thanks to Suresh for a nice name and the acronym! :-) On Fri, 21 Nov 2003, Pekka Savola wrote: > Hi, > > Based on the "simplified ISATAP" discussions and prior to that, my > desire to show that setting up configured tunnels in the 3GPP scenario > can be pretty simple, I banged the keyboard a bit and produced a > "proof-of-concept" draft: > > A Simple IPv6-in-IPv4 Configured Tunnel Set-Up Procedure > > Abstract > > This memo describes a set of operational procedures and one > implementation mechanism to provide a very simple and straightforward > way to easily manage IPv6-over-IPv4 configured tunnels between an ISP > and a customer. The configured tunnels work even if the IPv4 > addresses change dynamically, or are private addresses; the procedure > provides at least a /64 prefix per customer and requires no > administrative set-up. Support for NAT Traversal is currently out of > scope. > > I just sent it to the I-D repository, so in the meantime, it's > available (less than 10 pages of content) at: > > http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-setup-00.txt > > Comments, etc. are welcome, of course. > > (note, section 5.5.1 should have been 5.6 but no matter..) > > -- 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 Nov 21 11:34:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20349 for ; Fri, 21 Nov 2003 11:34:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANEA7-000K0h-Kn for v6ops-data@psg.com; Fri, 21 Nov 2003 16:29:39 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANE9u-000Jzs-R9 for v6ops@ops.ietf.org; Fri, 21 Nov 2003 16:29:26 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2003 17:26:51 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hALGTDv8021893; Fri, 21 Nov 2003 17:29:14 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA19147; Fri, 21 Nov 2003 16:29:24 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: I-D: Simple Configured Tunnel Setup Procedure References: From: Ole Troan Date: Fri, 21 Nov 2003 16:29:24 +0000 In-Reply-To: (Pekka Savola's message of "Fri, 21 Nov 2003 13:03:10 +0200 (EET)") Message-ID: <7t5oev5it23.fsf@mrwint.cisco.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > After sleeping on the idea, I extended it a bit to include a > limited form of NAT traversal, and beefed it up otherwise as well > (e.g., by including an "out of scope for this draft" subsection). > > Available at: > > http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-setup-01.txt > > Comments, etc. are of course still welcome :-) I do like the idea (but)... if the 'S' in STEP means simple to deploy then couldn't you achieve the same by just using L2TP? the user runs the LAC the ISP the LNS. IPv6/PPP/L2TP/UDP tunnelling between them. the ISP would typically have the required infrastructure already. authentication is defined and it should do NAT traversal. /ot > > Thanks to Suresh for a nice name and the acronym! :-) > > On Fri, 21 Nov 2003, Pekka Savola wrote: >> Hi, >> >> Based on the "simplified ISATAP" discussions and prior to that, my >> desire to show that setting up configured tunnels in the 3GPP scenario >> can be pretty simple, I banged the keyboard a bit and produced a >> "proof-of-concept" draft: >> >> A Simple IPv6-in-IPv4 Configured Tunnel Set-Up Procedure >> >> Abstract >> >> This memo describes a set of operational procedures and one >> implementation mechanism to provide a very simple and straightforward >> way to easily manage IPv6-over-IPv4 configured tunnels between an ISP >> and a customer. The configured tunnels work even if the IPv4 >> addresses change dynamically, or are private addresses; the procedure >> provides at least a /64 prefix per customer and requires no >> administrative set-up. Support for NAT Traversal is currently out of >> scope. >> >> I just sent it to the I-D repository, so in the meantime, it's >> available (less than 10 pages of content) at: >> >> http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-setup-00.txt >> >> Comments, etc. are welcome, of course. >> >> (note, section 5.5.1 should have been 5.6 but no matter..) >> >> > > -- > 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 Nov 21 13:36:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26040 for ; Fri, 21 Nov 2003 13:36:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANG52-0000AF-Rm for v6ops-data@psg.com; Fri, 21 Nov 2003 18:32:32 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ANG4q-00009i-IA for v6ops@ops.ietf.org; Fri, 21 Nov 2003 18:32:20 +0000 Received: (qmail 15384 invoked by uid 1007); 21 Nov 2003 18:32:19 -0000 Date: Fri, 21 Nov 2003 19:32:19 +0100 From: Gert Doering To: Ole Troan Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: I-D: Simple Configured Tunnel Setup Procedure Message-ID: <20031121183219.GS30954@Space.Net> References: <7t5oev5it23.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7t5oev5it23.fsf@mrwint.cisco.com> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, Nov 21, 2003 at 04:29:24PM +0000, Ole Troan wrote: > I do like the idea (but)... if the 'S' in STEP means simple to deploy > then couldn't you achieve the same by just using L2TP? the user runs > the LAC the ISP the LNS. IPv6/PPP/L2TP/UDP tunnelling between > them. the ISP would typically have the required infrastructure > already. authentication is defined and it should do NAT traversal. Been there, done that, works :-) The drawback is that it's only "simple" if you have an existing L2TP infrastructure (that already can do IPv6). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57386 (57785) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Fri Nov 21 14:27:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27735 for ; Fri, 21 Nov 2003 14:27:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANGsx-00036W-W1 for v6ops-data@psg.com; Fri, 21 Nov 2003 19:24:07 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANGsk-00035u-7t for v6ops@ops.ietf.org; Fri, 21 Nov 2003 19:23:54 +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 5782D82BF; Fri, 21 Nov 2003 20:23:48 +0100 (CET) From: "Jeroen Massar" To: "'Gert Doering'" , "'Ole Troan'" Cc: "'Pekka Savola'" , Subject: RE: I-D: Simple Configured Tunnel Setup Procedure Date: Fri, 21 Nov 2003 20:23:47 +0100 Organization: Unfix Message-ID: <004401c3b064$fd072d30$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20031121183219.GS30954@Space.Net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Gert Doering wrote: > On Fri, Nov 21, 2003 at 04:29:24PM +0000, Ole Troan wrote: > > I do like the idea (but)... if the 'S' in STEP means simple > to deploy > > then couldn't you achieve the same by just using L2TP? the user runs > > the LAC the ISP the LNS. IPv6/PPP/L2TP/UDP tunnelling between > > them. the ISP would typically have the required infrastructure > > already. authentication is defined and it should do NAT traversal. > > Been there, done that, works :-) > > The drawback is that it's only "simple" if you have an existing L2TP > infrastructure (that already can do IPv6). tinc / OpenVPN works indeed. I've implemented the first one in the SixXS framework and am currently running a beta for it. Tinc does UDP and TCP using RSA keys etc. Keys are 'uploaded' from the client to the SixXS configuration service and then the noc box syncs the POP. Using the "heartbeat" client it automatically works currently on both unices and Windows platforms. It is still in beta because we like to provide a quality service and there where still some minor details to be worked out. Now the hardest part is getting a NIC handle to signup to SixXS :) Also see http://www.sixxs.net/tools/configservice/ And http://www.sixxs.net/tools/heartbeat/ The 'heartbeat protocol' btw allows for true dynamic tunnels. The client sends a md5 signed heartbeat to the POP every 60 seconds or when the client notices an IP change, Windows has nice events for this and unices can sigHUP the client causing an instant update. which then adjusts it's proto-41 tunnel to the specified endpoint. Yes, these are authenticated+configured tunnels. Drafts for the configservice still have to be typed but it should be clear how it works from the above url, a draft for the heartbeat protocol is included in the unix tarball. Sources available at http://www.sixxs.net/archive/sixxs/heartbeat/ Windows sources will be released soon but we'll have to clean those up first for public release. The rest of the SixXS system is also open and free btw but currently not available for public download. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP75mQymqKFIzPnwjEQICRQCfT7DfriuDqOIhAe6MwZ5fZKZc2L8AoJgz RkHfP6OIoNFe236U2phdhDxG =kQKf -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Fri Nov 21 15:22:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00871 for ; Fri, 21 Nov 2003 15:22:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANHjy-0005gw-1e for v6ops-data@psg.com; Fri, 21 Nov 2003 20:18:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANHjk-0005gN-QQ for v6ops@ops.ietf.org; Fri, 21 Nov 2003 20:18:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hALKINr03946; Fri, 21 Nov 2003 22:18:23 +0200 Date: Fri, 21 Nov 2003 22:18:23 +0200 (EET) From: Pekka Savola To: Gert Doering cc: Ole Troan , Subject: Re: I-D: Simple Configured Tunnel Setup Procedure In-Reply-To: <20031121183219.GS30954@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 21 Nov 2003, Gert Doering wrote: > On Fri, Nov 21, 2003 at 04:29:24PM +0000, Ole Troan wrote: > > I do like the idea (but)... if the 'S' in STEP means simple to deploy > > then couldn't you achieve the same by just using L2TP? the user runs > > the LAC the ISP the LNS. IPv6/PPP/L2TP/UDP tunnelling between > > them. the ISP would typically have the required infrastructure > > already. authentication is defined and it should do NAT traversal. > > Been there, done that, works :-) > > The drawback is that it's only "simple" if you have an existing L2TP > infrastructure (that already can do IPv6). I haven't really looked into L2TP myself, but I have a similar impression than Gert -- L2TP -based system would be simple if all the parties were already using L2TP. The simplicity is just borne by a different set of folks. The current STEP proposal (except for UDP encapsulation which is pretty trivial) has zero code changes and zero new software needed at the client side, and very little to do at the ISP side. The ISP does have to hook the system up to its lease/RADIUS/etc. databases somehow and/or implement a small piece of code at the router that creates a tunnel dynamically from a received packet. So most of the work is done using unspecified management methods. For ISPs knowing what to do this should be straightforward -- for those that don't, there might have to be some additional ways to make it easier.. However, I would not want to discount L2TP as a solution. Could someone describe the infrastructure required a bit -- both at the user, router and the other parts? -- 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 Nov 21 17:33:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09037 for ; Fri, 21 Nov 2003 17:33:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANJm6-000Cbm-OD for v6ops-data@psg.com; Fri, 21 Nov 2003 22:29:14 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ANJlt-000CbL-Lh for v6ops@ops.ietf.org; Fri, 21 Nov 2003 22:29:01 +0000 Received: (qmail 22934 invoked by uid 1007); 21 Nov 2003 22:28:58 -0000 Date: Fri, 21 Nov 2003 23:28:58 +0100 From: Gert Doering To: Pekka Savola Cc: Gert Doering , Ole Troan , v6ops@ops.ietf.org Subject: Re: I-D: Simple Configured Tunnel Setup Procedure Message-ID: <20031121222858.GU30954@Space.Net> References: <20031121183219.GS30954@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, Nov 21, 2003 at 10:18:23PM +0200, Pekka Savola wrote: > However, I would not want to discount L2TP as a solution. Could > someone describe the infrastructure required a bit -- both at the > user, router and the other parts? OK, I'll give it a try. The formal specs can be found in rfc2661, so I'll try to be very brief here. The pieces that form L2TP are: - UDP packets (port 1701) - PPP frames packed into those - plus some control stuff to glue the bits together (session mgmt) So what really happens "down there" is that you run a normal PPP session with all possible protocol-CPs (IPCP, IPV6CP, IPXCP, ...) inside a IPv4 UDP data stream. The infrastructure in between, including NATs, just needs to know how to handle UDP (so it should be possible to run multiple L2TP sessions from behind the same NAT, but I haven't tested that one yet). On the client side, you (obviously) need a L2TP implementation. On Linux, the l2tp engine uses the stock system pppd for the PPP option and protocol negotiation. So as soon as you have a kernel that speaks IPv6 and a pppd that can do IPV6CP and setup IPV6 on the link, you're done. Most client operating systems these days come with a L2TP implementation, and adding IPv6 to the underlying PPP implementation should be something the vendors are doing anyway (to support direct PPP via POTS/ISDN, or PPPoE, etc., with IPv6). On the server side, there is an implementation of L2TP for Linux (the same implementation that also does the client side). Allegedly it does scale "well", but I have no idea how well. A "standard" ISP would run the L2TP on his access servers that are needed anyway to do end-customer dynamic DSL access (client side PPPoE that ends up in L2TP packets). That access server would then do PPP authentication versus some sort of AAA server, e.g. RADIUS, and the Radius server sends down static IPv6 prefixes, or "allocate something from the IPv6 pool ". For anonymous/unregistered access, you'd need to do some sort of "everybody uses the same account" and make sure via radius configuration that they get different addresses each. For the router vendor, what needs to be done to get this working is (roughly, assuming basic IPv6 functionality is there): - add IPv6 functionality to PPP - implement some sort of RADIUS configuration management to get IPv6 attributes - implement IPv6 address pools for dynamic client assignments all of which is needed for "PPP over ISDN/POTS with IPv6" anyway... Conclusion: if, as an ISP (or a vendor of ISP hardware) you want to support PPP over ISDN/POTS with IPv6 support, and at the same time you want to support L2TP clients (DSL users), the required glue to get IPv6 into L2TP should be very small. The *overall* complexity of such a system is high, though. The benefit is only "most of it is there anyway". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57386 (57785) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Sun Nov 23 18:22:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04141 for ; Sun, 23 Nov 2003 18:22:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AO3S8-000JWI-9Z for v6ops-data@psg.com; Sun, 23 Nov 2003 23:15:40 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AO3Rq-000JUp-M3 for v6ops@ops.ietf.org; Sun, 23 Nov 2003 23:15:23 +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 36-md50000000165.tmp for ; Mon, 24 Nov 2003 00:16:28 +0100 Message-ID: <139101c3b217$bead3480$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: I-D: Simple Configured Tunnel Setup Procedure Date: Mon, 24 Nov 2003 00:15:53 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 24 Nov 2003 00: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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable My feeling on this is that most of the ISPs will not accept off-band = procedures, and TSP seems useful to avoid that. Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "Marc Blanchet" Cc: Sent: Friday, November 21, 2003 9:38 AM Subject: Re: I-D: Simple Configured Tunnel Setup Procedure > Hi, >=20 > Thanks for the comments. (Btw, you might want to resubscribe with the=20 > address you use because the mails bounce to the list admin.) >=20 > On Thu, 20 Nov 2003, Marc Blanchet wrote: > > my reading is that: > > - good idea. > > - if you go more into the details which makes a complete solution, = you will > > end up redoing either tunnel broker or tunnel broker with TSP. > > - TSP automates the creation of tunnels with no complexity or = overhead. and > > it manages the delegation of prefixes, the mobility of the v4 side = (i.e. > > change of v4 address), can be part of a boot sequence of a node or = router, > > etc...=20 > > - basically, you need a signaling protocol of some sort to help the = two > > parties involved to setup the tunnel (and the various additional = needed > > info, such as prefix allocation, ...) >=20 > I do not believe there is a need for signaling protocol at all, and I=20 > think the memo tries to proof-of-concept this. >=20 > You can manage the change of v4 address without a protocol; there are > already protocols for prefix delegation and they can be reused, etc. > (Obviously, if there is a need for a simpler prefix delegation > mechanism than DHCPv6, that's a separate issue on its own.) >=20 > I considered TSP before starting to write this, but I could not=20 > justify the signaling protocol overhead and complexity to myself, as=20 > there clearly didn't seem to be a need for one. >=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 Nov 24 03:44:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00052 for ; Mon, 24 Nov 2003 03:44:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOCGn-000Kg9-I9 for v6ops-data@psg.com; Mon, 24 Nov 2003 08:40:33 +0000 Received: from [193.6.222.240] (helo=mignon.ki.iif.hu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOCGZ-000KfT-FL for v6ops@ops.ietf.org; Mon, 24 Nov 2003 08:40:19 +0000 Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id 331456E06; Mon, 24 Nov 2003 09:40:18 +0100 (CET) Received: from mignon.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51638-03; Mon, 24 Nov 2003 09:40:16 +0100 (CET) Received: by mignon.ki.iif.hu (Postfix, from userid 1003) id 8A94466DF; Mon, 24 Nov 2003 09:40:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id 85657662F; Mon, 24 Nov 2003 09:40:16 +0100 (CET) Date: Mon, 24 Nov 2003 09:40:16 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Subject: Re: I-D: Simple Configured Tunnel Setup Procedure In-Reply-To: <139101c3b217$bead3480$870a0a0a@consulintel.es> Message-ID: <20031124092337.N51429@mignon.ki.iif.hu> References: <139101c3b217$bead3480$870a0a0a@consulintel.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 24 Nov 2003, JORDI PALET MARTINEZ wrote: > My feeling on this is that most of the ISPs will not accept off-band > procedures, and TSP seems useful to avoid that. In my opinion if ISP wants to provide tunnel service they have to know in advance that they will serve something - at least, in order to be able to track the usage of service. If ISP is using RADIUS or Diameter authentication for obtaining the customers' tunnel endpoint addresses, they already had to have some form of agreement. It would be very easy for the customer just ask IPv6 tunnel service via the customer care center of ISP. Probably I would use this method to provide IPv6 for DSL/dial-up or otherwise authenticated users. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > Hi, > > > > Thanks for the comments. (Btw, you might want to resubscribe with the > > address you use because the mails bounce to the list admin.) > > > > On Thu, 20 Nov 2003, Marc Blanchet wrote: > > > my reading is that: - good idea. - if you go more into the details > > > which makes a complete solution, you will end up redoing either > > > tunnel broker or tunnel broker with TSP. - TSP automates the > > > creation of tunnels with no complexity or overhead. and it manages > > > the delegation of prefixes, the mobility of the v4 side (i.e. change > > > of v4 address), can be part of a boot sequence of a node or router, > > > etc... - basically, you need a signaling protocol of some sort to > > > help the two parties involved to setup the tunnel (and the various > > > additional needed info, such as prefix allocation, ...) > > > > I do not believe there is a need for signaling protocol at all, and I > > think the memo tries to proof-of-concept this. > > > > You can manage the change of v4 address without a protocol; there are > > already protocols for prefix delegation and they can be reused, etc. > > (Obviously, if there is a need for a simpler prefix delegation > > mechanism than DHCPv6, that's a separate issue on its own.) > > > > I considered TSP before starting to write this, but I could not > > justify the signaling protocol overhead and complexity to myself, as > > there clearly didn't seem to be a need for one. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > ********************************** > 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 Nov 24 04:14:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00897 for ; Mon, 24 Nov 2003 04:14:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOClL-000MHS-Ch for v6ops-data@psg.com; Mon, 24 Nov 2003 09:12:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOCl8-000MGy-II for v6ops@ops.ietf.org; Mon, 24 Nov 2003 09:11:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAO9Bbo20985; Mon, 24 Nov 2003 11:11:37 +0200 Date: Mon, 24 Nov 2003 11:11:37 +0200 (EET) From: Pekka Savola To: Mohacsi Janos cc: JORDI PALET MARTINEZ , Subject: Re: I-D: Simple Configured Tunnel Setup Procedure In-Reply-To: <20031124092337.N51429@mignon.ki.iif.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 24 Nov 2003, Mohacsi Janos wrote: > On Mon, 24 Nov 2003, JORDI PALET MARTINEZ wrote: > > My feeling on this is that most of the ISPs will not accept off-band > > procedures, and TSP seems useful to avoid that. > > In my opinion if ISP wants to provide tunnel service they have to know in > advance that they will serve something - at least, in order to be able to > track the usage of service. If ISP is using RADIUS or Diameter > authentication for obtaining the customers' tunnel endpoint > addresses, they already had to have some form of agreement. It would be > very easy for the customer just ask IPv6 tunnel service via the > customer care center of ISP. Probably I would use this method to provide > IPv6 for DSL/dial-up or otherwise authenticated users. Right.. my feeling is, from the ISP point-of-view, that either they want to have a simple mechanism with little machinery, or they want to have a system that is also future-proof for the time they'll enable v6 on the access link (e.g., a connection to the databases somehow, a system which requires only a small amount of changes, if any). The one thing I am *not* aware of is, how many of the ISPs have this L2TP + PPP stuff set up already. AFAIK, L2TP is basically needed for xDSL aggregation unless you do it with ATM (that's how many do it around here, at least). I could see why an ISP would not want certain "hackish" characteristics of a solution, like proposed in STEP in the "adhoc" mode. I'm not even sure how many ISPs would be interested of the "adhoc" mode (i.e, no user registration for v6), but it seems that it seems desirable at least for certain types of 3GPP operators. -- 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 Nov 24 08:52:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08186 for ; Mon, 24 Nov 2003 08:52:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOH4J-000BCq-BQ for v6ops-data@psg.com; Mon, 24 Nov 2003 13:47:59 +0000 Received: from [213.191.128.10] (helo=mxout.iskon.hr) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AOGG9-0008RM-6n for v6ops@ops.ietf.org; Mon, 24 Nov 2003 12:56:09 +0000 Received: (qmail 14908 invoked from network); 24 Nov 2003 13:56:00 +0100 Received: from webmail1.iskon.hr (HELO net.hr) (213.191.133.144) by mxout.iskon.hr with SMTP; 24 Nov 2003 13:56:00 +0100 Received: from net.hr ([213.191.133.144]) by net.hr ; Mon, 24 Nov 2003 13:55:59 +0100 From: "Damir Bilajbegovi=?ISO-8859-2?B?5g==?=" Reply-to: bilaj@net.hr To: v6ops@ops.ietf.org Date: Mon, 24 Nov 2003 13:55:59 +0100 Subject: Router Advertisement message Message-id: <3fc1ffdf.6ee0.0@net.hr> X-User-Info: 193.81.246.12 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Rcpt-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_10,BIZ_TLD autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have got one hard question: Network is simple; only one user is on link (no neighbours). He got address via DHCP v6 (no stateless address autoconfiguration), no Mobile IPv6 and no multicasts. User is not going to check router reach ability (e.g. he is not going to check is there is router advertisement messages...) Can be such network where is no Router Advertisement? I really do not know. My bosses asked me this question and I do not know if such network can exist. Thanks in advance Damir Bilajbegovic P.S: It must be supported if user send Router Solicitation message, but such user won’t sent such message. Router reachability is going to be checked via other low layer mechanism (physics layer in OSI) In Stateless address Autoconfiguration procedures is needed, but it is not going to support- address is going to be reached via DHCPv6. I can not think of any other usage of Router Advertisement message -- Trebate bolji pristup internetu? Nazovite IskonInternet na 0800 1000 ili pogledajte http://www.iskon.biz/individualni/usluge/dialup/ From owner-v6ops@ops.ietf.org Mon Nov 24 12:31:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17667 for ; Mon, 24 Nov 2003 12:31:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOKUV-000PiO-Dp for v6ops-data@psg.com; Mon, 24 Nov 2003 17:27:15 +0000 Received: from [65.194.140.2] (helo=pi-smtp.jnpr.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOKUJ-000Phg-SA for v6ops@ops.ietf.org; Mon, 24 Nov 2003 17:27:03 +0000 Received: from alpha.jnpr.net ([172.24.18.126]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Nov 2003 12:27:02 -0500 Received: from [172.24.253.82] ([172.24.253.82]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Nov 2003 09:27:01 -0800 In-Reply-To: <3fc1ffdf.6ee0.0@net.hr> References: <3fc1ffdf.6ee0.0@net.hr> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: <6D0B3B1C-1EA3-11D8-96C9-000A958B3CBA@juniper.net> Content-Transfer-Encoding: quoted-printable Cc: v6ops@ops.ietf.org From: Jeff Doyle Subject: Re: Router Advertisement message Date: Mon, 24 Nov 2003 10:27:06 -0700 To: bilaj@net.hr X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 24 Nov 2003 17:27:01.0589 (UTC) FILETIME=[2BD54050:01C3B2B0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,BIZ_TLD autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Sure, this can be done... on Juniper and Cisco routers, anyway. I'm=20 sure other vendors can also do it. - Juniper routers do not send RAs unless explicitly configured to do so. - Cisco routers send an RA by default, but can be configured to not=20 send them ("ipv6 nd suppress-ra"). Jeff On Nov 24, 2003, at 5:55 AM, Damir Bilajbegovi=C4=87 wrote: > Hi, > I have got one hard question: > Network is simple; only one user is on link (no neighbours). He got=20 > address > via DHCP v6 (no stateless address autoconfiguration), no Mobile IPv6=20= > and no > multicasts. User is not going to check router reach ability (e.g. he=20= > is not > going to check is there is router advertisement messages...) > Can be such network where is no Router Advertisement? > I really do not know. My bosses asked me this question and I do not=20 > know if > such network can exist. > Thanks in advance > Damir Bilajbegovic > P.S: It must be supported if user send Router Solicitation message, = but > such user won’t sent such message. > Router reachability is going to be checked via other low layer=20 > mechanism > (physics layer in OSI) > In Stateless address Autoconfiguration procedures is needed, but it is=20= > not > going to support- address is going to be reached via DHCPv6. > I can not think of any other usage of Router Advertisement message > > -- > Trebate bolji pristup internetu? > Nazovite IskonInternet na 0800 1000 ili pogledajte > http://www.iskon.biz/individualni/usluge/dialup/ > > From owner-v6ops@ops.ietf.org Mon Nov 24 13:33:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20269 for ; Mon, 24 Nov 2003 13:33:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOLTX-0004PX-Ht for v6ops-data@psg.com; Mon, 24 Nov 2003 18:30:19 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOLTJ-0004ON-9A for v6ops@ops.ietf.org; Mon, 24 Nov 2003 18:30:05 +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, 24 Nov 2003 10:30:05 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Nov 2003 10:30:04 -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); Mon, 24 Nov 2003 10:30:03 -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); Mon, 24 Nov 2003 10:30:06 -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, 24 Nov 2003 10:30:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.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: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Mon, 24 Nov 2003 10:30:03 -0800 Message-ID: Thread-Topic: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt thread-index: AcOlRfWRuGDRmlj/TsieongJUJbtGANaUPwQ From: "Dave Thaler" To: Cc: X-OriginalArrivalTime: 24 Nov 2003 18:30:20.0247 (UTC) FILETIME=[04027670:01C3B2B9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This is the issue I mentioned again in Minneapolis... From draft-ietf-v6ops-mech-v2-01.txt: >=20 > 3.2.1. Static Tunnel MTU >=20 > A node using a static tunnel MTU MUST limit the size of the IPv6 > packets it tunnels to 1280 bytes i.e., treat the tunnel interface as > having a fixed interface MTU of 1280 bytes. An implementation MAY > have a configuration knob which can be used to set a larger value of > the tunnel MTU than 1280 bytes, but if so the default MUST be 1280 > bytes. A larger fixed MTU should not be configured unless it has > been administratively ensured that the decapsulator can reassemble > packets of that size. Care should be taken when manually configuring > large tunnel MTUs to only do so when the MTU of the IPv4 path to the > tunnel endpoint is large to avoid causing excessive fragmentation. Here's a scenario which may become common: A mobile node has 1) an Ethernet interface connected to a v4-only network 2) some type of IPv6 over IPv4 tunnel that follows this spec, where the IPv4 address used for encapsulation is the address=20 on interface 1. 3) an IPv6 over IPv6 tunnel to its home agent to support mobile IPv6, where the IPv6 address used for encapsulation (i.e. its care-of-address) is the IPv6 address on interface 2. With route optimization optional,=20 one common case is where the majority of communication would be over this interface (reverse tunneled). Interface 3's MTU can be no smaller than 1280, so let's assume it's 1280. If interface 2's MTU is 1280, then each 1280-byte packet being reverse-tunneled out interface 3 must undergo fragmentation after being=20 encapsulated to go out interface 2. As a result, excessive fragmentation=20 on most data packets results. If the mobile node changes the MTU of interface 2 to be some larger value, then gratuitous fragmentation can be avoided. Obviously if the IPv4 path MTU isn't large enough to support 1280 + both encapsulations you'll get fragmentation regardless. But in general the mobile node doesn't know ahead of time whether a larger MTU will cause fragmentation whereas it does know that using 1280 WILL cause fragmentation. The current text is ambiguous as to whether it would be legal or illegal for the mobile node to (say) use a larger MTU on interface 2=20 (with IPv4 DF bit clear) automatically upon being configured to be a=20 mobile node. Is the intent that this is illegal? If so, this=20 seems harmful, and it would be good to point out that excessive=20 fragmentation will occur for mobile nodes. If this is not the=20 intent, then the language should be clarified. Also on the sentence: > A larger fixed MTU should not be configured unless it has > been administratively ensured that the decapsulator can reassemble > packets of that size. RFC 2460 section 5 says: > A node must be able to accept a fragmented packet that, after > reassembly, is as large as 1500 octets. Is this statement sufficient "administrative assurance" that the=20 decapsulator can reassemble packets up to 1500 octets in size? If so, I'd propose rewording as: > A fixed MTU larger than 1500 bytes should not be configured unless it has > been administratively ensured that the decapsulator can reassemble > packets of that size. -Dave From owner-v6ops@ops.ietf.org Mon Nov 24 14:01:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21559 for ; Mon, 24 Nov 2003 14:01:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOLuo-0005tt-29 for v6ops-data@psg.com; Mon, 24 Nov 2003 18:58:30 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOLuV-0005sJ-Fv for v6ops@ops.ietf.org; Mon, 24 Nov 2003 18:58:11 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id ABD198C; Tue, 25 Nov 2003 03:58:10 +0900 (JST) To: dthaler@windows.microsoft.com Cc: v6ops@ops.ietf.org Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Mon, 24 Nov 2003 10:30:03 -0800" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031124185810.ABD198C@coconut.itojun.org> Date: Tue, 25 Nov 2003 03:58:10 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The current text is ambiguous as to whether it would be legal or > illegal for the mobile node to (say) use a larger MTU on interface 2 > (with IPv4 DF bit clear) automatically upon being configured to be a > mobile node. Is the intent that this is illegal? If so, this > seems harmful, and it would be good to point out that excessive > fragmentation will occur for mobile nodes. If this is not the > intent, then the language should be clarified. > > Also on the sentence: > > A larger fixed MTU should not be configured unless it has > > been administratively ensured that the decapsulator can reassemble > > packets of that size. > > RFC 2460 section 5 says: > > A node must be able to accept a fragmented packet that, after > > reassembly, is as large as 1500 octets. > > Is this statement sufficient "administrative assurance" that the > decapsulator can reassemble packets up to 1500 octets in size? > > If so, I'd propose rewording as: > > A fixed MTU larger than 1500 bytes should not be configured unless it > has > > been administratively ensured that the decapsulator can reassemble > > packets of that size. the above sentence encourages unmatched/unnegotiated MTU/MRU configuration. i saw problems with these in the past so i'm skeptical with the suggested change. itojun From owner-v6ops@ops.ietf.org Mon Nov 24 17:17:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06351 for ; Mon, 24 Nov 2003 17:16:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOOwn-000I9Z-Hb for v6ops-data@psg.com; Mon, 24 Nov 2003 22:12:45 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOOwa-000I8k-8l for v6ops@ops.ietf.org; Mon, 24 Nov 2003 22:12:32 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAOMCMW27777; Mon, 24 Nov 2003 14:12:22 -0800 X-mProtect: <200311242212> 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 smtpd9f2Mpj; Mon, 24 Nov 2003 14:12:20 PST Message-ID: <3FC2841E.3090209@iprg.nokia.com> Date: Mon, 24 Nov 2003 14:20:14 -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: Jun-ichiro itojun Hagino CC: dthaler@windows.microsoft.com, v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt References: <20031124185810.ABD198C@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with certain elements of what both Dave and Itojun are saying. I believe that RFC 2460, section 5 (as quoted by Dave) provides sufficient administrative assurance that an IPv6-in-IPv4 tunnel decapsulator can reassemble packets up to 1500 octets. The only problem with Dave' s proposal is that, with no prior negotiation, the encapsulator has no way of knowing whether its tunneled packets will be fragmented by the IPv4 network, which could lead to black holes and/or poor performance. Reasons: 1) certain middleboxes drop IPv4 fragments; sometimes sending only the first fragment on to the final destination 2) Fragmenting IPv4 packets causes slow-path processing in some middleboxes 3) some middleboxes may not implement IPv4 fragmentation at all Itojun seems to be suggesting that an initial negotiation is needed to determine the MRU, and while learning the true MRU would clearly be a good thing it seems to me that the 1500 byte minimum MRU indicated by Dave is a reasonable assumption, and the true MRU will most likely be discovered in the TCP MSS negotiation anyway. However, I see a clear and necessary purpose for an initial negotiation, which is to determine a lower bound on the minimum IPv4 link MTU for the links on the IPv4 path from the encapsulator to the decapsulator. Discovering the minimum IPv4 link MTU is necessary to determine the maximum IPv6 packet/fragment size that can traverse the tunnel without incurring IPv4 fragmentation. So, I believe the initial negotiation is necessary and the best mechanism to support this is sending an IPv6 Router Solicitation and getting an IPv6 Router Advertisement back. (My writings have talked about using RS/RA exhanges for MTU negotiations among other purposes for a long time now.) Reasons why using the RS/RA mechanism is best: 1. We can pad the RSs to a particular size (e.g., 512 bytes, 1280 bytes, etc.) to "plumb" the IPv4 path MTU and get an initial lower bound on the minimum IPv4 link MTU. 2. We can verify that any RAs received come from a trusted router using, e.g., SEND or some other trust mechanism so that we will not be vulnerable to learning bad MTU/MRU information from malicious nodes. I talk about this particular approach in my current document on Dynamic MTU determination for IPv6-in-IPv4 tunnels found at: http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-04.txt but the approach can be augmented by including the decapsulator's MRU in the RA messages it returns. This might require adding a new type of MRU option, such as the ones I have discussed in some of my past works. Fred ftemplin@iprg.nokia.com Jun-ichiro itojun Hagino wrote: >>The current text is ambiguous as to whether it would be legal or >>illegal for the mobile node to (say) use a larger MTU on interface 2 >>(with IPv4 DF bit clear) automatically upon being configured to be a >>mobile node. Is the intent that this is illegal? If so, this >>seems harmful, and it would be good to point out that excessive >>fragmentation will occur for mobile nodes. If this is not the >>intent, then the language should be clarified. >> >>Also on the sentence: >> >> >>>A larger fixed MTU should not be configured unless it has >>>been administratively ensured that the decapsulator can reassemble >>>packets of that size. >>> >>> >>RFC 2460 section 5 says: >> >> >>> A node must be able to accept a fragmented packet that, after >>> reassembly, is as large as 1500 octets. >>> >>> >>Is this statement sufficient "administrative assurance" that the >>decapsulator can reassemble packets up to 1500 octets in size? >> >>If so, I'd propose rewording as: >> >> >>>A fixed MTU larger than 1500 bytes should not be configured unless it >>> >>> >>has >> >> >>>been administratively ensured that the decapsulator can reassemble >>>packets of that size. >>> >>> > > the above sentence encourages unmatched/unnegotiated MTU/MRU > configuration. i saw problems with these in the past so i'm skeptical > with the suggested change. > >itojun > > > From owner-v6ops@ops.ietf.org Mon Nov 24 17:50:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08067 for ; Mon, 24 Nov 2003 17:50:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOPVA-000KFj-9I for v6ops-data@psg.com; Mon, 24 Nov 2003 22:48:16 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOPUx-000KF2-HR for v6ops@ops.ietf.org; Mon, 24 Nov 2003 22:48:03 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 100948C; Tue, 25 Nov 2003 07:48:02 +0900 (JST) To: ftemplin@iprg.nokia.com Cc: dthaler@windows.microsoft.com, v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Mon, 24 Nov 2003 14:20:14 -0800" <3FC2841E.3090209@iprg.nokia.com> References: <3FC2841E.3090209@iprg.nokia.com> X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031124224802.100948C@coconut.itojun.org> Date: Tue, 25 Nov 2003 07:48:02 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > So, I believe the initial negotiation is necessary and the best mechanism > to support this is sending an IPv6 Router Solicitation and getting an IPv6 > Router Advertisement back. (My writings have talked about using RS/RA > exhanges for MTU negotiations among other purposes for a long time now.) > Reasons why using the RS/RA mechanism is best: both end of the tunnel could be router, so it looks weird for me that a router to send RS/receive and process RA (other than the validation rule in RFC2462). itojun From owner-v6ops@ops.ietf.org Mon Nov 24 18:30:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11053 for ; Mon, 24 Nov 2003 18:30:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOQ4g-000M4x-A1 for v6ops-data@psg.com; Mon, 24 Nov 2003 23:24:58 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOQ4U-000M4F-6h for v6ops@ops.ietf.org; Mon, 24 Nov 2003 23:24:46 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAONOha30307; Mon, 24 Nov 2003 15:24:43 -0800 X-mProtect: <200311242324> 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 smtpdc1hgkm; Mon, 24 Nov 2003 15:24:42 PST Message-ID: <3FC29513.5050307@iprg.nokia.com> Date: Mon, 24 Nov 2003 15:32:35 -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: Jun-ichiro itojun Hagino CC: dthaler@windows.microsoft.com, v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt References: <3FC2841E.3090209@iprg.nokia.com> <20031124224802.100948C@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Itojun, Nodes may act as hosts on some interfaces and routers on other interfaces. They may also act in different turns as routers and hosts on the same interface. I see nothing in RFC 2461 that precludes such "hybrid" nodes from sending RSs and processing RAs. In fact, the second-to-last paragraph of RFC 2461, section 6.2.7 ("Router Advertisement Consistency") says: "Note that it is not an error for different routers to advertise different sets of prefixes. Also, some routers might leave some fields as unspecified, i.e., with the value zero, while other routers specify values. The logging of errors SHOULD be restricted to conflicting information that causes hosts to switch from one value to another with each received advertisement." So, if router A has good reason to believe that router B advertises a different set of prefixes, I see nothing unusual about A sending RSs to B (and getting RAs back from B) to discover the different prefixes. Fred ftemplin@iprg.nokia.com Jun-ichiro itojun Hagino wrote: >>So, I believe the initial negotiation is necessary and the best mechanism >>to support this is sending an IPv6 Router Solicitation and getting an IPv6 >>Router Advertisement back. (My writings have talked about using RS/RA >>exhanges for MTU negotiations among other purposes for a long time now.) >>Reasons why using the RS/RA mechanism is best: >> >> > > both end of the tunnel could be router, so it looks weird for me that > a router to send RS/receive and process RA (other than the validation > rule in RFC2462). > >itojun > > From owner-v6ops@ops.ietf.org Mon Nov 24 20:15:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15093 for ; Mon, 24 Nov 2003 20:15:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AORjj-0002Aj-Mf for v6ops-data@psg.com; Tue, 25 Nov 2003 01:11:27 +0000 Received: from [210.130.48.196] (helo=starfruit.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AORjQ-00029Q-Bq for v6ops@ops.ietf.org; Tue, 25 Nov 2003 01:11:11 +0000 Received: by starfruit.itojun.org (Postfix, from userid 1001) id 7342C199D3; Tue, 25 Nov 2003 10:10:31 +0900 (JST) To: ftemplin@iprg.nokia.com Cc: dthaler@windows.microsoft.com, v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Mon, 24 Nov 2003 15:32:35 -0800" <3FC29513.5050307@iprg.nokia.com> References: <3FC29513.5050307@iprg.nokia.com> X-Mailer: Cue version 0.6 (031029-1517/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031125011031.7342C199D3@starfruit.itojun.org> Date: Tue, 25 Nov 2003 10:10:31 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Nodes may act as hosts on some interfaces and routers on other > interfaces. They may also act in different turns as routers and hosts > on the same interface. I see nothing in RFC 2461 that precludes such > "hybrid" nodes from sending RSs and processing RAs. > > In fact, the second-to-last paragraph of RFC 2461, section 6.2.7 > ("Router Advertisement Consistency") says: > > "Note that it is not an error for different routers to advertise > different sets of prefixes. Also, some routers might leave some > fields as unspecified, i.e., with the value zero, while other routers > specify values. The logging of errors SHOULD be restricted to > conflicting information that causes hosts to switch from one value to > another with each received advertisement." > > > So, if router A has good reason to believe that router B advertises > a different set of prefixes, I see nothing unusual about A sending > RSs to B (and getting RAs back from B) to discover the different > prefixes. i guess i mentioned it in the past, if we allow routers to advertise different set of prefixes (which is the case now with RFC2462) and allow routers to autoconfigure themselves with RA, we go into bootstraap problem when router reboots. i consider autoconfiguring router is a dangerous idea, and "hybrid router" idea is too. itojun From owner-v6ops@ops.ietf.org Mon Nov 24 20:30:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15404 for ; Mon, 24 Nov 2003 20:30:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AORzJ-00038p-7o for v6ops-data@psg.com; Tue, 25 Nov 2003 01:27:33 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AORz5-00038N-W6 for v6ops@ops.ietf.org; Tue, 25 Nov 2003 01:27: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 64BBF82C2 for ; Tue, 25 Nov 2003 02:27:02 +0100 (CET) From: "Jeroen Massar" To: Subject: 2001:db8::/32 IPv6 Documentation Prefix currently not in whois Date: Tue, 25 Nov 2003 02:26:49 +0100 Organization: Unfix Message-ID: <003401c3b2f3$3cf4d060$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hi, The RFC1918 prefixes are available in whois: NetRange: 192.168.0.0 - 192.168.255.255 CIDR: 192.168.0.0/16 NetName: IANA-CBLK1 NetHandle: NET-192-168-0-0-1 Parent: NET-192-0-0-0-0 NetType: IANA Special Use NameServer: BLACKHOLE-1.IANA.ORG NameServer: BLACKHOLE-2.IANA.ORG Comment: This block is reserved for special purposes. Comment: Please see RFC 1918 for additional information. Comment: RegDate: 1994-03-15 Updated: 2002-09-16 But the documentation prefix 2001:db8::/32 isn't and falls under the 2001:c00::/23 prefix by APNIC: inet6num: 2001:0C00::/23 netname: APNIC-AP-ALLOCATED-PORTABLES2 descr: Asia Pacific Network Information Center, Pty. Ltd. descr: Regional Internet Registry for the Asia-Pacific Region descr: Level 1 - 33 Park Road. descr: PO Box 2131 descr: Milton QLD 4064 descr: Australia country: AU Shouldn't it be handy if the prefix was also recorded in whois along with at least the draft's urls or even maybe an RFC when that is done? Currently the draft is to be expired the February 25th, a well known date to me, the draft is at: http://www.ietf.org/internet-drafts/draft-huston-ipv6-documentation-prefix-01.txt APNIC also has a FAQ about it here: http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html But a plain google on 2001:db8::/32 doesn't bring these up directly so it could be confusing for people not knowing what these prefixes are, who might know that whois should contain the information. What is next for this draft btw? Is it going up for RFC? Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP8Kv2CmqKFIzPnwjEQIhbACfYR3R+0F3YnIpaSqDnjigLYiseOUAoJCK QqADwh78jwEbsuOFOSj1TZPk =YVSE -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Nov 24 20:35:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15641 for ; Mon, 24 Nov 2003 20:35:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOS4g-0003PN-KK for v6ops-data@psg.com; Tue, 25 Nov 2003 01:33:06 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOS4U-0003Oo-C5 for v6ops@ops.ietf.org; Tue, 25 Nov 2003 01:32:54 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAP1WoU19049; Mon, 24 Nov 2003 17:32:50 -0800 X-mProtect: <200311250132> 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 smtpd3sMg4I; Mon, 24 Nov 2003 17:32:48 PST Message-ID: <3FC2B319.9080707@iprg.nokia.com> Date: Mon, 24 Nov 2003 17:40: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: Jun-ichiro itojun Hagino CC: dthaler@windows.microsoft.com, v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt References: <3FC29513.5050307@iprg.nokia.com> <20031125011031.7342C199D3@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hmm - you seem to be assuming that the only reason for router A to send an RS to router B (and get an RA back) is for the purpose of autoconfiguration (i.e., RFC 2462, section 5.5.3). I'm not assuming that at all. I believe it is useful in some cases for router A to discover the prefixes being advertised by router B w/o necessarily seeking to autoconfigure addresses based on those prefixes. (RFC 2461, section 6.2.7 gives one such example.) Fred ftemplin@iprg.nokia.com Jun-ichiro itojun Hagino wrote: > i guess i mentioned it in the past, if we allow routers to advertise > different set of prefixes (which is the case now with RFC2462) and > allow routers to autoconfigure themselves with RA, we go into > bootstraap problem when router reboots. i consider autoconfiguring > router is a dangerous idea, and "hybrid router" idea is too. > >itojun > > From owner-v6ops@ops.ietf.org Mon Nov 24 21:06:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16469 for ; Mon, 24 Nov 2003 21:06:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOSY5-0005Gp-LH for v6ops-data@psg.com; Tue, 25 Nov 2003 02:03:29 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOSXs-0005GS-DE for v6ops@ops.ietf.org; Tue, 25 Nov 2003 02:03:16 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 7A6958B; Tue, 25 Nov 2003 11:03:15 +0900 (JST) To: ftemplin@iprg.nokia.com Cc: dthaler@windows.microsoft.com, v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Mon, 24 Nov 2003 17:40:41 -0800" <3FC2B319.9080707@iprg.nokia.com> References: <3FC2B319.9080707@iprg.nokia.com> X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031125020315.7A6958B@coconut.itojun.org> Date: Tue, 25 Nov 2003 11:03:15 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Hmm - you seem to be assuming that the only reason for router A > to send an RS to router B (and get an RA back) is for the purpose > of autoconfiguration (i.e., RFC 2462, section 5.5.3). I'm not > assuming that at all. > > I believe it is useful in some cases for router A to discover the prefixes > being advertised by router B w/o necessarily seeking to autoconfigure > addresses based on those prefixes. (RFC 2461, section 6.2.7 gives one > such example.) if - A advertises P1/64 and P2/64, and has P1:id1 and P2:id2 as address - B advertises P3/64, and has P3:id3 as address onto the same ethernet broadcast domain, A would think that P3::/64 as off-link, and sends packets to P3:id3 to default route (instead of performing NS/NA). we can cook up more complex example like this, but i wouldn't bother. we really need simplification here. i personally would like to see RFC2461 section 6.2.7 to be updated to require routers to advertise consistent prefix information. we can consider it an operational issue (instead of implementation issue) so backward compatibility should not matter that much. itojun From owner-v6ops@ops.ietf.org Tue Nov 25 04:17:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09617 for ; Tue, 25 Nov 2003 04:17:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOZFZ-0000TW-Pi for v6ops-data@psg.com; Tue, 25 Nov 2003 09:12:49 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOZCf-0000Gy-2z for v6ops@ops.ietf.org; Tue, 25 Nov 2003 09:09:49 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 10:07:10 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAP99Y7k014714; Tue, 25 Nov 2003 10:09:35 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 09:09:46 +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: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Tue, 25 Nov 2003 09:09:45 -0000 Message-ID: Thread-Topic: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Thread-Index: AcOlRfWRuGDRmlj/TsieongJUJbtGANaUPwQACDvBOA= From: "Pascal Thubert (pthubert)" To: "Dave Thaler" , Cc: X-OriginalArrivalTime: 25 Nov 2003 09:09:46.0476 (UTC) FILETIME=[DF220AC0:01C3B333] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dave Thaler > Sent: lundi 24 novembre 2003 19:30 > To: Erik.Nordmark@Sun.COM > Cc: v6ops@ops.ietf.org > Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt >=20 > This is the issue I mentioned again in Minneapolis... >=20 > From draft-ietf-v6ops-mech-v2-01.txt: > > > > 3.2.1. Static Tunnel MTU > > > > A node using a static tunnel MTU MUST limit the size of the IPv6 > > packets it tunnels to 1280 bytes i.e., treat the tunnel interface > as > > having a fixed interface MTU of 1280 bytes. An implementation MAY > > have a configuration knob which can be used to set a larger value > of > > the tunnel MTU than 1280 bytes, but if so the default MUST be 1280 > > bytes. A larger fixed MTU should not be configured unless it has > > been administratively ensured that the decapsulator can reassemble > > packets of that size. Care should be taken when manually > configuring > > large tunnel MTUs to only do so when the MTU of the IPv4 path to > the > > tunnel endpoint is large to avoid causing excessive fragmentation. >=20 > Here's a scenario which may become common: >=20 > A mobile node has > 1) an Ethernet interface connected to a v4-only network > 2) some type of IPv6 over IPv4 tunnel that follows this spec, > where the IPv4 address used for encapsulation is the address > on interface 1. > 3) an IPv6 over IPv6 tunnel to its home agent to support mobile IPv6, > where the IPv6 address used for encapsulation (i.e. its > care-of-address) > is the IPv6 address on interface 2. With route optimization > optional, > one common case is where the majority of communication would be over >=20 > this interface (reverse tunneled). >=20 Hi Dave: On the side of this discussion, note that it would be beneficial to MIPv6 to consider IPv4 traversal in order to save the intermediate tunnel. It's very unclear where this discussion should take place. I proposed to Nemo a year ago, and the WG said it was a MIPv6 problem. I asked P2P to some MIPv6 members, who answered to me it was more likely to be a v6Ops problem. What do you think? Pascal From owner-v6ops@ops.ietf.org Tue Nov 25 04:30:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09843 for ; Tue, 25 Nov 2003 04:30:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOZTL-0001BE-8f for v6ops-data@psg.com; Tue, 25 Nov 2003 09:27:03 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOZSr-00019c-RK for v6ops@ops.ietf.org; Tue, 25 Nov 2003 09:26:33 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 10:23:53 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAP9QJOK019466; Tue, 25 Nov 2003 10:26:20 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 09:26:29 +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: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Date: Tue, 25 Nov 2003 09:26:28 -0000 Message-ID: Thread-Topic: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt Thread-Index: AcOy8dINHQl3vBgzTzqHk3DTtAADtwAQcLYw From: "Pascal Thubert (pthubert)" To: "Jun-ichiro itojun Hagino" , Cc: , X-OriginalArrivalTime: 25 Nov 2003 09:26:29.0361 (UTC) FILETIME=[34E62610:01C3B336] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Itojun: The example that Dave proposed, a MIPv6 (Nemo) router, has exactly that behavior when not at Home: It acts as a Host at ND level on the roaming interface to discover an attachment router and to autoconf a CareOf.=20 This gives you at least one case where it's an interesting thing to do. Fred: in our initial implementation, we've been through this but tried to save in the IPv6inv4 tunnel, using some automatic tunneling based on 6to4. In that case, there's no tunnel to send RS over. What we did fits with what Dave suggested (if I understand correctly). Rely on a correct IPv4 or IPv6 administrative MTU, and send PMTU ICMPs back based on RFC 2473. For more details about how that works (but nothing much about MTU since its RFC 2473) you may want to have a look at Doors (but I know Pekka won't). Goes through all sorts of PAT/NATs. http://www.ietf.org/internet-drafts/draft-thubert-nemo-ipv4-traversal-01 .txt Pascal > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Jun-ichiro > itojun Hagino > Sent: mardi 25 novembre 2003 02:11 > To: ftemplin@iprg.nokia.com > Cc: dthaler@windows.microsoft.com; v6ops@ops.ietf.org > Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt >=20 > > Nodes may act as hosts on some interfaces and routers on other > > interfaces. They may also act in different turns as routers and hosts > > on the same interface. I see nothing in RFC 2461 that precludes such > > "hybrid" nodes from sending RSs and processing RAs. > > > > In fact, the second-to-last paragraph of RFC 2461, section 6.2.7 > > ("Router Advertisement Consistency") says: > > > > "Note that it is not an error for different routers to advertise > > different sets of prefixes. Also, some routers might leave some > > fields as unspecified, i.e., with the value zero, while other routers > > specify values. The logging of errors SHOULD be restricted to > > conflicting information that causes hosts to switch from one value to > > another with each received advertisement." > > > > > > So, if router A has good reason to believe that router B advertises > > a different set of prefixes, I see nothing unusual about A sending > > RSs to B (and getting RAs back from B) to discover the different > > prefixes. >=20 > i guess i mentioned it in the past, if we allow routers to advertise > different set of prefixes (which is the case now with RFC2462) and > allow routers to autoconfigure themselves with RA, we go into > bootstraap problem when router reboots. i consider autoconfiguring > router is a dangerous idea, and "hybrid router" idea is too. >=20 > itojun From owner-v6ops@ops.ietf.org Tue Nov 25 08:02:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16244 for ; Tue, 25 Nov 2003 08:02:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOclT-000CTU-FY for v6ops-data@psg.com; Tue, 25 Nov 2003 12:57:59 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOclH-000CT2-5U for v6ops@ops.ietf.org; Tue, 25 Nov 2003 12:57:47 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAPCvhI31847; Tue, 25 Nov 2003 04:57:43 -0800 X-mProtect: <200311251257> 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 smtpdWQ8NB1; Tue, 25 Nov 2003 04:57:41 PST Message-ID: <3FC353A2.2030807@iprg.nokia.com> Date: Tue, 25 Nov 2003 05:05:38 -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: Jun-ichiro itojun Hagino CC: dthaler@windows.microsoft.com, v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt References: <3FC2B319.9080707@iprg.nokia.com> <20031125020315.7A6958B@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Itojun, I think I understand your concern now. There will certainly be "ROUTERS" that send "ROUTER ADVERTISEMENTS", and they will contain information about attached *prefixes* and in many cases autoconfig parameters. But, I'm not talking about those; I'm talking about "routers" that send "router advertisements" that contain information about attached *addresses* (locators?) and in most cases no autoconfig or prefix information at all. So, you are concerned with what would happen if I get a "ROUTER ADVERTISEMENT" when I was instead expecting to receive a "router advertisement" - correct? I think a good way to avoid the confusion would be to use the mechanisms specified in: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt In fact, let's see that this gets pushed through to standard asap. Thanks - Fred ftemplin@iprg.nokia.com Jun-ichiro itojun Hagino wrote: >>Hmm - you seem to be assuming that the only reason for router A >>to send an RS to router B (and get an RA back) is for the purpose >>of autoconfiguration (i.e., RFC 2462, section 5.5.3). I'm not >>assuming that at all. >> >>I believe it is useful in some cases for router A to discover the prefixes >>being advertised by router B w/o necessarily seeking to autoconfigure >>addresses based on those prefixes. (RFC 2461, section 6.2.7 gives one >>such example.) >> >> > > if > - A advertises P1/64 and P2/64, and has P1:id1 and P2:id2 as address > - B advertises P3/64, and has P3:id3 as address > onto the same ethernet broadcast domain, A would think that P3::/64 > as off-link, and sends packets to P3:id3 to default route > (instead of performing NS/NA). we can cook up more complex example > like this, but i wouldn't bother. we really need simplification here. > > i personally would like to see RFC2461 section 6.2.7 to be updated to > require routers to advertise consistent prefix information. we can > consider it an operational issue (instead of implementation issue) so > backward compatibility should not matter that much. > >itojun > > From owner-v6ops@ops.ietf.org Tue Nov 25 08:55:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17522 for ; Tue, 25 Nov 2003 08:55:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOdbj-000Frb-29 for v6ops-data@psg.com; Tue, 25 Nov 2003 13:51:59 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOdbX-000Fqm-31 for v6ops@ops.ietf.org; Tue, 25 Nov 2003 13:51:47 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPDpjA13636 for ; Tue, 25 Nov 2003 15:51:45 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 15:51:45 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 15:51:45 +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: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Tue, 25 Nov 2003 15:51:44 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D019549AF6A@esebe024.ntc.nokia.com> Thread-Topic: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Thread-Index: AcOuAjYDq0oia4WLScOaEPnoIQw5bQFWFjDw From: To: , Cc: , X-OriginalArrivalTime: 25 Nov 2003 13:51:45.0149 (UTC) FILETIME=[4372AAD0:01C3B35B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi everybody, (taking the chair hat off) >=20 > Do you mean: >=20 > [Juha W.] > > Furthermore, I personally don't believe that configured tunnels make > > a feasible solution for this specific problem (even though they > > provide a good solution for some other scenarios). You must remember > > the high number of UEs and dynamic addressing. And any extra > > configuration effort isn't nice for the users. If you make the extra > > configurations using SMS (like configuring APN settings for > > different applications), that means one SMS more. The point is: =20 > > IPv6 should be as easy as possible. >=20 > There are some assumptions in this paragraph and few=20 > technical facts. =20 > This needs more elaboration. >=20 > E.g.: > - why exactly would there have to be more than 1 SMS? The=20 > address is=20 > just 32 bits, 4 characters (out of 160 or so :-). Could be easily=20 > compressed in one message. >=20 > - why exactly should there be any extra config for the user? It=20 > could be completely transparent to them. Pekka really, this will not work. This is not what people want and this = is not what people do. The user wants to use the service and not to = spend her/his time configuring the mobile. There are quite some things = that have to be configured already and the last thing the user wants is = to configure the IPv6 tunnel every time the PDP Context is set up.=20 This is not going to happen! >=20 > > > Would a modification be required? I'm not so sure of=20 > that. There > > > must be some mechanisms to retrieve this information, either=20 > > > e.g. SNMP > > > query or access to a database, or something. That=20 > should be pretty=20 > > > much all you need. > >=20 > > That makes certain assumptions about implementations. > > Seriously, it is not feasible. Also I can't understand why you think > > digging info from a database is simpler than just using ISATAP. > > Anyway, enough emails on this subject for me since we're not getting > > anywhere. >=20 > I'd like to hear more of these assumptions. The configuration overhead is too much - period.=20 >=20 > That avoids getting the other features of ISATAP we don't need here,=20 > and provide a simpler architecture. >=20 > I do not believe this possibility has been analyzed well enough to > understand it's possibilities (or potential flaws). I think this thread and all the other threads seem to point to the fact = that we have to start dicussing solutions instead of scenarios. We know = the scenario now - we may need tunneling. If we could now wrap up ISATAP = in that way that it fulfills the requiremets given by the = scenarios/analysis. Right? Cheers, Jonne. >=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 Tue Nov 25 08:59:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17689 for ; Tue, 25 Nov 2003 08:59:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOdgQ-000G9Y-GU for v6ops-data@psg.com; Tue, 25 Nov 2003 13:56:50 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOdgB-000G8T-9o for v6ops@ops.ietf.org; Tue, 25 Nov 2003 13:56:35 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAPDu2213322; Tue, 25 Nov 2003 05:56:02 -0800 X-mProtect: <200311251356> 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 smtpdzdwO4F; Tue, 25 Nov 2003 05:56:01 PST Message-ID: <3FC3614F.8080100@iprg.nokia.com> Date: Tue, 25 Nov 2003 06:03:59 -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: ipv6@ietf.org, v6ops@ops.ietf.org Subject: "ROUTERS" vs. "routers" References: <3FC2B319.9080707@iprg.nokia.com> <20031125020315.7A6958B@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread took on an interesting twist that I felt warranted a new subject heading. RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS"). "ROUTERS" typically advertise autoconfig parameters and prefixes from their attached networks. Hosts use them to reach off-link nodes via default or more-specific routes. But, a new breed of routers (i.e., "routers") is emerging from paradigms such as Mobile Ad-hoc Networks. "routers" typically advertise host routes only (aka, "addresses" or "locators") and no prefix or autoconfig parameters at all. I talked about this dichotomy several years ago in my writings in the MANET wg and in some of the contract work I did at SRI International. The dichotomy is also discussed in documents such as the "global6" work by Charles Perkins and his colleagues. But, the notion of "routers" has really been around for decades and is quite well known in some circles. In the MANET paradigm, "routers" often have only a single network interface which may be used for multi-hop forwarding within a flat addressing space (i.e., using host routes and redirects to steer the multi-hop forwarding decisions) while "ROUTERS" are used to reach other off-link networks. But, the same paradigm can be applied to the emerging global IPv6 Internet. In particular, I believe we will soon see an emerging paradigm for IPv6 in which most (if not all) nodes will be "routers" and a smaller subset of the nodes will be "ROUTERS". A node can qualify as a "router" IFF it has the proper credentials so that other nodes can guard against redirection attacks. The NOID approach specifies a method by which "routers" may attain the proper credentials (it also supports site-multihoming as an added attraction): http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt "routers" will also need a means for distributing host routes w/o including the normal information traditional "ROUTERS" advertise. The "Default Router Preferences, More-Specific Routers and Load Sharing" approach specifies the necessary mechanisms: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt So, what is missing? It would be desireable for a node sending an RFC 2461 Router Solicitation to be able to specify whether "ROUTER" or "router" information (or both) was being solicited. This function can be accommodated by either providing a codepoint (i.e., 1-2 bits) in the existing Router Solicitation message or a new IPv6 Neighbor Discovery message type (call it a "Type II Router Solicitaiton" for lack of a better name.) Perhaps this isn't even needed; I would be happy to let others comment. So, where does the "all nodes are routers" model lead us? To an IPv6 Internet with end-to-end security, site multihoming, multi-hop forwarding capability, and a restoration of the end-to-end principles. I think we need to get on board with this, folks... Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Nov 25 08:59:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17714 for ; Tue, 25 Nov 2003 08:59:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOdhC-000GCk-82 for v6ops-data@psg.com; Tue, 25 Nov 2003 13:57:38 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOdgs-000GBO-13 for v6ops@ops.ietf.org; Tue, 25 Nov 2003 13:57:18 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPDvG604125 for ; Tue, 25 Nov 2003 15:57:16 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 15:57:16 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 15:57:15 +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: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP] Date: Tue, 25 Nov 2003 15:57:14 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D019549AF6B@esebe024.ntc.nokia.com> Thread-Topic: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP] Thread-Index: AcOumk6aMtDdBydnQ7O/uuxIL0OXrQEwTr+Q From: To: , Cc: X-OriginalArrivalTime: 25 Nov 2003 13:57:15.0157 (UTC) FILETIME=[0825E450:01C3B35C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, (chair hat on) I believe NAT-PT is already standards track RFC. I'm at least not ready = to deprecate it based on the information we have now. I believe the = NAT-PT applicability work should give us a direction with the NAT-PT = spec. Neutrally, we have three possibilities: 1) Keep current NAT-PT specs and get it draft standard if possible 2) Update the NAT-PT specs considerably and recycle it as PS 3) Move it to historic I'm not sure which way to go at this point. I hope the NAT-PT = applicability work can help us on that. Cheers, Jonne. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Pekka Savola > Sent: 19 November, 2003 14:35 > To: Jasminko Mulahusic > Cc: v6ops@ops.ietf.org > Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT=20 > Applicabilty > fo r 3GPP] >=20 >=20 > On Tue, 18 Nov 2003, Jasminko Mulahusic wrote: > > > As you pointed out the 3gpp-analysis draft addresses these > > > issues and I have no problems with that. It points to the > > > work to be done in SIPPING and says that such a solution > > > could reuse parts of NAT-PT. > >=20 > > i have a question to the wg chairs and/or ad:s: > >=20 > > do you plan to deprecate nat-pt before the work=20 > (ims-translator) has=20 > > been finished in the sipping wg? >=20 > I believe it's too early to plan either deprecating or embracing > NAT-PT. >=20 > HTH.. >=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 Tue Nov 25 09:33:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18940 for ; Tue, 25 Nov 2003 09:33:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOeBh-000IGg-0S for v6ops-data@psg.com; Tue, 25 Nov 2003 14:29:09 +0000 Received: from [158.38.62.77] (helo=smistad.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOeBD-000IFT-Vw for v6ops@ops.ietf.org; Tue, 25 Nov 2003 14:28:40 +0000 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id 182E220F32; Tue, 25 Nov 2003 15:28:39 +0100 (CET) Date: Tue, 25 Nov 2003 15:28:39 +0100 (CET) Message-Id: <20031125.152839.01257123.he@uninett.no> To: ftemplin@iprg.nokia.com Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" From: Havard Eidnes In-Reply-To: <3FC3614F.8080100@iprg.nokia.com> References: <3FC2B319.9080707@iprg.nokia.com> <20031125020315.7A6958B@coconut.itojun.org> <3FC3614F.8080100@iprg.nokia.com> X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hm, I hope I'm not the only one who find the choice of wording to be unfortunate. From=20the 10km-high perspective, there should be other and more fundamental distinguishing marks than the prefix length of advertisments or more general protocol behaviour to draw the line between what has traditionally been named "hosts" and "routers". I'll therefore give some pushback on introducing a subtle for-ipv6-only distinction between "ROUTERS" and "routers". Regards, - H=E5vard From owner-v6ops@ops.ietf.org Tue Nov 25 09:55:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19833 for ; Tue, 25 Nov 2003 09:55:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOeYj-000Ja6-55 for v6ops-data@psg.com; Tue, 25 Nov 2003 14:52:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOeYE-000JXT-SI for v6ops@ops.ietf.org; Tue, 25 Nov 2003 14:52:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAPEqNp17821; Tue, 25 Nov 2003 16:52:23 +0200 Date: Tue, 25 Nov 2003 16:52:23 +0200 (EET) From: Pekka Savola To: Jonne.Soininen@nokia.com cc: karim.el-malki@ericsson.com, , Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <2D3EB51EAED985419D54AB340A9D019549AF6A@esebe024.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 25 Nov 2003 Jonne.Soininen@nokia.com wrote: > > E.g.: > > - why exactly would there have to be more than 1 SMS? The > > address is > > just 32 bits, 4 characters (out of 160 or so :-). Could be easily > > compressed in one message. > > > > - why exactly should there be any extra config for the user? It > > could be completely transparent to them. > > Pekka really, this will not work. This is not what people want and > this is not what people do. The user wants to use the service and > not to spend her/his time configuring the mobile. There are quite > some things that have to be configured already and the last thing > the user wants is to configure the IPv6 tunnel every time the PDP > Context is set up. This is not going to happen! Again, you assume that the user actually has to configure anything at all. That doesn't need to be the case, I think. (At least, I haven't heard technical arguments why it couldn't be.) Who said that the user has to configure anything itself? The user receives a magical SMS message from his operator, the tunnel gets automatically activated, and we're done? Or does the user manually configure the APN as well, based on the SMS messages it sends/receives? > > > That makes certain assumptions about implementations. > > > Seriously, it is not feasible. Also I can't understand why you think > > > digging info from a database is simpler than just using ISATAP. > > > Anyway, enough emails on this subject for me since we're not getting > > > anywhere. > > > > I'd like to hear more of these assumptions. > > The configuration overhead is too much - period. Sounds like a circular argument without justification. > > That avoids getting the other features of ISATAP we don't need here, > > and provide a simpler architecture. > > > > I do not believe this possibility has been analyzed well enough to > > understand it's possibilities (or potential flaws). > > I think this thread and all the other threads seem to point to the > fact that we have to start dicussing solutions instead of scenarios. > We know the scenario now - we may need tunneling. If we could now > wrap up ISATAP in that way that it fulfills the requiremets given by > the scenarios/analysis. Right? We know that there is a scenario where tunneling is desirable in certain cases, yes. However, I'm not sure if we know the requirements of the scenario, or the scenario itself, well enough yet (see the points above why exactly configuring is bad, what exactly would need to be configured, etc.). Of course, talking about solutions might be OK as well, but only if one keeps the scenario in mind. I don't know what you mean by the ISATAP reference. Clearly, we could take it, and apply it in this specific scenario, and I think it would work, at least to some definition of "work". That doesn't mean it's the right thing to do, of course. Is it the *right* tool for the job? For example, a proof of concept procedure was introduced in draft-savola-v6ops-conftun-setup-01.txt; it would probably solve the problem in a much simpler and easier way; it's basically just expanding the couple of bullet points above about configured tunneling set-up methods. In the case of 3GPP, only proto-41 would be necessary -- basically just configured tunneling at the UE, and some tricks at the 3GPP operator side, depending on the mode in which it wishes to operate. -- 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 Nov 25 10:08:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20852 for ; Tue, 25 Nov 2003 10:08:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOelS-000KOo-JE for v6ops-data@psg.com; Tue, 25 Nov 2003 15:06:06 +0000 Received: from [66.218.79.80] (helo=web80510.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AOelC-000KNk-Ss for v6ops@ops.ietf.org; Tue, 25 Nov 2003 15:05:50 +0000 Message-ID: <20031125150550.46577.qmail@web80510.mail.yahoo.com> Received: from [63.197.18.101] by web80510.mail.yahoo.com via HTTP; Tue, 25 Nov 2003 07:05:50 PST Date: Tue, 25 Nov 2003 07:05:50 -0800 (PST) From: Fred Templin Subject: Re: "ROUTERS" vs. "routers" To: ipv6@ietf.org, v6ops@ops.ietf.org Cc: ftemplin@iprg.nokia.com, osprey67@yahoo.com In-Reply-To: <3FC3614F.8080100@iprg.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-886304300-1069772750=:45636" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-886304300-1069772750=:45636 Content-Type: text/plain; charset=us-ascii Whoops! I got just a tad bit overboard in my message and need to add some balance. There will still be *plenty* of simple hosts in the new paradigm that neither need nor want to be considered as "routers" or "ROUTERS". They will include things like my home printer, my home security system, my car's speedomeer, etc. These will be good candidates for an IPv6 local addressing scheme of some sort. Fred Templin osprey67@yahoo.com ftemplin@iprg.nokia.com Fred Templin wrote: The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread took on an interesting twist that I felt warranted a new subject heading. RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS"). "ROUTERS" typically advertise autoconfig parameters and prefixes from their attached networks. Hosts use them to reach off-link nodes via default or more-specific routes. But, a new breed of routers (i.e., "routers") is emerging from paradigms such as Mobile Ad-hoc Networks. "routers" typically advertise host routes only (aka, "addresses" or "locators") and no prefix or autoconfig parameters at all. I talked about this dichotomy several years ago in my writings in the MANET wg and in some of the contract work I did at SRI International. The dichotomy is also discussed in documents such as the "global6" work by Charles Perkins and his colleagues. But, the notion of "routers" has really been around for decades and is quite well known in some circles. In the MANET paradigm, "routers" often have only a single network interface which may be used for multi-hop forwarding within a flat addressing space (i.e., using host routes and redirects to steer the multi-hop forwarding decisions) while "ROUTERS" are used to reach other off-link networks. But, the same paradigm can be applied to the emerging global IPv6 Internet. In particular, I believe we will soon see an emerging paradigm for IPv6 in which most (if not all) nodes will be "routers" and a smaller subset of the nodes will be "ROUTERS". A node can qualify as a "router" IFF it has the proper credentials so that other nodes can guard against redirection attacks. The NOID approach specifies a method by which "routers" may attain the proper credentials (it also supports site-multihoming as an added attraction): http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt "routers" will also need a means for distributing host routes w/o including the normal information traditional "ROUTERS" advertise. The "Default Router Preferences, More-Specific Routers and Load Sharing" approach specifies the necessary mechanisms: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt So, what is missing? It would be desireable for a node sending an RFC 2461 Router Solicitation to be able to specify whether "ROUTER" or "router" information (or both) was being solicited. This function can be accommodated by either providing a codepoint (i.e., 1-2 bits) in the existing Router Solicitation message or a new IPv6 Neighbor Discovery message type (call it a "Type II Router Solicitaiton" for lack of a better name.) Perhaps this isn't even needed; I would be happy to let others comment. So, where does the "all nodes are routers" model lead us? To an IPv6 Internet with end-to-end security, site multihoming, multi-hop forwarding capability, and a restoration of the end-to-end principles. I think we need to get on board with this, folks... Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-886304300-1069772750=:45636 Content-Type: text/html; charset=us-ascii
Whoops! I got just a tad bit overboard in my message and need to
add some balance. There will still be *plenty* of simple hosts in the
new paradigm that neither need nor want to be considered as "routers"
or "ROUTERS". They will include things like my home printer, my
home security system, my car's speedomeer, etc. These will be
good candidates for an IPv6 local addressing scheme of some sort.
 
Fred Templin
 

Fred Templin <ftemplin@iprg.nokia.com> wrote:
The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread
took on an interesting twist that I felt warranted a new subject heading.

RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS").
"ROUTERS" typically advertise autoconfig parameters and prefixes from
their attached networks. Hosts use them to reach off-link nodes via default
or more-specific routes. But, a new breed of routers (i.e., "routers") is
emerging from paradigms such as Mobile Ad-hoc Networks. "routers"
typically advertise host routes only (aka, "addresses" or "locators") and
no prefix or autoconfig parameters at all.

I talked about this dichotomy several years ago in my writings
in the MANET wg and in some of the contract work I did at SRI
International. The dichotomy is also discussed in documents such
as the "global6" work by Charles Perkins and his colleagues. But,
the notion of "routers" has really been around for decades and is
quite well known in some circles.

In the MANET paradigm, "routers" often have only a single network
interface which may be used for multi-hop forwarding within a flat
addressing space (i.e., using host routes and redirects to steer the
multi-hop forwarding decisions) while "ROUTERS" are used to reach
other off-link networks. But, the same paradigm can be applied to the
emerging global IPv6 Internet.

In particular, I believe we will soon see an emerging paradigm for
IPv6 in which most (if not all) nodes will be "routers" and a smaller
subset of the nodes will be "ROUTERS". A node can qualify as a
"router" IFF it has the proper credentials so that other nodes can
guard against redirection attacks. The NOID approach specifies
a method by which "routers" may attain the proper credentials
(it also supports site-multihoming as an added attraction):

http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt

"routers" will also need a means for distributing host routes w/o
including the normal information traditional "ROUTERS" advertise.
The "Default Router Preferences, More-Specific Routers and Load
Sharing" approach specifies the necessary mechanisms:


http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt

So, what is missing? It would be desireable for a node sending
an RFC 2461 Router Solicitation to be able to specify whether
"ROUTER" or "router" information (or both) was being solicited.
This function can be accommodated by either providing a codepoint
(i.e., 1-2 bits) in the existing Router Solicitation message or a new
IPv6 Neighbor Discovery message type (call it a "Type II Router
Solicitaiton" for lack of a better name.) Perhaps this isn't even
needed; I would be happy to let others comment.

So, where does the "all nodes are routers" model lead us? To an
IPv6 Internet with end-to-end security, site multihoming, multi-hop
forwarding capability, and a restoration of the end-to-end principles.

I think we need to get on board with this, folks...

Fred
ftemplin@iprg.nokia.com






--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-886304300-1069772750=:45636-- From owner-v6ops@ops.ietf.org Tue Nov 25 10:25:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22482 for ; Tue, 25 Nov 2003 10:25:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOf1o-000LeV-Lm for v6ops-data@psg.com; Tue, 25 Nov 2003 15:23:00 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOf1b-000LdM-LQ for v6ops@ops.ietf.org; Tue, 25 Nov 2003 15:22:47 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 16:20:08 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAPFMXUV005295; Tue, 25 Nov 2003 16:22:34 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 15:22:45 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: "ROUTERS" vs. "routers" Date: Tue, 25 Nov 2003 15:22:43 -0000 Message-ID: Thread-Topic: "ROUTERS" vs. "routers" Thread-Index: AcOzYMqq/McgpH1dQmy1+QKMxpDFnwAAz07A From: "Pascal Thubert (pthubert)" To: "Havard Eidnes" , Cc: , X-OriginalArrivalTime: 25 Nov 2003 15:22:45.0382 (UTC) FILETIME=[FA001A60:01C3B367] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Havard I believe it's worth opening the Pandora's box. I agree with Fred that = things and usages have changed. On top of the MANET based examples that Fred proposed, I have in mind an = other 'Half and half' case. That's the concept on "Network in node" = which is a basically a host with a network attached to it or inside it. = Examples: - A traffic dispatcher - A PC with multiple Network addressable entities such as storage media - A PC with multiple users or applications, each one with a addressable = with different IP address from an "inner" network - A mobile router (still shows as a Host on the roaming interface) = acting as a bridge when at home - A ND proxy that is not exposed as a router, eg a Home Network behind a = Home Gateway. I'm not sure if in Fred's term I'm introducing "HOST" vs "host", but it = appears that the old paradigm of routers vs hosts seems limited for some = applications that IPv6 enables. Pascal > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of = Havard Eidnes > Sent: mardi 25 novembre 2003 15:29 > To: ftemplin@iprg.nokia.com > Cc: ipv6@ietf.org; v6ops@ops.ietf.org > Subject: Re: "ROUTERS" vs. "routers" >=20 > Hm, >=20 > I hope I'm not the only one who find the choice of wording to be > unfortunate. >=20 > From the 10km-high perspective, there should be other and more > fundamental distinguishing marks than the prefix length of > advertisments or more general protocol behaviour to draw the line > between what has traditionally been named "hosts" and "routers". >=20 > I'll therefore give some pushback on introducing a subtle > for-ipv6-only distinction between "ROUTERS" and "routers". >=20 > Regards, >=20 > - H=E5vard >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Tue Nov 25 10:47:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24103 for ; Tue, 25 Nov 2003 10:47:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOfLq-000MyC-5U for v6ops-data@psg.com; Tue, 25 Nov 2003 15:43:42 +0000 Received: from [158.38.62.77] (helo=smistad.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOfLd-000MxQ-IS for v6ops@ops.ietf.org; Tue, 25 Nov 2003 15:43:29 +0000 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id B0B5220F32; Tue, 25 Nov 2003 16:43:28 +0100 (CET) Date: Tue, 25 Nov 2003 16:43:28 +0100 (CET) Message-Id: <20031125.164328.95799586.he@uninett.no> To: pthubert@cisco.com Cc: ftemplin@iprg.nokia.com, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" From: Havard Eidnes In-Reply-To: References: X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hm, maybe I was unclear -- let me try to clarify. The distinction between routers and hosts and the criteria to separate between them is one which I perceive as having been well established in Internet technology for a Long Time. I think we should think twice before obfuscating this distinction, or try to sneak in something which is claimed to be somewhere between them. I'm therefore reacting negatively to the attempt at abusing the "router" term by introducing new and subtle meaning with a distinction between "ROUTER" and "router". Choose a different word if you insist on pursuing this, please! I've heard in other discussions the distinction between hosts implementing a "strong" versus a "weak" model, typically used as a distinguishing additional criteria when hosts are attached to multiple networks and/or have multiple addresses. However, my local RFC repository does not have any mention of that term. I wonder if this direction is something which could be pursued. Regards, - H=E5vard From owner-v6ops@ops.ietf.org Tue Nov 25 11:05:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24757 for ; Tue, 25 Nov 2003 11:05:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOfdV-000O6U-IA for v6ops-data@psg.com; Tue, 25 Nov 2003 16:01:57 +0000 Received: from [66.218.79.83] (helo=web80513.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AOfdJ-000O5H-Ax for v6ops@ops.ietf.org; Tue, 25 Nov 2003 16:01:45 +0000 Message-ID: <20031125160144.60580.qmail@web80513.mail.yahoo.com> Received: from [63.197.18.101] by web80513.mail.yahoo.com via HTTP; Tue, 25 Nov 2003 08:01:44 PST Date: Tue, 25 Nov 2003 08:01:44 -0800 (PST) From: Fred Templin Subject: Re: "ROUTERS" vs. "routers" To: Havard Eidnes , pthubert@cisco.com Cc: ftemplin@iprg.nokia.com, ipv6@ietf.org, v6ops@ops.ietf.org In-Reply-To: <20031125.164328.95799586.he@uninett.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-197517590-1069776104=:60318" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) 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.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-197517590-1069776104=:60318 Content-Type: text/plain; charset=us-ascii The goal of my message is to get a message out; not to push new terminology. See RFC 1122 for a discussion of the "strong" vs "weak" ES models. Thanks - Fred osprey67@yahoo.com ftemplin@iprg.nokia.com Havard Eidnes wrote: I've heard in other discussions the distinction between hosts implementing a "strong" versus a "weak" model, typically used as a distinguishing additional criteria when hosts are attached to multiple networks and/or have multiple addresses. However, my local RFC repository does not have any mention of that term. I wonder if this direction is something which could be pursued. --0-197517590-1069776104=:60318 Content-Type: text/html; charset=us-ascii
The goal of my message is to get a message out; not to
push new terminology. See RFC 1122 for a discussion
of the "strong" vs "weak" ES models.
 
Thanks - Fred
 
Havard Eidnes <he@uninett.no> wrote:

I've heard in other discussions the distinction between hosts
implementing a "strong" versus a "weak" model, typically used as a
distinguishing additional criteria when hosts are attached to multiple
networks and/or have multiple addresses. However, my local RFC
repository does not have any mention of that term. I wonder if this
direction is something which could be pursued.

--0-197517590-1069776104=:60318-- From owner-v6ops@ops.ietf.org Tue Nov 25 12:12:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27773 for ; Tue, 25 Nov 2003 12:12:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOgfZ-0001ni-VP for v6ops-data@psg.com; Tue, 25 Nov 2003 17:08:09 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOgfN-0001n5-HN for v6ops@ops.ietf.org; Tue, 25 Nov 2003 17:07:57 +0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAPH7eUP029059; Tue, 25 Nov 2003 09:07:41 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAPH7ebx006841; Tue, 25 Nov 2003 12:07:40 -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 hAPH7eS4010290; Tue, 25 Nov 2003 12:07:40 -0500 (EST) Message-Id: <200311251707.hAPH7eS4010290@thunk.east.sun.com> From: Bill Sommerfeld To: itojun@itojun.org (Jun-ichiro itojun Hagino) cc: ftemplin@iprg.nokia.com, dthaler@windows.microsoft.com, v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Tue, 25 Nov 2003 10:10:31 +0900." <20031125011031.7342C199D3@starfruit.itojun.org> Reply-to: sommerfeld@east.sun.com Date: Tue, 25 Nov 2003 12:07:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > So, if router A has good reason to believe that router B advertises > > a different set of prefixes, I see nothing unusual about A sending > > RSs to B (and getting RAs back from B) to discover the different > > prefixes. > > i guess i mentioned it in the past, if we allow routers to advertise > different set of prefixes (which is the case now with RFC2462) and > allow routers to autoconfigure themselves with RA, we go into > bootstraap problem when router reboots. i consider autoconfiguring > router is a dangerous idea, and "hybrid router" idea is too. So, I don't see a particularly good reason to disallow a device from having distinct router-like and host-like ports, especially if the strong multihoming model is in effect, so the device doesn't forward packets to or from the hostlike ports. (One obvious application for this is out-of-band management networks, which generally don't seem worth it to me in many cases..) - Bill From owner-v6ops@ops.ietf.org Tue Nov 25 13:26:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00615 for ; Tue, 25 Nov 2003 13:26:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOhpx-0006Aa-FX for v6ops-data@psg.com; Tue, 25 Nov 2003 18:22:57 +0000 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AOhpk-00069x-Ko for v6ops@ops.ietf.org; Tue, 25 Nov 2003 18:22:44 +0000 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 25 Nov 2003 18:22:43 +0000 (GMT) Date: Tue, 25 Nov 2003 18:22:42 +0000 From: David Malone To: Jeroen Massar Cc: v6ops@ops.ietf.org Subject: Re: 2001:db8::/32 IPv6 Documentation Prefix currently not in whois Message-ID: <20031125182242.GA73829@walton.maths.tcd.ie> References: <003401c3b2f3$3cf4d060$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003401c3b2f3$3cf4d060$210d640a@unfix.org> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I though the IPv4 doc prefix was 192.0.2.0/24 (as mentioned in RFC 3330). It doesn't seem to be listed in as clear a way in whois as 192.168.0.0/16 is. David. From owner-v6ops@ops.ietf.org Tue Nov 25 13:31:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00918 for ; Tue, 25 Nov 2003 13:31:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOhwG-0006aD-85 for v6ops-data@psg.com; Tue, 25 Nov 2003 18:29:28 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOhw4-0006Yt-50 for v6ops@ops.ietf.org; Tue, 25 Nov 2003 18:29:16 +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, 25 Nov 2003 10:29:18 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 10:29:15 -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, 25 Nov 2003 10:29:31 -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, 25 Nov 2003 10:29:12 -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, 25 Nov 2003 10:29:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.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: "ROUTERS" vs. "routers" Date: Tue, 25 Nov 2003 10:29:49 -0800 Message-ID: Thread-Topic: "ROUTERS" vs. "routers" Thread-Index: AcOzazPJCDZlhkKaSeCEmivAXw8UMgAFmrhw From: "Christian Huitema" To: "Havard Eidnes" , Cc: , , X-OriginalArrivalTime: 25 Nov 2003 18:29:11.0938 (UTC) FILETIME=[05B51620:01C3B382] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > The distinction between routers and hosts and the criteria to separate > between them is one which I perceive as having been well established > in Internet technology for a Long Time. Well, how do you qualify a PC running a software component like Microsoft's "Internet Connection Sharing"? It appears as a host to the ISP, and acts as a router for the local network. That software has been available since at least 1998.=20 But never mind PC. How do you qualify a home NAT that appears as a host to the ISP, get an IPv4 address using DHCP, and then appears as a router to the local network? There are millions of these. So what exactly is "well established"? -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Nov 25 13:36:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01121 for ; Tue, 25 Nov 2003 13:36:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOi0Y-0006yQ-7y for v6ops-data@psg.com; Tue, 25 Nov 2003 18:33:54 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOi0L-0006xB-Uu for v6ops@ops.ietf.org; Tue, 25 Nov 2003 18:33:42 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 1A9788A; Wed, 26 Nov 2003 03:33:41 +0900 (JST) To: sommerfeld@east.sun.com Cc: v6ops@ops.ietf.org Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Your message of "Tue, 25 Nov 2003 12:07:40 -0500" <200311251707.hAPH7eS4010290@thunk.east.sun.com> References: <200311251707.hAPH7eS4010290@thunk.east.sun.com> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031125183341.1A9788A@coconut.itojun.org> Date: Wed, 26 Nov 2003 03:33:41 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > So, if router A has good reason to believe that router B advertises > > > a different set of prefixes, I see nothing unusual about A sending > > > RSs to B (and getting RAs back from B) to discover the different > > > prefixes. > > > > i guess i mentioned it in the past, if we allow routers to advertise > > different set of prefixes (which is the case now with RFC2462) and > > allow routers to autoconfigure themselves with RA, we go into > > bootstraap problem when router reboots. i consider autoconfiguring > > router is a dangerous idea, and "hybrid router" idea is too. > > So, I don't see a particularly good reason to disallow a device from > having distinct router-like and host-like ports, especially if the > strong multihoming model is in effect, so the device doesn't forward > packets to or from the hostlike ports. i think the above is "give people guns to shoot their own foot" approach. i think the stability of router infrastructure is more important than permitting "shoot their own foot" config. for autoconfiguring novice user's home router (where routers would need to be autoconfigured with /48 prefix), we have prefix delegation proposal. itojun From owner-v6ops@ops.ietf.org Tue Nov 25 13:49:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01654 for ; Tue, 25 Nov 2003 13:49:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOiCE-0007xJ-IK for v6ops-data@psg.com; Tue, 25 Nov 2003 18:45:58 +0000 Received: from [158.38.62.77] (helo=smistad.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOiBu-0007vV-9a for v6ops@ops.ietf.org; Tue, 25 Nov 2003 18:45:38 +0000 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id 643A220F32; Tue, 25 Nov 2003 19:45:37 +0100 (CET) Date: Tue, 25 Nov 2003 19:45:36 +0100 (CET) Message-Id: <20031125.194536.114541470.he@uninett.no> To: huitema@windows.microsoft.com Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" From: Havard Eidnes In-Reply-To: References: X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I'm sure you'll excuse my naivete, but at least to my mind, a box performing packet forwarding service between different interfaces (be they logical or physical) to carry traffic where it itself is not an endpoint, makes a box fall into the general category of "a router". How it gets it's address(es), or whether it additionally performs NAT or NAT-PT functions shouldn't make a huge difference with respect to whether it is characterized as a "host" or a "router". Regards, - H=E5vard From owner-v6ops@ops.ietf.org Tue Nov 25 13:50:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01688 for ; Tue, 25 Nov 2003 13:50:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOiEH-00086j-JL for v6ops-data@psg.com; Tue, 25 Nov 2003 18:48:05 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOiDw-000850-Ti for v6ops@ops.ietf.org; Tue, 25 Nov 2003 18:47:45 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 2B1A082C4; Tue, 25 Nov 2003 19:47:42 +0100 (CET) From: "Jeroen Massar" To: Cc: Subject: RE: 2001:db8::/32 IPv6 Documentation Prefix currently not in whois Date: Tue, 25 Nov 2003 19:47:40 +0100 Organization: Unfix Message-ID: <014a01c3b384$9b3e6b40$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20031125182242.GA73829@walton.maths.tcd.ie> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- dwmalone@maths.tcd.ie [mailto:dwmalone@maths.tcd.ie] wrote: > I though the IPv4 doc prefix was 192.0.2.0/24 (as mentioned in > RFC 3330). It doesn't seem to be listed in as clear a way in > whois as 192.168.0.0/16 is. ARIN has it listed as: $ whois 192.0.2.0 Internet Assigned Numbers Authority RESERVED-192 (NET-192-0-0-0-1) 192.0.0.0 - 192.0.127.255 Internet Assigned Numbers Authority IANA (NET-192-0-2-0-1) 192.0.2.0 - 192.0.2.255 $ whois -h whois.arin.net NET-192-0-2-0-1 NetRange: 192.0.2.0 - 192.0.2.255 CIDR: 192.0.2.0/24 NetName: IANA NetHandle: NET-192-0-2-0-1 Parent: NET-192-0-0-0-1 NetType: Reassigned Comment: Please see RFC 3330 for additional information. RegDate: Updated: 2002-10-14 (ARIN still doesn't do CIDR queries) Better comparison indeed than the RF1918 prefixes. This does make clear that the draft should be advanced and the prefix documented IMHO. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP8OjyymqKFIzPnwjEQIPtQCffDx/NQXFjiDmHc3xWwU0mt68FmsAnR+A diAcPLtavEnX+HCbUEuSxiKi =fOZq -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Tue Nov 25 14:05:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02605 for ; Tue, 25 Nov 2003 14:05:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOiS3-0009M7-C4 for v6ops-data@psg.com; Tue, 25 Nov 2003 19:02:19 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOiRq-0009Kk-Hr for v6ops@ops.ietf.org; Tue, 25 Nov 2003 19:02:06 +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, 25 Nov 2003 11:02:00 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 11:02:05 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 11:02:05 -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, 25 Nov 2003 11:02: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); Tue, 25 Nov 2003 11:02:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.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: "ROUTERS" vs. "routers" Date: Tue, 25 Nov 2003 11:02:40 -0800 Message-ID: Thread-Topic: "ROUTERS" vs. "routers" Thread-Index: AcOzhFkcsUAuLZ6DS4i4FlI6gw3ckwAAcxOQ From: "Christian Huitema" To: "Havard Eidnes" Cc: , X-OriginalArrivalTime: 25 Nov 2003 19:02:05.0848 (UTC) FILETIME=[9E3FD980:01C3B386] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I'm sure you'll excuse my naivete, but at least to my mind, a box > performing packet forwarding service between different interfaces (be > they logical or physical) to carry traffic where it itself is not an > endpoint, makes a box fall into the general category of "a router". Sure. That is the definition. "If it forwards packets, it is a router." The problem occurs when one tries to legislate what boxes can and cannot do on the basis of some categorization. Operational constraints derive from operational environments. Different environment have different constraints. We should not legislate constraints into the protocol specification. -- Christian Huitema=20 From owner-v6ops@ops.ietf.org Tue Nov 25 17:08:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13580 for ; Tue, 25 Nov 2003 17:08:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOlI1-000Kg0-Mi for v6ops-data@psg.com; Tue, 25 Nov 2003 22:04:09 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOlHf-000Keq-Ff for v6ops@ops.ietf.org; Tue, 25 Nov 2003 22:03:47 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAPM3P926454; Tue, 25 Nov 2003 14:03:25 -0800 X-mProtect: <200311252203> Nokia Silicon Valley Messaging Protection Received: from danira-pool05293.americas.nokia.com (10.241.52.93, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd54RtnM; Tue, 25 Nov 2003 14:03:23 PST Message-ID: <3FC3D19F.4060604@iprg.nokia.com> Date: Tue, 25 Nov 2003 14:03:11 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Jonne.Soininen@nokia.com, karim.el-malki@ericsson.com, v6ops@ops.ietf.org, jasko@fakat.com, ftemplin@iprg.nokia.com Subject: Re: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Tue, 25 Nov 2003 Jonne.Soininen@nokia.com wrote: > > >>I think this thread and all the other threads seem to point to the >>fact that we have to start dicussing solutions instead of scenarios. >>We know the scenario now - we may need tunneling. If we could now >>wrap up ISATAP in that way that it fulfills the requiremets given by >>the scenarios/analysis. Right? >> >> > >We know that there is a scenario where tunneling is desirable in >certain cases, yes. However, I'm not sure if we know the requirements >of the scenario, or the scenario itself, well enough yet (see the >points above why exactly configuring is bad, what exactly would need >to be configured, etc.). > >Of course, talking about solutions might be OK as well, but only if >one keeps the scenario in mind. > >I don't know what you mean by the ISATAP reference. Clearly, we could >take it, and apply it in this specific scenario, and I think it would >work, at least to some definition of "work". That doesn't mean it's >the right thing to do, of course. Is it the *right* tool for the job? > Perhaps what might help would be an applicability statement such as the one I have just submitted to the I-D repository and have available for immediate perusal at: http://www.geocities.com/osprey67/isnoid-00.txt The document title and abstract appear below: Fred ftemplin@iprg.nokia.com > > Network Working Group F. Templin > Internet-Draft Nokia > Expires: May 25, 2004 November 25, 2003 > > > Applicability of ISATAP for NOID > draft-ietf-templin-isnoid-00.txt > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at http:// > www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 25, 2004. > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > Abstract > > This document describes the operation of the NOID multihoming > proposal on nodes with ISATAP interfaces. It uses the global DNS as > an extension of the ISATAP Potential Router List (PRL) and ISATAP > link-local addresses as next-hop addresses for IPv6 routes. From owner-v6ops@ops.ietf.org Tue Nov 25 17:18:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14093 for ; Tue, 25 Nov 2003 17:18:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOlSQ-000LOg-SJ for v6ops-data@psg.com; Tue, 25 Nov 2003 22:14:54 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOlSE-000LO7-Lg for v6ops@ops.ietf.org; Tue, 25 Nov 2003 22:14:42 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id BEF468B; Wed, 26 Nov 2003 07:14:41 +0900 (JST) To: huitema@windows.microsoft.com Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: RE: "ROUTERS" vs. "routers" In-Reply-To: Your message of "Tue, 25 Nov 2003 10:29:49 -0800" References: X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031125221441.BEF468B@coconut.itojun.org> Date: Wed, 26 Nov 2003 07:14:41 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk not sure on which mailing list we should continue this discussion. > > The distinction between routers and hosts and the criteria to separate > > between them is one which I perceive as having been well established > > in Internet technology for a Long Time. > > Well, how do you qualify a PC running a software component like > Microsoft's "Internet Connection Sharing"? It appears as a host to the > ISP, and acts as a router for the local network. That software has been > available since at least 1998. i guess you are using "host" to mean "being able to make TCP connection" here. "host" in IPv6 spec refers to forwarding functionality, so XP with Internet Code Sharing would be a "router" under IPv6 terminology. it is not unusual for a router (device that foward packet) be able to make outgoing TCP connection. itojun From owner-v6ops@ops.ietf.org Tue Nov 25 17:54:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15450 for ; Tue, 25 Nov 2003 17:54:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOm12-000NJA-Es for v6ops-data@psg.com; Tue, 25 Nov 2003 22:50:40 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOm0p-000NIA-8q for v6ops@ops.ietf.org; Tue, 25 Nov 2003 22:50:27 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPMoP622590 for ; Wed, 26 Nov 2003 00:50:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 00:50:25 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 00:50:25 +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: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Wed, 26 Nov 2003 00:50:24 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195094A26@esebe024.ntc.nokia.com> Thread-Topic: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Thread-Index: AcOzY75SupO+PqeJRJ+8V7L0qVGI1QAP3X8A From: To: Cc: , , X-OriginalArrivalTime: 25 Nov 2003 22:50:25.0376 (UTC) FILETIME=[83CDEE00:01C3B3A6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 25 November, 2003 16:52 >=20 > Again, you assume that the user actually has to configure anything at=20 > all. That doesn't need to be the case, I think. (At least,=20 > I haven't=20 > heard technical arguments why it couldn't be.) >=20 > Who said that the user has to configure anything itself? The user > receives a magical SMS message from his operator, the tunnel gets > automatically activated, and we're done? >=20 > Or does the user manually configure the APN as well, based on the SMS=20 > messages it sends/receives? Look, the IP address is dynamic and usually every PDP context activation = means a new IP address. Then there would have to be a mechanism for the = network to guess that the user would like to use IPv6 on this particular = PDP Context and send an SMS to configure the tunnel. The configuration = would have to be accepted by the user, and so on. This would not work.=20 =20 > Sounds like a circular argument without justification. I think the justification is above. >=20 > > > That avoids getting the other features of ISATAP we don't=20 > need here,=20 > > > and provide a simpler architecture. > > >=20 > > > I do not believe this possibility has been analyzed well enough to > > > understand it's possibilities (or potential flaws). > >=20 > > I think this thread and all the other threads seem to point to the > > fact that we have to start dicussing solutions instead of scenarios. > > We know the scenario now - we may need tunneling. If we could now > > wrap up ISATAP in that way that it fulfills the requiremets given by > > the scenarios/analysis. Right? >=20 > We know that there is a scenario where tunneling is desirable in > certain cases, yes. However, I'm not sure if we know the requirements > of the scenario, or the scenario itself, well enough yet (see the > points above why exactly configuring is bad, what exactly would need > to be configured, etc.). Configuration would not work. I think this has been explained above and = in other mails sent on this list. Trust me on this - configuring the = tunnels can be at the most a very marginal case. >=20 > Of course, talking about solutions might be OK as well, but only if=20 > one keeps the scenario in mind. Yes, now we do have already two different scenarios/analysis pairs that = call for some kind of solution. I think we should concentrate to see = what the solution would be. >=20 > I don't know what you mean by the ISATAP reference. Clearly, we could > take it, and apply it in this specific scenario, and I think it would > work, at least to some definition of "work". That doesn't mean it's > the right thing to do, of course. Is it the *right* tool for=20 > the job? =20 It is at least one possible tools for this job. Do you have others = candidates (except for configured tunnels)? >=20 > For example, a proof of concept procedure was introduced in > draft-savola-v6ops-conftun-setup-01.txt; it would probably solve the > problem in a much simpler and easier way; it's basically just > expanding the couple of bullet points above about configured tunneling > set-up methods. In the case of 3GPP, only proto-41 would be necessary > -- basically just configured tunneling at the UE, and some tricks at > the 3GPP operator side, depending on the mode in which it wishes to > operate. Sorry, I read the document really, really quickly. It is an interesting = document and we should discuss the different solutions if we decide to = go to the solutions space (not wearing chair hat-I think it would be = time). Of course, we have to consider all solutions.=20 Cheers, Jonne. >=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 Wed Nov 26 01:22:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27158 for ; Wed, 26 Nov 2003 01:22:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOsus-000Gpt-UF for v6ops-data@psg.com; Wed, 26 Nov 2003 06:12:46 +0000 Received: from [195.167.170.152] (helo=bowl.fysh.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOiDl-00083a-Vj for v6ops@ops.ietf.org; Tue, 25 Nov 2003 18:47:34 +0000 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AOiDg-00062P-00; Tue, 25 Nov 2003 18:47:28 +0000 Date: Tue, 25 Nov 2003 18:47:28 +0000 To: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" Message-ID: <20031125184728.GA23008@fysh.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Zefram X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Christian Huitema wrote: >But never mind PC. How do you qualify a home NAT that appears as a host >to the ISP, get an IPv4 address using DHCP, and then appears as a router >to the local network? The NAT divides the network into two areas, the difference between them being that certain things look different when seen from points of view in the two areas. One of the things that differs is whether the NAT box appears to be a router or a non-routing host. -zefram From owner-v6ops@ops.ietf.org Wed Nov 26 01:22:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27176 for ; Wed, 26 Nov 2003 01:22:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOsve-000Grp-4F for v6ops-data@psg.com; Wed, 26 Nov 2003 06:13:34 +0000 Received: from [138.77.5.126] (helo=mx2sophos.cqu.edu.au) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOmHm-000OAE-87 for v6ops@ops.ietf.org; Tue, 25 Nov 2003 23:07:58 +0000 Received: from proton.staff.ad.cqu.edu.au ([138.77.34.41] helo=ROKEMAIL.staff.ad.cqu.edu.au) by mx2sophos.cqu.edu.au with esmtp (Exim 4.22) id 1AOmHi-0005mz-5U; Wed, 26 Nov 2003 09:07:54 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: "ROUTERS" vs. "routers" Date: Wed, 26 Nov 2003 09:03:18 +1000 Message-ID: Thread-Topic: "ROUTERS" vs. "routers" Thread-Index: AcOzayQ2fJJeIPhvQPmbwYygA1zSrgAPBgyw From: "Amoakoh Gyasi-Agyei" To: "Havard Eidnes" , Cc: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Dear Havard; I may have to accept that I do share your feelings as I think there's = more than enough confusion with the terminologies used in the IT&T = industry at the moment. There are many possible letter combinations in = the English alphabet alone, so why can't we please use terminologies = freed of ambiguities? I already perceive a confusion with the usage of = the words "router", "switch" and "hub", etc. by some authors. Cheers, AGA -----Original Message----- From: Havard Eidnes [mailto:he@uninett.no]=20 Sent: Wednesday, 26 November 2003 1:43 AM To: pthubert@cisco.com Cc: ftemplin@iprg.nokia.com; ipv6@ietf.org; v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" Hm, maybe I was unclear -- let me try to clarify. The distinction between routers and hosts and the criteria to separate = between them is one which I perceive as having been well established in = Internet technology for a Long Time. I think we should think twice = before obfuscating this distinction, or try to sneak in something which = is claimed to be somewhere between them. I'm therefore reacting negatively to the attempt at abusing the "router" = term by introducing new and subtle meaning with a distinction between = "ROUTER" and "router". Choose a different word if you insist on = pursuing this, please! I've heard in other discussions the distinction between hosts = implementing a "strong" versus a "weak" model, typically used as a = distinguishing additional criteria when hosts are attached to multiple = networks and/or have multiple addresses. However, my local RFC = repository does not have any mention of that term. I wonder if this = direction is something which could be pursued. Regards, - H=E5vard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Wed Nov 26 01:27:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27337 for ; Wed, 26 Nov 2003 01:27:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOt6L-000HJh-4U for v6ops-data@psg.com; Wed, 26 Nov 2003 06:24:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOt66-000HJF-Iy for v6ops@ops.ietf.org; Wed, 26 Nov 2003 06:24:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQ6NoM00907; Wed, 26 Nov 2003 08:23:50 +0200 Date: Wed, 26 Nov 2003 08:23:50 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org cc: v6ops@ops.ietf.org Subject: Stop "ROUTERS" vs "routers" discussion in v6ops [RE: "ROUTERS" vs. "routers"] 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi everybody, Now that we've opened the particular can of worms, it's time to close it again. Let's not get into a too heated debate on what we call IPv6 routers; we have more pressing matters to discuss. Please don't continue the discussion of "ROUTERS" vs "routers" on v6ops mailing list. It doesn't seem to be relevant here, at least anymore. Thanks, Pekka writing as v6ops co-chair On Wed, 26 Nov 2003, Amoakoh Gyasi-Agyei wrote: > Dear Havard; > > I may have to accept that I do share your feelings as I think > there's more than enough confusion with the terminologies used in > the IT&T industry at the moment. There are many possible letter > combinations in the English alphabet alone, so why can't we please > use terminologies freed of ambiguities? I already perceive a > confusion with the usage of the words "router", "switch" and "hub", > etc. by some authors. > > Cheers, > AGA > > -----Original Message----- > From: Havard Eidnes [mailto:he@uninett.no] > Sent: Wednesday, 26 November 2003 1:43 AM > To: pthubert@cisco.com > Cc: ftemplin@iprg.nokia.com; ipv6@ietf.org; v6ops@ops.ietf.org > Subject: Re: "ROUTERS" vs. "routers" > > > Hm, > > maybe I was unclear -- let me try to clarify. > > The distinction between routers and hosts and the criteria to separate between them is one which I perceive as having been well established in Internet technology for a Long Time. I think we should think twice before obfuscating this distinction, or try to sneak in something which is claimed to be somewhere between them. > > I'm therefore reacting negatively to the attempt at abusing the "router" term by introducing new and subtle meaning with a distinction between "ROUTER" and "router". Choose a different word if you insist on pursuing this, please! > > I've heard in other discussions the distinction between hosts implementing a "strong" versus a "weak" model, typically used as a distinguishing additional criteria when hosts are attached to multiple networks and/or have multiple addresses. However, my local RFC repository does not have any mention of that term. I wonder if this direction is something which could be pursued. > > Regards, > > - Håvard > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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 Nov 26 01:52:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27930 for ; Wed, 26 Nov 2003 01:52:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOtTl-000Ix3-9Y for v6ops-data@psg.com; Wed, 26 Nov 2003 06:48:49 +0000 Received: from [203.102.234.227] (helo=nosense.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOsTF-000Ffa-9A for v6ops@ops.ietf.org; Wed, 26 Nov 2003 05:44:13 +0000 Received: from Dupy2.nosense.org (227.cust7.nsw.dsl.ozemail.com.au [203.102.234.227]) by nosense.org (Postfix) with SMTP id 307DB3F07B; Wed, 26 Nov 2003 16:15:25 +1030 (CST) Date: Wed, 26 Nov 2003 16:15:24 +1030 From: Mark Smith To: "Pascal Thubert (pthubert)" Cc: he@uninett.no, ftemplin@iprg.nokia.com, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" Message-Id: <20031126161524.2402f1b3.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: References: Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 25 Nov 2003 15:22:43 -0000 "Pascal Thubert (pthubert)" wrote: > - A PC with multiple Network addressable entities such as storage media I had the maybe not so strange idea a while back of having all components within a PC have an IPv6 address, or at least represented within the OS by an IPv6 eg keyboard, mouse, HDD etc. I'm not necessarily suggesting that inter-device communication occurs over TCP or UDP though. Just IPv6 addresses for management, and possibly other uses that I haven't thought of. You could then do tricks such as if the user complains that their HDD has stopped working, you could ping it over the network. Or have SNMP agents issue traps when eg. the keyboard stops working. I don't know whether this model would make the PC a router, or just that the PC's interface to the network acts as a proxy for all the device's "internal" IPv6 addresses, performing things such as DAD on their behalf. Regards, Mark. From owner-v6ops@ops.ietf.org Wed Nov 26 02:10:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09094 for ; Wed, 26 Nov 2003 02:10:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOtm6-000Jpt-FT for v6ops-data@psg.com; Wed, 26 Nov 2003 07:07:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOtlt-000JpR-It for v6ops@ops.ietf.org; Wed, 26 Nov 2003 07:07:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQ76oK02546; Wed, 26 Nov 2003 09:06:50 +0200 Date: Wed, 26 Nov 2003 09:06:50 +0200 (EET) From: Pekka Savola To: Jonne.Soininen@nokia.com cc: karim.el-malki@ericsson.com, , Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <2D3EB51EAED985419D54AB340A9D0195094A26@esebe024.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 26 Nov 2003 Jonne.Soininen@nokia.com wrote: > > Who said that the user has to configure anything itself? The user > > receives a magical SMS message from his operator, the tunnel gets > > automatically activated, and we're done? > > > > Or does the user manually configure the APN as well, based on the SMS > > messages it sends/receives? > > Look, the IP address is dynamic and usually every PDP context > activation means a new IP address. Then there would have to be a > mechanism for the network to guess that the user would like to use > IPv6 on this particular PDP Context and send an SMS to configure the > tunnel. The configuration would have to be accepted by the user, and > so on. This would not work. As for the client side configuration... No, this does not seem to be the case. The user just has to find out the IPv4 address of the tunnel endpoint somehow. As the tunnel endpoint is located at its local 3GPP operator, it is fairly static, and can even be routed somewhere else in the IGP if it moves. Manual one-time config (need to be redone only if you switch your home operator) is sufficient, as well as doing it with an SMS [as one-time config], looking it up from the DNS, or something else. So there clearly seems to be some disconnect here, maybe some assumptions which haven't been spelled out. Now, the network side configuration is slightly trickier.. Basically the options seem to be two-fold: either the home operator knows which users are potential IPv6 users in advance (and can associate "user-wants-ipv6" and the user information, and always when the customer performs the PDP context activation, update the tunnel end-point information), or that all the users are potential users (implying the tunnel end-point should be updated based on the first packet sent over the tunnel). The former requires a bit of ops & management glue to tie these two together. The latter requires a minor modification to proto-41 decapsulation code at the 3GPP operator's tunnel router, but basically that's it. (This is elaborated a bit in the STEP draft already mentioned.) There are probably other ways to tackle this problem as well. The point is, the client configuration seems close to trivial. The network configuration is slightly trickier, but should be manageable. > > Sounds like a circular argument without justification. > > I think the justification is above. Nope, there are still some assumptions out there... > > We know that there is a scenario where tunneling is desirable in > > certain cases, yes. However, I'm not sure if we know the requirements > > of the scenario, or the scenario itself, well enough yet (see the > > points above why exactly configuring is bad, what exactly would need > > to be configured, etc.). > > Configuration would not work. I think this has been explained above > and in other mails sent on this list. Trust me on this - configuring > the tunnels can be at the most a very marginal case. Based on the misunderstandings as shown above, I do not believe different people have a right mindset when they talk about "configuration". I'm not sure if folks realize that it's really not so complicated. See above. > > I don't know what you mean by the ISATAP reference. Clearly, we could > > take it, and apply it in this specific scenario, and I think it would > > work, at least to some definition of "work". That doesn't mean it's > > the right thing to do, of course. Is it the *right* tool for > > the job? > > It is at least one possible tools for this job. Do you have others > candidates (except for configured tunnels)? Configured tunnels work just fine. > > For example, a proof of concept procedure was introduced in > > draft-savola-v6ops-conftun-setup-01.txt; it would probably solve the > > problem in a much simpler and easier way; it's basically just > > expanding the couple of bullet points above about configured tunneling > > set-up methods. In the case of 3GPP, only proto-41 would be necessary > > -- basically just configured tunneling at the UE, and some tricks at > > the 3GPP operator side, depending on the mode in which it wishes to > > operate. > > Sorry, I read the document really, really quickly. It is an > interesting document and we should discuss the different solutions > if we decide to go to the solutions space (not wearing chair hat-I > think it would be time). Of course, we have to consider all > solutions. I'm not sure if it makes sense to look into solutions too much yet (but soon would be time for 3GPP I guess), as it clearly seems that the scenario is not spelled out clearly enough. -- 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 Nov 26 02:25:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21493 for ; Wed, 26 Nov 2003 02:25:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOtzd-000KVv-AK for v6ops-data@psg.com; Wed, 26 Nov 2003 07:21:45 +0000 Received: from [220.240.241.2] (helo=killjoy.zoic.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOq6C-0009C1-6a for v6ops@ops.ietf.org; Wed, 26 Nov 2003 03:12:16 +0000 Received: by killjoy.zoic.org (Postfix, from userid 1000) id 07CECCB1FE0; Wed, 26 Nov 2003 14:12:13 +1100 (EST) Date: Wed, 26 Nov 2003 14:12:12 +1100 From: "Nick 'Sharkey' Moore" To: Fred Templin Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" Message-ID: <20031126031212.GA4317@zoic.org> References: <3FC2B319.9080707@iprg.nokia.com> <20031125020315.7A6958B@coconut.itojun.org> <3FC3614F.8080100@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC3614F.8080100@iprg.nokia.com> X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS,RCVD_IN_SORBS_HTTP autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 2003-11-25, Fred Templin wrote: > > RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS"). > "ROUTERS" typically advertise autoconfig parameters and prefixes from > their attached networks. Hosts use them to reach off-link nodes via default > or more-specific routes. But, a new breed of routers (i.e., "routers") is > emerging from paradigms such as Mobile Ad-hoc Networks. "routers" > typically advertise host routes only (aka, "addresses" or "locators") and > no prefix or autoconfig parameters at all. > [...] > In the MANET paradigm, "routers" often have only a single network > interface which may be used for multi-hop forwarding [...] Firstly, I don't think differentiating 'router' and 'ROUTER' is a good idea. I for one would find it hard to follow in conversation :-) I think the usual definition of Router is a good one -- a Router is a node which forwards packets. It seems to me that the confusion is not in the definition of Router, but in the definitions of 'Interface', 'Link' and 'Network', which don't generally take wireless into account. -----Nick From owner-v6ops@ops.ietf.org Wed Nov 26 04:15:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28328 for ; Wed, 26 Nov 2003 04:15:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOviG-000PaP-W1 for v6ops-data@psg.com; Wed, 26 Nov 2003 09:11:56 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOvi1-000PZJ-S7 for v6ops@ops.ietf.org; Wed, 26 Nov 2003 09:11:42 +0000 Received: from fakat.com (pc5205203.nac.telia.se [131.115.205.203]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id hAQ9CTwN058347; Wed, 26 Nov 2003 10:12:30 +0100 (CET) (envelope-from jasko@fakat.com) Message-ID: <3FC46E46.4060800@fakat.com> Date: Wed, 26 Nov 2003 10:11:34 +0100 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Jonne.Soininen@nokia.com, karim.el-malki@ericsson.com, v6ops@ops.ietf.org Subject: Re: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] References: In-Reply-To: X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit pekka, > As for the client side configuration... > > No, this does not seem to be the case. The user just has to find out > the IPv4 address of the tunnel endpoint somehow. As the tunnel it must be completely transparent to the user. otherwise, it is a non-starter. the normal user doesn't care about such things. jasminko p.s. instead of endlessly repeating same arguments over and over, shouldn't we write a requirements document for UE tunneling, or something? From owner-v6ops@ops.ietf.org Wed Nov 26 04:39:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29535 for ; Wed, 26 Nov 2003 04:39:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOw4q-0000rZ-72 for v6ops-data@psg.com; Wed, 26 Nov 2003 09:35:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOw4d-0000qQ-OH for v6ops@ops.ietf.org; Wed, 26 Nov 2003 09:35:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQ9YxI05357; Wed, 26 Nov 2003 11:34:59 +0200 Date: Wed, 26 Nov 2003 11:34:58 +0200 (EET) From: Pekka Savola To: Jasminko Mulahusic cc: Jonne.Soininen@nokia.com, , Subject: Re: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <3FC46E46.4060800@fakat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 26 Nov 2003, Jasminko Mulahusic wrote: > > As for the client side configuration... > > > > No, this does not seem to be the case. The user just has to find out > > the IPv4 address of the tunnel endpoint somehow. As the tunnel > > it must be completely transparent to the user. otherwise, it is a > non-starter. the normal user doesn't care about such things. It can be completely transparent, yes. > p.s. instead of endlessly repeating same arguments over and over, > shouldn't we write a requirements document for UE tunneling, or something? That would be great, as it would probably help in understanding the scenario (and it's requirements) better. If you're volunteering.... :-) This seemed to have a good impact on the unmanaged tunneling discussion, why not here as well, then? :-) (The document probably wouldn't even have to be published as RFC, just circulated as a couple of revisions of an I-D, to facilitate discussion..) -- 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 Nov 26 05:25:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01141 for ; Wed, 26 Nov 2003 05:25:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOwoQ-0002x1-3Y for v6ops-data@psg.com; Wed, 26 Nov 2003 10:22:22 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOwoA-0002w5-ST for v6ops@ops.ietf.org; Wed, 26 Nov 2003 10:22:06 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 05:22:07 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042031@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , Jonne.Soininen@nokia.com Cc: karim.el-malki@ericsson.com, v6ops@ops.ietf.org, jasko@fakat.com Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Wed, 26 Nov 2003 05:21:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > As for the client side configuration... > > No, this does not seem to be the case. The user just has to find out > the IPv4 address of the tunnel endpoint somehow. As the tunnel > endpoint is located at its local 3GPP operator, it is fairly static, > and can even be routed somewhere else in the IGP if it moves. Manual > one-time config (need to be redone only if you switch your home > operator) is sufficient, as well as doing it with an SMS [as one-time > config], looking it up from the DNS, or something else. > > So there clearly seems to be some disconnect here, maybe some > assumptions which haven't been spelled out. > > Now, the network side configuration is slightly trickier.. > > Basically the options seem to be two-fold: either the home operator > knows which users are potential IPv6 users in advance (and can > associate "user-wants-ipv6" and the user information, and always when > the customer performs the PDP context activation, update the tunnel > end-point information), => This alternative is a non starter. This knowledge would not exist unless static addresses are used, and they're not used at all. or that all the users are potential users > (implying the tunnel end-point should be updated based on the first > packet sent over the tunnel). The former requires a bit of ops & > management glue to tie these two together. The latter requires a > minor modification to proto-41 decapsulation code at the 3GPP > operator's tunnel router, but basically that's it. => I'd rather not make this assumption either. It seems to me that we're going around trying to avoid using an existing, well understood, implemented in products, proposal (ISATAP), why? The people that implemented it in products are happy with it. It's time to make a concensus call on this issue. Frankly, this discussion has gone for a long time and no one is moving so let's get a feel for what the WG thinks. Hesham (This is > elaborated a bit in the STEP draft already mentioned.) There are > probably other ways to tackle this problem as well. > > The point is, the client configuration seems close to trivial. The > network configuration is slightly trickier, but should be manageable. > > > > Sounds like a circular argument without justification. > > > > I think the justification is above. > > Nope, there are still some assumptions out there... > > > > We know that there is a scenario where tunneling is desirable in > > > certain cases, yes. However, I'm not sure if we know > the requirements > > > of the scenario, or the scenario itself, well enough yet (see the > > > points above why exactly configuring is bad, what > exactly would need > > > to be configured, etc.). > > > > Configuration would not work. I think this has been explained above > > and in other mails sent on this list. Trust me on this - > configuring > > the tunnels can be at the most a very marginal case. > > Based on the misunderstandings as shown above, I do not believe > different people have a right mindset when they talk about > "configuration". I'm not sure if folks realize that it's really not > so complicated. See above. > > > > I don't know what you mean by the ISATAP reference. > Clearly, we could > > > take it, and apply it in this specific scenario, and I > think it would > > > work, at least to some definition of "work". That > doesn't mean it's > > > the right thing to do, of course. Is it the *right* tool for > > > the job? > > > > It is at least one possible tools for this job. Do you have others > > candidates (except for configured tunnels)? > > Configured tunnels work just fine. > > > > For example, a proof of concept procedure was introduced in > > > draft-savola-v6ops-conftun-setup-01.txt; it would > probably solve the > > > problem in a much simpler and easier way; it's basically just > > > expanding the couple of bullet points above about > configured tunneling > > > set-up methods. In the case of 3GPP, only proto-41 > would be necessary > > > -- basically just configured tunneling at the UE, and > some tricks at > > > the 3GPP operator side, depending on the mode in which > it wishes to > > > operate. > > > > Sorry, I read the document really, really quickly. It is an > > interesting document and we should discuss the different solutions > > if we decide to go to the solutions space (not wearing chair hat-I > > think it would be time). Of course, we have to consider all > > solutions. > > I'm not sure if it makes sense to look into solutions too much yet > (but soon would be time for 3GPP I guess), as it clearly seems that > the scenario is not spelled out clearly enough. > > -- > 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 Nov 26 05:44:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01573 for ; Wed, 26 Nov 2003 05:44:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOx7Y-0003oN-CG for v6ops-data@psg.com; Wed, 26 Nov 2003 10:42:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOx7K-0003nK-LY for v6ops@ops.ietf.org; Wed, 26 Nov 2003 10:41:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQAfnV06419; Wed, 26 Nov 2003 12:41:49 +0200 Date: Wed, 26 Nov 2003 12:41:49 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: Jonne.Soininen@nokia.com, , , Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042031@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (chair hat=on) Btw, please try to trim the text being quoted -- to make it easier to read -- and remove any unnecessary text (e.g. at the end). (chair hat=off) On Wed, 26 Nov 2003, Soliman Hesham wrote: > > Basically the options seem to be two-fold: either the home operator > > knows which users are potential IPv6 users in advance (and can > > associate "user-wants-ipv6" and the user information, and always when > > the customer performs the PDP context activation, update the tunnel > > end-point information), > > => This alternative is a non starter. This knowledge would not > exist unless static addresses are used, and they're not used > at all. This cannot be true. The home operator must know the address of the UE, if for no other reason, but because it's tunneled back from the foreign network. In the traditional ISP networks, the knowledge is out there, even for dynamic prefixes (e.g. in TACACS/RADIUS logs, etc.). I fail to see how that would be different for 3GPP? Please elaborate! > > or that all the users are potential users > > (implying the tunnel end-point should be updated based on the first > > packet sent over the tunnel). The former requires a bit of ops & > > management glue to tie these two together. The latter requires a > > minor modification to proto-41 decapsulation code at the 3GPP > > operator's tunnel router, but basically that's it. > > => I'd rather not make this assumption either. Well, some rather might! :-) Can you provide some technical arguments? > It seems to me that we're going around trying to avoid > using an existing, well understood, implemented in products, > proposal (ISATAP), why? The people that implemented it in > products are happy with it. This is not true. I know for sure that it is not well understood (I'm not sure how well I can argue about the others, so I don't respond to that point now). The previous ISATAP advocate, for example, thought it to be a simple host-to-router tunneling mechanism without direct connectivity between hosts in the ISATAP domain. That feature had been included for at least a couple of years or so.. > It's time to make a concensus call on this issue. Frankly, > this discussion has gone for a long time and no one is > moving so let's get a feel for what the WG thinks. The discussion has gone for long time, that's for sure, but I believe only until recently we've been able to tease apart the assumptions different people have about the requirements and the scenario in question. People have been talking past each other, with certain assumptions in mind (e.g. about configuration required in configured tunneling). I believe there is progress to be made, if especially folks who have taken ISATAP as their "one true solution" are willing to keep the eyes open. -- 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 Nov 26 06:18:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02424 for ; Wed, 26 Nov 2003 06:18:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOxed-0005O0-Ay for v6ops-data@psg.com; Wed, 26 Nov 2003 11:16:19 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOxeQ-0005NU-PM for v6ops@ops.ietf.org; Wed, 26 Nov 2003 11:16:06 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 06:16:07 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042033@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Jonne.Soininen@nokia.com, karim.el-malki@ericsson.com, v6ops@ops.ietf.org, jasko@fakat.com Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Wed, 26 Nov 2003 06:16:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > => This alternative is a non starter. This knowledge would not > > exist unless static addresses are used, and they're not used > > at all. > > This cannot be true. The home operator must know the address of the > UE, => Of course it knows it but it will know it in a different box (i.e. GGSN and DHCP for v4) but the tunnel end point is not on either one of those boxes. if for no other reason, but because it's tunneled back from the > foreign network. => I don't get this. > > > or that all the users are potential users > > > (implying the tunnel end-point should be updated based > on the first > > > packet sent over the tunnel). The former requires a > bit of ops & > > > management glue to tie these two together. The latter > requires a > > > minor modification to proto-41 decapsulation code at the 3GPP > > > operator's tunnel router, but basically that's it. > > > > => I'd rather not make this assumption either. > > Well, some rather might! :-) Can you provide some technical > arguments? => It doesn't exist today in routers AFAICS. And there is no reason to introduce it when we can do with other mechanisms in products that people seem to prefer. > > It seems to me that we're going around trying to avoid > > using an existing, well understood, implemented in products, > > proposal (ISATAP), why? The people that implemented it in > > products are happy with it. > > This is not true. I know for sure that it is not well > understood (I'm > not sure how well I can argue about the others, so I don't respond to > that point now). The previous ISATAP advocate, for example, thought > it to be a simple host-to-router tunneling mechanism without direct > connectivity between hosts in the ISATAP domain. That feature had > been included for at least a couple of years or so.. => We can't assume that it is not well understood because one person made a mistake. It is implemented on 4 different products that I know of (2 host platforms and two router platforms) and are all interoperable. > > > It's time to make a concensus call on this issue. Frankly, > > this discussion has gone for a long time and no one is > > moving so let's get a feel for what the WG thinks. > > The discussion has gone for long time, that's for sure, but I believe > only until recently we've been able to tease apart the assumptions > different people have about the requirements and the scenario in > question. People have been talking past each other, with certain > assumptions in mind (e.g. about configuration required in configured > tunneling). I believe there is progress to be made, if especially > folks who have taken ISATAP as their "one true solution" are willing > to keep the eyes open. => And vice versa. Hesham > > -- > 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 Nov 26 07:34:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04414 for ; Wed, 26 Nov 2003 07:34:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOyot-00095K-1c for v6ops-data@psg.com; Wed, 26 Nov 2003 12:30:59 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOyoX-000938-CQ for v6ops@ops.ietf.org; Wed, 26 Nov 2003 12:30:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQCU3T07970; Wed, 26 Nov 2003 14:30:03 +0200 Date: Wed, 26 Nov 2003 14:30:03 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: Jonne.Soininen@nokia.com, , , Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042033@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 26 Nov 2003, Soliman Hesham wrote: > > > => This alternative is a non starter. This knowledge would not > > > exist unless static addresses are used, and they're not used > > > at all. > > > > This cannot be true. The home operator must know the address of the > > UE, > > => Of course it knows it but it will know it in a different > box (i.e. GGSN and DHCP for v4) but the tunnel end point > is not on either one of those boxes. Certainly. But this is no problem. You can get that information using some means, e.g. SNMP. I don't know which kind of interfaces 3GPP boxes have, and which kind management systems they connect to, but I'm pretty sure there can be ways to extract that information. > > if for no other reason, but because it's tunneled back from the > > foreign network. > > => I don't get this. I mean, I understand foreign 3GPP operators use something like L2TP to transport the IPv4 packets back to the home operator, correct? The home operator has to have some kind of policy to who will be allowed in its network, i.e., when decapsulating the L2TP stream from the foreign operator, the 3GPP operator should check the source addresses of the packets (or at least do something to check that the packets are valid, for billing etc. reasons if for nothing else). > > > > minor modification to proto-41 decapsulation code at the 3GPP > > > > operator's tunnel router, but basically that's it. > > > > > > => I'd rather not make this assumption either. > > > > Well, some rather might! :-) Can you provide some technical > > arguments? > > => It doesn't exist today in routers AFAICS. Pretty close to trivial to implement. > And there is no reason to introduce it when we can do with other > mechanisms in products that people seem to prefer. On the contrary, there is no reason to bless a solution (and impose the burden of the solution on everyone eelse) that some have chosen because they didn't think of alternative ways to achieve the result. > => We can't assume that it is not well understood > because one person made a mistake. I can read myself, and I can say for sure that it isn't well understood. :-) > It is implemented > on 4 different products that I know of (2 host platforms > and two router platforms) and are all interoperable. Implementatable & interoperable is VERY FAR from being well understood. -- 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 Nov 26 07:48:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04982 for ; Wed, 26 Nov 2003 07:48:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOz2s-0009rF-6p for v6ops-data@psg.com; Wed, 26 Nov 2003 12:45:26 +0000 Received: from [217.32.164.138] (helo=i2kc03-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOz2f-0009q0-KK for v6ops@ops.ietf.org; Wed, 26 Nov 2003 12:45:13 +0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 12:45:12 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 12:45:11 +0000 x-mimeole: Produced By Microsoft Exchange V6.0.6375.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: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Wed, 26 Nov 2003 12:44:31 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7003EFEB62@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Thread-Index: AcOz7IDPd+W3BToWTK2oEIuFPJU1DgALfwlA From: To: , Cc: , , X-OriginalArrivalTime: 26 Nov 2003 12:45:11.0901 (UTC) FILETIME=[21B320D0:01C3B41B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, > the IGP if it moves. Manual one-time config (need to be=20 > redone only if you switch your home > operator) is sufficient, as well as doing it with an SMS [as=20 > one-time config], looking it up from the DNS, or something else. 'Manual one-time config' is still config. Show me a zero-config solution. And people change their home operator all the time. These are very real concerns that the operations community have and should be listened to. =20 Mat From owner-v6ops@ops.ietf.org Wed Nov 26 07:59:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05220 for ; Wed, 26 Nov 2003 07:59:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOzEi-000ARj-5u for v6ops-data@psg.com; Wed, 26 Nov 2003 12:57:40 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOzEN-000AQh-QW for v6ops@ops.ietf.org; Wed, 26 Nov 2003 12:57:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQCvDh08379; Wed, 26 Nov 2003 14:57:13 +0200 Date: Wed, 26 Nov 2003 14:57:13 +0200 (EET) From: Pekka Savola To: matthew.ford@bt.com cc: Jonne.Soininen@nokia.com, , , Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <0AAF93247C75E3408638B965DEE11A7003EFEB62@i2km41-ukdy.domain1.systemhost.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 26 Nov 2003 matthew.ford@bt.com wrote: > > the IGP if it moves. Manual one-time config (need to be > > redone only if you switch your home > > operator) is sufficient, as well as doing it with an SMS [as > > one-time config], looking it up from the DNS, or something else. > > 'Manual one-time config' is still config. Show me a zero-config > solution. And people change their home operator all the time. These are > very real concerns that the operations community have and should be > listened to. Right; if this is believed to be concern, there are basically three ways to avoid problems; each require some code, even though not necessarily protocols. Note that this is pretty much identical to how ISATAP is kickstarted with one simplification: - DNS lookup for something like 'tunnel-service"; if DNS search order is set, this is results in an A record. - a DHCPv4 option. - anycast-routed address, whether from private IPv4 address space, or from global address space (e.g. a /29 which is known to be unrouted in the DFZ). -- 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 Nov 26 08:00:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05278 for ; Wed, 26 Nov 2003 08:00:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOzET-000AR7-Cw for v6ops-data@psg.com; Wed, 26 Nov 2003 12:57:25 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOzEH-000AQT-77 for v6ops@ops.ietf.org; Wed, 26 Nov 2003 12:57:13 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQCvBM01846 for ; Wed, 26 Nov 2003 14:57:11 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 14:56:35 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 14:56:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Wed, 26 Nov 2003 14:56:34 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195094A28@esebe024.ntc.nokia.com> Thread-Topic: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Thread-Index: AcO0GRiVBEoOuUYdR8mnmwPlEUDH3gAAlmgQ From: To: , Cc: , , X-OriginalArrivalTime: 26 Nov 2003 12:56:35.0232 (UTC) FILETIME=[B8FF2A00:01C3B41C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, > Certainly. But this is no problem. You can get that information > using some means, e.g. SNMP. I don't know which kind of interfaces > 3GPP boxes have, and which kind management systems they connect to, > but I'm pretty sure there can be ways to extract that information. But this is a problem. The new solution has to be specified and = implemented. This is not a trivial process. The boxes (and most probably = are) of different vendors and implementing something like this and = integrating it to the current networks is not a trivial task.=20 So, theoretically everything is possible but practically this is not an = option. Automatic tunneling would be much better fit in this case. >=20 > > > if for no other reason, but because it's tunneled back from the=20 > > > foreign network. =20 > >=20 > > =3D> I don't get this. >=20 > I mean, I understand foreign 3GPP operators use something=20 > like L2TP to=20 > transport the IPv4 packets back to the home operator, correct? =20 Not quite. The mobility management and roaming are based on GPRS = Tunneling Protocol. It works a bit different than how I would assume = roaming works in the fixed network. > The=20 > home operator has to have some kind of policy to who will be allowed=20 > in its network, i.e., when decapsulating the L2TP stream from the=20 > foreign operator, the 3GPP operator should check the source addresses=20 > of the packets (or at least do something to check that the=20 > packets are=20 > valid, for billing etc. reasons if for nothing else). The policy is enforsed at the PDP Context activation time and GPRS = attach time point. If the GGSN is at the home network (even when the = user is roaming) the IP address is allocated from the home GGSN. Thus, = if the PDP Context could be activated it means that the user has the = right to use the IP services of that GGSN and the network where the GGSN = is. There is a short summary how GPRS works at RFC3314. > On the contrary, there is no reason to bless a solution (and impose > the burden of the solution on everyone eelse) that some have chosen > because they didn't think of alternative ways to achieve the result. >=20 > > =3D> We can't assume that it is not well understood > > because one person made a mistake. >=20 > I can read myself, and I can say for sure that it isn't well=20 > understood. :-) >=20 > > It is implemented > > on 4 different products that I know of (2 host platforms > > and two router platforms) and are all interoperable.=20 >=20 > Implementatable & interoperable is VERY FAR from being well > understood. We have to look at this. However, I have come to the same conclusion = about the implementation status of ISATAP. Maybe some vendors that have = implemented ISATAP could indicate which version of the ISATAP they are = shipping. Cheers, Jonne. From owner-v6ops@ops.ietf.org Wed Nov 26 08:47:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06654 for ; Wed, 26 Nov 2003 08:47:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOzxc-000Cqf-4h for v6ops-data@psg.com; Wed, 26 Nov 2003 13:44:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOzxP-000CqE-80 for v6ops@ops.ietf.org; Wed, 26 Nov 2003 13:43:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQDhk209108; Wed, 26 Nov 2003 15:43:46 +0200 Date: Wed, 26 Nov 2003 15:43:46 +0200 (EET) From: Pekka Savola To: Jonne.Soininen@nokia.com cc: H.Soliman@flarion.com, , , Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <2D3EB51EAED985419D54AB340A9D0195094A28@esebe024.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 26 Nov 2003 Jonne.Soininen@nokia.com wrote: > > Certainly. But this is no problem. You can get that information > > using some means, e.g. SNMP. I don't know which kind of interfaces > > 3GPP boxes have, and which kind management systems they connect to, > > but I'm pretty sure there can be ways to extract that information. > > But this is a problem. The new solution has to be specified and > implemented. This is not a trivial process. The boxes (and most > probably are) of different vendors and implementing something like > this and integrating it to the current networks is not a trivial > task. Which implemenation are you refering to? You probably wouldn't need to touch 3GPP systems; more probably, all you'd have to is to modify the tunnel router (which could be just a PC, a regular IPv6 router, or whatever). The biggest task I see is identifying the methods which could be used to extract the information about IPv4 addresses from existing systems. I'm sure e.g. billing and accounting systems *DO* exist ;-), so that may be one "hook" to the current systems. > So, theoretically everything is possible but practically this is not > an option. Automatic tunneling would be much better fit in this > case. Right. I can see that in some cases, digging the information out of the network could be painful, and folks might want to avoid that. That's why I mentioned the second possibility: modification to the tunnel decapsulation code, that receiving a packet with a source IPv4 address causes the allocation of a new configured tunnel interface, and triggers the advertisement of an IPv6 prefix. Not a big deal. This could also be implemented as one "configured tunnel set-up pseudointerface" if one wishes. The point is that it's just a simple configured tunnel from the user's perspective, and as much as possible, also from the ISP's perspective. > > I mean, I understand foreign 3GPP operators use something > > like L2TP to > > transport the IPv4 packets back to the home operator, correct? > > Not quite. The mobility management and roaming are based on GPRS > Tunneling Protocol. It works a bit different than how I would assume > roaming works in the fixed network. Oh, that's was what I meant; I assume the concepts are pretty similar. > > The > > home operator has to have some kind of policy to who will be allowed > > in its network, i.e., when decapsulating the L2TP stream from the > > foreign operator, the 3GPP operator should check the source addresses > > of the packets (or at least do something to check that the > > packets are > > valid, for billing etc. reasons if for nothing else). > > The policy is enforsed at the PDP Context activation time and GPRS > attach time point. If the GGSN is at the home network (even when the > user is roaming) the IP address is allocated from the home GGSN. > Thus, if the PDP Context could be activated it means that the user > has the right to use the IP services of that GGSN and the network > where the GGSN is. There is a short summary how GPRS works at > RFC3314. Right. So, the users, even when roaming, get the IP address from the home GGSN. So the addresses used by the users are known at least by the home GGSN, and probably also some other accounting/billing databases etc. If one doesn't provide the users a static IPv4 address, it may not be a requirement to provide a static IPv6 prefix (especially if the GGSNs etc. don't support v6 yet) either, right? In such a case, it'd probably be enough to just give everyone a v6 prefix either sequentially or depending on the v4 address, e.g. using the STEP "ad-hoc" mechanism. With that kind of "trick", the tunnel router would not have to get the user/IP-address/v6-prefix information from anywhere, but the tunnels would function as if they were configured tunnels, and the UE's would not even know the tunnel router is doing some "magic tricks" to generate configured tunnels. But that v6 prefix advertisement can be done over a configured tunnel (to some definition of "configured" at least :-) to the UE even with dynamic 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 Wed Nov 26 10:01:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09261 for ; Wed, 26 Nov 2003 10:01:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AP16Q-000GSd-Nd for v6ops-data@psg.com; Wed, 26 Nov 2003 14:57:14 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AP16E-000GSH-C4 for v6ops@ops.ietf.org; Wed, 26 Nov 2003 14:57:02 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 09:57:02 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042034@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , Jonne.Soininen@nokia.com Cc: karim.el-malki@ericsson.com, v6ops@ops.ietf.org, jasko@fakat.com Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Wed, 26 Nov 2003 09:56:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > But this is a problem. The new solution has to be specified and > > implemented. This is not a trivial process. The boxes (and most > > probably are) of different vendors and implementing something like > > this and integrating it to the current networks is not a trivial > > task. > > Which implemenation are you refering to? You probably wouldn't need > to touch 3GPP systems; more probably, all you'd have to is to modify > the tunnel router (which could be just a PC, a regular IPv6 > router, or > whatever). => A PC ??? Come on... The routers used to connect the GGSN to are BIG! 3GPP or not, a core router used in a telecommunications network is required to be reliable. Now, you said you did product development before, so think about how long it takes to specify a solution on a product level, order a project, allocate resources, develop it, test it then release it and support it. Think about that and then try to convince someone who already developed another solution to remove it and adopt this new idea that you propose (which we certainly don't understand fully yet). A much easier process is to ask for WG concensus on this issue and follow whatever the WG wants to do. > > Right. So, the users, even when roaming, get the IP address > from the > home GGSN. So the addresses used by the users are known at least by > the home GGSN, and probably also some other accounting/billing > databases etc. > > If one doesn't provide the users a static IPv4 address, it > may not be > a requirement to provide a static IPv6 prefix (especially if > the GGSNs > etc. don't support v6 yet) either, right? > > In such a case, it'd probably be enough to just give everyone a v6 > prefix either sequentially or depending on the v4 address, > e.g. using > the STEP "ad-hoc" mechanism. > > With that kind of "trick", the tunnel router would not have > to get the > user/IP-address/v6-prefix information from anywhere, but the tunnels > would function as if they were configured tunnels, and the UE's would > not even know the tunnel router is doing some "magic tricks" to > generate configured tunnels. => Pekka, I hope you realise how many assumptions you are making and assuming that this is _the_ way it should be. Again, is all this worth it? I don't think so. It'd be really great if there is a concensus call on this issue so that we can decide whether we _have_ to look at other options or simply take what we have now. Why not ask the WG? Hesham From owner-v6ops@ops.ietf.org Wed Nov 26 10:16:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11116 for ; Wed, 26 Nov 2003 10:16:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AP1ML-000HN2-Ai for v6ops-data@psg.com; Wed, 26 Nov 2003 15:13:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AP1M8-000HLv-7F for v6ops@ops.ietf.org; Wed, 26 Nov 2003 15:13:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQFDL711087; Wed, 26 Nov 2003 17:13:21 +0200 Date: Wed, 26 Nov 2003 17:13:21 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: Jonne.Soininen@nokia.com, , , Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042034@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 26 Nov 2003, Soliman Hesham wrote: > > Which implemenation are you refering to? You probably wouldn't need > > to touch 3GPP systems; more probably, all you'd have to is to modify > > the tunnel router (which could be just a PC, a regular IPv6 > > router, or > > whatever). > > => A PC ??? Come on... The routers used to connect the GGSN to are > BIG! 3GPP or not, a core router used in a telecommunications network > is required to be reliable. If the number of customers was high, the operator would deploy native, minial IPv6 support. The current IPv6 usage statistics suggest otherwise. If it the number of customers is low, I would be rather doubtful that the number of IPv6 users would be counted e.g. in hundreds of thousands in the first phases where tunneling from the UE is a reasonable solution. But in any case, whether the router is a PC or something else is rather irrelevant; the point is that it's probably some standard ISP industry equipment without a 3GPP "price added" tag. > Now, you said you did product development before, so think about how > long it takes to specify a solution on a product level, order a > project, allocate resources, develop it, test it then release it and > support it. Think about that and then try to convince someone who > already developed another solution to remove it and adopt this new > idea that you propose (which we certainly don't understand fully > yet). Are we asking anyone to remove anything? Is it the IETF's fault if someone wastes resources in a dead-end solution? In any case, resources needed for a "simple" product, like the one I described, would be rather minimal. (I agree that we probably don't understand the idea I proposed fully, but because the idea itself is simple, and the method operates with very strict premises (compared to e.g. ISATAP), I suspect it will be relatively easy to understand it in a very short order.) [[ whether or not now is the appropriate time to call for WG consensus on which way to go remains to be considered ]] -- 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 Nov 26 10:28:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11815 for ; Wed, 26 Nov 2003 10:28:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AP1Yt-000ICp-Ed for v6ops-data@psg.com; Wed, 26 Nov 2003 15:26:39 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AP1YA-000IAJ-P4 for v6ops@ops.ietf.org; Wed, 26 Nov 2003 15:25:55 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAQFPYI2019317; Wed, 26 Nov 2003 16:25:34 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 16:25:34 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639958@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Jonne.Soininen@nokia.com'" , pekkas@netcore.fi, H.Soliman@flarion.com Cc: v6ops@ops.ietf.org, jasko@fakat.com Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Wed, 26 Nov 2003 16:25:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > It is implemented > > > on 4 different products that I know of (2 host platforms > > > and two router platforms) and are all interoperable. > > > > Implementatable & interoperable is VERY FAR from being well > > understood. > > We have to look at this. However, I have come to the same > conclusion about the implementation status of ISATAP. Maybe > some vendors that have implemented ISATAP could indicate > which version of the ISATAP they are shipping. I think this is a good idea and would take it a step further. If the ISATAP authors are willing to analyse what has been implemented to possibly simplify the spec and address some other concerns (e.g. host-to-host) that would be the best outcome. /Karim From owner-v6ops@ops.ietf.org Wed Nov 26 10:29:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11855 for ; Wed, 26 Nov 2003 10:29:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AP1Zy-000IED-Jd for v6ops-data@psg.com; Wed, 26 Nov 2003 15:27:46 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AP1Zm-000IDr-LD for v6ops@ops.ietf.org; Wed, 26 Nov 2003 15:27:34 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 10:27:33 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042035@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Jonne.Soininen@nokia.com, karim.el-malki@ericsson.com, v6ops@ops.ietf.org, jasko@fakat.com Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] Date: Wed, 26 Nov 2003 10:27:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > But in any case, whether the router is a PC or something else is > rather irrelevant; the point is that it's probably some standard ISP > industry equipment without a 3GPP "price added" tag. => So what? It still needs to be developed. And this takes time. Unless people agree that the current alternative is unworkable it wouldn't make sense to start new work. > Are we asking anyone to remove anything? Is it the IETF's fault if > someone wastes resources in a dead-end solution? => That's your opinion. And this is why I want to know if it's a WG opinion as well. We can't have specs hanging for years and expect people to wait for IETF to produce the utopian solution before they can roll out products. Definitely not for a transition tool! The fact that several vendors developed it tells me that they understand it and are happy to roll it out. In any case, > resources needed for a "simple" product, like the one I described, > would be rather minimal. => There is a minimum development cost that is independent of whether you're adding an if statement or 10,000 loc. People won't do that minimum unless they are convinced that the alternative is unworkable. > [[ whether or not now is the appropriate time to call for WG > consensus > on which way to go remains to be considered ]] => I'll wait till that concensus call is made then. Hesham From owner-v6ops@ops.ietf.org Thu Nov 27 11:53:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12576 for ; Thu, 27 Nov 2003 11:53:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APPIz-000C9v-ES for v6ops-data@psg.com; Thu, 27 Nov 2003 16:47:49 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APPIk-000C8a-7g for v6ops@ops.ietf.org; Thu, 27 Nov 2003 16:47:34 +0000 Received: from fakat.com (pc5205203.nac.telia.se [131.115.205.203]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id hARGlMDc001271; Thu, 27 Nov 2003 17:47:23 +0100 (CET) (envelope-from jasko@fakat.com) Message-ID: <3FC62A9A.6030508@fakat.com> Date: Thu, 27 Nov 2003 17:47:22 +0100 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Soliman Hesham , Jonne.Soininen@nokia.com, karim.el-malki@ericsson.com, v6ops@ops.ietf.org Subject: Re: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE] References: In-Reply-To: X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > [[ whether or not now is the appropriate time to call for WG consensus > on which way to go remains to be considered ]] > and here are the requirements that have been expressed on this list so far: http://www.imslab.net/draft-mulahusic-ue-tunneling-reqs-00.txt if we have an existing mechanism that can fulfil those, let's recommend it and move on. if we don't have one let's say so and move on. i don't see where we'll get by holding up this spec because of this issue? after all, the spec states clearly that the native v6 is the best way to go. jasminko From owner-v6ops@ops.ietf.org Thu Nov 27 12:40:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13475 for ; Thu, 27 Nov 2003 12:40:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APQ4j-000Etw-TQ for v6ops-data@psg.com; Thu, 27 Nov 2003 17:37:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APQ4V-000EsB-BN for v6ops@ops.ietf.org; Thu, 27 Nov 2003 17:36:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hARHajZ05749; Thu, 27 Nov 2003 19:36:45 +0200 Date: Thu, 27 Nov 2003 19:36:45 +0200 (EET) From: Pekka Savola To: Jasminko Mulahusic cc: Soliman Hesham , , , Subject: UE tunneling requirements [Re: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE]] In-Reply-To: <3FC62A9A.6030508@fakat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for putting the document together. Highest order bit first: > i don't see where we'll get by holding up this spec because of this > issue? after all, the spec states clearly that the native v6 is the > best way to go. .. I certainly don't require holding the spec on this -- if the text is generic enough not to presuppose solutions, that would probably be fine by me.. On Thu, 27 Nov 2003, Jasminko Mulahusic wrote: > > [[ whether or not now is the appropriate time to call for WG consensus > > on which way to go remains to be considered ]] > > > > and here are the requirements that have been expressed on this list so far: > > http://www.imslab.net/draft-mulahusic-ue-tunneling-reqs-00.txt > > if we have an existing mechanism that can fulfil those, let's recommend > it and move on. > > if we don't have one let's say so and move on. some quick comments: ==> the requirement numbers go back to R3 after R5.. R2: Not requiring modification of the existing equipment The tunneling mechanism should not require that the existing network elements be upgraded or modified. I.e., additional and new nodes might be required to be placed somewhere in the network, but the assumption that the existing ones can be upgraded or modified to support new features, cannot and should not be made. ==> you should be more specific about that. You refer to 3GPP network equipment, correct? UE's would still be a fair game, naturally? The tunneling mechanism should work regardless if the client has a dynamic address, that can change over time, or a static address. It can not be assumed that the DHCP has been used when the client was assigned the dynamic address. ==> why can't you assume DHCP w/ dynamic address? Maybe using some 3GPP variant here, or what? spell it out.. R3: User may be located behind a NAT The UE might have been assigned an private address. It cannot be assumed that the user can control the NAT. Neither can it be assumed that any other part involved in the tunnel set up procedure will be able to control the NAT. ==> this should be clearer whether you require that the mechanism must be able to operate using private IPv4 addresses (there being a NAT *somewhere*), or whether the mechanism must also work when there is a NAT box between the UE and the 3GPP home operator's equipment (i.e., ISATAP wouldn't work either). May need serious reword. R3: Host-to-host vs. client-server communication The network operator should be able to decide wheater to allow direct host-to-host communication between UEs or wheather all packets will have to traverse the tunnel end-point. ==> this has to be reworded. You haven't even established a requirement for host-to-host tunneling, right? If that's done, on the other hand, there may be a requirement to be able to control it. ("client-server" -> "host-to-router" but that's inaccurate as well, because the UE could very well be a router) ==> additional requirements, maybe: - should one be able to have UE act as a router/bridge, to connect more nodes; i.e. should more than just one address be assigned to the UE. - you don't mention things like "simplicity", "security", as requirements at all. These are about number ones in my book. These are rather complex requirements, though, because they operate in so many layers (simplicity specification-wise, simplicity implementation-wise, simplicity operationally, etc.). - you do not mention whether the user should be able to get a static v6 address if its ipv4 address is dynamic. Maybe this is not a requirement (I don't see it s one myself) -- maybe there should be a non-requirements section? -- 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 Nov 27 22:27:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29900 for ; Thu, 27 Nov 2003 22:27:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APZCJ-000IzB-6B for v6ops-data@psg.com; Fri, 28 Nov 2003 03:21:35 +0000 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APZBy-000IyJ-2t for v6ops@ops.ietf.org; Fri, 28 Nov 2003 03:21:14 +0000 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hAS3GPpc021050 for ; Fri, 28 Nov 2003 11:16:27 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Nov 28 11:24:01 2003 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 11:24:00 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: how to get DNS server address Date: Fri, 28 Nov 2003 11:24:00 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EC73@bellnet-mail3.sbell.com.cn> Thread-Topic: how to get DNS server address Thread-Index: AcO1Xw5I+MoRZewARVWA3VXF5+Gi/g== From: "CTO WEI Renxiang" To: X-OriginalArrivalTime: 28 Nov 2003 03:24:00.0749 (UTC) FILETIME=[10F491D0:01C3B55F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, IPv6 support both stateless(no DHCP) and stateful(DHCP) configuration, = but DNS server address can only be obained through DHCP. How to get DNS = server address in stateless configuration mode?=20 Thanks. Renxiang Wei From owner-v6ops@ops.ietf.org Fri Nov 28 00:01:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02054 for ; Fri, 28 Nov 2003 00:01:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APahU-000NPL-7D for v6ops-data@psg.com; Fri, 28 Nov 2003 04:57:52 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APahC-000NOF-Qs for v6ops@ops.ietf.org; Fri, 28 Nov 2003 04:57:35 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HP100801PRXER@mailout1.samsung.com> for v6ops@ops.ietf.org; Fri, 28 Nov 2003 13:57:33 +0900 (KST) Received: from ep_mmp2 (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 <0HP100611PRWC0@mailout1.samsung.com> for v6ops@ops.ietf.org; Fri, 28 Nov 2003 13:57:32 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HP1006NHPRVLH@mmp2.samsung.com> for v6ops@ops.ietf.org; Fri, 28 Nov 2003 13:57:32 +0900 (KST) Date: Fri, 28 Nov 2003 13:58:02 +0900 From: Soohong Daniel Park Subject: RE: how to get DNS server address In-reply-to: <8634B809B90D6E4AACA4AB0562A1F07205EC73@bellnet-mail3.sbell.com.cn> To: "'CTO WEI Renxiang'" , v6ops@ops.ietf.org Cc: "'Soohong Daniel Park'" Message-id: <001701c3b56c$33bf5b20$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_10 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > IPv6 support both stateless(no DHCP) and stateful(DHCP) > configuration, Yes ! > but DNS server address can only be obained through DHCP. Never ! > How to get DNS server address in stateless configuration mode? This issue has being discussed in DNSOP WG mailing list... Please move to there... http://www.cafax.se/dnsop/maillist/ Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics From owner-v6ops@ops.ietf.org Fri Nov 28 04:43:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19809 for ; Fri, 28 Nov 2003 04:43:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APf5R-0009IX-Av for v6ops-data@psg.com; Fri, 28 Nov 2003 09:38:53 +0000 Received: from [195.37.70.2] (helo=tokyo.ccrle.nec.de) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APf5E-0009I6-Vw for v6ops@ops.ietf.org; Fri, 28 Nov 2003 09:38:41 +0000 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hAS9ccD1085782 for ; Fri, 28 Nov 2003 10:38:39 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hAS9bCQk085738 for ; Fri, 28 Nov 2003 10:37:12 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hAS9bACx085733; Fri, 28 Nov 2003 10:37:12 +0100 (CET) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5A96EE30A2; Fri, 28 Nov 2003 10:37:09 +0100 (CET) Date: Fri, 28 Nov 2003 10:36:06 +0100 From: Martin Stiemerling To: CTO WEI Renxiang , v6ops@ops.ietf.org Subject: Re: how to get DNS server address Message-ID: <6636452.1070015766@[10.1.1.109]> In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07205EC73@bellnet-mail3.sbell.com.cn> References: <8634B809B90D6E4AACA4AB0562A1F07205EC73@bellnet-mail3.sbell.com. cn> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Freitag, 28. November 2003 11:24 +0800 CTO WEI Renxiang wrote: | Hi, | | IPv6 support both stateless(no DHCP) and stateful(DHCP) configuration, | but DNS server address can only be obained through DHCP. How to get DNS | server address in stateless configuration mode? You can get the DNS server information (as well as any other service information) via DHCP even in IPv6 stateless address autoconfiguration. For this you have to use the O flag in the router advertisements (RA) and a DHCP server in stateless mode. With the O flag set in the RA the client should consult a DHCP server for further information, for instance DNS server's address. Martin | | Thanks. | | Renxiang Wei | Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de