From owner-ipng@sunroof.eng.sun.com Thu Aug 1 04:04:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71B4FoN022091; Thu, 1 Aug 2002 04:04:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71B4Euh022090; Thu, 1 Aug 2002 04:04:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71B4BoN022083 for ; Thu, 1 Aug 2002 04:04:11 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02601 for ; Thu, 1 Aug 2002 04:04:15 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01424 for ; Thu, 1 Aug 2002 05:03:48 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g71B2uG04003; Thu, 1 Aug 2002 18:02:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g71B1qc13211; Thu, 1 Aug 2002 18:01:59 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Bob Hinden cc: "Richard Draves" , "Thomas Narten" , ipng@sunroof.eng.sun.com Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Aug 2002 18:01:52 +0700 Message-ID: <13209.1028199712@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 31 Jul 2002 14:36:15 -0700 From: Bob Hinden Message-ID: <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> | Sorry, I wasn't clear. Keep the load-sharing that applies to routers of | equal priority in the router-selection draft. Load-sharing should be done | in these cases. The text that applies to the basic ND default-router case | should be removed as it would duplicate the load-sharing draft. I'm still not clear what this means. I really think that one doc for both of these is what is desirable. I suspect that part of the problem is that the relationship (or at least what I would like the relationship to be) isn't clear. That is, if load sharing is done, router preferences MUST be done as well. So, whatever status we give to load sharing, router preferences has to have at least the same status. I'm not sure that got adequately represented in the draft. The reason is that it simply isn't acceptable for nodes to start broadcasting packets over all routers on the link at random. If we don't have load balancing, it is possible to arrange for the "right" routers to get used (though in situations where load balancing would help, the net loses). If we have some kind of mandatory load balancing however, there needs to be a way for the net administrator to control it, and router prefs are that way - we can load balance amongst the preferred routers, and just ignore the others we're not going to choose anyway. Splitting this back into 2 docs will, I suspect, revert to the situation we had before, where "everyone has to implement load balancing" (because if they don't, it is useless), but router prefs are optional (because people keep wondering if it is possible to configure them properly, which is bizarre, but never mind). Keep it as one, but get the requirements right. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 04:54:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71Bs4oN022300; Thu, 1 Aug 2002 04:54:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71Bs3Nk022299; Thu, 1 Aug 2002 04:54:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71Bs0oN022292 for ; Thu, 1 Aug 2002 04:54:00 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11542 for ; Thu, 1 Aug 2002 04:54:05 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19908 for ; Thu, 1 Aug 2002 05:53:50 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g71BqiG14503; Thu, 1 Aug 2002 18:52:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g71Bpwc13285; Thu, 1 Aug 2002 18:51:58 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Thomas Narten cc: "Richard Draves" , ipng@sunroof.eng.sun.com, "Bob Hinden" Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: <200207311912.g6VJCIV16013@rotala.raleigh.ibm.com> References: <200207311912.g6VJCIV16013@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Aug 2002 18:51:58 +0700 Message-ID: <13283.1028202718@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 31 Jul 2002 15:12:18 -0400 From: Thomas Narten Message-ID: <200207311912.g6VJCIV16013@rotala.raleigh.ibm.com> | Section 4 has some "mays", some of which might better be | should/SHOULDs. I.e., an admin SHOULD set a low priority if the router | doesn't reach the internet (due to connectivity or firewall). Thomas, the point of the SHOULD etc words is to tell the implementor what to implement. They're not at all effective in attempting to control how people actually configure the equipment. And in any case, this is certainly not the doc to be attempting to tell people how to do that - if you want a BCP on setting up IPv6 routers in nice ways, then get someone to write one (as well as what prefs to set, and when, it could go into what lifetimes to use in various situations, etc). But none of that belongs here (or not pretending to be any more than general commentary so the implementor can understand what the user might want to do with the implementation). | Does it ever make sense to advertise a high preference in the absence | of more detailed knowledge of the topology? "None of your business." I will configure the preferences of the routers I manage in the way that makes my net work for me. All that is needed of the IETF is to provide the tool for me to use (and if you also want to give some "good usage" advice, that's OK as well, but it should not be as part of the protocol spec). | Also, in chatting with Erik Nordmark, he indicated that at one point | there were some discussions about adding a client capability to have a | map table that mapped received preferences into other values, to | handle situations where the received preferences didn't have the | desired result. Would that be a useful thing to have? Maybe. But this is a quality of implementation issue. I think this kind of thing only matters when one is attempting to specify things like "if I see any normal or high pref routers on interface A, that's what I want to use as my default, but if all I see is low, and there is a high pref router on interface B, then use that one" ... All this is really beyond the scope of the protocol of router prefs though. | One problem with the above is you assume that the implementor has | knowledge about the enivironments in which technology will be | deployed, and can thus make such tradeoffs. Naturally. This applies to all implementation choices in just about everything, from how much RAM is (and can be) installed, to what protocols are supported. If the implementor hasn't implemented the protocols with the features that are required, or in the way that makes sense for a particular environment, then that implementation should not be used there. | It would be better if the spec did not allow poor implementation | choices (that have undesirable consequences on the internet) to be | considered "in conformance with the standard". If they actually have undesirable consequences for the internet, I'd agree. But I don't see that here, only possibly undesirable consequences for the customer who installed the equipment. Given that, thanks for caring, but I want to be able to acquire cheap implementations when those are adequate for my purposes. | > You mean you don't understand the distinction between "best default | > router" and "best router for default"? | | Its a subtle distinction and the terms used to distinguish are not | very intuitive. It isn't that subtle, but it is also not very important in most cases. It sounds as if it should be, but unless the implementation is ignoring redirects, it isn't the volume of traffic that matters, but the number of different destinations. Then the best default router, and the best route to default, tend to be the same thing (you get one redirect for each local destination, and use that redirect to send large amounts of traffic), you get no redirects for the large numbers of different destinations all over the net, to each of which you probably send almost no traffic at all. That's better than no redirects for the comparatively smaller number of local hosts, and lots of redirects for all the rest, or it is in many cases. If we had "redirect this prefix" instead of just "redirect this address" then there would be almost no rationale at all for splitting the two concepts. "Type C" hosts (which will probably turn out to be most of them) won't care anyway, they'll see the routes announced, and rarely ever see any kind of redirect. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 05:01:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71C1NoN022335; Thu, 1 Aug 2002 05:01:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71C1NPO022334; Thu, 1 Aug 2002 05:01:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71C1KoN022327 for ; Thu, 1 Aug 2002 05:01:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13234 for ; Thu, 1 Aug 2002 05:01:24 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22399 for ; Thu, 1 Aug 2002 06:01:23 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA29199; Thu, 1 Aug 2002 14:59:34 +0300 Date: Thu, 1 Aug 2002 14:59:34 +0300 Message-Id: <200208011159.OAA29199@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: hinden@iprg.nokia.com, richdr@microsoft.com, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <13209.1028199712@munnari.OZ.AU> (message from Robert Elz on Thu, 01 Aug 2002 18:01:52 +0700) Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt References: <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> <13209.1028199712@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > Date: Wed, 31 Jul 2002 14:36:15 -0700 > From: Bob Hinden > Message-ID: <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> > > | Sorry, I wasn't clear. Keep the load-sharing that applies to routers of > | equal priority in the router-selection draft. Load-sharing should be done > | in these cases. The text that applies to the basic ND default-router case > | should be removed as it would duplicate the load-sharing draft. If we have two routes prefix1/K -> router1 prefix2/L -> router2 with K < L, and such that prefix1/K == prefix2/K (e.g. shorter prefix also covers addresses of the longer prefix). - which is more significant priority or prefix length? - if router2 is not reachable, obviously packets matching prefix2/L can be sent to router1. But, is there any advice on algorithm how the system detects if router2 becomes available? Just wait for RA? Probe with some logic?. (There is no RA in IPv4 -- I think this should work for IPv4 too!) Note: default routes are just a special case where K=0 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 06:09:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71D9poN022407; Thu, 1 Aug 2002 06:09:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71D9pB1022406; Thu, 1 Aug 2002 06:09:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71D9moN022399 for ; Thu, 1 Aug 2002 06:09:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04761 for ; Thu, 1 Aug 2002 06:09:52 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25319 for ; Thu, 1 Aug 2002 06:09:51 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g71DLef14293 for ; Thu, 1 Aug 2002 16:21:40 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 1 Aug 2002 16:09:46 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 1 Aug 2002 16:09:45 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 1 Aug 2002 16:09:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2395C.B444A60C" Subject: Flow label draft issues & new text Date: Thu, 1 Aug 2002 16:09:44 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757D3104D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcI5XLvPO8UiUXhmRIymWAZOIywpfw== To: Cc: , , , , X-OriginalArrivalTime: 01 Aug 2002 13:09:45.0458 (UTC) FILETIME=[B4E69520:01C2395C] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2395C.B444A60C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have gone through all the flow label related issues raised on the list = during the last month. In my opinion there were no big issues, but some = clarifications in the text were necessary. I have included a new = revision of the text, with the summary of the changes below. I'd like you to raise any objections you may have against the changes = ASAP, so that we can get the document finished. Jarno <>=20 Summary of changes since -02: Abstract: - Added a paragraph to the Abstract to shortly motivate the Flow Label = usage 1. Terminology and Definitions: - Changed the definition of "Classifier" to the definition of a "Flow = classifier" - Flow: Deleted "(s)" from "destination(s)", as a multicast destination = does not need the plural form. This change applied elsewhere as well. - Flow state: added "More than one flow can map to the same flow state." = to clarify the relation between a flow and flow state. - Flow state establishment method: Changed "source" to "source or = destination" 4. Flow Labeling Requirements: - Added "in the order of precedence" before the numbered list of ways of = labeling flows to clarify that e.g. (1) (if implemented and applicable!) = takes precedence over (4), even though (1) is a MAY and (4) is a SHOULD. - Added "If multiple flow classifiers map to the same flow state it may = be desirable to minimize the amount of state and use the same Flow Label = value with all such classifiers." - to clarify the text about using the same Flow Label value for = multiple address pairs. - Changed language from "verifying" and "new" to "selecting" and = "unique" in relation to the 'facility' to be more precise. - Changed from: "When a dynamically instantiated flow terminates, its Flow Label value = MUST NOT be reused until it is certain that all associated state has = been deleted from all nodes on the path. With some flow state = establishment methods signaling new state may be sufficient. A mechanism = with a sufficiently long timeout period before reusing the Flow Label = values can also be used." to: "Any Flow Label value not currently assigned by the facility can be = assigned by the facility at any time. Accidental Flow Label value reuse = SHOULD be prevented by not deleting the flow from the facility before it = is certain that all associated flow specific state has been deleted from = all relevant nodes. Collisions due to accidental node reboots SHOULD be = minimized by utilizing a random initial value for the Flow Label being = assigned by the facility. The method by which the flow state is cleared from the IPv6 nodes is to = be defined by the flow state establishment method used to set up the = state. This implies that IPv6 nodes SHOULD NOT establish any = flow-specific state unless so instructed by a specific flow state = establishment method. With some flow state establishment methods, = signaling new state simultaneously clearing the old state from the new = path may be sufficient. A mechanism with a sufficiently long timeout = period before reusing the Flow Label values can also be used." This should settle the discussion on the list about flow label value = reuse, timeouts, etc. 5. Flow State Establishment Requirements: - Changed from:=20 "(e.g. SCTP flows with multiple addresses at either end-points, or a = diffserv classifier with an address range. See ..." to: "(e.g. an SCTP connection between nodes with multiple addresses, or a = classifier with an address range, see ..." to clarify the text. - Removed the requirement (6). This was due to feedback from the NSIS = WG, and due to the realization that exact method by which a migrating = flow is identified is immaterial to the flow label spec itself. Any form = of a globally unique "session id" could be used, and it does not need to = be related to IP addresses. Furthermore, it is up to the flow state = establishment methods to define if they support flow migration or not. Security Considerations: - Removed the first paragraph. The argument against it was that the flow = label field does not add any new vulnerability, compared to the case = without the flow label field usage. Finer granularity analysis can = already be performed based on the other protocols fields. Informative References: - Removed the reference to the personal draft ------_=_NextPart_001_01C2395C.B444A60C Content-Type: text/plain; name="draft-ietf-ipv6-flow-label-xx.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ipv6-flow-label-xx.txt Content-Disposition: attachment; filename="draft-ietf-ipv6-flow-label-xx.txt" SVB2NiBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgSi4gUmFqYWhhbG1lDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9raWENCjxkcmFmdC1pZXRmLWlwdjYtZmxvdy1s YWJlbC14eC50eHQ+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBDb250YQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBU cmFuc3dpdGNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCLiBDYXJwZW50ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElCTQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBEZWVy aW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2lzY28NCkV4cGlyZXM6IEZlYnJ1YXJ5IDIwMDMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwMg0KDQoNCiAgICAgICAgICAgICAg ICAgICAgIElQdjYgRmxvdyBMYWJlbCBTcGVjaWZpY2F0aW9uDQogICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1pcHY2LWZsb3ctbGFiZWwteHgudHh0DQoNCg0KU3RhdHVzIG9mIHRoaXMgbWVt bw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBzdWJqZWN0 IHRvIGFsbCBwcm92aXNpb25zDQogICBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLiBOb3RlIHRoYXQgb3RoZXINCiAgIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQog ICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzIGF0IGFueQ0KICAgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJu ZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv MWlkLWFic3RyYWN0cy5odG1sDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRv dyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwNCg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0 aGUgdXNhZ2Ugb2YgdGhlIElQdjYgRmxvdyBMYWJlbCBmaWVsZCwgdGhlDQogICByZXF1aXJlbWVu dHMgZm9yIElQdjYgc291cmNlIG5vZGVzIGxhYmVsaW5nIGZsb3dzLCBhbmQgdGhlDQogICByZXF1 aXJlbWVudHMgZm9yIGZsb3cgc3RhdGUgZXN0YWJsaXNobWVudCBtZXRob2RzLg0KDQogICBUaGUg dXNhZ2Ugb2YgdGhlIEZsb3cgTGFiZWwgZmllbGQgZW5hYmxlcyBlZmZpY2llbnQgSVB2NiBmbG93 DQogICBjbGFzc2lmaWNhdGlvbiBiYXNlZCBvbmx5IG9uIElQdjYgbWFpbiBoZWFkZXIgZmllbGRz IGluIGZpeGVkDQogICBwb3NpdGlvbnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSYWphaGFs bWUsIGV0IGFsLiAgICAgICAgRXhwaXJlczogRmVicnVhcnkgMjAwMyAgICAgICAgICAgICAgICAg W1BhZ2UgMV0NCgwNCklOVEVSTkVULURSQUZUICAgICBkcmFmdC1pZXRmLWlwdjYtZmxvdy1sYWJl bC14eC50eHQgICAgICAgICBBdWd1c3QgMjAwMg0KDQoNCg0KMS4gIFRlcm1pbm9sb2d5IGFuZCBE ZWZpbml0aW9ucw0KDQogICBGbG93ICAgICAgICAgICAgICAgICAgIEEgc2VxdWVuY2Ugb2YgcmVs YXRlZCBwYWNrZXRzIHNlbnQgZnJvbSBhDQogICAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJj ZSB0byBhIHVuaWNhc3QsIGFueWNhc3QsIG9yIG11bHRpY2FzdA0KICAgICAgICAgICAgICAgICAg ICAgICAgICBkZXN0aW5hdGlvbi4gQSBmbG93IGNvdWxkIGNvbnNpc3Qgb2YgYWxsDQogICAgICAg ICAgICAgICAgICAgICAgICAgIHBhY2tldHMgaW4gYSBzcGVjaWZpYyB0cmFuc3BvcnQgY29ubmVj dGlvbiBvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICBhIG1lZGlhIHN0cmVhbS4gSG93ZXZl ciwgYSBmbG93IGlzIG5vdA0KICAgICAgICAgICAgICAgICAgICAgICAgICBuZWNlc3NhcmlseSAx OjEgbWFwcGVkIHRvIGEgdHJhbnNwb3J0DQogICAgICAgICAgICAgICAgICAgICAgICAgIGNvbm5l Y3Rpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgVGhpcyBkZWZpbml0aW9uIHNob3Vs ZCBub3QgYmUgY29uZnVzZWQgd2l0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgbW9y ZSByZXN0cmljdGl2ZSBkZWZpbml0aW9ucyBmb3IgImZsb3ciDQogICAgICAgICAgICAgICAgICAg ICAgICAgIGFuZCAibWljcm9mbG93IiBpbiBbUlNWUF0gYW5kIFtEaWZmU2Vydl0sDQogICAgICAg ICAgICAgICAgICAgICAgICAgIHJlc3BlY3RpdmVseS4gVGhpcyBkZWZpbml0aW9uIGluY2x1ZGVz LCBidXQgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgbm90IGxpbWl0ZWQgdG8gdGhlbS4N Cg0KICAgRmxvdyBjbGFzc2lmaWVyICAgICAgICBBbiBJUCBsYXllciBlbnRpdHkgdGhhdCBzZWxl Y3RzIHBhY2tldHMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgYmVsb25naW5nIHRvIGEgZmxv dyBiYXNlZCBvbiB0aGUgY29udGVudCBvZiBJUA0KICAgICAgICAgICAgICAgICAgICAgICAgICBo ZWFkZXIgZmllbGRzIGFjY29yZGluZyB0byBkZWZpbmVkIHJ1bGVzLg0KDQogICBGbG93IHN0YXRl ICAgICAgICAgICAgIFRoZSBpbmZvcm1hdGlvbiBzdG9yZWQgaW4gYW4gSVAgbm9kZSBkcml2aW5n DQogICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBmbG93IGNsYXNzaWZpY2F0aW9uIGFuZCB0 aGUgZmxvdy1zcGVjaWZpYw0KICAgICAgICAgICAgICAgICAgICAgICAgICB0cmVhdG1lbnQuIFRo ZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVj aWZpZWQgYnkgdGhlIG1ldGhvZCBkZWZpbmluZyB0aGUgZmxvdy0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgc3BlY2lmaWMgdHJlYXRtZW50LiBNb3JlIHRoYW4gb25lIGZsb3cgY2FuIG1hcA0K ICAgICAgICAgICAgICAgICAgICAgICAgICB0byB0aGUgc2FtZSBmbG93IHN0YXRlLg0KDQogICBG bG93IHN0YXRlICAgICAgICAgICAgIEEgY29udHJvbCBtZWNoYW5pc20gdXNlZCB0byBzZXQgdXAg dGhlIGZsb3cNCiAgIGVzdGFibGlzaG1lbnQgbWV0aG9kICAgc3RhdGUuIEEgZmxvdyBzdGF0ZSBl c3RhYmxpc2htZW50IG1ldGhvZCBjYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgYmUgZWl0 aGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgIC0gRHluYW1pYywgdW5kZXIgc291cmNlIG9y IGRlc3RpbmF0aW9uIG5vZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgY29udHJvbCAoZS5n LiBSU1ZQKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgLSBRdWFzaS1keW5hbWljLCB1bmRl ciBuZXR3b3JrIG1hbmFnZW1lbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgY29udHJvbCwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgLSBTdGF0aWMsIHRocm91Z2ggbWFudWFsIGNvbmZp Z3VyYXRpb24sIG9yDQogICAgICAgICAgICAgICAgICAgICAgICAgIC0gQWxnb3JpdGhtaWMgKGUu Zy4gbG9hZCBzcHJlYWRpbmcpDQoNCg0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1Qg Tk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNI T1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0K ICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjEx OS4NCg0KDQoyLiAgSW50cm9kdWN0aW9uDQoNCiAgIEEgZmxvdyBpcyBhIHNlcXVlbmNlIG9mIHJl bGF0ZWQgcGFja2V0cyBzZW50IGZyb20gYSBzb3VyY2UgdG8gYQ0KICAgdW5pY2FzdCwgYW55Y2Fz dCwgb3IgbXVsdGljYXN0IGRlc3RpbmF0aW9uLiBUbyBlbmFibGUgc3BlY2lmaWMNCiAgIHByb2Nl c3NpbmcgZm9yIHRoZSBmbG93LCBmbG93IHN0YXRlIG5lZWRzIHRvIGJlIGVzdGFibGlzaGVkIG9u IHRoZQ0KICAgbm9kZXMgcHJvdmlkaW5nIHRoZSBmbG93LXNwZWNpZmljIHRyZWF0bWVudC4gVGhl IGZsb3cgc3RhdGUgZGVmaW5lcw0KICAgd2hhdCBraW5kIG9mIHRyZWF0bWVudCBzaG91bGQgYmUg cHJvdmlkZWQsIGFuZCBob3cgdG8gY2xhc3NpZnkgdGhlDQogICBwYWNrZXRzIHRvIHRoZSBmbG93 Lg0KDQpSYWphaGFsbWUsIGV0IGFsLiAgICAgICAgRXhwaXJlczogRmVicnVhcnkgMjAwMyAgICAg ICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCklOVEVSTkVULURSQUZUICAgICBkcmFmdC1pZXRmLWlw djYtZmxvdy1sYWJlbC14eC50eHQgICAgICAgICBBdWd1c3QgMjAwMg0KDQoNCiAgIFRyYWRpdGlv bmFsbHksIGZsb3cgY2xhc3NpZmllcnMgaGF2ZSBiZWVuIGJhc2VkIG9uIHRoZSA1LXR1cGxlIG9m IHRoZQ0KICAgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMsIHBvcnRzIGFuZCB0aGUg dHJhbnNwb3J0IHByb3RvY29sDQogICB0eXBlIChlLmcuIHRoZSAibWljcm9mbG93IiBkZWZpbml0 aW9uIGluIFtEaWZmU2Vydl0pLiBIb3dldmVyLCBzb21lDQogICBvZiB0aGVzZSBmaWVsZHMgbWF5 IGJlIHVuYXZhaWxhYmxlIGR1ZSB0byBlaXRoZXIgZnJhZ21lbnRhdGlvbiBvcg0KICAgZW5jcnlw dGlvbiwgb3IgbG9jYXRpbmcgdGhlbSBwYXN0IGEgY2hhaW4gb2YgSVB2NiBvcHRpb24gaGVhZGVy cyBtYXkNCiAgIGJlIGluZWZmaWNpZW50LiBBZGRpdGlvbmFsbHksIGRlcGVuZGVuY2Ugb24gaGln aGVyIGxheWVyIGhlYWRlcnMgYnkNCiAgIHRoZSBJUCBsYXllciByZXByZXNlbnRzIGEgbGF5ZXIg dmlvbGF0aW9uLCBwb3NzaWJseSBoaW5kZXJpbmcgdGhlDQogICBpbnRyb2R1Y3Rpb24gb2YgbmV3 IHRyYW5zcG9ydCBsYXllciBwcm90b2NvbHMuDQoNCiAgIFRoZSAzLXR1cGxlIG9mIHRoZSBGbG93 IExhYmVsIGFuZCB0aGUgU291cmNlIGFuZCBEZXN0aW5hdGlvbiBBZGRyZXNzDQogICBmaWVsZHMg ZW5hYmxlcyBlZmZpY2llbnQgSVB2NiBmbG93IGNsYXNzaWZpY2F0aW9uLCB3aGVyZSBvbmx5IElQ djYNCiAgIG1haW4gaGVhZGVyIGZpZWxkcyBpbiBmaXhlZCBwb3NpdGlvbnMgYXJlIHVzZWQuIFRo ZSBzcGVjaWZpY2F0aW9uIG9mDQogICB0aGUgSVB2NiBGbG93IExhYmVsIGZpZWxkIGlzIGdpdmVu IGluIHNlY3Rpb24gMyBiZWxvdy4NCg0KICAgVGhlIG1pbmltdW0gbGV2ZWwgb2YgSVB2NiBmbG93 IHN1cHBvcnQgY29uc2lzdHMgb2YgbGFiZWxpbmcgdGhlDQogICBmbG93cy4gSVB2NiBzb3VyY2Ug bm9kZXMgY2FuIGxhYmVsIGtub3duIGZsb3dzIChlLmcuIFRDUCBjb25uZWN0aW9ucywNCiAgIFJU UCBzdHJlYW1zKSwgZXZlbiBpZiB0aGUgbm9kZSBpdHNlbGYgd291bGQgbm90IHJlcXVpcmUgYW55 IGZsb3ctDQogICBzcGVjaWZpYyB0cmVhdG1lbnQuIERvaW5nIHRoaXMgZW5hYmxlcyBsb2FkIHNw cmVhZGluZyBhbmQgcmVjZWl2ZXINCiAgIG9yaWVudGVkIHJlc291cmNlIHJlc2VydmF0aW9ucywg Zm9yIGV4YW1wbGUuIFJlcXVpcmVtZW50cyBmb3IgZmxvdw0KICAgbGFiZWxpbmcgYXJlIGdpdmVu IGluIHNlY3Rpb24gNC4NCg0KICAgU3BlY2lmaWMgZmxvdyBzdGF0ZSBlc3RhYmxpc2htZW50IG1l dGhvZHMgYW5kIHRoZSByZWxhdGVkIHNlcnZpY2UNCiAgIG1vZGVscyBhcmUgb3V0IG9mIHNjb3Bl IGZvciB0aGlzIHNwZWNpZmljYXRpb24sIGJ1dCB0aGUgZ2VuZXJpYw0KICAgcmVxdWlyZW1lbnRz IGVuYWJsaW5nIGNvLWV4aXN0ZW5jZSBvZiBkaWZmZXJlbnQgbWV0aG9kcyBpbiBJUHY2IG5vZGVz DQogICBhcmUgc2V0IGZvcnRoIGluIHNlY3Rpb24gNS4NCg0KDQozLiAgSVB2NiBGbG93IExhYmVs IFNwZWNpZmljYXRpb24NCg0KICAgVGhlIDIwLWJpdCBGbG93IExhYmVsIGZpZWxkIGluIHRoZSBJ UHY2IGhlYWRlciBTSE9VTEQgYmUgdXNlZCBieSBhDQogICBzb3VyY2UgdG8gbGFiZWwgc2VxdWVu Y2VzIG9mIHJlbGF0ZWQgcGFja2V0cyBzZW50IHRvIGEgc3BlY2lmaWMNCiAgIHVuaWNhc3QsIGFu eWNhc3QsIG9yIG11bHRpY2FzdCBkZXN0aW5hdGlvbi4gQSBub24temVybyBGbG93IExhYmVsDQog ICBpbmRpY2F0ZXMgdGhhdCB0aGUgSVB2NiBwYWNrZXQgaXMgbGFiZWxlZC4gSVB2NiBub2RlcyBm b3J3YXJkaW5nIG9yDQogICByZWNlaXZpbmcgYSBsYWJlbGVkIElQdjYgcGFja2V0IGNhbiB1c2Ug dGhlIEZsb3cgTGFiZWwgYW5kIFNvdXJjZSBhbmQNCiAgIERlc3RpbmF0aW9uIEFkZHJlc3MgZmll bGRzIHRvIGNsYXNzaWZ5IHRoZSBwYWNrZXQgdG8gYSBjZXJ0YWluIGZsb3cuDQogICBUaGUgcGFj a2V0IE1BWSBiZSBnaXZlbiBzb21lIGZsb3ctc3BlY2lmaWMgdHJlYXRtZW50IGJhc2VkIG9uIHRo ZQ0KICAgZmxvdyBzdGF0ZSBlc3RhYmxpc2hlZCBvbiBhIHNldCBvZiBJUHY2IG5vZGVzLiBUaGUg bmF0dXJlIG9mIHRoZQ0KICAgc3BlY2lmaWMgdHJlYXRtZW50IGFuZCB0aGUgbWV0aG9kcyBmb3Ig dGhlIGZsb3cgc3RhdGUgZXN0YWJsaXNobWVudA0KICAgYXJlIG91dCBvZiBzY29wZSBmb3IgdGhp cyBzcGVjaWZpY2F0aW9uLg0KDQogICBUaGUgRmxvdyBMYWJlbCB2YWx1ZSBzZXQgYnkgdGhlIHNv dXJjZSBNVVNUIGJlIGRlbGl2ZXJlZCB1bmNoYW5nZWQgdG8NCiAgIHRoZSBkZXN0aW5hdGlvbiBu b2RlKHMpLg0KDQogICBJUHY2IG5vZGVzIE1VU1QgTk9UIGFzc3VtZSBtYXRoZW1hdGljYWwgb3Ig b3RoZXIgbm9uLXN0YW5kYXJkaXplZA0KICAgcHJvcGVydGllcyBvZiB0aGUgRmxvdyBMYWJlbCB2 YWx1ZXMgYXNzaWduZWQgYnkgc291cmNlIG5vZGVzLiBSb3V0ZXINCiAgIHBlcmZvcm1hbmNlIFNI T1VMRCBOT1QgYmUgZGVwZW5kZW50IG9uIHRoZSBkaXN0cmlidXRpb24gb2YgdGhlIEZsb3cNCiAg IExhYmVsIHZhbHVlcy4gRXNwZWNpYWxseSwgdGhlIEZsb3cgTGFiZWwgYml0cyBhbG9uZSBtYWtl IHBvb3INCiAgIG1hdGVyaWFsIGZvciBhIGhhc2gga2V5Lg0KDQogICBJZiBhbiBJUHY2IG5vZGUg aXMgbm90IHByb3ZpZGluZyBmbG93LXNwZWNpZmljIHRyZWF0bWVudCwgaXQgTVVTVA0KICAgaWdu b3JlIHRoZSBmaWVsZCB3aGVuIHJlY2VpdmluZyBvciBmb3J3YXJkaW5nIGEgcGFja2V0Lg0KDQoN Cg0KUmFqYWhhbG1lLCBldCBhbC4gICAgICAgIEV4cGlyZXM6IEZlYnJ1YXJ5IDIwMDMgICAgICAg ICAgICAgICAgIFtQYWdlIDNdDQoMDQpJTlRFUk5FVC1EUkFGVCAgICAgZHJhZnQtaWV0Zi1pcHY2 LWZsb3ctbGFiZWwteHgudHh0ICAgICAgICAgQXVndXN0IDIwMDINCg0KDQo0LiAgRmxvdyBMYWJl bGluZyBSZXF1aXJlbWVudHMNCg0KICAgVG8gZW5hYmxlIEZsb3cgTGFiZWwgYmFzZWQgY2xhc3Np ZmljYXRpb24sIHNvdXJjZXMgTVVTVCBsYWJlbCBhbGwNCiAgIHBhY2tldHMgYmVsb25naW5nIHRv IGEgZmxvdy4NCg0KICAgVGhlIGFzc2lnbm1lbnQgb2YgYSBwYWNrZXQgdG8gYSBmbG93IHRha2Vz IHZhcmlvdXMgZm9ybXMsIHByZXNlbnRlZA0KICAgYmVsb3cgaW4gdGhlIG9yZGVyIG9mIHByZWNl ZGVuY2U6DQoNCiAgICgxKSAgVGhlIHNvdXJjZSBNQVkgdGFrZSBwYXJ0IGluIGEgc2lnbmFsaW5n IHByb3RvY29sIHRoYXQgcmVzdWx0cyBpbg0KICAgICAgICBhc3NpZ25pbmcgY2VydGFpbiB0cmFu c3BvcnQgY29ubmVjdGlvbihzKSBvciBhcHBsaWNhdGlvbiBkYXRhDQogICAgICAgIHN0cmVhbShz KSB0byBzcGVjaWZpYyBmbG93KHMpLg0KDQogICAoMikgIFRoZSBzb3VyY2UgTUFZIGJlIGNvbmZp Z3VyZWQgdG8gYXNzaWduIGNlcnRhaW4gdHJhbnNwb3J0DQogICAgICAgIGNvbm5lY3Rpb24ocykg b3IgYXBwbGljYXRpb24gZGF0YSBzdHJlYW0ocykgdG8gc3BlY2lmaWMgZmxvdyhzKS4NCg0KICAg KDMpICBUaGUgc291cmNlIFNIT1VMRCBhc3NpZ24gZWFjaCBuZXcgYXBwbGljYXRpb24gZGF0YSBz dHJlYW0gKGUuZy4NCiAgICAgICAgUlRQIHN0cmVhbXMpIHRvIGEgbmV3IGZsb3cuDQoNCiAgICg0 KSAgVGhlIHNvdXJjZSBTSE9VTEQgYXNzaWduIGVhY2ggbmV3IHRyYW5zcG9ydCBjb25uZWN0aW9u IChlLmcuDQogICAgICAgIFRDUCwgU0NUUCkgdG8gYSBuZXcgZmxvdy4NCg0KICAgSXQgaXMgbmVj ZXNzYXJ5IHRoYXQgZmxvdyBjbGFzc2lmaWVycyBkb3duc3RyZWFtIGZyb20gdGhlIHNvdXJjZSBj YW4NCiAgIGNsYXNzaWZ5IHBhY2tldHMgdW5hbWJpZ3VvdXNseSwgaS5lLiB0aGF0IGFsbCBwYWNr ZXRzIHdoaWNoIHRoZQ0KICAgc291cmNlIGhhcyBjaG9zZW4gdG8gbGFiZWwgYXMgYSBzaW5nbGUg ZmxvdyBjYW4gYmUgZWZmaWNpZW50bHkNCiAgIGlkZW50aWZpZWQgYXMgc3VjaC4NCg0KICAgVG8g ZW5hYmxlIHRoaXMsIHRoZSBzb3VyY2Ugbm9kZSBNVVNUIGtlZXAgdHJhY2sgb2YgdGhlIEZsb3cg TGFiZWwNCiAgIHZhbHVlcyBpdCBpcyBjdXJyZW50bHkgdXNpbmcgb3IgaGFzIHJlY2VudGx5IHVz ZWQuIFdoZW4gYSBuZXcgZmxvdyBpcw0KICAgaW5zdGFudGlhdGVkLCBhIHVuaXF1ZSBGbG93IExh YmVsIE1VU1QgYmUgc2VsZWN0ZWQgZm9yIGl0LiBBIEZsb3cNCiAgIExhYmVsIHZhbHVlIGlzIGNv bnNpZGVyZWQgdW5pcXVlIGlmIGl0IGlzIG5vdCBjdXJyZW50bHkgaW4gdXNlIHdpdGgNCiAgIHRo ZSBzYW1lIFNvdXJjZSBhbmQgRGVzdGluYXRpb24gYWRkcmVzc2VzLiBJZiBtdWx0aXBsZSBmbG93 DQogICBjbGFzc2lmaWVycyBtYXAgdG8gdGhlIHNhbWUgZmxvdyBzdGF0ZSBpdCBtYXkgYmUgZGVz aXJhYmxlIHRvDQogICBtaW5pbWl6ZSB0aGUgYW1vdW50IG9mIHN0YXRlIGFuZCB1c2UgdGhlIHNh bWUgRmxvdyBMYWJlbCB2YWx1ZSB3aXRoDQogICBhbGwgc3VjaCBjbGFzc2lmaWVycy4gSW4gdGhp cyBjYXNlIHRoZSByZXF1aXJlbWVudCBmb3IgdW5pcXVlbmVzcw0KICAgZXh0ZW5kcyB0byBhbGwg cG9zc2libGUgKFNvdXJjZSwgRGVzdGluYXRpb24pIGFkZHJlc3MgcGFpcnMuDQoNCiAgIFRoZSBJ UHY2IHNvdXJjZSBub2RlIE1VU1QgcHJvdmlkZSBhIGZhY2lsaXR5IGZvciBzZWxlY3RpbmcgYW5k DQogICBhc3NpZ25pbmcgdW5pcXVlIEZsb3cgTGFiZWwgdmFsdWVzLCBhbmQgZm9yIHN0b3Jpbmcg dGhlIEZsb3cgTGFiZWwNCiAgIGFuZCB0aGUgYXNzb2NpYXRlZCBTb3VyY2UgYW5kIERlc3RpbmF0 aW9uIEFkZHJlc3NlcyBjdXJyZW50bHkgaW4gdXNlLg0KICAgVGhlIGZhY2lsaXR5IE1VU1QgYmUg dXNlZCB3aGVuZXZlciBhIGxhYmVsIG5lZWRzIHRvIGJlIGFzc2lnbmVkIGZvciBhDQogICBuZXcg Zmxvdy4gVGhlIGZhY2lsaXR5IFNIT1VMRCBwcm92aWRlIGEgcHJvZ3JhbW1pbmcgaW50ZXJmYWNl IHdpdGggYXQNCiAgIGxlYXN0IHRoZSBmb2xsb3dpbmcgZnVuY3Rpb25hbGl0eToNCg0KICAgKDEp ICB0byBhc3NpZ24gYW55IEZsb3cgTGFiZWwgdmFsdWUgZm9yIGEgbmV3IGZsb3cNCg0KICAgKDIp ICB0byBhc3NpZ24gYSBzcGVjaWZpYyBGbG93IExhYmVsIGZvciBhIG5ldyBmbG93LCBhbmQNCg0K ICAgKDMpICB0byBkZWxldGUgYSBmbG93LCBpLmUuIHRvIGZyZWUgYSBGbG93IExhYmVsIG5vIGxv bmdlciBpbiB1c2UuDQoNCiAgIFRoZSBpbnRlcmZhY2UgZGVmaW5pdGlvbiBmb3IgdGhlIGZhY2ls aXR5IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcw0KICAgZG9jdW1lbnQuDQoNCg0KDQpSYWph aGFsbWUsIGV0IGFsLiAgICAgICAgRXhwaXJlczogRmVicnVhcnkgMjAwMyAgICAgICAgICAgICAg ICAgW1BhZ2UgNF0NCgwNCklOVEVSTkVULURSQUZUICAgICBkcmFmdC1pZXRmLWlwdjYtZmxvdy1s YWJlbC14eC50eHQgICAgICAgICBBdWd1c3QgMjAwMg0KDQoNCiAgIEFueSBGbG93IExhYmVsIHZh bHVlIG5vdCBjdXJyZW50bHkgYXNzaWduZWQgYnkgdGhlIGZhY2lsaXR5IGNhbiBiZQ0KICAgYXNz aWduZWQgYnkgdGhlIGZhY2lsaXR5IGF0IGFueSB0aW1lLiBBY2NpZGVudGFsIEZsb3cgTGFiZWwg dmFsdWUNCiAgIHJldXNlIFNIT1VMRCBiZSBwcmV2ZW50ZWQgYnkgbm90IGRlbGV0aW5nIHRoZSBm bG93IGZyb20gdGhlIGZhY2lsaXR5DQogICBiZWZvcmUgaXQgaXMgY2VydGFpbiB0aGF0IGFsbCBh c3NvY2lhdGVkIGZsb3cgc3BlY2lmaWMgc3RhdGUgaGFzIGJlZW4NCiAgIGRlbGV0ZWQgZnJvbSBh bGwgcmVsZXZhbnQgbm9kZXMuIENvbGxpc2lvbnMgZHVlIHRvIGFjY2lkZW50YWwgbm9kZQ0KICAg cmVib290cyBTSE9VTEQgYmUgbWluaW1pemVkIGJ5IHV0aWxpemluZyBhIHJhbmRvbSBpbml0aWFs IHZhbHVlIGZvcg0KICAgdGhlIEZsb3cgTGFiZWwgYmVpbmcgYXNzaWduZWQgYnkgdGhlIGZhY2ls aXR5Lg0KDQogICBUaGUgbWV0aG9kIGJ5IHdoaWNoIHRoZSBmbG93IHN0YXRlIGlzIGNsZWFyZWQg ZnJvbSB0aGUgSVB2NiBub2RlcyBpcw0KICAgdG8gYmUgZGVmaW5lZCBieSB0aGUgZmxvdyBzdGF0 ZSBlc3RhYmxpc2htZW50IG1ldGhvZCB1c2VkIHRvIHNldCB1cA0KICAgdGhlIHN0YXRlLiBUaGlz IGltcGxpZXMgdGhhdCBJUHY2IG5vZGVzIFNIT1VMRCBOT1QgZXN0YWJsaXNoIGFueQ0KICAgZmxv dy1zcGVjaWZpYyBzdGF0ZSB1bmxlc3Mgc28gaW5zdHJ1Y3RlZCBieSBhIHNwZWNpZmljIGZsb3cg c3RhdGUNCiAgIGVzdGFibGlzaG1lbnQgbWV0aG9kLiBXaXRoIHNvbWUgZmxvdyBzdGF0ZSBlc3Rh Ymxpc2htZW50IG1ldGhvZHMsDQogICBzaWduYWxpbmcgbmV3IHN0YXRlIHNpbXVsdGFuZW91c2x5 IGNsZWFyaW5nIHRoZSBvbGQgc3RhdGUgZnJvbSB0aGUNCiAgIG5ldyBwYXRoIG1heSBiZSBzdWZm aWNpZW50LiBBIG1lY2hhbmlzbSB3aXRoIGEgc3VmZmljaWVudGx5IGxvbmcNCiAgIHRpbWVvdXQg cGVyaW9kIGJlZm9yZSByZXVzaW5nIHRoZSBGbG93IExhYmVsIHZhbHVlcyBjYW4gYWxzbyBiZSB1 c2VkLg0KDQogICBXaXRoIFtSU1ZQXSBvciBbU0RQXSBlaXRoZXIgdGhlIHNvdXJjZSBvciB0aGUg ZGVzdGluYXRpb24gb2YgdGhlIGZsb3cNCiAgIGNvdWxkIGhhdmUgYSBwcmVmZXJlbmNlIGZvciB0 aGUgRmxvdyBMYWJlbCB2YWx1ZSB0byBiZSB1c2VkLiBGb3INCiAgIGV4YW1wbGUsIGEgZGVzdGlu YXRpb24gd2l0aCBtdWx0aXBsZSBzb3VyY2VzIHNlbmRpbmcgcGFja2V0cyB0byBpdA0KICAgY291 bGQgcmVxdWlyZSBhbGwgdGhlIHNvdXJjZXMgdG8gdXNlIHRoZSBzYW1lIEZsb3cgTGFiZWwgdmFs dWUgaW4NCiAgIG9yZGVyIHRvIGNvbGxhcHNlIHRoZSBjbGFzc2lmaWVyIHN0YXRlIHRvIGEgc2lu Z2xlIGZsb3cgc3RhdGUgZW50cnksDQogICBpbnN0ZWFkIG9mIGhhdmluZyBzZXBhcmF0ZSBjbGFz c2lmaWVyIHN0YXRlIGZvciBlYWNoIHNvdXJjZSAocmVmLiB0aGUNCiAgIFdpbGRjYXJkLUZpbHRl ciByZXNlcnZhdGlvbiBzdHlsZSBpbiBbUlNWUF0pLiBUaGVyZWZvcmUgdGhlIHNvdXJjZQ0KICAg U0hPVUxEIGhvbm9yIHRoZSBkZXN0aW5hdGlvbidzIHJlcXVlc3QgdG8gbWFyayB0aGUgcGFja2V0 cyB3aXRoIHRoZQ0KICAgRmxvdyBMYWJlbCB2YWx1ZSBzcGVjaWZpZWQuDQoNCiAgIFRvIGVuYWJs ZSB0aGUgcGVlcihzKSB0byBrbm93IHRoZSBhc3NpZ25lZCBvciByZXF1ZXN0ZWQgRmxvdyBMYWJl bA0KICAgdmFsdWUsIHRoZSB2YWx1ZSBTSE9VTEQgYmUgaW5jbHVkZWQgYWxvbmcgd2l0aCB0aGUg U291cmNlIGFuZA0KICAgRGVzdGluYXRpb24gYWRkcmVzc2VzIGFzIHBhcnQgb2YgYW55IHNpZ25h bGluZyBkZWFsaW5nIHdpdGggdGhlIGZsb3csDQogICBlLmcuIHRyYW5zcG9ydCBsYXllciBjb25u ZWN0aW9uIHNldCB1cCwgUlNWUCBmb3IgcmVzb3VyY2UNCiAgIHJlc2VydmF0aW9uLCBvciBTRFAg Zm9yIG1lZGlhIHNlc3Npb24gcGFyYW1ldGVycy4NCg0KDQo1LiAgRmxvdyBTdGF0ZSBFc3RhYmxp c2htZW50IFJlcXVpcmVtZW50cw0KDQogICBUbyBlbmFibGUgZmxvdy1zcGVjaWZpYyB0cmVhdG1l bnQsIGZsb3cgc3RhdGUgbmVlZHMgdG8gYmUgZXN0YWJsaXNoZWQNCiAgIG9uIGFsbCBvciBhIHN1 YnNldCBvZiB0aGUgSVB2NiBub2RlcyBvbiB0aGUgcGF0aCBmcm9tIHRoZSBzb3VyY2UgdG8NCiAg IHRoZSBkZXN0aW5hdGlvbihzKS4gVGhlIG1ldGhvZHMgZm9yIHRoZSBzdGF0ZSBlc3RhYmxpc2ht ZW50LCBhcyB3ZWxsDQogICBhcyB0aGUgbW9kZWxzIGZvciBmbG93LXNwZWNpZmljIHRyZWF0bWVu dCBhcmUgZGVmaW5lZCBpbiBzZXBhcmF0ZQ0KICAgc3BlY2lmaWNhdGlvbnMuDQoNCiAgIFRvIGVu YWJsZSBjby1leGlzdGVuY2Ugb2YgZGlmZmVyZW50IG1ldGhvZHMgaW4gSVB2NiBub2RlcywgdGhl DQogICBtZXRob2RzIE1VU1QgbWVldCB0aGUgZm9sbG93aW5nIGJhc2ljIHJlcXVpcmVtZW50czoN Cg0KICAgKDEpICBBIHBhY2tldCBpcyBjbGFzc2lmaWVkIHVuYW1iaWd1b3VzbHkgdG8gYSBmbG93 IG9uIHRoZSBiYXNpcyBvZg0KICAgICAgICB0aGUgRmxvdyBMYWJlbCwgYW5kIHRoZSBTb3VyY2Ug YW5kIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGRzLg0KICAgICAgICBEZXBlbmRpbmcgb24gdGhl IG1ldGhvZCBzZW1hbnRpY3MsIG11bHRpcGxlIHN1Y2ggdHJpcGxldHMgTUFZDQogICAgICAgIGlk ZW50aWZ5IHRoZSBzYW1lIGZsb3cgc3RhdGUgKGUuZy4gYW4gU0NUUCBjb25uZWN0aW9uIGJldHdl ZW4NCiAgICAgICAgbm9kZXMgd2l0aCBtdWx0aXBsZSBhZGRyZXNzZXMsIG9yIGEgY2xhc3NpZmll ciB3aXRoIGFuIGFkZHJlc3MNCiAgICAgICAgcmFuZ2UsIHNlZSB0aGUgUlNWUCBXaWxkY2FyZC1G aWx0ZXIgZXhhbXBsZSBpbiBzZWN0aW9uIDQgYWJvdmUpLg0KICAgICAgICBUaGUgZmxvdyBzdGF0 ZSBlc3RhYmxpc2htZW50IG1ldGhvZCBNVVNUIGNvbnZleSB0aGlzIGNsYXNzaWZ5aW5nDQogICAg ICAgIGluZm9ybWF0aW9uIHRvIHRoZSBJUHY2IG5vZGVzIHRoYXQgbmVlZCB0byBwZXJmb3JtIHRo ZQ0KDQpSYWphaGFsbWUsIGV0IGFsLiAgICAgICAgRXhwaXJlczogRmVicnVhcnkgMjAwMyAgICAg ICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCklOVEVSTkVULURSQUZUICAgICBkcmFmdC1pZXRmLWlw djYtZmxvdy1sYWJlbC14eC50eHQgICAgICAgICBBdWd1c3QgMjAwMg0KDQoNCiAgICAgICAgY2xh c3NpZmljYXRpb24uIFVzYWdlIG9mIGFueSBhZGRpdGlvbmFsIGhlYWRlciBmaWVsZHMgZm9yIGZs b3cNCiAgICAgICAgY2xhc3NpZmljYXRpb24gaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNw ZWNpZmljYXRpb24uDQoNCiAgICgyKSAgVGhlIElQdjYgbm9kZSBmYWNpbGl0eSBrZWVwaW5nIHRy YWNrIG9mIHRoZSBGbG93IExhYmVsIGFuZCB0aGUNCiAgICAgICAgYXNzb2NpYXRlZCBTb3VyY2Ug YW5kIERlc3RpbmF0aW9uIEFkZHJlc3NlcyBNVVNUIGJlIHV0aWxpemVkDQogICAgICAgIHdoZW4g YXNzaWduaW5nIEZsb3cgTGFiZWwgdmFsdWVzIHRvIG5ldyBmbG93cyAoc2VlIHNlY3Rpb24gNA0K ICAgICAgICBhYm92ZSkuDQoNCiAgICgzKSAgVGhlIEZsb3cgTGFiZWwgdmFsdWUgMCBpcyByZXNl cnZlZCBmb3Igbm9uLWxhYmVsZWQgcGFja2V0cy4NCg0KICAgKDQpICBUaGUgbWV0aG9kIE1VU1Qg cHJvdmlkZSB0aGUgbWVhbnMgZm9yIGZsb3cgc3RhdGUgY2xlYW4tdXAgZnJvbQ0KICAgICAgICB0 aGUgSVB2NiBub2RlcyBwcm92aWRpbmcgdGhlIGZsb3ctc3BlY2lmaWMgdHJlYXRtZW50LiBCb3Ro IHNvZnQtDQogICAgICAgIGFuZCBoYXJkLXN0YXRlIG1ldGhvZHMgYXJlIHBvc3NpYmxlLg0KDQog ICAoNSkgIEZsb3cgc3RhdGUgZXN0YWJsaXNobWVudCBtZXRob2RzIFNIT1VMRCBiZSBhYmxlIHRv IHJlY292ZXIgZnJvbQ0KICAgICAgICB0aGUgY2FzZSB3aGVyZSB0aGUgcmVxdWVzdGVkIGZsb3cg c3RhdGUgY2Fubm90IGJlIHN1cHBvcnRlZC4NCg0KDQpTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0K DQogICBUaGUgdXNlIG9mIHRoZSBGbG93IExhYmVsIGZpZWxkIGVuYWJsZXMgZmxvdyBjbGFzc2lm aWNhdGlvbiBhbHNvIGluDQogICB0aGUgcHJlc2VuY2Ugb2YgZW5jcnlwdGlvbiBvZiBJUHY2IHBh eWxvYWRzLiBUaGlzIGFsbG93cyB0aGUNCiAgIHRyYW5zcG9ydCBoZWFkZXIgdmFsdWVzIHRvIHJl bWFpbiBjb25maWRlbnRpYWwsIHdoaWNoIG1heSBsZXNzZW4gdGhlDQogICBwb3NzaWJpbGl0aWVz IGZvciBzb21lIGZvcm1zIG9mIHRyYWZmaWMgYW5hbHlzaXMuDQoNCg0KSUFOQSBDb25zaWRlcmF0 aW9ucw0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgZGVmaW5lIGFueSB3ZWxsLWtu b3duIHZhbHVlcy4NCg0KDQpBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFRoZSBkaXNjdXNzaW9uIG9u IHRoZSB0b3BpYyBpbiB0aGUgSVB2NiBXRyBtYWlsaW5nIGxpc3QgaGFzIGJlZW4NCiAgIGluc3Ry dW1lbnRhbCBmb3IgdGhlIGRlZmluaXRpb24gb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgYXV0 aG9ycw0KICAgd2FudCB0byB0aGFuayBTdGV2ZSBCbGFrZSwgSmltIEJvdW5kLCBGcmFuY2lzIER1 cG9udCwgUm9iZXJ0IEVseiwNCiAgIFRvbnkgSGFpbiwgQm9iIEhpbmRlbiwgQ2hyaXN0aWFuIEh1 aXRlbWEsIEZyYW5rIEthc3RlbmhvbHosIENoYXJsZXMNCiAgIFBlcmtpbnMsIEhlc2hhbSBTb2xp bWFuLCBNaWNoYWVsIFRob21hcywgYW5kIE1hcmdhcmV0IFdhc3Nlcm1hbiBmb3INCiAgIHRoZWly IGNvbnRyaWJ1dGlvbnMuDQoNCg0KTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0lQdjZdICAg ICAgUy4gRGVlcmluZywgUi4gSGluZGVuLCAiSW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lvbiA2DQog ICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIiwgUkZDIDI0NjAsIERlY2VtYmVyIDE5OTguDQoN Cg0KSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbRGlmZlNlcnZdICBTLiBCbGFrZSwgRC4g QmxhY2ssIE0uIENhcmxzb24sIEUuIERhdmllcywgWi4gV2FuZywgVy4NCiAgICAgICAgICAgICAg IFdlaXNzLCAiQW4gQXJjaGl0ZWN0dXJlIGZvciBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlIiwgUkZD DQogICAgICAgICAgICAgICAyNDc1LCBEZWNlbWJlciAxOTk4Lg0KDQoNClJhamFoYWxtZSwgZXQg YWwuICAgICAgICBFeHBpcmVzOiBGZWJydWFyeSAyMDAzICAgICAgICAgICAgICAgICBbUGFnZSA2 XQ0KDA0KSU5URVJORVQtRFJBRlQgICAgIGRyYWZ0LWlldGYtaXB2Ni1mbG93LWxhYmVsLXh4LnR4 dCAgICAgICAgIEF1Z3VzdCAyMDAyDQoNCg0KICAgW1JGQzE4MDldICAgQy4gUGFydHJpZGdlLCAi VXNpbmcgdGhlIEZsb3cgTGFiZWwgRmllbGQgaW4gSVB2NiIsIFJGQw0KICAgICAgICAgICAgICAg MTgwOSwgSnVuZSAxOTk1Lg0KDQogICBbUlNWUF0gICAgICBSLiBCcmFkZW4sIEwuIFpoYW5nLCBT LiBCZXJzb24sIFMuIEhlcnpvZywgUy4gSmFtaW4sDQogICAgICAgICAgICAgICAiUmVzb3VyY2Ug UmVzZXJ2YXRpb24gUHJvdG9jb2wgKFJTVlApIFZlcnNpb24gMQ0KICAgICAgICAgICAgICAgRnVu Y3Rpb25hbCBTcGVjaWZpY2F0aW9uIiwgUkZDIDIyMDUsIFNlcHRlbWJlciAxOTk3Lg0KDQogICBb U0RQXSAgICAgICBNLiBIYW5kbGV5LCBWLiBKYWNvYnNvbiwgIlNEUDogU2Vzc2lvbiBEZXNjcmlw dGlvbg0KICAgICAgICAgICAgICAgUHJvdG9jb2wiLCBSRkMgMjMyNywgQXByaWwgMTk5OC4NCg0K DQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgSmFybm8gUmFqYWhhbG1lDQogICBOb2tpYSBSZXNl YXJjaCBDZW50ZXINCiAgIFAuTy4gQm94IDQwNw0KICAgRklOLTAwMDQ1IE5PS0lBIEdST1VQLA0K ICAgRmlubGFuZA0KICAgRS1tYWlsOiBqYXJuby5yYWphaGFsbWVAbm9raWEuY29tDQoNCiAgIEFs ZXggQ29udGENCiAgIFRyYW5zd2l0Y2ggQ29ycG9yYXRpb24NCiAgIDMgRW50ZXJwcmlzZSBEcml2 ZQ0KICAgU2hlbHRvbiwgQ1QgMDY0ODQNCiAgIFVTQQ0KICAgRW1haWw6IGFjb250YUB0eGMuY29t DQoNCiAgIEJyaWFuIEUuIENhcnBlbnRlcg0KICAgSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0 b3J5DQogICBTYWV1bWVyc3RyYXNzZSA0IC8gUG9zdGZhY2gNCiAgIDg4MDMgUnVlc2NobGlrb24N CiAgIFN3aXR6ZXJsYW5kDQogICBFbWFpbDogYnJpYW5AaHVyc2xleS5pYm0uY29tDQoNCiAgIFN0 ZXZlIERlZXJpbmcNCiAgIENpc2NvIFN5c3RlbXMsIEluYy4NCiAgIDE3MCBXZXN0IFRhc21hbiBE cml2ZQ0KICAgU2FuIEpvc2UsIENBIDk1MTM0LTE3MDYNCiAgIFVTQQ0KICAgRW1haWw6IGRlZXJp bmdAY2lzY28uY29tDQoNCg0KRXhwaXJhdGlvbiBEYXRlDQoNCiAgIFRoaXMgbWVtbyBpcyBmaWxl ZCBhcyA8ZHJhZnQtaWV0Zi1pcHY2LWZsb3ctbGFiZWwteHgudHh0PiBhbmQgZXhwaXJlcw0KICAg aW4gRmVicnVhcnkgMjAwMy4NCg0KDQoNCg0KDQoNCg0KDQpSYWphaGFsbWUsIGV0IGFsLiAgICAg ICAgRXhwaXJlczogRmVicnVhcnkgMjAwMyAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCg== ------_=_NextPart_001_01C2395C.B444A60C-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 06:41:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71DfnoN022502; Thu, 1 Aug 2002 06:41:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71Dfn1j022501; Thu, 1 Aug 2002 06:41:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71DfkoN022494 for ; Thu, 1 Aug 2002 06:41:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12090 for ; Thu, 1 Aug 2002 06:41:46 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05575 for ; Thu, 1 Aug 2002 07:41:45 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g71Df6G18230; Thu, 1 Aug 2002 20:41:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g71DeEc13873; Thu, 1 Aug 2002 20:40:16 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: hinden@iprg.nokia.com, richdr@microsoft.com, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: <200208011159.OAA29199@burp.tkv.asdf.org> References: <200208011159.OAA29199@burp.tkv.asdf.org> <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> <13209.1028199712@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Aug 2002 20:40:14 +0700 Message-ID: <13871.1028209214@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 1 Aug 2002 14:59:34 +0300 From: Markku Savela Message-ID: <200208011159.OAA29199@burp.tkv.asdf.org> | - which is more significant priority or prefix length? prefix length. The draft is quite clear about that. The preferences are only a method to allow routers that would otherwise be considered equal to be ranked (a last step disambiguator). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 07:57:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71EvhoN022590; Thu, 1 Aug 2002 07:57:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71EvhPQ022589; Thu, 1 Aug 2002 07:57:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71EveoN022582 for ; Thu, 1 Aug 2002 07:57:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16144 for ; Thu, 1 Aug 2002 07:57:44 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08808 for ; Thu, 1 Aug 2002 08:57:43 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA29435; Thu, 1 Aug 2002 17:56:41 +0300 Date: Thu, 1 Aug 2002 17:56:41 +0300 Message-Id: <200208011456.RAA29435@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: hinden@iprg.nokia.com, richdr@microsoft.com, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <13871.1028209214@munnari.OZ.AU> (message from Robert Elz on Thu, 01 Aug 2002 20:40:14 +0700) Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt References: <200208011159.OAA29199@burp.tkv.asdf.org> <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> <13209.1028199712@munnari.OZ.AU> <13871.1028209214@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > | - which is more significant priority or prefix length? > > prefix length. The draft is quite clear about that. The preferences > are only a method to allow routers that would otherwise be considered > equal to be ranked (a last step disambiguator). Ok, that much I sort of guessed, but is there as simple answer to my followup question: - if router2 is not reachable, obviously packets matching prefix2/L can be sent to router1. But, is there any advice on algorithm how the system detects if router2 becomes available? Just wait for RA? Probe with some logic?. (There is no RA in IPv4 -- I think this should work for IPv4 too!) Ok, so my address matches the route for router2, but this router is currently unreachable (no entry in neighbor cache). Do I a) drop the packet b) if there is a reachable router with shorter matching prefix, send there I guess (b), but then the question is when and how is router2 "rediscovered". I'm pretty sure I can invent some ad hoc algorithm, but I also wanted to know other opinions? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 08:03:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71F39oN022617; Thu, 1 Aug 2002 08:03:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71F39kE022616; Thu, 1 Aug 2002 08:03:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71F36oN022609 for ; Thu, 1 Aug 2002 08:03:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17709 for ; Thu, 1 Aug 2002 08:03:10 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20278 for ; Thu, 1 Aug 2002 09:03:04 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g71F2NG21088; Thu, 1 Aug 2002 22:02:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g71F1Zc14381; Thu, 1 Aug 2002 22:01:35 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: hinden@iprg.nokia.com, richdr@microsoft.com, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: <200208011456.RAA29435@burp.tkv.asdf.org> References: <200208011456.RAA29435@burp.tkv.asdf.org> <200208011159.OAA29199@burp.tkv.asdf.org> <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> <13209.1028199712@munnari.OZ.AU> <13871.1028209214@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Aug 2002 22:01:35 +0700 Message-ID: <14379.1028214095@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 1 Aug 2002 17:56:41 +0300 From: Markku Savela Message-ID: <200208011456.RAA29435@burp.tkv.asdf.org> | I guess (b), but then the question is when and how is router2 | "rediscovered". I'm pretty sure I can invent some ad hoc algorithm, | but I also wanted to know other opinions? See section 3.4 kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 10:55:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71HtNoN022862; Thu, 1 Aug 2002 10:55:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71HtNVY022861; Thu, 1 Aug 2002 10:55:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71HtKoN022854 for ; Thu, 1 Aug 2002 10:55:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18539 for ; Thu, 1 Aug 2002 10:55:23 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01799 for ; Thu, 1 Aug 2002 11:55:23 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 1 Aug 2002 10:55:22 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Aug 2002 10:55:03 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 1 Aug 2002 10:55:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: AD comments on draft-ietf-ipv6-router-selection-02.txt Date: Thu, 1 Aug 2002 10:55:01 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEE20@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-ipv6-router-selection-02.txt Thread-Index: AcI5a85WtQXofvqBSoyYQCSkgOe1ZwAGCJOA From: "Richard Draves" To: "Markku Savela" , Cc: , , X-OriginalArrivalTime: 01 Aug 2002 17:55:01.0920 (UTC) FILETIME=[8F1B6A00:01C23984] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g71HtKoN022855 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ok, that much I sort of guessed, but is there as simple > answer to my followup question: > > - if router2 is not reachable, obviously packets matching prefix2/L > can be sent to router1. But, is there any advice on algorithm how > the system detects if router2 becomes available? Just wait for RA? > Probe with some logic?. (There is no RA in IPv4 -- I think this > should work for IPv4 too!) > > Ok, so my address matches the route for router2, but this > router is currently unreachable (no entry in neighbor cache). Do I > > a) drop the packet > > b) if there is a reachable router with shorter matching prefix, send > there As kre points out I think the draft answers your questions, but I want to followup on one point that should probably be clarified in the draft. When you say "currently unreachable (no entry in neighbor cache)" it sounds like you might have a misunderstanding. If the host has no information about the router's reachability then the host should assume the router is reachable. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 11:31:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71IV5oN023450; Thu, 1 Aug 2002 11:31:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71IV5gb023449; Thu, 1 Aug 2002 11:31:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71IUxoN023442 for ; Thu, 1 Aug 2002 11:30:59 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16685 for ; Thu, 1 Aug 2002 11:31:03 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28659 for ; Thu, 1 Aug 2002 12:31:02 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id VAA29712; Thu, 1 Aug 2002 21:30:58 +0300 Date: Thu, 1 Aug 2002 21:30:58 +0300 Message-Id: <200208011830.VAA29712@burp.tkv.asdf.org> From: Markku Savela To: richdr@microsoft.com CC: kre@munnari.OZ.AU, hinden@iprg.nokia.com, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <7695E2F6903F7A41961F8CF888D87EA8063CEE20@red-msg-06.redmond.corp.microsoft.com> (richdr@microsoft.com) Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt References: <7695E2F6903F7A41961F8CF888D87EA8063CEE20@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Richard Draves" > As kre points out I think the draft answers your questions, Right, I commented without reading the draft properly :-) > but I want to followup on one point that should probably be > clarified in the draft. When you say "currently unreachable (no > entry in neighbor cache)" it sounds like you might have a > misunderstanding. If the host has no information about the router's > reachability then the host should assume the router is reachable. Hmm.... the IPv6 neighbor discovery says that after probes fail, entry should be removed, see RFC-2461 7.3.3 Upon entering the PROBE state, a node sends a unicast Neighbor Solicitation message to the neighbor using the cached link-layer address..... ..... If no response is received after waiting RetransTimer milliseconds after sending the MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry SHOULD be deleted. As to 3.4 in internet-drafts/draft-ietf-ipv6-router-selection-02.txt, it talks only about routers X and Y. Playing nasty, I imagine situation where I have routers X, Y and Z (with prefix lengths X > Y > Z) and destination matching all of them. Now, if only Z is currently reachable, I should probably probe both X and Y using some logic... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 11:49:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71InkoN023511; Thu, 1 Aug 2002 11:49:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71InkP1023510; Thu, 1 Aug 2002 11:49:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71IneoN023503 for ; Thu, 1 Aug 2002 11:49:40 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24531 for ; Thu, 1 Aug 2002 11:49:44 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08950 for ; Thu, 1 Aug 2002 12:49:44 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 1 Aug 2002 11:49:43 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Aug 2002 11:49:43 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 1 Aug 2002 11:49:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: AD comments on draft-ietf-ipv6-router-selection-02.txt Date: Thu, 1 Aug 2002 11:49:42 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEE22@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-ipv6-router-selection-02.txt Thread-Index: AcI5iaEq2RfyzqXiQrmxHlPtyGYq8AAAasUQ From: "Richard Draves" To: "Markku Savela" Cc: , , , X-OriginalArrivalTime: 01 Aug 2002 18:49:42.0648 (UTC) FILETIME=[3292C780:01C2398C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g71InfoN023504 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hmm.... the IPv6 neighbor discovery says that after probes > fail, entry should be removed, see RFC-2461 7.3.3 > > Upon entering the PROBE state, a node sends a unicast Neighbor > Solicitation message to the neighbor using the cached link-layer > address..... > ..... If no response is received after waiting RetransTimer > milliseconds after sending the MAX_UNICAST_SOLICIT solicitations, > retransmissions cease and the entry SHOULD be deleted. I think to implement router-selection, you need to keep track of whether a router is reachable or unreachable. Whether that's in the Neighbor Cache Entry or not and how it interacts with the ND states is an implementation concern that is not specified in the draft. Note that RFC 2461 does not really say that implementations should delete a data structure, it is saying that implementations should behave as if the conceptual data structure were deleted. RFC 2461 is a protocol spec not an implementation spec. > As to 3.4 in internet-drafts/draft-ietf-ipv6-router-selection-02.txt, > it talks only about routers X and Y. > > Playing nasty, I imagine situation where I have routers X, Y > and Z (with prefix lengths X > Y > Z) and destination > matching all of them. Now, if only Z is currently reachable, > I should probably probe both X and Y using some logic... Yes both X & Y should be probed. I think section 3.4 implies that, although it could be clarified. Section 3.4 says "When a host avoids using a non-reachable router X ..." - it's quite possible for this clause to apply to more than one router. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 12:34:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JYHoN023614; Thu, 1 Aug 2002 12:34:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71JYH9N023613; Thu, 1 Aug 2002 12:34:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JY5oN023591 for ; Thu, 1 Aug 2002 12:34:08 -0700 (PDT) Received: from lillen (hobo077.Eng.Sun.COM [129.146.31.77]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g71JY4g07919; Thu, 1 Aug 2002 21:34:04 +0200 (MEST) Date: Thu, 1 Aug 2002 19:30:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt To: Richard Draves Cc: ipng@sunroof.eng.sun.com, Bob Hinden , narten@us.ibm.com In-Reply-To: "Your message with ID" <200207311912.g6VJCIV16013@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Suppose you have a host with two next-hop routers, R1 and R2. R1 > connects the host to the rest of the internet. R2 connects the host > to a specific /48. 99% of the host's traffic goes to that /48. Then > R2 is the best default router for the host, because sending traffic > to R2 will produce the fewest Redirects. But R1 is the best router > for ::/0. I don't understand what this means. "Best router for ::/0" is the same as best default router in my mind. As far as I can tell the distinction you are trying to make only makes sense when the question asked is "which is the best router for prefix P". But the node cares about "which is the best router for destination D" - nodes don't send packets to prefixes - they send packets to addresses. So I'm utterly confused. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 12:35:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JYYoN023622; Thu, 1 Aug 2002 12:34:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71JYM0l023619; Thu, 1 Aug 2002 12:34:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JYCoN023605 for ; Thu, 1 Aug 2002 12:34:13 -0700 (PDT) Received: from lillen (hobo077.Eng.Sun.COM [129.146.31.77]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g71JYAg07923; Thu, 1 Aug 2002 21:34:10 +0200 (MEST) Date: Thu, 1 Aug 2002 19:37:40 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt To: Robert Elz Cc: Bob Hinden , Richard Draves , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <13209.1028199712@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I suspect that part of the problem is that the relationship (or at least > what I would like the relationship to be) isn't clear. > > That is, if load sharing is done, router preferences MUST be done as well. > > So, whatever status we give to load sharing, router preferences has to have > at least the same status. I'm not sure that got adequately represented in > the draft. Given that load sharing is currently described as mandatory, your point implies that router preferences should also be mandatory. Perhaps others have different views. Given the 3 pieces load sharing, router preference, more specific routes (which have preference a load sharing themselves) we might have the following choices (I can't think of other combinations that make sense to me): 1. all are optional 2. load sharing is mandatory; others are optional 3. load sharing and router preferences are mandatory; more specific is optional 4. all are mandatory The current document says #2. Your point is #3 as far as I can tell. I guess the WG needs to choose. But independent of this, if is confusing to have both mandatory and optional protocol pieces in the same document if it can be easily avoided. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 12:33:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JXOoN023579; Thu, 1 Aug 2002 12:33:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71JXOKP023578; Thu, 1 Aug 2002 12:33:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JXGoN023571 for ; Thu, 1 Aug 2002 12:33:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24609 for ; Thu, 1 Aug 2002 12:33:20 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00683 for ; Thu, 1 Aug 2002 12:33:10 -0700 (PDT) Received: from kenawang ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA12892; Thu, 1 Aug 2002 12:32:52 -0700 (PDT) Message-Id: <4.2.2.20020801151633.02f1a100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 01 Aug 2002 15:29:33 -0400 To: jarno.rajahalme@nokia.com From: Margaret Wasserman Subject: Re: Flow label draft issues & new text Cc: , , , , In-Reply-To: <009CA59D1752DD448E07F8EB2F911757D3104D@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jarno, >The method by which the flow state is cleared from the IPv6 nodes is to be defined by the flow state establishment method used to set up the state. This implies that IPv6 nodes SHOULD NOT establish any flow-specific state unless so instructed by a specific flow state establishment method. I don't agree with the "SHOULD NOT" above... There are some potential uses for flow identification that do not rely on any sort of flow establishment mechanism or signalling, such as the use of flow labels for load balancing. To have a useful flow label for these mechanisms, an IPv6 node simply labels all of the packets in a given TCP/SCTP connection or UDP communication with the same flow label,making some basic effort not to re-use flows too often -- such as starting with a random number and monotonically increasing it for each new connection or communication. It would be fairly trivial to assign a flow label in this fashion -- not much harder than setting it to zero. So, you get a reasonable return for very little work. Of course, this type of non-unique flow labeling isn't consistent with using flow labels to cache next-hop information, for example. For those more sophisticated needs, a real flow establishment (and maintenance) method may be needed. But, I don't think that we should require a more sophisticated method to be present in order to use the flow label at all. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 12:35:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JZFoN023630; Thu, 1 Aug 2002 12:35:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71JZFIs023629; Thu, 1 Aug 2002 12:35:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JYNoN023620 for ; Thu, 1 Aug 2002 12:35:08 -0700 (PDT) Received: from lillen (hobo077.Eng.Sun.COM [129.146.31.77]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g71JYLg07937; Thu, 1 Aug 2002 21:34:22 +0200 (MEST) Date: Thu, 1 Aug 2002 19:55:44 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: AD comments on draft-ietf-ipv6-router-selection-02.txt To: Richard Draves Cc: Bob Hinden , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA8063CEE1A@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 3.4. Router Reachability Probing When a host avoids using a non-reachable router X and instead uses another router Y, and the host would have used router X if router X were reachable, then the host SHOULD probe router X's reachability s/were/was/ by sending a Neighbor Solicitation. A host MUST NOT probe a router's reachability in the absence of useful traffic that the host would have sent to the router if it were reachable. In any case, these probes MUST be rate-limited to no more than one per minute per router. "probe" isn't well-defined. There are two possible interpretations: 1. Send a single unicast neighbor solicitation 2. Do what RFC 2461 does when in the PROBE state (implies retransmitting NS messages N times) I think #1 is the intent; it would make sense to state that explicitly. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 1 20:08:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g7238coN024949; Thu, 1 Aug 2002 20:08:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g7238cA3024948; Thu, 1 Aug 2002 20:08:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g7238VoN024941 for ; Thu, 1 Aug 2002 20:08:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00090 for ; Thu, 1 Aug 2002 20:08:36 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16955 for ; Thu, 1 Aug 2002 21:08:35 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A32294B22; Fri, 2 Aug 2002 12:08:29 +0900 (JST) To: Margaret Wasserman Cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com, aconta@txc.com, brian@hursley.ibm.com, deering@cisco.com, hinden@iprg.nokia.com In-reply-to: mrw's message of Thu, 01 Aug 2002 15:29:33 -0400. <4.2.2.20020801151633.02f1a100@mail.windriver.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: Flow label draft issues & new text From: itojun@iijlab.net Date: Fri, 02 Aug 2002 12:08:29 +0900 Message-Id: <20020802030829.A32294B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I don't agree with the "SHOULD NOT" above... > >There are some potential uses for flow identification that do not rely on >any sort of flow establishment mechanism or signalling, such as the use of >flow labels for load balancing. > >To have a useful flow label for these mechanisms, an IPv6 node simply labels >all of the packets in a given TCP/SCTP connection or UDP communication with >the same flow label,making some basic effort not to re-use flows too often -- >such as starting with a random number and monotonically increasing it for >each new connection or communication. > >It would be fairly trivial to assign a flow label in this fashion -- not >much harder than setting it to zero. So, you get a reasonable return for >very little work. I agree with Margaret. KAME has been doing this (automatically assign flow labels to TCP/connected UDP traffic) for a long time, so that we can help traffic analysis/diffserv researchers. (they can't correlate traffic due to the use of ESP, or SSH) draft-itojun-ipv6-flowlabel-api-01.txt has more details on it. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 2 01:39:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g728dn3U025522; Fri, 2 Aug 2002 01:39:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g728dncT025521; Fri, 2 Aug 2002 01:39:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g728df3U025514 for ; Fri, 2 Aug 2002 01:39:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24014 for ; Fri, 2 Aug 2002 01:39:46 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29552 for ; Fri, 2 Aug 2002 02:39:45 -0600 (MDT) Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.05) id 17aXyI-000jjs-00; Fri, 02 Aug 2002 09:39:42 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA24780; Fri, 2 Aug 2002 09:39:41 +0100 Message-ID: <3D4A4572.72E2A079@hursley.ibm.com> Date: Fri, 02 Aug 2002 10:40:18 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: itojun@iijlab.net CC: Margaret Wasserman , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com, aconta@txc.com, deering@cisco.com, hinden@iprg.nokia.com Subject: Re: Flow label draft issues & new text References: <20020802030829.A32294B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think in the end this is an argument about nothing. > This implies that IPv6 nodes SHOULD NOT establish any > flow-specific state unless so instructed by a specific flow state establishment method. > What Margaret and itojun refer to are flow state establishment methods that happen to consist of algorithms built into the sending node (rather than signaling mechanisms or pre-configured flow states). These algorithms must avoid duplicate labels, just as signaled or pre-configured methods must. So the sentence is in fact a no-op and can be deleted. While I'm writing, I agree with all of Jarno's other changes. Brian itojun@iijlab.net wrote: > > >I don't agree with the "SHOULD NOT" above... > > > >There are some potential uses for flow identification that do not rely on > >any sort of flow establishment mechanism or signalling, such as the use of > >flow labels for load balancing. > > > >To have a useful flow label for these mechanisms, an IPv6 node simply labels > >all of the packets in a given TCP/SCTP connection or UDP communication with > >the same flow label,making some basic effort not to re-use flows too often -- > >such as starting with a random number and monotonically increasing it for > >each new connection or communication. > > > >It would be fairly trivial to assign a flow label in this fashion -- not > >much harder than setting it to zero. So, you get a reasonable return for > >very little work. > > I agree with Margaret. KAME has been doing this (automatically > assign flow labels to TCP/connected UDP traffic) for a long time, > so that we can help traffic analysis/diffserv researchers. > (they can't correlate traffic due to the use of ESP, or SSH) > draft-itojun-ipv6-flowlabel-api-01.txt has more details on it. > > itojun -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 2 04:40:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72BeC3U025864; Fri, 2 Aug 2002 04:40:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72BeBVm025863; Fri, 2 Aug 2002 04:40:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Be63U025856 for ; Fri, 2 Aug 2002 04:40:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20012 for ; Fri, 2 Aug 2002 04:40:11 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17995 for ; Fri, 2 Aug 2002 04:40:10 -0700 (PDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g72Be7V23213 for ; Fri, 2 Aug 2002 14:40:07 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 Aug 2002 14:40:08 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 2 Aug 2002 14:40:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 2 Aug 2002 14:40:08 +0300 content-class: urn:content-classes:message Subject: RE: Flow label draft issues & new text MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 2 Aug 2002 14:40:06 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719811E@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcI5kkUNy6LGz1XGTJKO9x5sGEh2MwAgkQcA To: Cc: , , , , X-OriginalArrivalTime: 02 Aug 2002 11:40:08.0346 (UTC) FILETIME=[5A4E27A0:01C23A19] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g72Be63U025857 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, The draft explicitly states that each transport connection SHOULD be labeled, and explicitly mentions labeling enabling load-balancing that you described. So I do not think there is any conflict with the intent of the authors (and the text) and the uses you describe. The intent of the "SHOULD NOT" you refer is not to conflict with the other text in the draft. I still think it would be dangerous if IPv6 nodes create *flow-specific* state based on a random packet they forward. Load-balancing applications does not need state per-flow, but state per interface. This state is created before any packets are forwarded, or the state can be algorithmically deduced from the packet headers. This is explicitly included in the definition of the "flow state establishment method" in section 1. No new state entries are created when packets are forwarded (esp. memory usage is not increased after load-balancing an outgoing packet). Another way to put it is that load-balancing works on aggregates of flows where by some function (e.g. a hash) packets from a single flow are deterministically mapped to the same outgoing interface (unless routing changes). The defined flow labeling policy guarantees that different flows do not use the same flow label with the same addresses at the same time. Currently the text states that it is the responsibility of the "flow owner" to hold on to the label as long as required for any flow-specific state to be cleared from the network. In case of load-balancing there is no flow specific state to be cleared. Even if load-balancing would not require consecutive flows to have different labels, I agree that it would be useful not to re-use a recently used value for some time unless otherwise requested by the "flow owner". However, I really would not like to specify any minimum timeouts nor define a single mandatory method by which this must be accomplished. Would it be adequate to state that "The facility SHOULD NOT assign a previously used value sooner than it needs to. This can be accomplished for example by monotonically increasing the assigned value for each new flow."? (The random initial value is already in the text). This would leave ample space for implementation specific methods for e.g. partitioning the flow label space, assigning randomly selected values (statistically different from any recent value), etc. Technically, the above addition is not needed, since the draft already states that a value may not be reused until all flow-specific state has been cleared from the network. After the state is gone, no-one will know the value is re-used... Anyway, it would provide useful guidance for implementers. Jarno > -----Original Message----- > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > Sent: 1. elokuuta 2002 22:30 > To: Rajahalme Jarno (NRC/Helsinki) > Cc: ipng@sunroof.eng.sun.com; aconta@txc.com; brian@hursley.ibm.com; > deering@cisco.com; Hinden Bob (IPRG) > Subject: Re: Flow label draft issues & new text > > > > Hi Jarno, > > >The method by which the flow state is cleared from the IPv6 > nodes is to be defined by the flow state establishment method > used to set up the state. This implies that IPv6 nodes SHOULD > NOT establish any flow-specific state unless so instructed by > a specific flow state establishment method. > > I don't agree with the "SHOULD NOT" above... > > There are some potential uses for flow identification that do > not rely on > any sort of flow establishment mechanism or signalling, such > as the use of > flow labels for load balancing. > > To have a useful flow label for these mechanisms, an IPv6 > node simply labels > all of the packets in a given TCP/SCTP connection or UDP > communication with > the same flow label,making some basic effort not to re-use > flows too often -- > such as starting with a random number and monotonically > increasing it for > each new connection or communication. > > It would be fairly trivial to assign a flow label in this > fashion -- not > much harder than setting it to zero. So, you get a > reasonable return for > very little work. > > Of course, this type of non-unique flow labeling isn't > consistent with using > flow labels to cache next-hop information, for example. For > those more > sophisticated needs, a real flow establishment (and > maintenance) method may > be needed. But, I don't think that we should require a more > sophisticated > method to be present in order to use the flow label at all. > > Margaret > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 2 04:44:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72BiA3U025914; Fri, 2 Aug 2002 04:44:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72BiAKj025913; Fri, 2 Aug 2002 04:44:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Bi43U025906 for ; Fri, 2 Aug 2002 04:44:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA26249 for ; Fri, 2 Aug 2002 04:44:09 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15806 for ; Fri, 2 Aug 2002 05:44:07 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g72BgPl09388 for ; Fri, 2 Aug 2002 14:42:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 Aug 2002 14:44:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 2 Aug 2002 14:44:06 +0300 content-class: urn:content-classes:message Subject: RE: Flow label draft issues & new text MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 2 Aug 2002 14:44:05 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757D31056@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcI50ep/ZxSHsTEGSauh8R+k4HBZcgAR550g To: , Cc: , , , , X-OriginalArrivalTime: 02 Aug 2002 11:44:06.0321 (UTC) FILETIME=[E8264210:01C23A19] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g72Bi43U025907 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Let's agree first what the "SHOULD NOT" applies to, see my response to Margaret. Anyway, we have explicitly tried to encourage KAME-style flow labeling as the default by the IPv6 stacks. But obviously there still are some details to get cleared up to avoid ambiguous interpretation of the text. Jarno > -----Original Message----- > From: ext itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: 2. elokuuta 2002 6:08 > To: Margaret Wasserman > Cc: Rajahalme Jarno (NRC/Helsinki); ipng@sunroof.eng.sun.com; > aconta@txc.com; brian@hursley.ibm.com; deering@cisco.com; Hinden Bob > (IPRG) > Subject: Re: Flow label draft issues & new text > > > >I don't agree with the "SHOULD NOT" above... > > > >There are some potential uses for flow identification that > do not rely on > >any sort of flow establishment mechanism or signalling, such > as the use of > >flow labels for load balancing. > > > >To have a useful flow label for these mechanisms, an IPv6 > node simply labels > >all of the packets in a given TCP/SCTP connection or UDP > communication with > >the same flow label,making some basic effort not to re-use > flows too often -- > >such as starting with a random number and monotonically > increasing it for > >each new connection or communication. > > > >It would be fairly trivial to assign a flow label in this > fashion -- not > >much harder than setting it to zero. So, you get a > reasonable return for > >very little work. > > I agree with Margaret. KAME has been doing this (automatically > assign flow labels to TCP/connected UDP traffic) for a > long time, > so that we can help traffic analysis/diffserv researchers. > (they can't correlate traffic due to the use of ESP, or SSH) > draft-itojun-ipv6-flowlabel-api-01.txt has more details on it. > > itojun > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 2 09:53:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Gr53U027213; Fri, 2 Aug 2002 09:53:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72Gr4QL027212; Fri, 2 Aug 2002 09:53:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Gqx3U027205 for ; Fri, 2 Aug 2002 09:52:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02578 for ; Fri, 2 Aug 2002 09:53:05 -0700 (PDT) Received: from e1.ny.us.ibm.com. (e1.ny.us.ibm.com [32.97.182.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23073 for ; Fri, 2 Aug 2002 09:53:04 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com. (8.12.2/8.12.2) with ESMTP id g72GohbW188768; Fri, 2 Aug 2002 12:50:43 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g72Goefi109958; Fri, 2 Aug 2002 12:50:41 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g72GnYI06512; Fri, 2 Aug 2002 12:49:34 -0400 Message-Id: <200208021649.g72GnYI06512@rotala.raleigh.ibm.com> To: Robert Elz cc: "Richard Draves" , ipng@sunroof.eng.sun.com, "Bob Hinden" Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: Message from "Thu, 01 Aug 2002 18:51:58 +0700." <13283.1028202718@munnari.OZ.AU> Date: Fri, 02 Aug 2002 12:49:33 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > Date: Wed, 31 Jul 2002 15:12:18 -0400 > From: Thomas Narten > Message-ID: <200207311912.g6VJCIV16013@rotala.raleigh.ibm.com> > | Section 4 has some "mays", some of which might better be > | should/SHOULDs. I.e., an admin SHOULD set a low priority if the router > | doesn't reach the internet (due to connectivity or firewall). > Thomas, the point of the SHOULD etc words is to tell the implementor > what to implement. They're not at all effective in attempting to control > how people actually configure the equipment. SHOULD (or should) are used both to tell implementors what to implement and to make recommendations on how stuff ought to be configured/deployed/used. A goal of having shoulds on how things should be configured is to prevent ill-thought settings from being used by default. We do this all the time. Its prudent damage-avoidance. > And in any case, this is certainly not the doc to be attempting to tell > people how to do that - if you want a BCP on setting up IPv6 routers in > nice ways, then get someone to write one (as well as what prefs to set, > and when, it could go into what lifetimes to use in various situations, etc). Its common to mix applicability stuff in with a protocol standard. We do it far more often than writing a separate standalone applicability document. > But none of that belongs here (or not pretending to be any more than general > commentary so the implementor can understand what the user might want to > do with the implementation). > | Does it ever make sense to advertise a high preference in the absence > | of more detailed knowledge of the topology? > "None of your business." In other words, are you saying the document should provide no guidance to admins on how they should configure things, because that is by definition out of scope in a protocol docuent? If so, I disagree. > I will configure the preferences of the routers I manage in the way > that makes my net work for me. All that is needed of the IETF is > to provide the tool for me to use (and if you also want to give some > "good usage" advice, that's OK as well, but it should not be as part > of the protocol spec). Noone is saying you can't configure things the way you want. A SHOULD means, do this unless you understand what you are doing, understand the consequences of doing something different, but want to do something different anyway. > | Also, in chatting with Erik Nordmark, he indicated that at one point > | there were some discussions about adding a client capability to have a > | map table that mapped received preferences into other values, to > | handle situations where the received preferences didn't have the > | desired result. Would that be a useful thing to have? > Maybe. But this is a quality of implementation issue. I think this kind > of thing only matters when one is attempting to specify things like "if > I see any normal or high pref routers on interface A, that's what I want > to use as my default, but if all I see is low, and there is a high pref > router on interface B, then use that one" ... > All this is really beyond the scope of the protocol of router prefs though. You seem to be making it sound like a protocol spec should document only the on-the-wire part, and things relating to configuration are out-of-scope. If this is your point, I disagree on principle. > | One problem with the above is you assume that the implementor has > | knowledge about the enivironments in which technology will be > | deployed, and can thus make such tradeoffs. > Naturally. This applies to all implementation choices in just about > everything, from how much RAM is (and can be) installed, to what protocols > are supported. > If the implementor hasn't implemented the protocols with the features > that are required, or in the way that makes sense for a particular > environment, then that implementation should not be used there. You are assuming that an end user will have the choice of not using a feature. If the device is (say) a PDA, you might not have the ability to turn it off or otherwise control its usage. For better or worse, I think there are fewer and fewer places where the implementor really has a good idea of where something will be deployed. Consequently, we have to assume things will be deployed in the general internet, not in some sort of restricted environment (or include an applicability statement saying where something shouldn't be used). > | It would be better if the spec did not allow poor implementation > | choices (that have undesirable consequences on the internet) to be > | considered "in conformance with the standard". > If they actually have undesirable consequences for the internet, I'd > agree. But I don't see that here, only possibly undesirable consequences > for the customer who installed the equipment. Given that, thanks for > caring, but I want to be able to acquire cheap implementations when those > are adequate for my purposes. My text relates to flushing the entire ND cache and losing associated cached PMTU information. Are you saying this is OK to do this and doesn't have harmful consequences? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 2 11:25:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72IPF3U027752; Fri, 2 Aug 2002 11:25:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72IPFdF027751; Fri, 2 Aug 2002 11:25:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72IP93U027741 for ; Fri, 2 Aug 2002 11:25:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12246 for ; Fri, 2 Aug 2002 11:25:14 -0700 (PDT) Received: from noao.edu (noao.edu [140.252.1.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20449 for ; Fri, 2 Aug 2002 12:25:13 -0600 (MDT) Received: from baja.tuc.noao.edu ([140.252.8.105] verified) by noao.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP id 4872033; Fri, 02 Aug 2002 11:25:13 -0700 Received: (from shroff@localhost) by baja.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) id LAA03782; Fri, 2 Aug 2002 11:24:48 -0700 (MST) Date: Fri, 2 Aug 2002 11:24:48 -0700 (MST) From: "Chirag H. Shroff" Message-Id: <200208021824.LAA03782@baja.tuc.noao.edu> To: ipng@sunroof.eng.sun.com Subject: getaddrinfo Cc: shroff@noao.edu X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following is an example from R Stevens book "UNP". I am having difficulties with the code shown below. When I try to compile it using...... gcc tcp_connect.c -lsocket -lnsl -lresolv -lc I get the following error messages.... baja{shroff}% gcc tcp_connect.c -lsocket -lnsl -lresolv -lc tcp_connect.c: In function `tcp_connect': tcp_connect.c:38: storage size of `hints' isn't known tcp_connect.c:40: sizeof applied to an incomplete type tcp_connect.c:53: dereferencing pointer to incomplete type tcp_connect.c:53: dereferencing pointer to incomplete type tcp_connect.c:53: dereferencing pointer to incomplete type tcp_connect.c:56: dereferencing pointer to incomplete type tcp_connect.c:56: dereferencing pointer to incomplete type tcp_connect.c:61: dereferencing pointer to incomplete type I think these errors are due to the use of getaddrinfo. I am very new to socket programming. I'll be greatful if someone can tell me where i am going wrong. Thanks a lot, Chirag #include #include #include #include #include #include #include #include #include //#include "addrinfo.h" #define ERROR -1 #define OK 1 #define TRUE 1 /******************************************************************************** * tcp_connect - client task * * * RETURNS: OK or ERROR */ int tcp_connect (const char *host, const char *serv) { int sockfd, n; struct addrinfo hints, *res, *ressave; bzero (&hints, sizeof (struct addrinfo)); hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_STREAM; if ((n = getaddrinfo (host, serv, &hints, &res)) != 0) { printf ("tcp_connect error for %s, %s: %s\n\n",host,serv,gai_strerror(n)); return ERROR; } ressave = res; do { if((sockfd=socket (res->ai_family,res->ai_socktype,res->ai_protocol))<0) continue; if (connect (sockfd, res->ai_addr, res->ai_addrlen) == 0) break; // connected. close (sockfd); // connect was not successful, so ignore this socket. } while ((res = res->ai_next) != NULL); if (res == NULL) { // connection could not be established. printf ("tcp_connect error for %s, %s", host,serv); return ERROR; } freeaddrinfo (ressave); return (sockfd); } int main () { tcp_connect ("140.252.7.10", "daytime"); exit (0); } -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 2 12:44:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JiW3U029777; Fri, 2 Aug 2002 12:44:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72JiWCa029776; Fri, 2 Aug 2002 12:44:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JiR3U029769 for ; Fri, 2 Aug 2002 12:44:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03910 for ; Fri, 2 Aug 2002 12:44:33 -0700 (PDT) Received: from noao.edu (noao.edu [140.252.1.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05572 for ; Fri, 2 Aug 2002 13:44:32 -0600 (MDT) Received: from baja.tuc.noao.edu ([140.252.8.105] verified) by noao.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP id 4872898; Fri, 02 Aug 2002 12:44:32 -0700 Received: (from shroff@localhost) by baja.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) id MAA03980; Fri, 2 Aug 2002 12:44:07 -0700 (MST) Date: Fri, 2 Aug 2002 12:44:07 -0700 (MST) From: "Chirag H. Shroff" Message-Id: <200208021944.MAA03980@baja.tuc.noao.edu> To: billcote@zk3.dec.com Subject: Re: getaddrinfo Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your reply. I included the defination when i added again i got the following message: baja{shroff}% gcc tcp_connect.c -lsocket -lnsl -lresolv -lc Undefined first referenced symbol in file getaddrinfo /var/tmp/cc0PNKdp.o gai_strerror /var/tmp/cc0PNKdp.o freeaddrinfo /var/tmp/cc0PNKdp.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status from my prev experiences i know that when we dont add a library corresponding to the function call we get the above message. I am trying a lot to find the library but i am not able to. Which library do i need to add? Where am I going wrong? Please help. Thanks a lot. Chirag > From billcote@zk3.dec.com Fri Aug 2 11:42 MST 2002 > X-Autogenerated: Mirror > X-Mirrored-by: (Chirag Shroff) > Date: Fri, 02 Aug 2002 14:42:34 -0400 > From: Bill Cote USG > User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.4) Gecko/20011025 Netscape6/6.2 > X-Accept-Language: en-us > MIME-Version: 1.0 > To: "Chirag H. Shroff" > Subject: Re: getaddrinfo > Content-Transfer-Encoding: 7bit > > It looks like you don't have the getaddrinfo struct defined in any of > your headers. Check those out to make sure that it's in there (should > be in netdb.h). If not, you may need to include a different one > > Chirag H. Shroff wrote: > > > The following is an example from R Stevens book "UNP". I am having difficulties > > with the code shown below. > > > > When I try to compile it using...... > > > > gcc tcp_connect.c -lsocket -lnsl -lresolv -lc > > > > I get the following error messages.... > > > > baja{shroff}% gcc tcp_connect.c -lsocket -lnsl -lresolv -lc > > tcp_connect.c: In function `tcp_connect': > > tcp_connect.c:38: storage size of `hints' isn't known > > tcp_connect.c:40: sizeof applied to an incomplete type > > tcp_connect.c:53: dereferencing pointer to incomplete type > > tcp_connect.c:53: dereferencing pointer to incomplete type > > tcp_connect.c:53: dereferencing pointer to incomplete type > > tcp_connect.c:56: dereferencing pointer to incomplete type > > tcp_connect.c:56: dereferencing pointer to incomplete type > > tcp_connect.c:61: dereferencing pointer to incomplete type > > > > I think these errors are due to the use of getaddrinfo. I am very new to socket > > programming. I'll be greatful if someone can tell me where i am going wrong. > > > > Thanks a lot, > > > > Chirag > > > > > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > //#include "addrinfo.h" > > > > #define ERROR -1 > > #define OK 1 > > #define TRUE 1 > > > > > > /******************************************************************************** > > * tcp_connect - client task > > * > > * > > * RETURNS: OK or ERROR > > */ > > > > int tcp_connect (const char *host, const char *serv) { > > > > int sockfd, n; > > struct addrinfo hints, *res, *ressave; > > > > bzero (&hints, sizeof (struct addrinfo)); > > hints.ai_family = AF_UNSPEC; > > hints.ai_socktype = SOCK_STREAM; > > > > if ((n = getaddrinfo (host, serv, &hints, &res)) != 0) { > > printf ("tcp_connect error for %s, %s: %s\n\n",host,serv,gai_strerror(n)); return ERROR; > > } > > > > ressave = res; > > > > do { > > > > if((sockfd=socket (res->ai_family,res->ai_socktype,res->ai_protocol))<0) continue; > > > > if (connect (sockfd, res->ai_addr, res->ai_addrlen) == 0) > > break; // connected. > > > > close (sockfd); // connect was not successful, so ignore this socket. > > > > } while ((res = res->ai_next) != NULL); > > > > > > if (res == NULL) { // connection could not be established. > > printf ("tcp_connect error for %s, %s", host,serv); > > return ERROR; > > } > > > > freeaddrinfo (ressave); > > > > return (sockfd); > > } > > > > int main () { > > > > tcp_connect ("140.252.7.10", "daytime"); > > > > exit (0); > > } > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 2 15:17:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72MHG3U000203; Fri, 2 Aug 2002 15:17:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72MHGdP000202; Fri, 2 Aug 2002 15:17:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72MHA3U000194 for ; Fri, 2 Aug 2002 15:17:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23248 for ; Fri, 2 Aug 2002 15:17:16 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22748 for ; Fri, 2 Aug 2002 15:17:15 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA04137 for ; Fri, 2 Aug 2002 15:17:15 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g72MHEZ22946; Fri, 2 Aug 2002 15:17:14 -0700 X-mProtect: <200208022217> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpde1tkxn; Fri, 02 Aug 2002 15:17:08 PDT Message-Id: <4.3.2.7.2.20020802140116.02cb6270@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Aug 2002 15:16:11 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: References: <"Your message with ID" <13209.1028199712@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >we might have the following choices (I can't think of other combinations that >make sense to me): >1. all are optional >2. load sharing is mandatory; others are optional >3. load sharing and router preferences are mandatory; more specific is >optional >4. all are mandatory The current proposal is to split the document and make load sharing mandatory and router preferences and more specific routes optional. This is choice 2. As far as I can tell only one person has objected to this approach and has suggested choice 3. (perhaps 4). Are there any other objections to the current proposal? Bob p.s. >But independent of this, if is confusing to have both mandatory and optional >protocol pieces in the same document if it can be easily avoided. Me too. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 2 15:48:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Mms3U000462; Fri, 2 Aug 2002 15:48:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72Mms2J000461; Fri, 2 Aug 2002 15:48:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Mml3U000454 for ; Fri, 2 Aug 2002 15:48:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07173 for ; Fri, 2 Aug 2002 15:48:52 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14619 for ; Fri, 2 Aug 2002 16:48:51 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 674194B22; Sat, 3 Aug 2002 07:48:47 +0900 (JST) To: "Chirag H. Shroff" Cc: ipng@sunroof.eng.sun.com In-reply-to: shroff's message of Fri, 02 Aug 2002 11:24:48 MST. <200208021824.LAA03782@baja.tuc.noao.edu> 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: getaddrinfo From: itojun@iijlab.net Date: Sat, 03 Aug 2002 07:48:47 +0900 Message-Id: <20020802224847.674194B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The following is an example from R Stevens book "UNP". I am having difficulties >with the code shown below. the book has more than a couple of errors in IPv6 section, so be warned... >When I try to compile it using...... > gcc tcp_connect.c -lsocket -lnsl -lresolv -lc >I get the following error messages.... >baja{shroff}% gcc tcp_connect.c -lsocket -lnsl -lresolv -lc >tcp_connect.c: In function `tcp_connect': i guess you are using Solaris, but which version? #include should be enough for pulling defs for struct addrinfo. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 3 00:21:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g737LN3U001388; Sat, 3 Aug 2002 00:21:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g737LMsr001387; Sat, 3 Aug 2002 00:21:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g737LF3U001380 for ; Sat, 3 Aug 2002 00:21:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28445 for ; Sat, 3 Aug 2002 00:21:18 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA04915 for ; Sat, 3 Aug 2002 01:21:16 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g737LAA86150 for ; Sat, 3 Aug 2002 16:21:11 +0900 (JST) Date: Sat, 03 Aug 2002 16:21:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: per-connection config and destination address selection In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 72 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 30 Jul 2002 14:29:25 +0900, >>>>> JINMEI Tatuya said: > This may rather be an implementation issue, so I don't think we need a > major revise of the draft just due to this. But I also think it would > be good to add some note about the dependency in Section 8 before > publishing the draft. I've locally discussed the issue with some people including the author, and would like to propose the attached changes based on the discussion. The changes do not modify the policy of selection rules, so I believe we can agree on them. The author of the draft has already agreed. I'm posting the changes here to see if there is an objection to the changes from other wg members. If not, then the author will revise the draft once again, and in parallel the IESG will approve the draft. So please check the followings, and speak up if you have an objection. There are two changes in Section 5 (Source Address Selection). Change the last sentence in Rule4: Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB. An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer care-of addresses over home addresses. To: An implementation should provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. and change the last sentence in: Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary address, then prefer SB. An implementation MUST support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer temporary addresses over public addresses. to: An implementation MUST provide a mechanism allowing an application to reverse the sense of this preference and prefer temporary addresses over public addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. (end of change) The rationale of the changes is that the issue is rather than in the wording in the selection rules. With this change, we avoided the wording "per-connection" and "a socket option", so that the draft will be generic and be independent of implementation details. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 3 21:54:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g744sc3U002548; Sat, 3 Aug 2002 21:54:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g744sb4F002547; Sat, 3 Aug 2002 21:54:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g744sW3U002540 for ; Sat, 3 Aug 2002 21:54:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03567 for ; Sat, 3 Aug 2002 21:54:35 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA05889 for ; Sat, 3 Aug 2002 22:54:27 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g72904G13714; Fri, 2 Aug 2002 16:00:05 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g728xCc17752; Fri, 2 Aug 2002 15:59:14 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Brian E Carpenter cc: itojun@iijlab.net, Margaret Wasserman , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com, aconta@txc.com, deering@cisco.com, hinden@iprg.nokia.com Subject: Re: Flow label draft issues & new text In-Reply-To: <3D4A4572.72E2A079@hursley.ibm.com> References: <3D4A4572.72E2A079@hursley.ibm.com> <20020802030829.A32294B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Aug 2002 15:59:12 +0700 Message-ID: <17750.1028278752@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 02 Aug 2002 10:40:18 +0200 From: Brian E Carpenter Message-ID: <3D4A4572.72E2A079@hursley.ibm.com> | I think in the end this is an argument about nothing. I think I agree with that. | > This implies that IPv6 nodes SHOULD NOT establish any flow-specific | > state unless so instructed by a specific flow state establishment method. | | What Margaret and itojun refer to are flow state establishment methods that | happen to consist of algorithms built into the sending node (rather than | signaling mechanisms or pre-configured flow states). These algorithms | must avoid duplicate labels, just as signaled or pre-configured | methods must. Yes, when you consider only the source nodes. There the method you describe is correct, and the concerns expressed aren't a problem. The wording could perhaps be improved to make that clear. But... | So the sentence is in fact a no-op and can be deleted. I don't agree with that - I read the relevant sentence as being directed at intermediate nodes (routers), not at the end nodes (hosts). That is, I thought that it was trying to say that routers should not just "notice" that there seems to be a flow passing by, and attempt to do magic things to that flow, because there's no way to flush the state they establish to do that. That is, there needs to be some kind of setup mechanism (anything from RSVP to an RFC) that defines just how the flows are established, and when they should be torn down again. Don't delete it, just make its scope clearer. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 4 17:39:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g750dq3U003663; Sun, 4 Aug 2002 17:39:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g750dqkf003662; Sun, 4 Aug 2002 17:39:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g750dj3U003655 for ; Sun, 4 Aug 2002 17:39:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04497 for ; Sun, 4 Aug 2002 17:39:48 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07577 for ; Sun, 4 Aug 2002 18:39:48 -0600 (MDT) Received: from kenawang ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA08943 for ; Sun, 4 Aug 2002 17:39:40 -0700 (PDT) Message-Id: <4.2.2.20020804200432.024dadc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 04 Aug 2002 20:40:32 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As mentioned on this list previously, the IPv6 WG has been asked to review draft-savola-ipv6-127-prefixlen-04.txt, which has been submitted to the RFC editor for publication as an Informational RFC. The draft discusses several operational issues with the use of /127 prefixes on point-to-point links between routers. Reviewing this draft raised several interesting questions, in my mind, about our current addressing architecture... First, I wondered why this would be an issue when all recent versions of the Addressing Architecture, including the most recent update (draft-ietf-ipngwg-addr-arch-v3-08.txt) specify a maximum length prefix of /64 for all addresses that don't start with '000'. At least, this is clearly implied by the following wording: "For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." Unfortunately, operators seem to be ignoring this restriction in numbering point-to-point links between routers. I have spoken to a few IPv6 operators, and it is common practice to use /125, /126 or even /127 prefixes for these links. What does this mean for us? Well, in my opinion, we don't want to standardize a restriction that we _know_ will be ignored by the folks who are deploying the software. We want/need to use EUI-64-based addresses for address autoconfiguration. But, is this inherently incompatible with the folks using longer prefixes on point-to-point links? Why do all IIDs need to be in modified EUI-64 format? Do we want to remove this restriction from the addressing architecture? Or can we show good reasons why it shouldn't be ignored? We also may want to be cautious about standardizing mechanisms that rely on a hard /64 boundary between the prefix and IID. For example, what is the minimum number of IID bits I must have to use privacy addresses? The addressing architecture also imparts special meaning to two bits in the middle of the IID. Bits 70 and 71 of an IPv6 address are called the 'u' bit and the 'g' bit, and their semantics are based on the meanings of the corresponding bits in EUI-64 identifiers (with the sense of the 'u' bit reversed). The 'u' bit is supposed to indicate whether the IID is a globally unique EUI-64-based identifier (1=yes, 0=no), and the 'g' bit is reserved (must be 0). When longer prefixes are used, though, these bits end-up in the prefix, instead of in the IID. Can we really expect operators to reserve these two bits for this use? Or will they allocate their longer prefixes without worrying about the meaning of these two bits? If we think that, in practice, operators will ignore the meaning of these two bits, does the 'u' bit really have any meaning at all? Do I have any answers to all of the questions I keep asking? :-) Well, maybe... In my opinion, we should not standardize a hard boundary between the prefix and the IID, especially if we know it will be ignored by operators. We can make it clear that a 64-bit boundary is required in order to use EUI-64-based addresses for address autoconfiguration. And, it might make sense to document a maximum prefix length that is consistent with privacy addresses. I also think that we should drop the 'u' and 'g' bit semantics from the addressing architecture. It is pretty clear, at this point, that we won't ever be certain that an address with the 'u'-bit set has a globally unique IID, so there really isn't any reason to clutter up the addressing architecture with these strange bits. What do the rest of you think? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 4 20:25:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g753PT3U004014; Sun, 4 Aug 2002 20:25:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g753PTxH004013; Sun, 4 Aug 2002 20:25:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g753PN3U004006 for ; Sun, 4 Aug 2002 20:25:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20010 for ; Sun, 4 Aug 2002 20:25:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15248 for ; Sun, 4 Aug 2002 21:25:29 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g753PLW03257; Sun, 4 Aug 2002 20:25:21 -0700 (PDT) From: Bill Manning Message-Id: <200208050325.g753PLW03257@boreas.isi.edu> Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020804200432.024dadc0@mail.windriver.com> from Margaret Wasserman at "Aug 4, 2 08:40:32 pm" To: mrw@windriver.com (Margaret Wasserman) Date: Sun, 4 Aug 2002 20:25:21 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % Unfortunately, operators seem to be ignoring this restriction in % numbering point-to-point links between routers. I have spoken to % a few IPv6 operators, and it is common practice to use /125, /126 % or even /127 prefixes for these links. /64s are a waste of space. their use can be confusing when things are p2p. % We want/need to use EUI-64-based addresses for address % autoconfiguration. But, is this inherently incompatible with % the folks using longer prefixes on point-to-point links? Why % do all IIDs need to be in modified EUI-64 format? Do we % want to remove this restriction from the addressing architecture? % Or can we show good reasons why it shouldn't be ignored? Yes please. It would be highly desirable to locally use subnets in the, say 70-110 bit range. % We also may want to be cautious about standardizing mechanisms % that rely on a hard /64 boundary between the prefix and IID. % For example, what is the minimum number of IID bits I must % have to use privacy addresses? Well, the real problem is mixing transport locators with node identifiers, as is done with the current architecture. Hard-coding the split @ 64 bits will encourage vendors to hardcode these restrictions in silicon. Avoiding this was an early design consideration that seems to have been lost. Ideally we should lose the node identifer from the addressing architecture. (I know, if wishes were horses...) % Can we really expect operators to reserve these two bits for % this use? Or will they allocate their longer prefixes without % worrying about the meaning of these two bits? We will allocate, ignoring implied meaning in these bits. % In my opinion, we should not standardize a hard boundary between % the prefix and the IID, especially if we know it will be ignored % by operators. Amen (and for other reasons as well) % We can make it clear that a 64-bit boundary is required in order % to use EUI-64-based addresses for address autoconfiguration. And, % it might make sense to document a maximum prefix length that is % consistent with privacy addresses. EUI-64 based numbers really have no place in IPv6 addresses, except as a local optimization. Use of EUI-64 addresses introduces privacy concerns that require the invention of grevious hacks to address mgmt. % I also think that we should drop the 'u' and 'g' bit semantics % from the addressing architecture. It is pretty clear, at this % point, that we won't ever be certain that an address with the % 'u'-bit set has a globally unique IID, so there really isn't % any reason to clutter up the addressing architecture with these % strange bits. Amen to this as well. % What do the rest of you think? Well, here is one set of opinions. % % Margaret % % % % % % % % % % % % % % -------------------------------------------------------------------- % IETF IPng Working Group Mailing List % IPng Home Page: http://playground.sun.com/ipng % FTP archive: ftp://playground.sun.com/pub/ipng % Direct all administrative requests to majordomo@sunroof.eng.sun.com % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 4 22:05:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7555C3U004290; Sun, 4 Aug 2002 22:05:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7555CUU004289; Sun, 4 Aug 2002 22:05:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g755563U004282 for ; Sun, 4 Aug 2002 22:05:06 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g75555g22730; Mon, 5 Aug 2002 07:05:06 +0200 (MEST) Date: Mon, 5 Aug 2002 07:03:08 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: per-connection config and destination address selection To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The rationale of the changes is that the issue is rather than in the > wording in the selection rules. With this change, we avoided the > wording "per-connection" and "a socket option", so that the draft will > be generic and be independent of implementation details. I agree with these changes. But it would also be useful to have a draft (or add to an existing draft?) the actual API extensions for these knobs, whether they are socket options and/or flags passed to getaddrinfo. Is anybody working on such a draft? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 4 23:53:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g756ru3U004493; Sun, 4 Aug 2002 23:53:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g756rugJ004492; Sun, 4 Aug 2002 23:53:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g756ro3U004485 for ; Sun, 4 Aug 2002 23:53:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19385 for ; Sun, 4 Aug 2002 23:53:53 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12303 for ; Mon, 5 Aug 2002 00:53:52 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g756u5W26932 for ; Mon, 5 Aug 2002 09:56:05 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 5 Aug 2002 09:53:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 5 Aug 2002 09:53:50 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 5 Aug 2002 09:53:49 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757D31059@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcI7cbQBv1BZDHxvSwqiFGqxg6Sp+AA2vfaw To: , Cc: , , , , , X-OriginalArrivalTime: 05 Aug 2002 06:53:50.0769 (UTC) FILETIME=[DAE92A10:01C23C4C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g756rp3U004486 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, You got my point exactly, any suggestions on how to make the text clearer about this? Jarno > -----Original Message----- > From: ext Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: 2. elokuuta 2002 11:59 > To: Brian E Carpenter > Cc: itojun@iijlab.net; Margaret Wasserman; Rajahalme Jarno > (NRC/Helsinki); ipng@sunroof.eng.sun.com; aconta@txc.com; > deering@cisco.com; Hinden Bob (IPRG) > Subject: Re: Flow label draft issues & new text > > > Date: Fri, 02 Aug 2002 10:40:18 +0200 > From: Brian E Carpenter > Message-ID: <3D4A4572.72E2A079@hursley.ibm.com> > > | I think in the end this is an argument about nothing. > > I think I agree with that. > > | > This implies that IPv6 nodes SHOULD NOT establish any > flow-specific > | > state unless so instructed by a specific flow state > establishment method. > | > | What Margaret and itojun refer to are flow state > establishment methods that > | happen to consist of algorithms built into the sending > node (rather than > | signaling mechanisms or pre-configured flow states). > These algorithms > | must avoid duplicate labels, just as signaled or pre-configured > | methods must. > > Yes, when you consider only the source nodes. There the method you > describe is correct, and the concerns expressed aren't a problem. > The wording could perhaps be improved to make that clear. > > But... > > | So the sentence is in fact a no-op and can be deleted. > > I don't agree with that - I read the relevant sentence as > being directed > at intermediate nodes (routers), not at the end nodes > (hosts). That is, > I thought that it was trying to say that routers should not > just "notice" > that there seems to be a flow passing by, and attempt to do > magic things > to that flow, because there's no way to flush the state they > establish to > do that. That is, there needs to be some kind of setup > mechanism (anything > from RSVP to an RFC) that defines just how the flows are > established, and > when they should be torn down again. > > Don't delete it, just make its scope clearer. > > kre > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 02:14:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g759EW3U004809; Mon, 5 Aug 2002 02:14:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g759EWOL004808; Mon, 5 Aug 2002 02:14:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g759EO3U004801 for ; Mon, 5 Aug 2002 02:14:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11397 for ; Mon, 5 Aug 2002 02:14:29 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10444 for ; Mon, 5 Aug 2002 03:14:28 -0600 (MDT) Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.05) id 17bdwY-000IIg-00; Mon, 05 Aug 2002 10:14:26 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA45424; Mon, 5 Aug 2002 10:14:19 +0100 Message-ID: <3D4E4210.656214C1@hursley.ibm.com> Date: Mon, 05 Aug 2002 11:14:56 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Robert Elz CC: itojun@iijlab.net, Margaret Wasserman , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com, aconta@txc.com, deering@cisco.com, hinden@iprg.nokia.com Subject: Re: Flow label draft issues & new text References: <3D4A4572.72E2A079@hursley.ibm.com> <20020802030829.A32294B22@coconut.itojun.org> <17750.1028278752@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Fri, 02 Aug 2002 10:40:18 +0200 > From: Brian E Carpenter > Message-ID: <3D4A4572.72E2A079@hursley.ibm.com> > > | I think in the end this is an argument about nothing. > > I think I agree with that. > > | > This implies that IPv6 nodes SHOULD NOT establish any flow-specific > | > state unless so instructed by a specific flow state establishment method. > | > | What Margaret and itojun refer to are flow state establishment methods that > | happen to consist of algorithms built into the sending node (rather than > | signaling mechanisms or pre-configured flow states). These algorithms > | must avoid duplicate labels, just as signaled or pre-configured > | methods must. > > Yes, when you consider only the source nodes. There the method you > describe is correct, and the concerns expressed aren't a problem. > The wording could perhaps be improved to make that clear. > > But... > > | So the sentence is in fact a no-op and can be deleted. > > I don't agree with that - I read the relevant sentence as being directed > at intermediate nodes (routers), not at the end nodes (hosts). That is, > I thought that it was trying to say that routers should not just "notice" > that there seems to be a flow passing by, and attempt to do magic things > to that flow, because there's no way to flush the state they establish to > do that. That is, there needs to be some kind of setup mechanism (anything > from RSVP to an RFC) that defines just how the flows are established, and > when they should be torn down again. > > Don't delete it, just make its scope clearer. Since intermediate nodes are not allowed to change the flow label, it never even occurred to me to think of it in that context. Send text. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 06:21:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75DLC3U005108; Mon, 5 Aug 2002 06:21:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75DLCRi005107; Mon, 5 Aug 2002 06:21:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75DL73U005100 for ; Mon, 5 Aug 2002 06:21:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11872 for ; Mon, 5 Aug 2002 06:21:12 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23120 for ; Mon, 5 Aug 2002 07:21:10 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g75DKLG22753; Mon, 5 Aug 2002 20:20:22 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g75DJiH15121; Mon, 5 Aug 2002 20:19:44 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: jarno.rajahalme@nokia.com cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: <009CA59D1752DD448E07F8EB2F911757D31059@esebe004.NOE.Nokia.com> References: <009CA59D1752DD448E07F8EB2F911757D31059@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Aug 2002 20:19:44 +0700 Message-ID: <15119.1028553584@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 5 Aug 2002 09:53:49 +0300 From: jarno.rajahalme@nokia.com Message-ID: <009CA59D1752DD448E07F8EB2F911757D31059@esebe004.NOE.Nokia.com> | any suggestions on how to make the text clearer about this? brian@hursley.ibm.com said: | Send text. Me and my big keyboard... Well.. The method by which the flow state is cleared from the IPv6 nodes is to be defined by the flow state establishment method used to set up the state. That's fine. This implies that IPv6 nodes SHOULD NOT establish any flow-specific state unless so instructed by a specific flow state establishment method. That's fine too, provided that you assume that the reader has actually read the definitions, and noticed: Flow state A control mechanism used to set up the flow establishment method state. A flow state establishment method can be either - Dynamic, under source or destination node control (e.g. RSVP), - Quasi-dynamic, under network management control, - Static, through manual configuration, or - Algorithmic (e.g. load spreading) (grammar nit: I don't think "either" is correct to describe a choice among more than 2 things, make it "any of"). The problem is that many simply assume that they know what all the words mean, and treat the definitions section, like acknowledgments, and security considerations, as something of no relevance, and skip it. So, perhaps add In particular, nodes should not simply react to observing the flow labels of traffic passing through. This is not a flow state establishment method, and, in particular, gives no hint as to when packets may now be part of a different flow than previous packets similarly labeled. The rest ... With some flow state establishment methods, signaling new state simultaneously clearing the old state from the new path may be sufficient. A mechanism with a sufficiently long timeout period before reusing the Flow Label values can also be used. is also OK, that's just hints to flow state setup types (ie: working groups and the link) as to what they might like to define in their protocols. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 06:33:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75DXe3U005166; Mon, 5 Aug 2002 06:33:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75DXdbB005165; Mon, 5 Aug 2002 06:33:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75DXK3U005155 for ; Mon, 5 Aug 2002 06:33:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04827 for ; Mon, 5 Aug 2002 06:32:45 -0700 (PDT) Received: from znsgs01r.europe.nortel.com (h2s128a211n47.user.nortelnetworks.com [47.211.128.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01614 for ; Mon, 5 Aug 2002 07:32:44 -0600 (MDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g75DWOD24949; Mon, 5 Aug 2002 14:32:24 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 14:32:25 +0100 Message-ID: <4103264BC8D3D51180B7002048400C456345C3@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Mon, 5 Aug 2002 14:32:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23C84.8686C8C8" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23C84.8686C8C8 Content-Type: text/plain; charset="iso-8859-1" Hi. I had also been thinking about this matter, in particular in relation to routers having to advertise exactly matching prefix lengths to go with the hosts' chosen IID length for stateless autoconfig. Further comments below... > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: 05 August 2002 01:41 > To: ipng@sunroof.eng.sun.com > Subject: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt > > > > As mentioned on this list previously, the IPv6 WG has been asked > to review draft-savola-ipv6-127-prefixlen-04.txt, which has been > submitted to the RFC editor for publication as an Informational > RFC. > > The draft discusses several operational issues with the use of /127 > prefixes on point-to-point links between routers. > > Reviewing this draft raised several interesting questions, in my > mind, about our current addressing architecture... > > First, I wondered why this would be an issue when all recent versions > of the Addressing Architecture, including the most recent update > (draft-ietf-ipngwg-addr-arch-v3-08.txt) specify a maximum length > prefix of /64 for all addresses that don't start with '000'. At > least, this is clearly implied by the following wording: > > "For all unicast addresses, except those that start with binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format." > > Unfortunately, operators seem to be ignoring this restriction in > numbering point-to-point links between routers. I have spoken to > a few IPv6 operators, and it is common practice to use /125, /126 > or even /127 prefixes for these links. > > What does this mean for us? Well, in my opinion, we don't want > to standardize a restriction that we _know_ will be ignored by > the folks who are deploying the software. > > We want/need to use EUI-64-based addresses for address > autoconfiguration. But, is this inherently incompatible with > the folks using longer prefixes on point-to-point links? Why > do all IIDs need to be in modified EUI-64 format? Do we > want to remove this restriction from the addressing architecture? > Or can we show good reasons why it shouldn't be ignored? Two totally unrelated points here: - Coordination of prefix lengths and IID lengths between routers and hosts in stateless autoconfig becomes more complex. At present we would just assume 64 each. - Whilst it is undesirable to artificially restrict what is possible because of what is currently 'easy' in hardware, knowing that a significant (or even the majority) of prefixes are guaranteed to be no more than 64 bits in length would allow part of forwarding tables to be built with only half the memory and with today's top end general purpose processors the processing can be carried out in one register. Given that the removal of strict hierarchical allocation for techno-political reasons is likely to result in continued expansion of the DFZ forwarding table size, savings in both storage and processing time are probably worthwhile. I haven't seen any analysis of the savings that knowing a significant fraction of the table would be for 64 bit maximum prefixes. On the other hand, singling out the EUI-64 format as the sole (standardised) IID format does not cater for all evntualities. Other formats may become useful. > > We also may want to be cautious about standardizing mechanisms > that rely on a hard /64 boundary between the prefix and IID. > For example, what is the minimum number of IID bits I must > have to use privacy addresses? > If IIDs other than 64 bits are available, consideration should be given to encoding the length of the IID in the address prefix. This allows various sanity checks to be done and potentially reduces the amount of knowledge needed for autoconfig. Routers could check that prefixes advertised were not longer than the maximum implied by the IID length, and stateless autoconfig could verify that the prefix was of the right kind to match with a particular IID, and (with a little additional work) routers could identify what sort of prefixes were needed. Assuming backwards compatibility is needed, prefixes starting 001 binary would be assumed to be 64 bit prefixes as at present. It would probably be appropriate to release another portion of the reserved address space for the explicitly encoded IID length prefixes. > > The addressing architecture also imparts special meaning to two > bits in the middle of the IID. Bits 70 and 71 of an IPv6 address > are called the 'u' bit and the 'g' bit, and their semantics are > based on the meanings of the corresponding bits in EUI-64 > identifiers (with the sense of the 'u' bit reversed). The > 'u' bit is supposed to indicate whether the IID is a globally > unique EUI-64-based identifier (1=yes, 0=no), and the 'g' bit > is reserved (must be 0). When longer prefixes are used, though, > these bits end-up in the prefix, instead of in the IID. > > Can we really expect operators to reserve these two bits for > this use? Or will they allocate their longer prefixes without > worrying about the meaning of these two bits? > > If we think that, in practice, operators will ignore the meaning > of these two bits, does the 'u' bit really have any meaning at all? > If the subset of address prefixes that go with 64 bit EUI-64 IIDs are identifiable, then we can continue with the special interpretation of the g and u bits. Operators can allocate their longer prefixes out of a different set that is allowed to have /127 prefixes. > Do I have any answers to all of the questions I keep asking? :-) > Well, maybe... > > In my opinion, we should not standardize a hard boundary between > the prefix and the IID, especially if we know it will be ignored > by operators. As long as we know where the boundary is. > > We can make it clear that a 64-bit boundary is required in order > to use EUI-64-based addresses for address autoconfiguration. And, > it might make sense to document a maximum prefix length that is > consistent with privacy addresses. > > I also think that we should drop the 'u' and 'g' bit semantics > from the addressing architecture. It is pretty clear, at this > point, that we won't ever be certain that an address with the > 'u'-bit set has a globally unique IID, so there really isn't > any reason to clutter up the addressing architecture with these > strange bits. Once it is known what the length of the IID is, we can keep the semantics of the u and g bits if we want but it becomes much less of an issue if it is no longer the only way and also there should be no chance of confusion (if the prefix starts 001 binary, prefixes longer than /64 should be discarded and never used to form addresses). The semantics of the EUI-64 could be separated out and put in a separate draft to emphasise this. > > What do the rest of you think? > My twopennorth' Elwyn Davies > Margaret > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ------_=_NextPart_001_01C23C84.8686C8C8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt

Hi.

I had also been thinking about this matter, in = particular in relation to routers having to advertise exactly matching = prefix lengths to go with the hosts' chosen IID length for stateless = autoconfig.

Further comments below...

> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: 05 August 2002 01:41
> To: ipng@sunroof.eng.sun.com
> Subject: Thoughts on = draft-savola-ipv6-127-prefixlen-04.txt
>
>
>
> As mentioned on this list previously, the IPv6 = WG has been asked
> to review = draft-savola-ipv6-127-prefixlen-04.txt, which has been
> submitted to the RFC editor for publication as = an Informational
> RFC.
>
> The draft discusses several operational issues = with the use of /127
> prefixes on point-to-point links between = routers.
>
> Reviewing this draft raised several interesting = questions, in my
> mind, about our current addressing = architecture...
>
> First, I wondered why this would be an issue = when all recent versions
> of the Addressing Architecture, including the = most recent update
> (draft-ietf-ipngwg-addr-arch-v3-08.txt) specify = a maximum length
> prefix of /64 for all addresses that don't = start with '000'.  At
> least, this is clearly implied by the following = wording:
>
> "For all unicast addresses, except those = that start with binary
> value 000, Interface IDs are required to be 64 = bits long and to be
> constructed in Modified EUI-64 = format."
>
> Unfortunately, operators seem to be ignoring = this restriction in
> numbering point-to-point links between = routers.  I have spoken to
> a few IPv6 operators, and it is common practice = to use /125, /126
> or even /127 prefixes for these links.
>
> What does this mean for us?  Well, in my = opinion, we don't want
> to standardize a restriction that we _know_ = will be ignored by
> the folks who are deploying the = software.
>   
> We want/need to use EUI-64-based addresses for = address
> autoconfiguration.  But, is this = inherently incompatible with
> the folks using longer prefixes on = point-to-point links?  Why
> do all IIDs need to be in modified EUI-64 = format?  Do we
> want to remove this restriction from the = addressing architecture?
> Or can we show good reasons why it shouldn't be = ignored?

Two totally unrelated points here:
-  Coordination of prefix lengths and IID = lengths between routers and hosts in stateless autoconfig becomes more = complex.  At present we would just assume 64 each.

-  Whilst it is undesirable to artificially = restrict what is possible because of what is currently 'easy' in = hardware, knowing that a significant (or even the majority) of prefixes = are guaranteed to be no more than 64 bits in length would allow part of = forwarding tables to be built with only half the memory and with = today's top end general purpose processors the processing can be = carried out in one register.  Given that the removal of strict = hierarchical allocation for techno-political reasons is likely to = result in continued expansion of the DFZ forwarding table size, savings = in both storage and processing time are probably worthwhile.  I = haven't seen any analysis of the savings that knowing a significant = fraction of the table would be for 64 bit maximum prefixes.

On the other hand, singling out the EUI-64 format as = the sole (standardised) IID format does not cater for all = evntualities.  Other formats may become useful.

>
> We also may want to be cautious about = standardizing mechanisms
> that rely on a hard /64 boundary between the = prefix and IID.
> For example, what is the minimum number of IID = bits I must
> have to use privacy addresses?
>
If IIDs other than 64 bits are available, = consideration should be given to encoding the length of the IID in the = address prefix.  This allows various sanity checks to be done and = potentially reduces the amount of knowledge needed for = autoconfig.  Routers could check that prefixes advertised were not = longer than the maximum implied by the IID length, and stateless = autoconfig could verify that the prefix was of the right kind to match = with a particular IID, and (with a little additional work) routers = could identify what sort of prefixes were needed.

Assuming backwards compatibility is needed, prefixes = starting 001 binary would be assumed to be 64 bit prefixes as at = present.  It would probably be appropriate to release another = portion of the reserved address space for the explicitly encoded IID = length prefixes.

>
> The addressing architecture also imparts = special meaning to two
> bits in the middle of the IID.  Bits 70 = and 71 of an IPv6 address
> are called the 'u' bit and the 'g' bit, and = their semantics are
> based on the meanings of the corresponding bits = in EUI-64
> identifiers (with the sense of the 'u' bit = reversed).  The
> 'u' bit is supposed to indicate whether the IID = is a globally
> unique EUI-64-based identifier (1=3Dyes, = 0=3Dno), and the 'g' bit
> is reserved (must be 0).  When longer = prefixes are used, though,
> these bits end-up in the prefix, instead of in = the IID.
>
> Can we really expect operators to reserve these = two bits for
> this use?  Or will they allocate their = longer prefixes without
> worrying about the meaning of these two = bits?
>
> If we think that, in practice, operators will = ignore the meaning
> of these two bits, does the 'u' bit really have = any meaning at all?
>
If the subset of address prefixes that go with 64 = bit EUI-64 IIDs are identifiable, then we can continue with the special = interpretation of the g and u bits.  Operators can allocate their = longer prefixes out of a different set that is allowed to have /127 = prefixes.

> Do I have any answers to all of the questions I = keep asking? :-)
> Well, maybe...
>
> In my opinion, we should not standardize a hard = boundary between
> the prefix and the IID, especially if we know = it will be ignored
> by operators.

As long as we know where the boundary is.

>
> We can make it clear that a 64-bit boundary is = required in order
> to use EUI-64-based addresses for address = autoconfiguration.  And,
> it might make sense to document a maximum = prefix length that is
> consistent with privacy addresses.
>
> I also think that we should drop the 'u' and = 'g' bit semantics
> from the addressing architecture.  It is = pretty clear, at this
> point, that we won't ever be certain that an = address with the
> 'u'-bit set has a globally unique IID, so there = really isn't
> any reason to clutter up the addressing = architecture with these
> strange bits.

Once it is known what the length of the IID is, we = can keep the semantics of the u and g bits if we want but it becomes = much less of an issue if it is no longer the only way and also there = should be no chance of confusion (if the prefix starts 001 binary, = prefixes longer than /64 should be discarded and never used to form = addresses).  The semantics of the EUI-64 could be separated out = and put in a separate draft to emphasise this.

>
> What do the rest of you think?
>

My twopennorth'

Elwyn Davies

> Margaret
>
>
>
>
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C23C84.8686C8C8-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 06:36:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75DaK3U005186; Mon, 5 Aug 2002 06:36:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75DaKB0005185; Mon, 5 Aug 2002 06:36:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75DaE3U005178 for ; Mon, 5 Aug 2002 06:36:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14595 for ; Mon, 5 Aug 2002 06:36:19 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28818 for ; Mon, 5 Aug 2002 07:36:13 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g75DZUG01149; Mon, 5 Aug 2002 20:35:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g75DYuH15633; Mon, 5 Aug 2002 20:34:56 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Bill Manning cc: mrw@windriver.com (Margaret Wasserman), ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208050325.g753PLW03257@boreas.isi.edu> References: <200208050325.g753PLW03257@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Aug 2002 20:34:56 +0700 Message-ID: <15631.1028554496@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 4 Aug 2002 20:25:21 -0700 (PDT) From: Bill Manning Message-ID: <200208050325.g753PLW03257@boreas.isi.edu> I agree with everything you say except this ... | EUI-64 based numbers really have no place in IPv6 | addresses, except as a local optimization. Use of | EUI-64 addresses introduces privacy concerns that | require the invention of grevious hacks to address | mgmt. There are two different privacy concerns - one is that people can tell which brand of LAN cards I am using (or the manufacturer of some other equipment). For the vast majority of people, "big deal". There may be a few organisations that actually care about this, but they can simply assign addresses 1 2 3 4 ... if they want to, and completely avoid that concern. The other is "user tracing" and what matters there is whether there is a unique addr that comes at least fairly close to identifying a user. For this it doesn't matter in the slightest if the address is based upon an EUI or not, all that matters is that it is stable. People have been used to hiding behind NATs which conceal their real addresses, and make them be just "one of many" using anything from the same addr block. Now global addresses are becoming available again, this concern is becoming more prevalent (it never used to bother anyone, as in the early days there was essentially no-one on the net who would collect this kind of info and misuse it - besides the fact that most systems (and addresses) were home for large numbers of individuals anyway). The "grevious hacks" are only needed to cope with the 2nd of those, the first has a much more trivial solution. And the 2nd is completely unrelated to the use of EUI's. So, I don't think it is correct to blame privacy problems in any way on the use of EUI's for autoconfig. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 06:37:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75Dbs3U005221; Mon, 5 Aug 2002 06:37:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75DbsnT005220; Mon, 5 Aug 2002 06:37:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75Dbl3U005210 for ; Mon, 5 Aug 2002 06:37:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16537 for ; Mon, 5 Aug 2002 06:37:51 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29081 for ; Mon, 5 Aug 2002 07:36:57 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g75DZSG01133; Mon, 5 Aug 2002 20:35:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g75DYhH15625; Mon, 5 Aug 2002 20:34:54 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020804200432.024dadc0@mail.windriver.com> References: <4.2.2.20020804200432.024dadc0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Aug 2002 20:34:43 +0700 Message-ID: <15623.1028554483@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 04 Aug 2002 20:40:32 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020804200432.024dadc0@mail.windriver.com> | What does this mean for us? Well, in my opinion, we don't want | to standardize a restriction that we _know_ will be ignored by | the folks who are deploying the software. I agree. This is a point I have been trying to make for ages. But there is more than that, even if we didn't know that it was going to be ignored (is being ignored), we'd want to be asking ourselves why we'd want to be standardising something for which we have no use at all. | We want/need to use EUI-64-based addresses for address | autoconfiguration. But, is this inherently incompatible with | the folks using longer prefixes on point-to-point links? No, not in the least, we do it every day. | Why do all IIDs need to be in modified EUI-64 format? They don't. And if we look back at the earliest addressing discussions there was always the assumption that they wouldn't (all) be. It was only when 8+8 started being considered that this suddenly started seeming important to people - 8+8 has been long abandoned as a possibility, but this remnant of it is hanging on. Perhaps there are some people out there hoping that it can be reincarnated? It cannot - that's the kind of thing that would have to be introduced at the start of deployment, as it depends upon addressing assignments, it would be too late now, even if it had been possible, once. | Do we want to remove this restriction from the addressing architecture? Yes. | Or can we show good reasons why it shouldn't be ignored? I certainly can't - and I have been asking why anyone cares about this for ages now. The only answer I have ever received is "because the addressing architecture says so", which is just crazy. It is the same whenever someone asks about using a prefix longer than 64 on p2p links - several people tend to say "you can't do that because the addressing architecture says you can't, it is illegal" - but never with any sign of anything that will fail to work because of this. Simply "it is illegal therefore you cannot" - which some people believe, and others simply ignore, and find that they have no problems at all. | We also may want to be cautious about standardizing mechanisms | that rely on a hard /64 boundary between the prefix and IID. It depends upon where we're looking from. Autoconfig (which relies upon this) is just fine, because it is a local choice - sites can choose to use 64 bit IIDs in which case autoconfig works, or they can choose to use smaller ones, and give up the possibility of autoconfig. Anything else similar would also be just fine (including 3041). But we don't want to be doing anything that assumes that anyone outside the site is able to make assumptions about the way the site is using the address space. | Can we really expect operators to reserve these two bits for this use? no. | Or will they allocate their longer prefixes without | worrying about the meaning of these two bits? Yes. It is already done. | If we think that, in practice, operators will ignore the meaning | of these two bits, does the 'u' bit really have any meaning at all? Yes, in the context of nets with mixed autoconfig & statically assigned addresses, it is just fine. It allows addresses to be assigned with the knowledge that autoconfig isn't going to break on some node (essentially the 64 bit address space is divided into half reserved for autoconfig, and half for other forms of config). But it isn't something that should be observed from outside. | I also think that we should drop the 'u' and 'g' bit semantics | from the addressing architecture. Does 'g' actually have semantics, I didn't think we had gone that far... | It is pretty clear, at this | point, that we won't ever be certain that an address with the | 'u'-bit set has a globally unique IID, That's true regardless of anything else we do here - that is, even if we could assume that 'u' being set means that an address has been built out of an EUI-64 built from its MAC addr. One obvious case is where a node wants to retain its address, after the MAC addr from which it was built has been removed. Eg: a pretty common case, you have a major server, it has the current state of the art in net connectivity plugged into it, and it assigns itself its IPv6 addr. Then the state of the art advances (100Mbit ethernet becomes a household commodity, and servers all start using GBit instead). So, the 100Mbit card is yanked, and a GBit card is inserted. The node now gets statically configured with its previous address, as it is quite widely known, and there's no need to change it. The 'u' bit has to remain set for this to work of course. That's all fine - but now I have this spare 100Mbit card lying around, and 100Mbit now being a household commodity, and not really adequate anywhere else, I take it home, and plug it into one of my systems there, where the 10Mbit that used to be adequate is now just wet string... The system there isn't well known anywhere, so it doesn't need to keep its old address, and just uses autoconf based upon the mac addr of the card that has just been plugged in. Now, we have two nodes with exactly the same IID. IPv6 has no problem with this (the two nodes live on completely different nets, with completely different prefixes). Nor does TCP, UDP, or anything else. Some people here would say that the rules were broken when a card that's mac addr was still in use as an IID was allowed to be used elsewhere - but you can be sure that if I can get a free working card, I'm not going to let that kind of nicety bother me much (nor is just about anyone else). What I might be able to do of course, and what lots of people with old suns do all the time, is reprogram the MAC addr to something different (old suns are starting to need this, as their batteries are dying, and the nvram that stored their mac addresses is all losing its memory). When I do this, there's no way I cm going to go to IEEE and get myself an OID to make my own unique EUI's - for one card? No, I am just going to invent something that looks good to me. As long as it is unique on my LAN, it will work. But now we have the IPv6 stack, looking at the programmed (unique appearing) MAC addr on the card (or in the sun's nvram) and about to autoconfigure itself an address. How is it supposed to determine that the MAC addr it is seeing isn't one that was programmed by the manufacturer, but is instead one that I just decided it should have? Is there any implementation around that isn't going to set the 'u' bit in such a case - even though the address very likely isn't globally unique? We simply need to end the pretence. | so there really isn't | any reason to clutter up the addressing architecture with these | strange bits. I'm not sure about the architecture, but the use of 'u' for autoconfig needs to be somewhere, that's just fine as it is now. The rest of all of this should simply be deleted from everywhere (the hard part is to get people to stop thinking about the IID as being unique, which they persist in doing, regardless of how much evidence that it isn't is thrown their way). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 06:59:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75Dwx3U005326; Mon, 5 Aug 2002 06:58:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75DwxBL005325; Mon, 5 Aug 2002 06:58:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75Dwq3U005318 for ; Mon, 5 Aug 2002 06:58:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19029 for ; Mon, 5 Aug 2002 06:58:55 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03324 for ; Mon, 5 Aug 2002 07:58:55 -0600 (MDT) Received: from kenawang ([147.11.233.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA07785; Mon, 5 Aug 2002 06:58:22 -0700 (PDT) Message-Id: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 05 Aug 2002 09:59:13 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <15623.1028554483@munnari.OZ.AU> References: <4.2.2.20020804200432.024dadc0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'm not sure about the architecture, but the use of 'u' for autoconfig >needs to be somewhere, that's just fine as it is now. When you say that we need the 'u'-bit for autoconfig, do you just mean that we should continue to reverse this bit in the EUI-64 identifier before we use it, to remain consistent with current practice? Or are you saying that the semantics of the 'u'-bit (that it indicates an IID is globally unique) has some importance for autoconfig? >The rest of all of this should simply be deleted from everywhere (the hard >part is to get people to stop thinking about the IID as being unique, which >they persist in doing, regardless of how much evidence that it isn't is >thrown their way). In the Yokohama meeting, Steve Deering lead a discussion on the uniqueness of IIDs, and there was a pretty big majority of people in the room who thought that we shouldn't even require IIDs to be unique on a link. Addresses need to be unique (obviously), but not necessarily the IIDs from which they are created. The discussion will be documented in the minutes, and we'll offer a chance for people on the list to comment before we make any final decision, of course. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 11:36:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75IaD3U006066; Mon, 5 Aug 2002 11:36:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75IaDgN006065; Mon, 5 Aug 2002 11:36:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75Ia83U006058 for ; Mon, 5 Aug 2002 11:36:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19565 for ; Mon, 5 Aug 2002 11:36:12 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24221 for ; Mon, 5 Aug 2002 11:36:12 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g75IWZI12533; Mon, 5 Aug 2002 11:32:35 -0700 (PDT) From: Bill Manning Message-Id: <200208051832.g75IWZI12533@boreas.isi.edu> Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <15631.1028554496@munnari.OZ.AU> from Robert Elz at "Aug 5, 2 08:34:56 pm" To: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 5 Aug 2002 11:32:34 -0700 (PDT) Cc: bmanning@ISI.EDU, mrw@windriver.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % Date: Sun, 4 Aug 2002 20:25:21 -0700 (PDT) % From: Bill Manning % Message-ID: <200208050325.g753PLW03257@boreas.isi.edu> % % % I agree with everything you say except this ... % % | EUI-64 based numbers really have no place in IPv6 % | addresses, except as a local optimization. Use of % | EUI-64 addresses introduces privacy concerns that % | require the invention of grevious hacks to address % | mgmt. % % There are two different privacy concerns - one is that people can tell % which brand of LAN cards I am using (or the manufacturer of some other % equipment). For the vast majority of people, "big deal". There may % be a few organisations that actually care about this, but they can simply % assign addresses 1 2 3 4 ... if they want to, and completely avoid that % concern. Yes. % The other is "user tracing" and what matters there is whether there is % a unique addr that comes at least fairly close to identifying a user. % For this it doesn't matter in the slightest if the address is based upon % an EUI or not, all that matters is that it is stable. People have been % used to hiding behind NATs which conceal their real addresses, and make % them be just "one of many" using anything from the same addr block. % Now global addresses are becoming available again, this concern is % becoming more prevalent (it never used to bother anyone, as in the % early days there was essentially no-one on the net who would collect this % kind of info and misuse it - besides the fact that most systems (and % addresses) were home for large numbers of individuals anyway). % % The "grevious hacks" are only needed to cope with the 2nd of those, the % first has a much more trivial solution. And the 2nd is completely unrelated % to the use of EUI's. So, I don't think it is correct to blame privacy % problems in any way on the use of EUI's for autoconfig. Well... there was a whole privacy issue raised and to such a degree that the IAB felt compelled to make a public statement about it. And there is the goofy DNS abomination that attempts to randomize the lower 64 bits on a regular basis... to provide anonymity. In any case, the whole issue "goes away" if/when we rethink placing node identity information in a topological address. To the extent that EUI-64 numbers represent node identity and not topological information, it is, IMHO, a bad thing and should be excised from an addressing architecture, except as a foot-note for some special case events. % % kre % % % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 12:40:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75JeB3U006327; Mon, 5 Aug 2002 12:40:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75JeAiB006326; Mon, 5 Aug 2002 12:40:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75Je53U006319 for ; Mon, 5 Aug 2002 12:40:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17896 for ; Mon, 5 Aug 2002 12:40:10 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24788 for ; Mon, 5 Aug 2002 13:40:09 -0600 (MDT) Received: from kenawang ([147.11.233.32]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA16172; Mon, 5 Aug 2002 12:39:55 -0700 (PDT) Message-Id: <4.2.2.20020805150737.024bd810@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 05 Aug 2002 15:40:27 -0400 To: "Elwyn Davies" From: Margaret Wasserman Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4103264BC8D3D51180B7002048400C456345C3@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, first let me publicly apologize for bringing up these issues with the Addressing Architecture document after it has officially been through last call (multiple times). Also, I'd like to state that I'm not speaking on behalf of the WG co-chairs or anything. So, you can just feel free to ignore my late, and possibly misguided, thoughts on this subject... My co-chairs definitely don't agree with me, and I'm willing to admit that they know a lot more about this subject than I do. In re-reading the addressing architecture, I'm actually not sure whether or not there is a problem here. It does state what I mentioned earlier: "For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." But, it also states: "IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length similar to IPv4 addresses under Classless Interdomain Routing." Is this sufficient to allow autoconfig and privacy to require /64 addresses on end-node networks, and to allow operators to manually configure longer prefixes for their point-to-point links? I'm mainly concerned that the current wording will lead to one of two things: - People building equipment that doesn't understand prefixes longer than /64 -- if so, what happens when this equipment is placed on a manually configured network with a longer prefix? - Other IPv6 standards relying on a hard /64 boundary, and not functioning properly on networks with longer prefixes. Does anyone else think that these are real concerns? Or, do you think that people who ignore the IPv6 architecture in configuring their networks just get what they deserve? Can anyone explain _why_ operators want to configure longer prefixes when there are so very many /64 prefixes available? Is this just because that's how it's always been done? Or are there actual technical reasons to prefer a much smaller address space on a point-to-point link? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 13:36:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75Ka43U006660; Mon, 5 Aug 2002 13:36:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75Ka4ib006659; Mon, 5 Aug 2002 13:36:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75KZw3U006652 for ; Mon, 5 Aug 2002 13:35:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23471 for ; Mon, 5 Aug 2002 13:36:04 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28125 for ; Mon, 5 Aug 2002 13:36:03 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g75KZJjI119756; Mon, 5 Aug 2002 16:35:26 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g75KZGFA028016; Mon, 5 Aug 2002 16:35:17 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g75K6kB28220; Mon, 5 Aug 2002 16:06:46 -0400 Message-Id: <200208052006.g75K6kB28220@rotala.raleigh.ibm.com> To: Margaret Wasserman cc: "Elwyn Davies" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: Message from "Mon, 05 Aug 2002 15:40:27 EDT." <4.2.2.20020805150737.024bd810@mail.windriver.com> Date: Mon, 05 Aug 2002 16:06:45 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret. > Well, first let me publicly apologize for bringing up these issues > with the Addressing Architecture document after it has officially been > through last call (multiple times). Note: In the IETF, valid technical issues can be brought up until the IESG has approved the document. There is no notion that once a LC has happened, valid issues cannot be raised. That doesn't mean one should wait until after LC to raise issues, of course. But the idea that one should not raise issues because it's technically procedurally too late, I find at odds with the IETF tradition of doing the technical Right Thing. Of course, the later an issue is raised, the harder it generally is to sway the WG. So the arguments need to be strong. > Also, I'd like to state that I'm not speaking on behalf of the WG > co-chairs or anything. Good to be clear on this in general! > "For all unicast addresses, except those that start with binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format." > But, it also states: > "IPv6 unicast addresses are aggregatable with prefixes of arbitrary > bit-length similar to IPv4 addresses under Classless Interdomain Routing." > Is this sufficient to allow autoconfig and privacy to require /64 > addresses on end-node networks, and to allow operators to manually > configure longer prefixes for their point-to-point links? > I'm mainly concerned that the current wording will lead to one of two > things: > - People building equipment that doesn't understand prefixes > longer than /64 -- if so, what happens when this > equipment is placed on a manually configured network > with a longer prefix? They better not be doing this. We have been over this territory a number of times already, with some folks arguing only a misreading of the spec would allow one to conclude that prefixes cannot be longer than /64, (or that an implementation might hardwire things about format prefix 001 being the only legal one), etc. But other folks were still worried that people might still make poor implementation choices, so words have been changed a number of times to make this more clear just to be sure. The current document is a lot better in this regard than its predecessor, IMO. If anyone thinks this is still an issue, it would be good to point out the specific text that is believed to be unclear and suggest replacement wording. > - Other IPv6 standards relying on a hard /64 boundary, and not > functioning properly on networks with longer prefixes. AFAIK, no specs make this assumption. We consciously decided NOT to change ND/addrconf, for example, to say prefixes needed to be /64s. Other prefix lengths are still supported. However, it is true that there are some places where /64 is in fact not changable in practice (without very significant upheaval in well-established documents). You cannot do stateless addrconf on an Ethernet (or FDDI, or any other typical LAN) with a prefix other than /64. I view this as a reasonable engineering compromise between an number of tradeoffs (but won't attempt to list them here). Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 5 23:11:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g766BN3U007749; Mon, 5 Aug 2002 23:11:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g766BNSH007748; Mon, 5 Aug 2002 23:11:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g766BH3U007741 for ; Mon, 5 Aug 2002 23:11:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25261 for ; Mon, 5 Aug 2002 23:11:23 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17687 for ; Tue, 6 Aug 2002 00:11:22 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g766B4502965; Tue, 6 Aug 2002 09:11:05 +0300 Date: Tue, 6 Aug 2002 09:11:04 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: Elwyn Davies , Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020805150737.024bd810@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 5 Aug 2002, Margaret Wasserman wrote: [...] > - Other IPv6 standards relying on a hard /64 boundary, and not > functioning properly on networks with longer prefixes. > > Does anyone else think that these are real concerns? This would become one. If you know an address, and be able to "guess" the prefix length (ie: assume /64), this opens quite a few possibilities for all kinds of specifications. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 6 02:58:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769wB3U010166; Tue, 6 Aug 2002 02:58:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g769wBnT010165; Tue, 6 Aug 2002 02:58:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769w53U010155 for ; Tue, 6 Aug 2002 02:58:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04379 for ; Tue, 6 Aug 2002 02:58:13 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27059 for ; Tue, 6 Aug 2002 03:58:06 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g769uuG14988; Tue, 6 Aug 2002 16:56:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g769tAH25736; Tue, 6 Aug 2002 16:55:13 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> References: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 2002 16:55:10 +0700 Message-ID: <25734.1028627710@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 05 Aug 2002 09:59:13 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> | >I'm not sure about the architecture, but the use of 'u' for autoconfig | >needs to be somewhere, that's just fine as it is now. | | When you say that we need the 'u'-bit for autoconfig, do you just mean | that we should continue to reverse this bit in the EUI-64 identifier | before we use it, to remain consistent with current practice? No, not just that, though that should remain of course. | Or are you saying that the semantics of the 'u'-bit (that it indicates | an IID is globally unique) has some importance for autoconfig? Not for autoconfig itself, but for manual config. Or perhaps for manual config to be able to cooperate with autoconfig. It is nice to be able to manually config some nodes on a link, and autoconfig others, and not need to worry whether the manually assigned address just might possibly conflict with some node's (perhaps node yet to be acquired) ability to autoconfig its natural address. Dividing the available space into two pieces, one for autoconf to use, and one for the various other assignment types (manual config, dhcp, etc) avoids this, so this use of the 'u' bit should be retained. When we encounter some new media type, for which we don't yet have an "IPv6 over foo" spec, we could pick a different bit to serve this purpose though, if we wanted to make it quite clear that nodes off the link simply cannot attempt to interpret this bit (which they should not be doing). Side note: this looks as if autoconfig is being given a special status not available to the other config methods, in that it has a reserved part of the iid space, and all the rest get to share what is left over. But that's not the case. What matters here is where the address assignments are done. For autoconfig, that's in every node, using manufacturer code alone, following the procedures of the rfc (and usually nothing else). All other assignments follow some site addressing plan, if some site wants to use the 'g' bit (or any other bit) to distinguish between dhcp assigned addresses and manually configured addresses, they can do that - all that's needed is for their dhcp server to co-operate. Nothing is required that touches more than the internal config of that site, so there is nothing we need to standardise here. | In the Yokohama meeting, Steve Deering lead a discussion on the | uniqueness of IIDs, and there was a pretty big majority of people | in the room who thought that we shouldn't even require IIDs to | be unique on a link. Addresses need to be unique (obviously), but | not necessarily the IIDs from which they are created. The discussion | will be documented in the minutes, and we'll offer a chance for people | on the list to comment before we make any final decision, of course. I know that was directed at the rest of the list (I was there, and absolutely agree with this decision). It has been discussed a bit on the list since the WG meeting (it is the one topic from the meeting which really has). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 6 03:06:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76A6C3U010220; Tue, 6 Aug 2002 03:06:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76A6CQ9010219; Tue, 6 Aug 2002 03:06:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76A663U010212 for ; Tue, 6 Aug 2002 03:06:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00131 for ; Tue, 6 Aug 2002 03:06:12 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18216 for ; Tue, 6 Aug 2002 03:05:59 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g769xgG16920; Tue, 6 Aug 2002 16:59:42 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g769x9H25747; Tue, 6 Aug 2002 16:59:09 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Bill Manning cc: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208051832.g75IWZI12533@boreas.isi.edu> References: <200208051832.g75IWZI12533@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 2002 16:59:09 +0700 Message-ID: <25745.1028627949@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 5 Aug 2002 11:32:34 -0700 (PDT) From: Bill Manning Message-ID: <200208051832.g75IWZI12533@boreas.isi.edu> | In any case, the whole issue "goes away" if/when we rethink | placing node identity information in a topological address. | To the extent that EUI-64 numbers represent node identity | and not topological information, it is, IMHO, a bad thing | and should be excised from an addressing architecture, except | as a foot-note for some special case events. No, this is wrong. The privacy concern comes with having anything stable in the address which identifies the user - including the whole address. EUI-64's in there are just one way of achieving that (which would perhaps be a little more stable than 128 bit addresses, given that renumbering is supposed to happen - or perhaps not, as we're already seeing people who have decided that renumbering is simply impossible for them, and will never happen, no matter what...) The numbers 1 2 3 represent node identity in exactly the same way as EUI-64's do, putting the EUI there instead of '1' changes just about nothing at all wrt this concern. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 6 03:29:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76AT73U010331; Tue, 6 Aug 2002 03:29:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76AT7r4010330; Tue, 6 Aug 2002 03:29:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76ASv3U010323 for ; Tue, 6 Aug 2002 03:28:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09032 for ; Tue, 6 Aug 2002 03:29:02 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14359 for ; Tue, 6 Aug 2002 04:28:48 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g76AS1G08798; Tue, 6 Aug 2002 17:28:02 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g76AROH25829; Tue, 6 Aug 2002 17:27:24 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Thomas Narten cc: Margaret Wasserman , "Elwyn Davies" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208052006.g75K6kB28220@rotala.raleigh.ibm.com> References: <200208052006.g75K6kB28220@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 2002 17:27:24 +0700 Message-ID: <25827.1028629644@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 05 Aug 2002 16:06:45 -0400 From: Thomas Narten Message-ID: <200208052006.g75K6kB28220@rotala.raleigh.ibm.com> | They better not be doing this. We have been over this territory a | number of times already, with some folks arguing only a misreading of | the spec would allow one to conclude that prefixes cannot be longer | than /64, There's no need to argue this (any more anyway), there are any number of messages on this (I think) and certainly other (like the 6bone) lists which state that as an absolute incontrovertible fact (no prefix length longer than 64 is allowed) - and quote the addr arch doc (and the latest draft) as justification. We really need to fix that - and also get rid of the other odds and ends in that draft thats imply make no sense when prefixes longer than 64 are being used. | If anyone thinks this is still an issue, it would be good to point out | the specific text that is believed to be unclear and suggest | replacement wording. OK (though I'm not sure "unclear" is the right description)... All this relates to draft-ietf-ipngwg-addr-arch-v3-08.txt naturally (the version dated June 29, 2002, so I believe it is the most current). The para (near the end of page 8): For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. should simply be deleted. No replacement required. Then the last line on page 8, and continuing into page 9: Modified EUI-64 format based Interface identifiers may have global scope when derived from a global token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.) or where global tokens are undesirable (e.g., temporary tokens for privacy [PRIV]). should also be deleted. No replacement is required. Then, next paragraph Modified EUI-64 format interface identifiers are formed by inverting the "u" bit (universal/local bit in IEEE EUI-64 terminology) when forming the interface identifier from IEEE EUI-64 identifiers. In the resulting Modified EUI-64 format the "u" bit is set to one (1) to indicate global scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an IEEE EUI-64 identifier are as follows: Delete the 2nd sentence, no replacement required. That leaves... Modified EUI-64 format interface identifiers are formed by inverting the "u" bit (universal/local bit in IEEE EUI-64 terminology) when forming the interface identifier from IEEE EUI-64 identifiers. The first three octets in binary of an IEEE EUI-64 identifier are as follows: Then, lower down on page 9, the paragraph The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with global scope. should simply be deleted. No replacement is required. This is perhaps the worst of everything in the draft, no matter what happens to the rest, that paragraph simply has to be deleted. This is the "we have no idea what we're going to do with this, but we are going to define it anyway" (and while doing so, ignore the fact that lots of people are ignoring us) approach. Next, at the end of page 10 (sect 2.5.4) spanning onto page 11 ... All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field. should simply be deleted. No replacement is required. The paragraph following that one would then look rather out of context (though nothing it contains is objectionable), so I would delete that one as well, it isn't required for anything. The rest of the draft is all very careful to express things in terms of variables (n m etc) and is all fine. | However, it is true that there are some places where /64 is in fact | not changable in practice (without very significant upheaval in | well-established documents). You cannot do stateless addrconf on an | Ethernet (or FDDI, or any other typical LAN) with a prefix other than | /64. I view this as a reasonable engineering compromise between an | number of tradeoffs (but won't attempt to list them here). Absolutely. That's just fine, and I don't think anyone is suggesting changing that. If you know that the link is an ethernet (etc), then you are going to have a pretty good idea that the prefix length is 64. But if you have no idea what kind of link an address happens to be connected to (so you are clearly neither the node owning the address, nor connected to the same prefix, nor the local network manager) then why should you care? Eg: munnari.oz.au's IPv6 addr (the advertised one anyway) is 2001:388:c02:4000::1:21 Do you want to guess what kind of link that is connected to, and what its prefix length happens to be ??? Is there any rational reason at all that you're ever going to care? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 6 13:07:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76K7C3U012169; Tue, 6 Aug 2002 13:07:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76K7CUZ012168; Tue, 6 Aug 2002 13:07:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76K773U012161 for ; Tue, 6 Aug 2002 13:07:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25583 for ; Tue, 6 Aug 2002 13:07:15 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20638 for ; Tue, 6 Aug 2002 13:07:14 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g76K74e8161828; Tue, 6 Aug 2002 16:07:06 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g76K72Fa096034; Tue, 6 Aug 2002 16:07:02 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g76K5Yp03177; Tue, 6 Aug 2002 16:05:34 -0400 Message-Id: <200208062005.g76K5Yp03177@rotala.raleigh.ibm.com> To: jinmei@isl.rdc.toshiba.co.jp cc: ipng@sunroof.eng.sun.com Subject: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt Date: Tue, 06 Aug 2002 16:05:34 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is my long overdue review of this document. Note that since this is document is intended to be published as Informational, no IETF Last Call will be done, and once the remaining issues are resolved the document can be brought before IESG as a whole. Most of these comments are nits. The one more significant issue is that it would be good to clarify how this document relates to the on-going Austin Group work (which has standardized the Basic API). The references to Posix may be dated. The related text in draft-ietf-ipngwg-rfc2553bis-06.txt might be helpful. Also, some changes to the Basic API were made recently to align it with the Austin Group work. Some of those same changes may need to be made to this document as well. Detailed comments. Abstract: > A separate specification [RFC-2553] contain changes to the sockets take out the references; saying "rfc 2553" without making it a reference is OK. See the RFC editors guidelines on abstracts for more details (draft-rfc-editor-rfc2223bis-02.txt). Note: the abstract itself could really be rewritten to be more clear/concise. Early in the introduction, the document should say it is updating/replacing the RFC 2292. General: it would be good to have a proper reference to the posix standards in the references section. I.e.: > 4.3BSD Reno sockets API in 1990. The reason is that these ancillary > data fields are part of the Posix.1g standard and should therefore be > adopted by most vendors. Also, how does this align with the Austin group work and the revised basic API? Are the documents in sync with each other? I say this because the Basic API is apparently in alignment with the Austin Group work. It would probably be useful to have some text saying how this document relates to that standard. Also, take a look at the most recent changes to the basic API. Do any spill over into this document? One change to the basic API that seems relevant to this one: > . More alignments with [3]: > - [3] does not contain protocol family definitions (PF_xxx). > Replaced PF_INET6 with AF_INET6, or removed as appropriate. This document still refernces PF_INET, etc. I note that there are some new ICMP types that have been assigned that this document doesn't seem to reference (e.g., those greater than 138). Should they be added? > are taken from http://www.iana.org/assignments/protocol-numbers. this URL should be restricted to http://www.iana.org/numbers.html (the URL in the document is not stable over long periods of time) > All data sent via raw sockets MUST be in network byte order and all s/MUST/must/? (this document doesn't really use MUST/MAY/SHOULD language). Either downcase this usage here, or include a definition (e.g., a reference to the 2119 definitions). > In order to clear an installed filter the application can issue a > setsockopt for ICMP6_FILTER with a zero length. When no such filter > has been installed corresponding getsockopt() will return the kernel > default filter. last part doesn't parse quite right. s/installed corresponding/installed, / ?? > We note that many of the functions and socket options defined in this > document may have error returns that are not defined in this > document. Many of these possible error returns will be recognized > only as implementations proceed. This might have been true the first time this document was produced. Is it still true today? > 4.3BSD Reno sockets API in 1990. The reason is that these ancillary > data fields are part of the Posix.1g standard and should therefore be > adopted by most vendors. why are there appendices? seems like at least some of these are part of the spec itself. Putting them in the appendices would imply that they perhaps aren't important. Re: references to RFC 2553; should they point to the revised ID instead? (since it is about ready to become an RFC) note: "int " is used throughout. Is this a short/long int? Does this need to be clarified, or is the current usage adequate? > inet6_opt_set_val() - add one component of the option content to the option > > Three functions deal with a returned options header: > > inet6_opt_next() - extract the next option from the options header > inet6_opt_find() - extract an option of a specified type from the header > inet6_opt_get_val() - retrieve one component of the option content some of the lines go beyond column 80(?). Rfc editor won't allow that. Can you reformat to keep lines within acceptable length? (Check the RFC editor formatting rules for details.) > 5. Extensions to Socket Ancillary Data > > This specification uses ancillary data as defined in Posix.1g with > the following compatible extensions: should this ID also include text relative to the austin group work? > - A new CMSG_SPACE macro is defined. It is used to determine how much > space need to be allocated for an ancillary data item. See Section s/need/needs/ > operation. Returning the received hop limit is useful for programs > such as Traceroute and for IPv6 applications that need to verify that > the received hop limit is 255 (e.g., that the packet has not been > forwarded). how does this help traceroute? Traceroute needs to set, not receive the ttl. > To specify the outgoing traffic class value, just specify the control > information as ancillary data for sendmsg() or using setsockopt(). > Just like the hop limit value, the interpretation of the integer > traffic class value is > > x < -1: return an error of EINVAL > x == -1: use kernel default > 0 <= x <= 255: use x > x >= 256: return an error of EINVAL note that the terminology surrounding diffserv/traffic class has changed (see RFC 3260). Is the current API still OK? there are only 64 diffserv values now. (I think this is OK, but the authors should recheck). > ENXIO The interface specified by ipi6_ifindex does not exist > > ENETDOWN The interface specified by ipi6_ifindex is not enabled for > IPv6 use. > Indention not right. (too far to left) > This document and [RFC-2553] specify various methods that affect the > selection of the packet's outgoing interface. This subsection > summarizes the ordering among those in order to ensure determined > behavior. s/determined/deterministic/? > every multicast packet on the corresponding socket. The reason for > the ordering comes from expectation that the source address is > specified as well and that the pair of the address and the outgoing > interface should be desired. s/desired/preferred/? Source routing with IPv4 sockets API (the IP_OPTIONS socket option) s/with/with the/ ? > int inet6_opt_init(void *extbuf, size_t extlen); > > This function returns the number of bytes needed for the empty > extension header i.e. without any options. I don't understand this sentence. Does this then always return the same value? And doesn't an "empty" header require 0 bytes? Or is this actually "length remaining"? Actully, the "length" field is weird in subsequent usages to. Is it really a length, or an offset into the options? Calling it length is confusing. Is it too late to change this? > - The new inet6_opt_XXX() functions were made different that the old s/that/than/ Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 6 14:00:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76L013U012275; Tue, 6 Aug 2002 14:00:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76L01Tb012274; Tue, 6 Aug 2002 14:00:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76Kxr3U012267 for ; Tue, 6 Aug 2002 13:59:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03555 for ; Tue, 6 Aug 2002 13:59:57 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14988 for ; Tue, 6 Aug 2002 14:59:52 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 6 Aug 2002 13:59:47 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 6 Aug 2002 13:59:46 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Aug 2002 14:00:01 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 6 Aug 2002 13:59:45 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 6 Aug 2002 13:59:48 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 6 Aug 2002 13:59:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Tue, 6 Aug 2002 14:00:22 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073841AC@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt thread-index: AcI9EHtMmXge5UPoTOyMB6w4WgW8XQAewQHw From: "Dave Thaler" To: "Pekka Savola" , "Margaret Wasserman" Cc: "Elwyn Davies" , , X-OriginalArrivalTime: 06 Aug 2002 20:59:11.0091 (UTC) FILETIME=[1CFDDC30:01C23D8C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g76Kxu3U012268 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] [...] > If you know an address, and be able to "guess" the prefix length (ie: > assume /64), this opens quite a few possibilities for all kinds of > specifications. For example, the reserved subnet anycast addresses (such as the subnet router anycast address) become much more useful. For example, instead of having to use a RouterAlert option, you could make an IPv6 multicast traceroute (see http://www.dante.net/mbone/refs/draft-ietf-idmr-traceroute-ipm-07.txt for the IPv4 spec) that uses the subnet router anycast address, and not burden other routers with HbH processing. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 01:27:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g778Rw3U014073; Wed, 7 Aug 2002 01:27:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g778Rv8I014072; Wed, 7 Aug 2002 01:27:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g778Rp3U014064 for ; Wed, 7 Aug 2002 01:27:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02031 for ; Wed, 7 Aug 2002 01:28:00 -0700 (PDT) Received: from atnsmtp91.24on.cc (ATNSMTP91.24on.cc [213.225.2.184]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16251 for ; Wed, 7 Aug 2002 02:27:58 -0600 (MDT) Received: from mail pickup service by atnsmtp91.24on.cc with Microsoft SMTPSVC; Wed, 7 Aug 2002 10:29:54 +0200 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by atnsmtp91.24on.cc with Microsoft SMTPSVC(5.5.1877.447.44); Tue, 6 Aug 2002 12:09:03 +0200 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14815; Tue, 6 Aug 2002 03:05:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28773; Tue, 6 Aug 2002 02:59:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769wB3U010166; Tue, 6 Aug 2002 02:58:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g769wBnT010165; Tue, 6 Aug 2002 02:58:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769w53U010155 for ; Tue, 6 Aug 2002 02:58:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04379 for ; Tue, 6 Aug 2002 02:58:13 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27059 for ; Tue, 6 Aug 2002 03:58:06 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g769uuG14988; Tue, 6 Aug 2002 16:56:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g769tAH25736; Tue, 6 Aug 2002 16:55:13 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> References: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 2002 16:55:10 +0700 Message-ID: <25734.1028627710@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 05 Aug 2002 09:59:13 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> | >I'm not sure about the architecture, but the use of 'u' for autoconfig | >needs to be somewhere, that's just fine as it is now. | | When you say that we need the 'u'-bit for autoconfig, do you just mean | that we should continue to reverse this bit in the EUI-64 identifier | before we use it, to remain consistent with current practice? No, not just that, though that should remain of course. | Or are you saying that the semantics of the 'u'-bit (that it indicates | an IID is globally unique) has some importance for autoconfig? Not for autoconfig itself, but for manual config. Or perhaps for manual config to be able to cooperate with autoconfig. It is nice to be able to manually config some nodes on a link, and autoconfig others, and not need to worry whether the manually assigned address just might possibly conflict with some node's (perhaps node yet to be acquired) ability to autoconfig its natural address. Dividing the available space into two pieces, one for autoconf to use, and one for the various other assignment types (manual config, dhcp, etc) avoids this, so this use of the 'u' bit should be retained. When we encounter some new media type, for which we don't yet have an "IPv6 over foo" spec, we could pick a different bit to serve this purpose though, if we wanted to make it quite clear that nodes off the link simply cannot attempt to interpret this bit (which they should not be doing). Side note: this looks as if autoconfig is being given a special status not available to the other config methods, in that it has a reserved part of the iid space, and all the rest get to share what is left over. But that's not the case. What matters here is where the address assignments are done. For autoconfig, that's in every node, using manufacturer code alone, following the procedures of the rfc (and usually nothing else). All other assignments follow some site addressing plan, if some site wants to use the 'g' bit (or any other bit) to distinguish between dhcp assigned addresses and manually configured addresses, they can do that - all that's needed is for their dhcp server to co-operate. Nothing is required that touches more than the internal config of that site, so there is nothing we need to standardise here. | In the Yokohama meeting, Steve Deering lead a discussion on the | uniqueness of IIDs, and there was a pretty big majority of people | in the room who thought that we shouldn't even require IIDs to | be unique on a link. Addresses need to be unique (obviously), but | not necessarily the IIDs from which they are created. The discussion | will be documented in the minutes, and we'll offer a chance for people | on the list to comment before we make any final decision, of course. I know that was directed at the rest of the list (I was there, and absolutely agree with this decision). It has been discussed a bit on the list since the WG meeting (it is the one topic from the meeting which really has). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 06:38:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Dcx3U015729; Wed, 7 Aug 2002 06:38:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77DcxA2015728; Wed, 7 Aug 2002 06:38:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Dcr3U015721 for ; Wed, 7 Aug 2002 06:38:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12702 for ; Wed, 7 Aug 2002 06:39:02 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23434 for ; Wed, 7 Aug 2002 07:39:01 -0600 (MDT) Received: from kenawang ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA28632; Wed, 7 Aug 2002 06:38:26 -0700 (PDT) Message-Id: <4.2.2.20020807085415.00aa1270@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 07 Aug 2002 09:37:33 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <25734.1028627710@munnari.OZ.AU> References: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Having made the mistake of jumping into this swamp, I guess I'll keep swimming... But, first let me point out, as a WG chair, that the addressing architecture is a WG document with a long history of compromise and consensus. No significant changes will (or should) be made to the addressing architecture based on my personal opinions, even if a few other people agree with me. It would require a consensus of the WG to change the addressing architecture in the ways that I have suggested. We have discussed these things before (on the mailing list and in person) and, so far, there has been no WG consensus to make these sorts of changes. Now, back to my individual thoughts... >Not for autoconfig itself, but for manual config. Or perhaps for manual >config to be able to cooperate with autoconfig. It is nice to be >able to manually config some nodes on a link, and autoconfig others, >and not need to worry whether the manually assigned address just might >possibly conflict with some node's (perhaps node yet to be acquired) >ability to autoconfig its natural address. But, the semantics of the 'u' bit don't provide this... The 'u' bit indicates that a particular IID has been generated from a globally unique EUI-64 identifier. Addresses that are generated from other sources -- non-globally unique EUI-64s, serial numbers, random numbers, etc. will not have the 'u' bit set. So, it can't really be used to distinguish autoconfigured addresses from manually configured addresses -- it is used to distinguish IIDs that are (or should be) globally unique from IIDs that may not be globally unique. This is a holdover from the 8+8/GRE discussions that we had a few years back involving the potential benefits of separating identification information (the IID) from topological routing information (the prefix). Currently, IP addresses are overloaded to contain both types of information. For a large number of documented reasons, we chose not to pursue the 8+8/GRE mechanism. But there were a substantial number of people (I was one of them) who thought that it was important to maintain the global uniqueness of the IID, so that we might later be able to pursue such a mechanism. So, we decided that the lower 64-bits of an IPv6 should always be a globally unique EUI-64 identifier. Not much later, due to the fact that not all systems have EUI-64 identifiers and rising concerns about privacy issues, we backed off of this position and decided to use the 'u' bit to distinguish between globally unique IIDs and non-globally- unique IIDs. And, there we stand today... Personally, I think that it is highly unlikely that there will be any benefits to being able to separate the identification and topological routing information for _some_ hosts. So, I believe that we eliminated the ability to implement 8+8/GRE-like mechanisms altogether when we decided to use the 'u' bit to distinguish between the IIDs that were globally unique and those that were not. I argued this at the time, but there was clear WG consensus to use the 'u' bit. I have been told, though, that there are still a significant number of people who believe that the 'u' bit should be maintained for later use in a system that separates ID and routing goop (as it was called in GRE). These people were reportedly willing to accept the compromise of splitting the address space into two portions (via the 'u' bit), one that would have unique IIDs and one that would not. If there are folks who still believe that this is a valuable property, could you please speak up in support of it, and explain why? At that time, it didn't seem like a big issue to add a hard /64 boundary into the IPv6 address, because we already had several hard boundaries in our addresses to provide separate fields for aggregation (the TLA/SLA stuff). Since then, we have removed the other hard boundaries and moved to a CIDR-like address structure, but we have maintained the hard /64 boundary, and required Modfied EUI-64 IIDs for all global unicast addresses. There are some major advantages to retaining this hard /64 boundary: - It makes autoconfiguration simpler, since all prefixes are /64s and all IIDs are 64-bits long. It would require major, and inadvisable, changes to autoconfiguration to allow autoconfiguration using prefixes longer than /64. - Memory systems and processors are much better at dealing with 64-bit values than they are at dealing with longer values. So, the fact that most prefixes in the routing system will be 64-bits or shorter should allow IPv6 routers to perform better than they could if longer prefixes were commonly used. But, what I think this WG needs to think about and understand is _why_ operators are using longer prefixes on their router-to-router links. Is this just because that's how it has always been done? Or are there real technical reasons for preferring to use longer prefixes in that case? There are two reasons sited in the /127 draft (see subject): - A router can easily know the address of the router on the other end of the link... What is this used for? How valuable is this? - /127 prefixes ping-pong attacks that were possible with older versions of ICMP. These problems were fixed in ICMPv3, though, so is this really likely to be a problem for deployed IPv6 routers? If there are sound reasons to use longer prefixes in some cases, we may not want to have an addressing architecture that forbids it. But, I haven't seen anyone speak up with those reasons. Going once... Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 06:51:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77DpE3U015760; Wed, 7 Aug 2002 06:51:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77DpEl1015759; Wed, 7 Aug 2002 06:51:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Dp83U015752 for ; Wed, 7 Aug 2002 06:51:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15414 for ; Wed, 7 Aug 2002 06:51:10 -0700 (PDT) Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19432 for ; Wed, 7 Aug 2002 07:51:10 -0600 (MDT) Received: from repligate ([67.36.187.80]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020807135108.GAWV24870.mail1-0.chcgil.ameritech.net@repligate>; Wed, 7 Aug 2002 08:51:08 -0500 Message-ID: <06d701c23e19$8d8cbab0$8c56fea9@repligate> From: "Jim Fleming" To: "Robert Elz" , "Margaret Wasserman" , , "Richard Henderson" , , "Joe Baptista" , "Richard J. Sexton" Cc: , "Michael Froomkin - U.Miami School of Law" , "Milton Mueller" , "Judith Oppenheimer" , "Joop Teernstra" References: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <4.2.2.20020807085415.00aa1270@mail.windriver.com> Subject: 2002..4:11 MARS.....Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Wed, 7 Aug 2002 08:51:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The year is 2002, are you up to date on how 2002 addressing and 128-bit DNS works ? Feel free to stop by .MARS, if you need an update.... http://www.ActiveWorlds.com Jim Fleming 2002:[IPv4]:000X:03DB http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 4:11 MARS ----- Original Message ----- From: "Margaret Wasserman" To: "Robert Elz" Cc: Sent: Wednesday, August 07, 2002 8:37 AM Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt > > Having made the mistake of jumping into this swamp, I guess I'll keep > swimming... > > But, first let me point out, as a WG chair, that the addressing architecture > is a WG document with a long history of compromise and consensus. No significant > changes will (or should) be made to the addressing architecture based on my > personal opinions, even if a few other people agree with me. It would require > a consensus of the WG to change the addressing architecture in the ways that > I have suggested. We have discussed these things before (on the mailing list > and in person) and, so far, there has been no WG consensus to make these sorts > of changes. > > Now, back to my individual thoughts... > > >Not for autoconfig itself, but for manual config. Or perhaps for manual > >config to be able to cooperate with autoconfig. It is nice to be > >able to manually config some nodes on a link, and autoconfig others, > >and not need to worry whether the manually assigned address just might > >possibly conflict with some node's (perhaps node yet to be acquired) > >ability to autoconfig its natural address. > > But, the semantics of the 'u' bit don't provide this... > > The 'u' bit indicates that a particular IID has been generated from a > globally unique EUI-64 identifier. Addresses that are generated from > other sources -- non-globally unique EUI-64s, serial numbers, random > numbers, etc. will not have the 'u' bit set. So, it can't really be > used to distinguish autoconfigured addresses from manually configured > addresses -- it is used to distinguish IIDs that are (or should be) > globally unique from IIDs that may not be globally unique. > > This is a holdover from the 8+8/GRE discussions that we had a few > years back involving the potential benefits of separating identification > information (the IID) from topological routing information (the prefix). > Currently, IP addresses are overloaded to contain both types of > information. > > For a large number of documented reasons, we chose not to pursue the > 8+8/GRE mechanism. But there were a substantial number of people > (I was one of them) who thought that it was important to maintain the > global uniqueness of the IID, so that we might later be able to pursue > such a mechanism. So, we decided that the lower 64-bits of an IPv6 should > always be a globally unique EUI-64 identifier. Not much later, due to > the fact that not all systems have EUI-64 identifiers and rising concerns > about privacy issues, we backed off of this position and decided to use > the 'u' bit to distinguish between globally unique IIDs and non-globally- > unique IIDs. And, there we stand today... > > Personally, I think that it is highly unlikely that there will be any > benefits to being able to separate the identification and topological > routing information for _some_ hosts. So, I believe that we eliminated > the ability to implement 8+8/GRE-like mechanisms altogether when we decided > to use the 'u' bit to distinguish between the IIDs that were globally > unique and those that were not. I argued this at the time, but there > was clear WG consensus to use the 'u' bit. > > I have been told, though, that there are still a significant number of > people who believe that the 'u' bit should be maintained for later use > in a system that separates ID and routing goop (as it was called in > GRE). These people were reportedly willing to accept the compromise > of splitting the address space into two portions (via the 'u' bit), > one that would have unique IIDs and one that would not. If there are > folks who still believe that this is a valuable property, could you > please speak up in support of it, and explain why? > > At that time, it didn't seem like a big issue to add a hard /64 > boundary into the IPv6 address, because we already had several > hard boundaries in our addresses to provide separate fields for > aggregation (the TLA/SLA stuff). Since then, we have removed the > other hard boundaries and moved to a CIDR-like address structure, > but we have maintained the hard /64 boundary, and required Modfied > EUI-64 IIDs for all global unicast addresses. > > There are some major advantages to retaining this hard /64 boundary: > > - It makes autoconfiguration simpler, since all prefixes are > /64s and all IIDs are 64-bits long. It would require > major, and inadvisable, changes to autoconfiguration to > allow autoconfiguration using prefixes longer than /64. > > - Memory systems and processors are much better at dealing with > 64-bit values than they are at dealing with longer > values. So, the fact that most prefixes in the routing > system will be 64-bits or shorter should allow IPv6 > routers to perform better than they could if longer > prefixes were commonly used. > > But, what I think this WG needs to think about and understand is _why_ > operators are using longer prefixes on their router-to-router links. > Is this just because that's how it has always been done? Or are there > real technical reasons for preferring to use longer prefixes in that > case? There are two reasons sited in the /127 draft (see subject): > > - A router can easily know the address of the router > on the other end of the link... What is this > used for? How valuable is this? > > - /127 prefixes ping-pong attacks that were possible with > older versions of ICMP. These problems were > fixed in ICMPv3, though, so is this really likely > to be a problem for deployed IPv6 routers? > > If there are sound reasons to use longer prefixes in some cases, we > may not want to have an addressing architecture that forbids it. But, > I haven't seen anyone speak up with those reasons. > > Going once... > > Margaret > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 08:00:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77F0f3U015946; Wed, 7 Aug 2002 08:00:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77F0fDs015945; Wed, 7 Aug 2002 08:00:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77F0Y3U015938 for ; Wed, 7 Aug 2002 08:00:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11745 for ; Wed, 7 Aug 2002 08:00:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01452 for ; Wed, 7 Aug 2002 09:00:41 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21774; Wed, 7 Aug 2002 10:59:26 -0400 (EDT) Message-Id: <200208071459.KAA21774@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-default-addr-select-09.txt Date: Wed, 07 Aug 2002 10:59:25 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipv6-default-addr-select-09.txt Pages : 25 Date : 07-Aug-02 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-default-addr-select-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-default-addr-select-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-default-addr-select-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020807104005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-default-addr-select-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-default-addr-select-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020807104005.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 08:58:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Fwv3U016221; Wed, 7 Aug 2002 08:58:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77FwvlI016220; Wed, 7 Aug 2002 08:58:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Fwp3U016213 for ; Wed, 7 Aug 2002 08:58:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01648 for ; Wed, 7 Aug 2002 08:59:01 -0700 (PDT) Received: from roam.psg.com (dynwav-217-35.uoregon.edu [128.223.217.35]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23330 for ; Wed, 7 Aug 2002 08:59:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17cTD8-0000ry-00; Wed, 07 Aug 2002 08:58:58 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt References: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <25734.1028627710@munnari.OZ.AU> Message-Id: Date: Wed, 07 Aug 2002 08:58:58 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Or are you saying that the semantics of the 'u'-bit (that it indicates > | an IID is globally unique) has some importance for autoconfig? > > Not for autoconfig itself, but for manual config. Or perhaps for manual > config to be able to cooperate with autoconfig. It is nice to be > able to manually config some nodes on a link, and autoconfig others, > and not need to worry whether the manually assigned address just might > possibly conflict with some node's (perhaps node yet to be acquired) > ability to autoconfig its natural address. the subject of this draft is point to point links randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 10:19:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77HJW3U016418; Wed, 7 Aug 2002 10:19:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77HJWPL016417; Wed, 7 Aug 2002 10:19:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77HJQ3U016410 for ; Wed, 7 Aug 2002 10:19:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05083 for ; Wed, 7 Aug 2002 10:19:34 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12123 for ; Wed, 7 Aug 2002 11:19:33 -0600 (MDT) Received: from kenawang ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA29435; Wed, 7 Aug 2002 10:18:57 -0700 (PDT) Message-Id: <4.2.2.20020807131738.02572760@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 07 Aug 2002 13:19:44 -0400 To: Randy Bush From: Margaret Wasserman Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Cc: Robert Elz , ipng@sunroof.eng.sun.com In-Reply-To: References: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <25734.1028627710@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >the subject of this draft is point to point links Exactly. So, let me re-iterate something from my last message, in case folks didn't read that far: "But, what I think this WG needs to think about and understand is _why_ operators are using longer prefixes on their router-to-router links. Is this just because that's how it has always been done? Or are there real technical reasons for preferring to use longer prefixes in that case? There are two reasons sited in the /127 draft (see subject): - A router can easily know the address of the router on the other end of the link... What is this used for? How valuable is this? - /127 prefixes ping-pong attacks that were possible with older versions of ICMP. These problems were fixed in ICMPv3, though, so is this really likely to be a problem for deployed IPv6 routers? If there are sound reasons to use longer prefixes in some cases, we may not want to have an addressing architecture that forbids it." Would folks who are using these longer links speak up and explain why? Are there significant problems caused by using /64 prefixes that are solved by using longer prefixes? Thanks, Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 10:32:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77HWp3U016523; Wed, 7 Aug 2002 10:32:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77HWpHN016522; Wed, 7 Aug 2002 10:32:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77HWj3U016503 for ; Wed, 7 Aug 2002 10:32:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07508 for ; Wed, 7 Aug 2002 10:32:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27325 for ; Wed, 7 Aug 2002 10:32:53 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g77HTOi08207; Wed, 7 Aug 2002 10:29:24 -0700 (PDT) From: Bill Manning Message-Id: <200208071729.g77HTOi08207@boreas.isi.edu> Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020807085415.00aa1270@mail.windriver.com> from Margaret Wasserman at "Aug 7, 2 09:37:33 am" To: mrw@windriver.com (Margaret Wasserman) Date: Wed, 7 Aug 2002 10:29:23 -0700 (PDT) Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % There are some major advantages to retaining this hard /64 boundary: % % - It makes autoconfiguration simpler, since all prefixes are % /64s and all IIDs are 64-bits long. It would require % major, and inadvisable, changes to autoconfiguration to % allow autoconfiguration using prefixes longer than /64. % % - Memory systems and processors are much better at dealing with % 64-bit values than they are at dealing with longer % values. So, the fact that most prefixes in the routing % system will be 64-bits or shorter should allow IPv6 % routers to perform better than they could if longer % prefixes were commonly used. If these arguments were not valid when selecting 128bit addresses then -WHY- would they be valid now? Why did IPv6 not select 64bit addresses? % If there are sound reasons to use longer prefixes in some cases, we % may not want to have an addressing architecture that forbids it. But, % I haven't seen anyone speak up with those reasons. CIDR. address conservation. Just because it looks like an in-exaustable greenfield, does not make it so. We -WILL- run out at some point. --bill (who is tilting at windmills at this point) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 13:43:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Khv3U016968; Wed, 7 Aug 2002 13:43:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77KhnOC016967; Wed, 7 Aug 2002 13:43:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Khd3U016960 for ; Wed, 7 Aug 2002 13:43:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18994 for ; Wed, 7 Aug 2002 13:43:50 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29428 for ; Wed, 7 Aug 2002 13:43:50 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA01063 for ; Wed, 7 Aug 2002 13:43:49 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g77KhnW05666; Wed, 7 Aug 2002 13:43:49 -0700 X-mProtect: <200208072043> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdllKcSh; Wed, 07 Aug 2002 13:43:47 PDT Message-Id: <4.3.2.7.2.20020807134147.026af340@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Aug 2002 13:42:45 -0700 To: IPv6 List From: Bob Hinden Subject: Draft IPv6 Working Group Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft IPv6 working group meeting minutes from the Yokohama IETF can be found at: http://playground.sun.com/pub/ipng/html/minutes/ipv6-minutes-july2002.txt The presentation slides can be found at: http://playground.sun.com/pub/ipng/html/meetings.html The slides for the informal talk on IPv6 Deployment Activities and Products in Japan given at the lunch break between the two IPv6 sessions can be found at: http://playground.sun.com/pub/ipng/html/ipng-presentations.html Please send me comments and corrections. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 13:52:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Kqr3U017065; Wed, 7 Aug 2002 13:52:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77Kqrew017064; Wed, 7 Aug 2002 13:52:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Kql3U017057 for ; Wed, 7 Aug 2002 13:52:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10576 for ; Wed, 7 Aug 2002 13:52:55 -0700 (PDT) Received: from ensemada.lava.net (ensemada.lava.net [64.65.64.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03189 for ; Wed, 7 Aug 2002 14:52:55 -0600 (MDT) Received: from malasada.lava.net ([64.65.64.17]) (2330 bytes) by ensemada.lava.net; Wed, 7 Aug 2002 10:50:18 -1000 (HST) via sendmail [esmtp] id for Date: Wed, 7 Aug 2002 10:50:18 -1000 (HST) From: Antonio Querubin To: Margaret Wasserman cc: Randy Bush , Robert Elz , Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020807131738.02572760@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 7 Aug 2002, Margaret Wasserman wrote: > "But, what I think this WG needs to think about and understand is _why_ > operators are using longer prefixes on their router-to-router links. > Is this just because that's how it has always been done? Or are there > real technical reasons for preferring to use longer prefixes in that > case? There are two reasons sited in the /127 draft (see subject): > > - A router can easily know the address of the router > on the other end of the link... What is this > used for? How valuable is this? > > - /127 prefixes ping-pong attacks that were possible with > older versions of ICMP. These problems were > fixed in ICMPv3, though, so is this really likely > to be a problem for deployed IPv6 routers? > > If there are sound reasons to use longer prefixes in some cases, we > may not want to have an addressing architecture that forbids it." > > Would folks who are using these longer links speak up and explain > why? Are there significant problems caused by using /64 prefixes > that are solved by using longer prefixes? - At any particular site, it makes it easy to notice that an address is a link address if they're confined to a single pre-selected subnet. - Simple conservation principle - ie. why is it necessary to use a whole /64 just for a single point to point link? What specific advantage or capability do you gain on a point to point link by using something longer than a /127 or /126? And if that capability isn't needed or deemed important, why waste? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 22:39:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g785dP3U018244; Wed, 7 Aug 2002 22:39:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g785dPbt018243; Wed, 7 Aug 2002 22:39:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g785dJ3U018235 for ; Wed, 7 Aug 2002 22:39:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03964 for ; Wed, 7 Aug 2002 22:39:28 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16073 for ; Wed, 7 Aug 2002 22:39:27 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5B1E34B22 for ; Thu, 8 Aug 2002 14:39:22 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Thu, 08 Aug 2002 14:39:22 +0900 Message-Id: <20020808053922.5B1E34B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk many of existing implementations abstract IPv6-over-IPv4 tunnels, like following, as pseudo interfaces: - configured tunnels (RFC2893 section 4) - gif(4) in KAME - 6to4 tunnels (RFC3056) - stf(4) in KAME - isatap none of the above document specify what IPv6 MTU to use for these interfaces. (RFC3056 has a pointer to RFC2893, but RFC2893 has nothing about IPv6 MTU) the lack of standard IPv6 MTU could lead to interoperability problem. consider the following scenario: - node A is using MTU X for tunnel interface (X >= 1280) - node B is using MTU Y for tunnel interface (Y > X >= 1280) now, if B transmits packets larger than X, A may drop it as it is larger than MTU (assuming MRU == MTU), causing blackhole. also, MTU mismatch could have some impact to PMTUD if A and B are routers. with configured tunnels, the issue is not that serious as we only need two party to agree on what MTU to use (so if operators are clever/careful enough, we are okay). for 6to4 and isatap, the issue is serious as there are multiple nodes sharing the same virtual link. we actually have experienced interoperability problem between KAME and JunOS for configured tunnels, as KAME is using 1280 as MTU and JunOS is using infinity (so PMTUD does not occur). therefore, I propose: - to specify default IPv6 MTU of RFC2893 tunnel interface be 1280, in RFC2893bis (so, 6to4 MTU will become 1280). of course operators can override if they wish to, specifically for configured tunnel case. - add reference from isatap document to 2893bis to follow it. any comments? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 22:48:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g785mk3U018272; Wed, 7 Aug 2002 22:48:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g785mk34018271; Wed, 7 Aug 2002 22:48:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g785me3U018264 for ; Wed, 7 Aug 2002 22:48:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23846 for ; Wed, 7 Aug 2002 22:48:50 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13258 for ; Wed, 7 Aug 2002 22:48:48 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 7 Aug 2002 22:48:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E252@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Thread-Index: AcI+GEVsEfNLBedlQnOe3SnW2vCMNgAc5ybQ From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g785mf3U018265 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > Having made the mistake of jumping into this swamp, > I guess I'll keep swimming... To be honest, I think it was about time that this issue came to a head. Because the issue is not about /127 prefixes, but it is about the reading of [addrarch] that says (or does not) that a prefix longer than /64 is not to be used for anycast addresses. > But, first let me point out, as a WG chair, that the > addressing architecture is a WG document with a long > history of compromise and consensus. This is very, very true. > No significant changes will (or should) be made to the > addressing architecture based on my personal opinions, > even if a few other people agree with me. It would require > a consensus of the WG to change the addressing architecture > in the ways that I have suggested. We have discussed these > things before (on the mailing list and in person) and, so > far, there has been no WG consensus to make these sorts > of changes. This is fair. Back to Pekka's draft: I think it would be fair to say that Pekka's draft is valid if [addrarch] is _not_ to be modified, and needs to be dumped if [addrarch] is to be modified. > This is a holdover from the 8+8/GRE discussions that we had a few I assume you meant GSE, not GRE. > For a large number of documented reasons, we chose not to > pursue the 8+8/GRE mechanism. But there were a substantial > number of people (I was one of them) who thought that it was > important to maintain the global uniqueness of the IID, so > that we might later be able to pursue such a mechanism. I don't think this has changed. This might sound a paradox, but here it is anyway: As the author of a protocol (MHAP) that has been compared to 8+8/GSE many times (with or without reasons) and that actually does address the issue of the uniqueness of the IID, I still think that it is not wise to close this door although I have myself provided an alternative way out. In other words: I personally don't care about the 'u' bit, but now is not the time to close doors as long that big unknown about multihoming is not settled. > Personally, I think that it is highly unlikely that there > will be any benefits to being able to separate the > identification and topological routing information for > _some_ hosts. I hope you don't mind my bluntness, but you don't know yet; nobody does. Now is not the time to close doors. > I have been told, though, that there are still a > significant number of people who believe that the 'u' > bit should be maintained for later use in a system that > separates ID and routing goop (as it was called in > GRE). These people were reportedly willing to accept the > compromise of splitting the address space into two portions > (via the 'u' bit), one that would have unique IIDs and one > that would not. If there are folks who still believe that > this is a valuable property, could you please speak up in > support of it, and explain why? As mentioned above, now is the time to keep our options open. I hope that this counts as a valid opinion, as my personal agenda actually goes against what I recommend we do WRT this matter, which is that we actually keep the 'u' bit for the time being. > At that time, it didn't seem like a big issue to add a > hard /64 boundary into the IPv6 address, because we already > had several hard boundaries in our addresses to provide > separate fields for aggregation (the TLA/SLA stuff). Since > then, we have removed the other hard boundaries and moved > to a CIDR-like address structure, but we have maintained the > hard /64 boundary, and required Modfied EUI-64 IIDs for all > global unicast addresses. Note about this: My reading is that there still is a semi-hard boundary at /48, (site) and I think this is good. > But, what I think this WG needs to think about and understand > is _why_ operators are using longer prefixes on their > router-to-router links. Is this just because that's how it has > always been done? There is a large part of this. I peer with both /127s and /64s. Both work fine. The issue here is *not* I repeat *not* whether or not /127s or /126s are suitable for ptp links. I support Pekka's draft saying that /127s are not good, but /126s or /112s are technically usable. Recently, I peered with John Fraizier. I don't think that there was any questions about using a /64 for the tunnel (John, please comment as needed). I also setup private peerings with buddies and there again we used /64s. That being said, the issue again is *not* about it. The issue is: can we finally get everyone to go in the same direction? Among many others, kre and I have debated over and over the issue. None of us is wrong, and none of us is right. Let's put an end to this and settle it. We have more important things to do. > - A router can easily know the address of the router on the > other end of the link... What is this used for? How valuable > is this? This is worth its weight in gold. Look at an IPv4 example: Your router's address is x.y.x.33 /30. What is the other end (coz you want to ping it to see if the circuit is up)? It's x.y.z.34. I don't need a calculator for this, but the NOC dude that picks up the phone at 3 am does, and still will get 50% wrong and try to ping x.y.z.32 :-(( IPv6 example: Your router's address is x:y:z:t::1/64. What is the other end? Mmmm. Let's try x:y:z:t::2/64. As I said above, it all comes to this: Do we have a consensus about modifying [addrarch]? Yes -> Let's modify it. No -> Let's move Pekka's draft to Informational or BCP and settle this. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:15:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786FW3U018325; Wed, 7 Aug 2002 23:15:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786FCx1018324; Wed, 7 Aug 2002 23:15:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786F73U018317 for ; Wed, 7 Aug 2002 23:15:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29524 for ; Wed, 7 Aug 2002 23:15:17 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24046 for ; Thu, 8 Aug 2002 00:15:16 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g786EAE27036; Thu, 8 Aug 2002 09:14:10 +0300 Date: Thu, 8 Aug 2002 09:14:10 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Margaret Wasserman , Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <2B81403386729140A3A899A8B39B046405E252@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 7 Aug 2002, Michel Py wrote: > > Having made the mistake of jumping into this swamp, > > I guess I'll keep swimming... > > To be honest, I think it was about time that this issue came to a head. > Because the issue is not about /127 prefixes, but it is about the > reading of [addrarch] that says (or does not) that a prefix longer than > /64 is not to be used for anycast addresses. No. > > No significant changes will (or should) be made to the > > addressing architecture based on my personal opinions, > > even if a few other people agree with me. It would require > > a consensus of the WG to change the addressing architecture > > in the ways that I have suggested. We have discussed these > > things before (on the mailing list and in person) and, so > > far, there has been no WG consensus to make these sorts > > of changes. > > This is fair. > > Back to Pekka's draft: I think it would be fair to say that Pekka's > draft is valid if [addrarch] is _not_ to be modified, and needs to be > dumped if [addrarch] is to be modified. This is incorrect; there are two issues here: 1) addrarch statements about /64 which make the use of longer than /64 "forbidden" 2) people still using /127 and in future experiencing problems due to subnet router anycast address. The point of my draft has *ALWAYS* been 2). It's not an advocacy document (point 1) above), even though people have tried to make it one (and I must admit I've given in an inch or two). > > But, what I think this WG needs to think about and understand > > is _why_ operators are using longer prefixes on their > > router-to-router links. Is this just because that's how it has > > always been done? > > There is a large part of this. I peer with both /127s and /64s. Both > work fine. Your routers probably don't support subnet router anycast address. > The issue here is *not* I repeat *not* whether or not /127s > or /126s are suitable for ptp links. I support Pekka's draft saying that > /127s are not good, but /126s or /112s are technically usable. There are two issues, as stated above. > As I said above, it all comes to this: > Do we have a consensus about modifying [addrarch]? > > Yes -> Let's modify it. > No -> Let's move Pekka's draft to Informational or BCP and settle this. There are other options also. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:24:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786OQ3U018361; Wed, 7 Aug 2002 23:24:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786OQEG018360; Wed, 7 Aug 2002 23:24:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786OL3U018351 for ; Wed, 7 Aug 2002 23:24:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12587 for ; Wed, 7 Aug 2002 23:24:31 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00942 for ; Wed, 7 Aug 2002 23:24:30 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g786ONf27116; Thu, 8 Aug 2002 09:24:23 +0300 Date: Thu, 8 Aug 2002 09:24:22 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: <20020808053922.5B1E34B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 8 Aug 2002 itojun@iijlab.net wrote: > the lack of standard IPv6 MTU could lead to interoperability problem. > consider the following scenario: > - node A is using MTU X for tunnel interface (X >= 1280) > - node B is using MTU Y for tunnel interface (Y > X >= 1280) > > now, if B transmits packets larger than X, A may drop it as it is > larger than MTU (assuming MRU == MTU), causing blackhole. > also, MTU mismatch could have some impact to PMTUD if A and B are > routers. MRU == MTU seems an invalid assumption (in practise). Nodes must be able to receive packets with at least 1500 bytes (I tried looking up where this was stated but couldn't remember where). But what is the problem here? If node A drops the packet, it sends packet too big message back, and the sources adjust? > with configured tunnels, the issue is not that serious as we only need > two party to agree on what MTU to use (so if operators are > clever/careful enough, we are okay). for 6to4 and isatap, the issue > is serious as there are multiple nodes sharing the same virtual link. > > we actually have experienced interoperability problem between KAME and > JunOS for configured tunnels, as KAME is using 1280 as MTU and JunOS > is using infinity (so PMTUD does not occur). Every node must be capable of at least being a recipient to PTMUD (that is, adjusting the sending MTU based on packet too big messages). Else we have way too many problems. > therefore, I propose: > - to specify default IPv6 MTU of RFC2893 tunnel interface be 1280, > in RFC2893bis (so, 6to4 MTU will become 1280). of course operators > can override if they wish to, specifically for configured tunnel case. > - add reference from isatap document to 2893bis to follow it. Operationally, the 1280 default for configured tunnels seems very unoptimal. Source nodes which use a larger MTU, like 1500, need to initiate PMTUD if they use links with tunnels; not good. For automatic tunnels (incl. 6to4 etc.) 1280 might be a safe choice. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:28:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786SR3U018386; Wed, 7 Aug 2002 23:28:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786SR3v018385; Wed, 7 Aug 2002 23:28:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786SM3U018378 for ; Wed, 7 Aug 2002 23:28:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02736 for ; Wed, 7 Aug 2002 23:28:32 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02905 for ; Thu, 8 Aug 2002 00:28:31 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 7 Aug 2002 23:28:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E254@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Thread-Index: AcI+oxGpB75zq5tbTJi0pRtTIRzkSQAAGDpg From: "Michel Py" To: "Pekka Savola" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g786SM3U018379 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Savola wrote: > This is incorrect; there are two issues here: > 1) addrarch statements about /64 which make the use of > longer than /64 "forbidden" > 2) people still using /127 and in future experiencing > problems due to subnet router anycast address. > The point of my draft has *ALWAYS* been 2). It's not > an advocacy document (point 1) above), even though people > have tried to make it one (and I must admit I've given > in an inch or two). This is a good point, please allow me to rephrase: *if* [addrarch] was to be modified to make prefixes longer than /64 "legal", you would then have to modify your draft to remove issue #1. Although issue #2 is perfectly valid and I will gladly support it *if* it does become issue #1, the fact of the matter is, as Margaret pointed out, your draft does bring a policy issue. So, whether you like it or not, your draft is an advocacy document. What I should have said is: - If [addrarch] is to be modified, you are looking at a major re-write. - If [addrarch] is *not* to be modified, your draft is fine as-is. Hope this makes sense. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:28:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786Sm3U018396; Wed, 7 Aug 2002 23:28:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786Sl7K018395; Wed, 7 Aug 2002 23:28:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786Sc3U018388 for ; Wed, 7 Aug 2002 23:28:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02802 for ; Wed, 7 Aug 2002 23:28:49 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00786 for ; Thu, 8 Aug 2002 00:28:48 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F1F194B23; Thu, 8 Aug 2002 15:28:41 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Thu, 08 Aug 2002 09:24:22 +0300. 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: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Thu, 08 Aug 2002 15:28:41 +0900 Message-Id: <20020808062842.F1F194B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >MRU == MTU seems an invalid assumption (in practise). >Nodes must be able to receive packets with at least 1500 bytes (I tried >looking up where this was stated but couldn't remember where). >But what is the problem here? If node A drops the packet, it sends packet >too big message back, and the sources adjust? i know of no nodes that transmit packet too big messgages, when incoming packets exceed MRU. too big messages are generated when outgoing packets exceed MTU. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:34:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786Y43U018445; Wed, 7 Aug 2002 23:34:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786Y477018444; Wed, 7 Aug 2002 23:34:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786Xv3U018437 for ; Wed, 7 Aug 2002 23:33:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03983 for ; Wed, 7 Aug 2002 23:34:05 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03035 for ; Thu, 8 Aug 2002 00:34:04 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 2A2974B22; Thu, 8 Aug 2002 15:33:58 +0900 (JST) To: Pekka Savola , ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Thu, 08 Aug 2002 15:28:41 +0900. <20020808062842.F1F194B23@coconut.itojun.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: Re: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Thu, 08 Aug 2002 15:33:58 +0900 Message-Id: <20020808063358.2A2974B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Nodes must be able to receive packets with at least 1500 bytes (I tried >>looking up where this was stated but couldn't remember where). the above statement is about the packet size after reassembly, not about the link MRU. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:39:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786dJ3U018471; Wed, 7 Aug 2002 23:39:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786dJrc018470; Wed, 7 Aug 2002 23:39:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786dC3U018463 for ; Wed, 7 Aug 2002 23:39:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA15016 for ; Wed, 7 Aug 2002 23:39:20 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA16919 for ; Thu, 8 Aug 2002 00:39:18 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 277054B22; Thu, 8 Aug 2002 15:39:12 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Thu, 08 Aug 2002 09:24:22 +0300. 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: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Thu, 08 Aug 2002 15:39:12 +0900 Message-Id: <20020808063912.277054B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> we actually have experienced interoperability problem between KAME and >> JunOS for configured tunnels, as KAME is using 1280 as MTU and JunOS >> is using infinity (so PMTUD does not occur). >Every node must be capable of at least being a recipient to PTMUD (that >is, adjusting the sending MTU based on packet too big messages). Else we >have way too many problems. let me annotate. we experienced troubles under the following configuration. MTU mismatch occured between routers, and caused troubles to the end nodes that are served by these routers. end node --- KAME ============== Juniper --- end node 1280 infty itoju -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:41:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786ff3U018496; Wed, 7 Aug 2002 23:41:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786ffwN018495; Wed, 7 Aug 2002 23:41:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786fa3U018488 for ; Wed, 7 Aug 2002 23:41:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA15473 for ; Wed, 7 Aug 2002 23:41:44 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18450 for ; Thu, 8 Aug 2002 00:41:43 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g786fcB27322; Thu, 8 Aug 2002 09:41:38 +0300 Date: Thu, 8 Aug 2002 09:41:37 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: <20020808062842.F1F194B23@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 8 Aug 2002 itojun@iijlab.net wrote: > >MRU == MTU seems an invalid assumption (in practise). > >Nodes must be able to receive packets with at least 1500 bytes (I tried > >looking up where this was stated but couldn't remember where). > >But what is the problem here? If node A drops the packet, it sends packet > >too big message back, and the sources adjust? > > i know of no nodes that transmit packet too big messgages, when > incoming packets exceed MRU. No nodes do; but I know of no nodes that drop packets they're able to receive based on some configured maximum value either. > too big messages are generated > when outgoing packets exceed MTU. But if a node X is able to send packet on a medium (in case of tunneling, nothing physical though), and node Y is able to receive it, why should it check MRU? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:48:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786mG3U018537; Wed, 7 Aug 2002 23:48:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786mGJT018536; Wed, 7 Aug 2002 23:48:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786mA3U018529 for ; Wed, 7 Aug 2002 23:48:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16797 for ; Wed, 7 Aug 2002 23:48:19 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13324 for ; Wed, 7 Aug 2002 23:48:19 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 7 Aug 2002 23:48:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E255@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Thread-Index: AcI8wFQcz044VTG/SGiI/GNRXayNggB5g+9w From: "Michel Py" To: "Thomas Narten" , "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g786mB3U018530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >> "For all unicast addresses, except those that start with >> binary value 000, Interface IDs are required to be 64 bits >> long and to be constructed in Modified EUI-64 format." > Thomas Narten wrote: > If anyone thinks this is still an issue, it would be good to > point out the specific text that is believed to be unclear > and suggest replacement wording. I do not suggest replacement wording as the one quoted >> above is clear to my poor English. If I may, it appears to me that the issue currently being discussed is about the [addrarch] text being flawed, not being unclear. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 7 23:49:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786nt3U018555; Wed, 7 Aug 2002 23:49:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g786nscN018553; Wed, 7 Aug 2002 23:49:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g786nm3U018546 for ; Wed, 7 Aug 2002 23:49:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19667 for ; Wed, 7 Aug 2002 23:49:56 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14238 for ; Wed, 7 Aug 2002 23:49:55 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 85C2A4B24; Thu, 8 Aug 2002 15:49:49 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Thu, 08 Aug 2002 09:41:37 +0300. 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: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Thu, 08 Aug 2002 15:49:49 +0900 Message-Id: <20020808064949.85C2A4B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> i know of no nodes that transmit packet too big messgages, when >> incoming packets exceed MRU. >No nodes do; but I know of no nodes that drop packets they're able to >receive based on some configured maximum value either. >> too big messages are generated >> when outgoing packets exceed MTU. >But if a node X is able to send packet on a medium (in case of tunneling, >nothing physical though), and node Y is able to receive it, why should it >check MRU? since there's no standard, some implementation can be picky and assume MRU == MTU. maybe RFC2893 should talk more about MRU and MTU. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 8 00:01:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g787183U018614; Thu, 8 Aug 2002 00:01:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78718Lw018613; Thu, 8 Aug 2002 00:01:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g787123U018606 for ; Thu, 8 Aug 2002 00:01:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19316 for ; Thu, 8 Aug 2002 00:01:11 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27299 for ; Thu, 8 Aug 2002 00:01:09 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g78714X27489; Thu, 8 Aug 2002 10:01:04 +0300 Date: Thu, 8 Aug 2002 10:01:04 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: <20020808064949.85C2A4B24@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 8 Aug 2002 itojun@iijlab.net wrote: > >> i know of no nodes that transmit packet too big messgages, when > >> incoming packets exceed MRU. > >No nodes do; but I know of no nodes that drop packets they're able to > >receive based on some configured maximum value either. > >> too big messages are generated > >> when outgoing packets exceed MTU. > >But if a node X is able to send packet on a medium (in case of tunneling, > >nothing physical though), and node Y is able to receive it, why should it > >check MRU? > > since there's no standard, some implementation can be picky and > assume MRU == MTU. maybe RFC2893 should talk more about MRU and MTU. I've configured Ethernet MTU to be 1500 on the sender side and 1280 on the recipient side (MRU is generally unconfigurable); it works without problems as far as I've noticed. These issues are not specific to tunnels as far as I can see. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 8 01:48:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g788mR3U019035; Thu, 8 Aug 2002 01:48:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g788mRS6019034; Thu, 8 Aug 2002 01:48:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g788mM3U019027 for ; Thu, 8 Aug 2002 01:48:22 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00142 for ; Thu, 8 Aug 2002 01:48:31 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14910 for ; Thu, 8 Aug 2002 02:48:30 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g788mSrG014946 for ; Thu, 8 Aug 2002 10:48:28 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g788mRkS095494 for ; Thu, 8 Aug 2002 10:48:27 +0200 Subject: EUI-64 based interface identifiers To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Thu, 8 Aug 2002 10:48:26 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.9a |January 7, 2002) at 08/08/2002 10:48:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have 2 questions regarding EUI-64 based interface identifiers. On Linux for zSeries we face the scenario that various Linuxes on one machine might share the same network (Fast/Gigabit Ethernet) card. Of course this card has just one MAC address. To avoid detection of duplicate addresses during stateless autoconfiguration we are replacing the part 0xFFFE of the link local address by a 16-bit value. This value is unique among all Linuxes sharing the same network card. A MAC of 00:04:AC:7C:BC:48 for a shared network card would result in the following link local addresses for the Linuxes sharing this card: Linux 1: fe80::4:ac00:17c:bc48 Linux 2: fe80::4:ac00:27c:bc48 Linux 3: fe80::4:ac00:37c:bc48 ... This procedure does not correspond to what is written in RFC 2373 "Appendix A: Creating EUI-64 based Interface Identifiers" and in "http://standards.ieee.org/regauth/oui/tutorials/EUI64.html". The algorithm described there would result in a link local address of fe80::204:acff:fe7c:bc48 for all Linuxes sharing the same card. But we are not inverting the "u" bit in the resulting interface identifiers. Hence the resulting 64-bit interface identifiers have local scope. According to a short discussion about a similar topic that happened on this mailing list quite a long time ago (I found it in the mail archive, file ipng.200002): "=> you can do what you want when the global bit is reset/reversed." Thus I assume the above procedure -- replacing 0xFFFE by a unique identifier and not inverting the "u" bit -- does not violate any RFCs. Am I right in this assumption? Another question is: Do you know of any applications that rely on the part "FFFE" of interface identifiers? E.g. network sniffers might use the value to identify interface identifiers. Regards, Andreas Herrmann -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 8 04:55:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78Btj3U020161; Thu, 8 Aug 2002 04:55:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78Btj5x020160; Thu, 8 Aug 2002 04:55:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78Btd3U020147 for ; Thu, 8 Aug 2002 04:55:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29647 for ; Thu, 8 Aug 2002 04:55:48 -0700 (PDT) Received: from web21411.mail.yahoo.com (web21411.mail.yahoo.com [216.136.232.80]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA21444 for ; Thu, 8 Aug 2002 04:55:48 -0700 (PDT) Message-ID: <20020808115548.54890.qmail@web21411.mail.yahoo.com> Received: from [203.200.20.226] by web21411.mail.yahoo.com via HTTP; Thu, 08 Aug 2002 04:55:48 PDT Date: Thu, 8 Aug 2002 04:55:48 -0700 (PDT) From: Pavan Mahoorker Subject: How and where to get Conformance test case documenst To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-96787363-1028807748=:54115" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-96787363-1028807748=:54115 Content-Type: text/plain; charset=us-ascii Hi all How and where to get the conformance test case documents ex:http://www.tahi.org and If any one knows some other site pls let me know it. Thanx and Regds Pavan --------------------------------- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs --0-96787363-1028807748=:54115 Content-Type: text/html; charset=us-ascii

Hi all

How and where to get the conformance test case documents ex:http://www.tahi.org

and If any one knows some other site pls let me know it.

Thanx and Regds

Pavan

 



Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs --0-96787363-1028807748=:54115-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 8 07:48:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78Emn3U020534; Thu, 8 Aug 2002 07:48:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78Emn7E020533; Thu, 8 Aug 2002 07:48:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78Emh3U020526 for ; Thu, 8 Aug 2002 07:48:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07570 for ; Thu, 8 Aug 2002 07:48:52 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14466 for ; Thu, 8 Aug 2002 07:48:51 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA11337 for ; Thu, 8 Aug 2002 07:48:50 -0700 (MST)] Received: [from il06exm06.corp.mot.com (il06exm06.corp.mot.com [199.5.78.47]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA08281 for ; Thu, 8 Aug 2002 07:47:04 -0700 (MST)] Received: by il06exm06.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 8 Aug 2002 09:48:48 -0500 Message-ID: From: Jung Cyndi-ACJ099 To: "'Pekka Savola'" , itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 MTU for tunnel pseudo interfaces Date: Thu, 8 Aug 2002 09:48:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This sounds like a case where you should apply the old rule "be conservative with what you send and generous with what you are willing to receive" - if you have successfully received the whole packet, please don't drop it. Cyndi -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, August 08, 2002 12:01 AM To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MTU for tunnel pseudo interfaces On Thu, 8 Aug 2002 itojun@iijlab.net wrote: > >> i know of no nodes that transmit packet too big messgages, when > >> incoming packets exceed MRU. > >No nodes do; but I know of no nodes that drop packets they're able to > >receive based on some configured maximum value either. > >> too big messages are generated > >> when outgoing packets exceed MTU. > >But if a node X is able to send packet on a medium (in case of tunneling, > >nothing physical though), and node Y is able to receive it, why should it > >check MRU? > > since there's no standard, some implementation can be picky and > assume MRU == MTU. maybe RFC2893 should talk more about MRU and MTU. I've configured Ethernet MTU to be 1500 on the sender side and 1280 on the recipient side (MRU is generally unconfigurable); it works without problems as far as I've noticed. These issues are not specific to tunnels as far as I can see. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 05:05:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79C5H3U024386; Fri, 9 Aug 2002 05:05:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79C5GYJ024385; Fri, 9 Aug 2002 05:05:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79C5A3U024378 for ; Fri, 9 Aug 2002 05:05:11 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g79C5Hg05343; Fri, 9 Aug 2002 14:05:17 +0200 (MEST) Date: Fri, 9 Aug 2002 14:03:19 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 MTU for tunnel pseudo interfaces To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020808053922.5B1E34B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > none of the above document specify what IPv6 MTU to use for these > interfaces. (RFC3056 has a pointer to RFC2893, but RFC2893 has nothing > about IPv6 MTU) I see these words in RFC 2893 which seem to be relevant to this issue: The IPv6 layer in the encapsulating node 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. This is suggesting that the interface MTU for such a tunnel is dynamic by being a function of the IPv4 path MTU across the tunnel. A result of such behavior is that the initial MTU for such a tunnel interface would be the interface MTUs for the underlying physical interface for the tunnel, minus 20 bytes for the IPv4 header. But I take it from your question that you'd like to see a fixed number for the MTU. Is this really necessary? > now, if B transmits packets larger than X, A may drop it as it is > larger than MTU (assuming MRU == MTU), causing blackhole. Such an assumption and the resulting dropping behavior seems like a very bad idea. (Are there such implementations?) If folks make such assumptions I guess we need to make it more clear what "be liberal in what you accept" in the case of tunnels and explain what the "T" stands for in "MTU". But it doesn't follow that we need to pick a fixed MTU number. > also, MTU mismatch could have some impact to PMTUD if A and B are > routers. I don't understand the issue. Care to explain? > we actually have experienced interoperability problem between KAME and > JunOS for configured tunnels, as KAME is using 1280 as MTU and JunOS > is using infinity (so PMTUD does not occur). Do either of then drop received packets that exceed the configured MTU? The way you dscribe it it seems like JunOS doesn't follow the text in section 3.2 in RFC 2893, but that by itself will merely cause inefficient behavior (IPv4 reassembly at the router = tunnel endpoint instead of e2e IPv6 path mtu discovery and IPv6 reassembly at the IPv6 endpoint) and not interoperability problems. > therefore, I propose: > - to specify default IPv6 MTU of RFC2893 tunnel interface be 1280, > in RFC2893bis (so, 6to4 MTU will become 1280). of course operators > can override if they wish to, specifically for configured tunnel case. Seems like overkill. But perhaps I don't understand the details of the problems yet. BTW: Shouldn't we discuss RFC 2893 on the ngtrans list? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 05:12:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79CC93U024405; Fri, 9 Aug 2002 05:12:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79CC8Rh024404; Fri, 9 Aug 2002 05:12:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79CC23U024397 for ; Fri, 9 Aug 2002 05:12:03 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g79CC9g06116; Fri, 9 Aug 2002 14:12:09 +0200 (MEST) Date: Fri, 9 Aug 2002 14:10:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 MTU for tunnel pseudo interfaces To: itojun@iijlab.net Cc: Pekka Savola , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020808064949.85C2A4B24@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > since there's no standard, some implementation can be picky and > assume MRU == MTU. maybe RFC2893 should talk more about MRU and MTU. How about: A node implementing RFC 2893 MUST be able to reassemble IPv4 packets of a size up to and including 65353 octets and MUST NOT place any limits on the size of the received encapsulated packets. In particular, it MUST NOT assume that the maximum size of received packets has anything to do with the MTU for the tunnel. Of course, it might also make sense to add some SHOULD (or MUST?) to section 3.2 in RFC 2893 to make IPv4 MTU discovery across the tunnel seem less optional than what the current text says. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 06:11:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79DBP3U025212; Fri, 9 Aug 2002 06:11:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79DBPvc025211; Fri, 9 Aug 2002 06:11:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79DBK3U025204 for ; Fri, 9 Aug 2002 06:11:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03502 for ; Fri, 9 Aug 2002 06:11:30 -0700 (PDT) From: Robert.Peschi@alcatel.be Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24797 for ; Fri, 9 Aug 2002 07:11:17 -0600 (MDT) Received: from bemail01.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g79D5q732340; Fri, 9 Aug 2002 15:06:00 +0200 Subject: Re: DAD vs. DIID To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Date: Fri, 9 Aug 2002 15:10:37 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/09/2002 15:10:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, On Mon, 5 Aug 2002, Margaret Wasserman wrote in "Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt": > In the Yokohama meeting, Steve Deering lead a > discussion on the uniqueness of IIDs, and there > was a pretty big majority of people in the room > who thought that we shouldn't even require IIDs > to be unique on a link. Addresses need to be > unique (obviously), but not necessarily the > IIDs from which they are created. The discussion > will be documented in the minutes, and we'll offer > a chance for people on the list to comment before > we make any final decision, of course. I went through the minutes and presentation of Yokohama meeting about "DAD vs. DIID Discussion". Maybe I am missing something here, but, if the Interface Identifier is not unique anymore on a link, what is it then supposed to identify and be used for ? Also, how would then the Link Local address be formed ? Thanks for any clarification there, Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 07:01:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79E1C3U025310; Fri, 9 Aug 2002 07:01:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79E1CB9025309; Fri, 9 Aug 2002 07:01:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79E163U025302 for ; Fri, 9 Aug 2002 07:01:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12269 for ; Fri, 9 Aug 2002 07:01:14 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23463 for ; Fri, 9 Aug 2002 08:01:14 -0600 (MDT) Received: from kenawang ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA04864; Fri, 9 Aug 2002 07:00:48 -0700 (PDT) Message-Id: <4.2.2.20020809093305.0186a250@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 09 Aug 2002 09:58:44 -0400 To: Robert.Peschi@alcatel.be From: Margaret Wasserman Subject: Re: DAD vs. DIID Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, >Maybe I am missing something here, but, if the >Interface Identifier is not unique anymore on a >link, what is it then supposed to identify and >be used for ? The suggestion doesn't change the purpose of an IID, just the scope of its uniqueness. In the current (pre-change) addressing architecture, an IID is unique on the link. So, within the scope of a given link, the IID can be used to identify a particular interface (and, by extension, a given node). This change would modify the scope of that uniqueness to be a subnet prefix, not the whole link. So, within a set of interfaces using a particular subnet prefix, the IID would identify a particular interface. Most links will have multiple subnet prefixes in use, because they will have a link-local prefix and a global prefix. Some links may have many subnet prefixes in use (link-local, one or more site-local subnets and one or more global subnets). Have you seen the slides that Steve Deering presented on this subject? If they aren't already up on the IETF proceedings page, they should be shortly. They give an example of what this means. Although the wording is fairly arcane in order to be exactly correct, the real change comes down to this: OLD: IIDs are required to be unique on a link. NEW: Only complete addresses are required to be unique on a link. Relaxing the restriction to the second case makes the use of privacy addresses easier, it doesn't require any major changes to implementations (we are already doing Duplicate _Address_ Detection, not Duplicate IID Detection), and it meets the requirements to uniquely identify a node for communication. A side-effect of this change is that we will need to update the Address Autoconfiguration spec to require the use of DAD on all addresses, and not allow the currently documented optimization to only perform DAD on the link-local address. I can only think of two cases where the same IID would get used for different hosts on the same link: - If some hosts on the link do not configure global addresses, but others do. - If there are two (or more) subnets running over the same link, and not all of the hosts on the link are members of both (or all) subnets. >Also, how would then the Link Local address be formed ? Not all IIDs are used to create link-local addresses. An interface is required to have at least one link-local address, and the IID used to create that address must be different than the IIDs used to create link-local addresses on other interfaces on the same link (as required by the per-subnet uniqueness clause, and as checked by DAD). But it is not necessary, for example, to create link-local addresses with the randomly generated IIDs used to create privacy addresses. It is important for folks to understand what we are changing here, so please let me know if any of the above is confusing or unclear. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 08:27:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79FR13U026576; Fri, 9 Aug 2002 08:27:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79FR1uQ026575; Fri, 9 Aug 2002 08:27:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79FQs3U026565 for ; Fri, 9 Aug 2002 08:26:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09766 for ; Fri, 9 Aug 2002 08:27:03 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25317 for ; Fri, 9 Aug 2002 08:27:02 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 923AF4B22; Sat, 10 Aug 2002 00:26:54 +0900 (JST) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Fri, 09 Aug 2002 14:03:19 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Sat, 10 Aug 2002 00:26:54 +0900 Message-Id: <20020809152654.923AF4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> none of the above document specify what IPv6 MTU to use for these >> interfaces. (RFC3056 has a pointer to RFC2893, but RFC2893 has nothing >> about IPv6 MTU) > >I see these words in RFC 2893 which seem to be relevant to this issue: > The IPv6 layer in the encapsulating node 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. > >This is suggesting that the interface MTU for such a tunnel is dynamic >by being a function of the IPv4 path MTU across the tunnel. >A result of such behavior is that the initial MTU for such a tunnel >interface would be the interface MTUs for the underlying physical >interface for the tunnel, minus 20 bytes for the IPv4 header. > >But I take it from your question that you'd like to see a fixed number for >the MTU. Is this really necessary? yes, it definitely needs to be a fixed number. in other words, IPv6 link MTU should not be computed based on IPv4 PMTU (which is dynamic). PMTUD assumes that link MTUs are stable enough. by using IPv4 PMTU as basis for IPv6 link MTU, IPv6 link MTU will be affected by IPv4 routing changes. it will have negative impact to IPv6 PMTUD. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 08:37:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79FbK3U026614; Fri, 9 Aug 2002 08:37:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79FbK4c026613; Fri, 9 Aug 2002 08:37:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79FbF3U026606 for ; Fri, 9 Aug 2002 08:37:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12561 for ; Fri, 9 Aug 2002 08:37:24 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07811; Fri, 9 Aug 2002 08:37:24 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g79FbKG11425; Fri, 9 Aug 2002 08:37:20 -0700 (PDT) From: Bill Manning Message-Id: <200208091537.g79FbKG11425@boreas.isi.edu> Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: <20020809152654.923AF4B22@coconut.itojun.org> from "itojun@iijlab.net" at "Aug 10, 2 00:26:54 am" To: itojun@iijlab.net Date: Fri, 9 Aug 2002 08:37:20 -0700 (PDT) Cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % >But I take it from your question that you'd like to see a fixed number for % >the MTU. Is this really necessary? % % yes, it definitely needs to be a fixed number. in other words, IPv6 % link MTU should not be computed based on IPv4 PMTU (which is dynamic). % PMTUD assumes that link MTUs are stable enough. by using IPv4 PMTU % as basis for IPv6 link MTU, IPv6 link MTU will be affected by IPv4 % routing changes. it will have negative impact to IPv6 PMTUD. % % itojun for "cross-talk" to occur, is there a presumption of fate-sharing on links? e.g. do you presume that a single link will always support both v4 and v6? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 08:40:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Fe03U026642; Fri, 9 Aug 2002 08:40:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79Fe0eA026641; Fri, 9 Aug 2002 08:40:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Fdr3U026634 for ; Fri, 9 Aug 2002 08:39:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05532 for ; Fri, 9 Aug 2002 08:40:02 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17746 for ; Fri, 9 Aug 2002 09:40:01 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E605F4B23; Sat, 10 Aug 2002 00:39:51 +0900 (JST) To: Bill Manning Cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: bmanning's message of Fri, 09 Aug 2002 08:37:20 MST. <200208091537.g79FbKG11425@boreas.isi.edu> 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: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Sat, 10 Aug 2002 00:39:51 +0900 Message-Id: <20020809153951.E605F4B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > for "cross-talk" to occur, is there a presumption of fate-sharing > on links? e.g. do you presume that a single link will always > support both v4 and v6? no, i do not assume that. since this is a document about tunnelling, IPv4 path could be arbitrary (some of the paths could be IPv4-only of course) while IPv6 (over IPv4) is one-hop. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 08:41:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Ffm3U026672; Fri, 9 Aug 2002 08:41:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79Ffmfu026671; Fri, 9 Aug 2002 08:41:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Ffe3U026664 for ; Fri, 9 Aug 2002 08:41:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13642 for ; Fri, 9 Aug 2002 08:41:49 -0700 (PDT) From: Robert.Peschi@alcatel.be Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24680 for ; Fri, 9 Aug 2002 09:41:48 -0600 (MDT) Received: from bemail01.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g79Faom15554; Fri, 9 Aug 2002 17:36:50 +0200 Subject: Re: DAD vs. DIID To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Date: Fri, 9 Aug 2002 17:41:35 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/09/2002 17:41:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, Thank you for your clarification. I now get the point. > This change would modify the scope of that uniqueness > to be a subnet prefix, not the whole link. So, > within a set of interfaces using a particular > subnet prefix, the IID would identify a particular > interface. > > (..) > > OLD: IIDs are required to be unique on a link. > > NEW: Only complete addresses are required to > be unique on a link. > > Relaxing the restriction to the second case makes > the use of privacy addresses easier, I understand that there is no actual need to require /link IID uniqueness. Though, it is not entirely clear to me why the /subnet IID uniqueness rather than the /link uniqueness makes the case of privacy addresses easier. Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 08:42:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Fgi3U026692; Fri, 9 Aug 2002 08:42:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79Fgh0x026688; Fri, 9 Aug 2002 08:42:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79FgX3U026681 for ; Fri, 9 Aug 2002 08:42:34 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g79Fgcg26478; Fri, 9 Aug 2002 17:42:38 +0200 (MEST) Date: Fri, 9 Aug 2002 17:40:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 MTU for tunnel pseudo interfaces To: itojun@iijlab.net Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020809152654.923AF4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > yes, it definitely needs to be a fixed number. in other words, IPv6 > link MTU should not be computed based on IPv4 PMTU (which is dynamic). > PMTUD assumes that link MTUs are stable enough. I know of no such assumption. In fact PMTUD is designed deal with routing using different paths with different MTU over time (and even at the same time) by taking the minimum of the reported MTUs. Dealing with an interface which changes MTU falls out of that design for free. > by using IPv4 PMTU > as basis for IPv6 link MTU, IPv6 link MTU will be affected by IPv4 > routing changes. it will have negative impact to IPv6 PMTUD. What exactly is the negative impact? Using a dyanmic MTU for the tunnels has the positive impact of being able to send larger, thereby fewer, packets when the path supports the larger MTU. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 08:58:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Fwl3U027017; Fri, 9 Aug 2002 08:58:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79FwkeK027016; Fri, 9 Aug 2002 08:58:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Fwd3U027009 for ; Fri, 9 Aug 2002 08:58:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10905 for ; Fri, 9 Aug 2002 08:58:48 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14851 for ; Fri, 9 Aug 2002 08:58:47 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4352C4B22; Sat, 10 Aug 2002 00:58:39 +0900 (JST) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Fri, 09 Aug 2002 17:40:38 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Sat, 10 Aug 2002 00:58:39 +0900 Message-Id: <20020809155839.4352C4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> yes, it definitely needs to be a fixed number. in other words, IPv6 >> link MTU should not be computed based on IPv4 PMTU (which is dynamic). >> PMTUD assumes that link MTUs are stable enough. >I know of no such assumption. >In fact PMTUD is designed deal with routing using different paths with >different MTU over time (and even at the same time) by taking the minimum >of the reported MTUs. Dealing with an interface which changes MTU >falls out of that design for free. i haven't seen links that changes MTU (*1) dynamically based on dynamic changes from outside (*2). in this case (*1) is "IPv6 MTU on top of tunnel" and (*2) is "IPv4 routing changes". maybe my experience is limited, but anyway, i have never seen one. >> by using IPv4 PMTU >> as basis for IPv6 link MTU, IPv6 link MTU will be affected by IPv4 >> routing changes. it will have negative impact to IPv6 PMTUD. >What exactly is the negative impact? if link MTUs are not stable enough, there will be more ICMP too big than we desire. >Using a dyanmic MTU for the tunnels has the positive impact of being able >to send larger, thereby fewer, packets when the path supports the larger MTU. with the cost of complexity in tunnel endpoint implementations (needs to maintain IPv4 path MTU and reflect it to IPv6 tunnel link MTU). i would really like to know how many of existing implementations follow this part of RFC2983. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 09:04:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79G4v3U027079; Fri, 9 Aug 2002 09:04:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79G4v3C027078; Fri, 9 Aug 2002 09:04:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79G4p3U027071 for ; Fri, 9 Aug 2002 09:04:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20359 for ; Fri, 9 Aug 2002 09:05:01 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24450 for ; Fri, 9 Aug 2002 09:05:01 -0700 (PDT) Received: from kenawang ([147.11.233.33]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA02440; Fri, 9 Aug 2002 09:04:42 -0700 (PDT) Message-Id: <4.2.2.20020809115738.017bb3c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 09 Aug 2002 12:05:14 -0400 To: Robert.Peschi@alcatel.be From: Margaret Wasserman Subject: Re: DAD vs. DIID Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, >Though, it is not entirely clear to me why >the /subnet IID uniqueness rather than the /link >uniqueness makes the case of privacy addresses easier. To ensure IID uniqueness on a link, a node that implements privacy addresses would need to generate a link-local address for each randomly generated IID (in addition to the global address generated for privacy), perform DAD on that address, and maintain that address for the lifetime of the privacy address in order to respond to other nodes' DAD messages. If we only require IIDs to be unique within a subnet, a node that implements privacy addresses will only need to generate the single privacy address and perform DAD for that address. As currently document (prior to the discussed changes) the privacy document is incompatible, in this minor way, with the addressing architecture and the autoconfiguration documents. We had two options for what to change: - Relax the uniqueness restriction in the addressing architecture, and make a corresponding change to the autoconfiguration document. -OR- - Modify the privacy address document to require the creation and maintenance of link-local addresses, as described above. We had a consensus within the room in Yokohama to choose the first option, and we are currently checking that consenus with the list. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 09:45:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Gjp3U027163; Fri, 9 Aug 2002 09:45:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79GjpaX027162; Fri, 9 Aug 2002 09:45:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Gji3U027155 for ; Fri, 9 Aug 2002 09:45:45 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g79Gjog02373; Fri, 9 Aug 2002 18:45:50 +0200 (MEST) Date: Fri, 9 Aug 2002 18:43:51 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 MTU for tunnel pseudo interfaces To: itojun@iijlab.net Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020809155839.4352C4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i haven't seen links that changes MTU (*1) dynamically based on > dynamic changes from outside (*2). in this case (*1) is "IPv6 MTU > on top of tunnel" and (*2) is "IPv4 routing changes". > maybe my experience is limited, but anyway, i have never seen one. I having a hard time parsing this regular expression. Looking at the definitions in RFC 2460 and 1981 I see it clearly: link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one piece over a link. When the link is a tunnel the link MTU is defined to effectively vary based on the path MTU of that tunnel, since different size packets can be conveyed in one piece over the tunnel at different points in time. > if link MTUs are not stable enough, there will be more ICMP too big > than we desire. Please provide an analysis. I don't think this is the case. The time limit for when an path MTU increase is attempted (10 minutes by default in RFC 1981) limits this whether the potential for increase is for a tunnel link (due to IPv4 routing changes) or due to IPv6 routing using a different set of links. When the path MTU decreases (for a tunnel link, or due to IPv6 routing using a different set of links) a single ICMP too big is sufficient. (Of course, if there is a window full of large packets you might see more than one subject to ICMP error rate limiting.) The point is that I don't see why there should be anything new here for tunneling. The tradeoffs for path MTU discovery are: - downside of ICMP error packets - downside of additional roundtrip times due to the data packets being lost when the packet is to big - the benefit of making the retransmission unit the same as the loss unit, while being able to with larger packets If this tradeoff comes up with PMTUD makes sense when there is no tunneling, then I don't see why the same conclusion doesn't hold for the case of nested PMTUD using tunnels. So I'm looking forward to your performance analysis. > with the cost of complexity in tunnel endpoint implementations (needs > to maintain IPv4 path MTU and reflect it to IPv6 tunnel link MTU). Yes. And there is additional complexity to implement PMTUD in the non-tunneling case. Thus I think your arguments about performance and implementation complexity can also be used to argue that we shouldn't do PMTUD at all and instead send with 1280 bytes. FWIW The Solaris implementation doesn't have soft state in the tunneling pseudo-device driver. It is all reflected in the conceptual neighbor cache for the "upper IP layer" when an ICMP too big arrives from the "lower IP layer". > i would really like to know how many of existing implementations follow > this part of RFC2983. Solaris does. I might also make sense to ask what folks do that have IPv4 in IPv4 IPsec tunnels. I *think* (but am far from certain) that the disadvantage of doubling the number of packet due to the packets with the IP+ESP headers being too big means that it is common for such implementions to reflect PMTU up through the tunnelong pseudo interface. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 09:49:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Gns3U027180; Fri, 9 Aug 2002 09:49:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79Gnsxn027179; Fri, 9 Aug 2002 09:49:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Gnm3U027172 for ; Fri, 9 Aug 2002 09:49:49 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g79Gnsg02820; Fri, 9 Aug 2002 18:49:54 +0200 (MEST) Date: Fri, 9 Aug 2002 18:47:55 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 MTU for tunnel pseudo interfaces To: Erik Nordmark Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I having a hard time parsing this regular expression. I'm also having a hard time writing :-) I meant to say I'm having a hard time parsing this regular expression :-) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 09:53:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79GrH3U027208; Fri, 9 Aug 2002 09:53:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79GrHRR027207; Fri, 9 Aug 2002 09:53:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79GrB3U027200 for ; Fri, 9 Aug 2002 09:53:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08073 for ; Fri, 9 Aug 2002 09:53:21 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09935 for ; Fri, 9 Aug 2002 10:53:20 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 9 Aug 2002 09:53:20 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FC5.43EEBAA9" Subject: RE: IPv6 MTU for tunnel pseudo interfaces x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Date: Fri, 9 Aug 2002 09:53:20 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF233@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 MTU for tunnel pseudo interfaces Thread-Index: AcI/vj+83qy6bvQySN2cFPuj85f5agABVuoQ From: "Mohan Parthasarathy" To: , "Erik Nordmark" Cc: X-OriginalArrivalTime: 09 Aug 2002 16:53:20.0366 (UTC) FILETIME=[441D18E0:01C23FC5] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C23FC5.43EEBAA9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 > >> yes, it definitely needs to be a fixed number. in=20 > other words, IPv6 > >> link MTU should not be computed based on IPv4 PMTU=20 > (which is dynamic). > >> PMTUD assumes that link MTUs are stable enough. > >I know of no such assumption. > >In fact PMTUD is designed deal with routing using different=20 > paths with=20 > >different MTU over time (and even at the same time) by taking the=20 > >minimum of the reported MTUs. Dealing with an interface=20 > which changes=20 > >MTU falls out of that design for free. >=20 > i haven't seen links that changes MTU (*1) dynamically based on > dynamic changes from outside (*2). in this case (*1)=20 > is "IPv6 MTU > on top of tunnel" and (*2) is "IPv4 routing changes". > maybe my experience is limited, but anyway, i have=20 > never seen one. >=20 How about IPsec on the IPv4 path ? > >> by using IPv4 PMTU > >> as basis for IPv6 link MTU, IPv6 link MTU will be=20 > affected by IPv4 > >> routing changes. it will have negative impact to IPv6 PMTUD. > >What exactly is the negative impact? >=20 > if link MTUs are not stable enough, there will be more=20 > ICMP too big > than we desire. >=20 > >Using a dyanmic MTU for the tunnels has the positive impact of being=20 > >able to send larger, thereby fewer, packets when the path=20 > supports the=20 > >larger MTU. >=20 > with the cost of complexity in tunnel endpoint=20 > implementations (needs > to maintain IPv4 path MTU and reflect it to IPv6 tunnel=20 > link MTU). > i would really like to know how many of existing=20 > implementations follow > this part of RFC2983. >=20 At a minimum, implementations should be able to convert the=20 ICMP errors happening from within the IPv4 tunnel back to ICMPV6 error and send it back to the original sender (IPv6 sender in case of IPv6 over IPv4 tunnels). Otherwise path mtu discovery will never work assuming you set the DF bit in the IPv4 header. if you do this, storing the state is not really complex I guess. -mohan > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- >=20 ------_=_NextPart_001_01C23FC5.43EEBAA9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: IPv6 MTU for tunnel pseudo interfaces

 
> >>    yes, it definitely needs = to be a fixed number.  in
> other words, IPv6
> >>    link MTU should not be = computed based on IPv4 PMTU
> (which is dynamic).
> >>    PMTUD assumes that link = MTUs are stable enough.
> >I know of no such assumption.
> >In fact PMTUD is designed deal with routing = using different
> paths with
> >different MTU over time (and even at the = same time) by taking the
> >minimum of the reported MTUs. Dealing with = an interface
> which changes
> >MTU falls out of that design for = free.
>
>       i haven't seen = links that changes MTU (*1) dynamically based on
>       dynamic changes = from outside (*2).  in this case (*1)
> is "IPv6 MTU
>       on top of = tunnel" and (*2) is "IPv4 routing changes".
>       maybe my = experience is limited, but anyway, i have
> never seen one.
>

How about IPsec on the IPv4 path ?

> >>       by = using IPv4 PMTU
> >>    as basis for IPv6 link = MTU, IPv6 link MTU will be
> affected by IPv4
> >>    routing changes.  it = will have negative impact to IPv6 PMTUD.
> >What exactly is the negative impact?
>
>       if link MTUs are = not stable enough, there will be more
> ICMP too big
>       than we = desire.
>
> >Using a dyanmic MTU for the tunnels has the = positive impact of being
> >able to send larger, thereby fewer, packets = when the path
> supports the
> >larger MTU.
>
>       with the cost of = complexity in tunnel endpoint
> implementations (needs
>       to maintain IPv4 = path MTU and reflect it to IPv6 tunnel
> link MTU).
>       i would really = like to know how many of existing
> implementations follow
>       this part of = RFC2983.
>
At a minimum, implementations should be able to = convert the
ICMP errors happening from within the IPv4 tunnel = back to
ICMPV6 error and send it back to the original sender = (IPv6 sender
in case of IPv6 over IPv4 tunnels). Otherwise path = mtu
discovery will never work assuming you set the DF bit = in
the IPv4 header. if you do this, storing the = state
is not really complex I guess.

-mohan

> itojun
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &n= bsp;          http://playground.sun.com/ipng
> FTP = archive:           = ;          
ftp://playground.sun.com/pub/i= png
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C23FC5.43EEBAA9-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 09:53:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Grw3U027229; Fri, 9 Aug 2002 09:53:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79Grwpm027228; Fri, 9 Aug 2002 09:53:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Gro3U027221 for ; Fri, 9 Aug 2002 09:53:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08274 for ; Fri, 9 Aug 2002 09:54:00 -0700 (PDT) Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23410 for ; Fri, 9 Aug 2002 09:54:00 -0700 (PDT) Received: from repligate ([67.36.187.80]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020809165359.UWRL21716.mail1-0.chcgil.ameritech.net@repligate>; Fri, 9 Aug 2002 11:53:59 -0500 Message-ID: <0d4201c23fc5$768f3880$8c56fea9@repligate> From: "Jim Fleming" To: "Erik Nordmark" Cc: , References: Subject: Re: IPv6 MTU for tunnel pseudo interfaces Date: Fri, 9 Aug 2002 11:54:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Erik Nordmark" > > I meant to say > I'm having a hard time parsing this regular expression :-) > http://www.rebol.com/ C@t will be back... Jim Fleming 2002:[IPv4]:000X:03DB http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 10:17:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79HHw3U027313; Fri, 9 Aug 2002 10:17:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79HHvMh027312; Fri, 9 Aug 2002 10:17:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79HHq3U027305 for ; Fri, 9 Aug 2002 10:17:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06588 for ; Fri, 9 Aug 2002 10:17:59 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08504 for ; Fri, 9 Aug 2002 10:17:58 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA20716; Fri, 9 Aug 2002 20:17:46 +0300 Date: Fri, 9 Aug 2002 20:17:46 +0300 Message-Id: <200208091717.UAA20716@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com In-reply-to: <4.2.2.20020809115738.017bb3c0@mail.windriver.com> (message from Margaret Wasserman on Fri, 09 Aug 2002 12:05:14 -0400) Subject: Re: DAD vs. DIID References: <4.2.2.20020809115738.017bb3c0@mail.windriver.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Margaret Wasserman > To ensure IID uniqueness on a link, a node that implements > privacy addresses would need to generate a link-local > address for each randomly generated IID (in addition to the > global address generated for privacy), perform DAD on > that address, and maintain that address for the lifetime > of the privacy address in order to respond to other nodes' > DAD messages. Well, that is only one possible implemetation. Another way, when node sees DAD with ID part matching any of the nodes ID's, it can act as if it had the address and defend it (note: this is ONLY with DAD probes, for normal NS it replies only if address is actually configured as whole). This solution does not need actual generation of link local address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 15:28:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79MSU3U028208; Fri, 9 Aug 2002 15:28:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79MSTu9028207; Fri, 9 Aug 2002 15:28:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79MSN3U028200 for ; Fri, 9 Aug 2002 15:28:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21000 for ; Fri, 9 Aug 2002 15:28:33 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19206 for ; Fri, 9 Aug 2002 16:28:32 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA22024 for ; Fri, 9 Aug 2002 15:28:32 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79MSVn10312; Fri, 9 Aug 2002 15:28:31 -0700 X-mProtect: <200208092228> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkOTwIk; Fri, 09 Aug 2002 15:28:26 PDT Message-Id: <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Aug 2002 15:27:15 -0700 To: IPv6 List From: Bob Hinden Subject: Changes to IPv6 Addressing Architecture Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At the IPv6 working group sessions at the Yokohama IETF two changes to the IP Version 6 Addressing Architecture draft were discussed. These changes were proposed based on feedback received from our area director and email discussion on the mailing list. A summary of the AD comments is include at the end of the email. The changes that were proposed at the meeting were to relax the interface identifier uniqueness requirements (from the link to subnet prefix) and to change the definition of Site-Local addresses to make the subnet field 54-bits (and eliminate the 38-bit zero field). After discussing the proposed changes, a consensus was reached at the Yokohama meeting to make them. The purpose of this email is to validate that consensus on the mailing list and to review the specific changes to the internet draft. The proposed changes (changed lines marked by "|") to the ID are as follows: Change to second sentence in the first paragraph of section 2.5.1: Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet | prefix. They may also be unique over a broader scope. In some cases | an interface's identifier will be derived directly from that interface's link-layer address. The same interface identifier may be used on multiple interfaces on a single node, as long as they are attached to different links. and from section 2.5.6 where site-local is defined: Site-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111011| subnet ID | interface ID | | +----------+-------------------------+----------------------------+ Site-local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Although a subnet ID may | be up to 54-bits long, it is expected that most globally-connected | sites will use the same subnet IDs for site-local and global prefixes. | If there is agreement with these changes I will submit a new draft (-09) that the area directors can proceed with. Bob ------------------------------------------------------------------- Comments from Thomas Narten: >1) The -07 ID contains the wording: > > > Interface identifiers in IPv6 unicast addresses are used to identify > > interfaces on a link. They are required to be unique on that link. > >Given the on-going issues surrounding DAD vs DIID, I felt it >appropriate to check with the WG whether this wording was indeed what >the WG believed the architecture should require. > >2) The -07 ID contains the wording: > > > Site-Local addresses have the following format: > > > > | 10 | > > | bits | 38 bits | 16 bits | 64 bits | > > +----------+-------------+-----------+----------------------------+ > > |1111111011| 0 | subnet ID | interface ID | > > +----------+-------------+-----------+----------------------------+ > >Given that the fixed 16-bit subnet ID in global addresses was changed >to one having a flexible boundary, the subnet ID in site-locals should >also not have a fixed boundary. Note that other parts of the document >showing addresses were updated to use generic "m" bits, rather than >fixing the field at 16 bits, under the concern that implementations >*might* somehow hardcode the boundary in their implementations. > >Also, it might be good to clarify that the middle bits are undefined >and should be 0. I.e., implementors could interpret the above words as >saying the bits are defined to always be zero (as opposed to just >reserved for future use and MUST be zero), which could lead >implementations to somehow check that those bits are 0, and if not, do >something incorrect (like signal an error). > >The specific text that was proposed and discussed at the Yokohama >meeting addresses the main concern I had. > >At the meeting, there were still some folks that seemed unhappy with >the proposed change. I'd be interested in understand why. Only itojun >spoke up on this point, and he stated this would make site-local >addresses more attractive, which he didn't consider a feature. :-) > >Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 15:34:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79MYI3U028225; Fri, 9 Aug 2002 15:34:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79MYIQa028224; Fri, 9 Aug 2002 15:34:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79MYC3U028217 for ; Fri, 9 Aug 2002 15:34:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25283 for ; Fri, 9 Aug 2002 15:34:22 -0700 (PDT) Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25173 for ; Fri, 9 Aug 2002 15:34:21 -0700 (PDT) Received: from repligate ([67.36.184.14]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020809223420.HKAQ18992.mailhost.chi1.ameritech.net@repligate>; Fri, 9 Aug 2002 17:34:20 -0500 Message-ID: <0ec801c23ff4$e7a62270$8c56fea9@repligate> From: "Jim Fleming" To: "IPv6 List" , "Bob Hinden" Cc: References: <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> Subject: Re: Changes to IPv6 Addressing Architecture Draft Date: Fri, 9 Aug 2002 17:34:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Has the ICANN Board and staff approved this ? Jim Fleming 2002:[IPv4]:000X:03DB http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ----- Original Message ----- From: "Bob Hinden" To: "IPv6 List" Sent: Friday, August 09, 2002 5:27 PM Subject: Changes to IPv6 Addressing Architecture Draft > > At the IPv6 working group sessions at the Yokohama IETF two changes to the > IP Version 6 Addressing Architecture draft > > > > were discussed. These changes were proposed based on feedback received > from our area director and email discussion on the mailing list. A summary > of the AD comments is include at the end of the email. > > The changes that were proposed at the meeting were to relax the interface > identifier uniqueness requirements (from the link to subnet prefix) and to > change the definition of Site-Local addresses to make the subnet field > 54-bits (and eliminate the 38-bit zero field). > > After discussing the proposed changes, a consensus was reached at the > Yokohama meeting to make them. The purpose of this email is to validate > that consensus on the mailing list and to review the specific changes to > the internet draft. > > The proposed changes (changed lines marked by "|") to the ID are as follows: > > Change to second sentence in the first paragraph of section 2.5.1: > > Interface identifiers in IPv6 unicast addresses are used to identify > interfaces on a link. They are required to be unique within a subnet | > prefix. They may also be unique over a broader scope. In some cases | > an interface's identifier will be derived directly from that > interface's link-layer address. The same interface identifier may be > used on multiple interfaces on a single node, as long as they are > attached to different links. > > and from section 2.5.6 where site-local is defined: > > Site-Local addresses have the following format: > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111011| subnet ID | interface ID | | > +----------+-------------------------+----------------------------+ > > Site-local addresses are designed to be used for addressing inside of > a site without the need for a global prefix. Although a subnet ID may | > be up to 54-bits long, it is expected that most globally-connected | > sites will use the same subnet IDs for site-local and global prefixes. | > > > If there is agreement with these changes I will submit a new draft (-09) > that the area directors can proceed with. > > Bob > > ------------------------------------------------------------------- > > Comments from Thomas Narten: > > >1) The -07 ID contains the wording: > > > > > Interface identifiers in IPv6 unicast addresses are used to identify > > > interfaces on a link. They are required to be unique on that link. > > > >Given the on-going issues surrounding DAD vs DIID, I felt it > >appropriate to check with the WG whether this wording was indeed what > >the WG believed the architecture should require. > > > >2) The -07 ID contains the wording: > > > > > Site-Local addresses have the following format: > > > > > > | 10 | > > > | bits | 38 bits | 16 bits | 64 bits | > > > +----------+-------------+-----------+----------------------------+ > > > |1111111011| 0 | subnet ID | interface ID | > > > +----------+-------------+-----------+----------------------------+ > > > >Given that the fixed 16-bit subnet ID in global addresses was changed > >to one having a flexible boundary, the subnet ID in site-locals should > >also not have a fixed boundary. Note that other parts of the document > >showing addresses were updated to use generic "m" bits, rather than > >fixing the field at 16 bits, under the concern that implementations > >*might* somehow hardcode the boundary in their implementations. > > > >Also, it might be good to clarify that the middle bits are undefined > >and should be 0. I.e., implementors could interpret the above words as > >saying the bits are defined to always be zero (as opposed to just > >reserved for future use and MUST be zero), which could lead > >implementations to somehow check that those bits are 0, and if not, do > >something incorrect (like signal an error). > > > >The specific text that was proposed and discussed at the Yokohama > >meeting addresses the main concern I had. > > > >At the meeting, there were still some folks that seemed unhappy with > >the proposed change. I'd be interested in understand why. Only itojun > >spoke up on this point, and he stated this would make site-local > >addresses more attractive, which he didn't consider a feature. :-) > > > >Thomas > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 17:47:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7A0lf3U028367; Fri, 9 Aug 2002 17:47:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7A0lfuY028366; Fri, 9 Aug 2002 17:47:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7A0lY3U028359 for ; Fri, 9 Aug 2002 17:47:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25746 for ; Fri, 9 Aug 2002 17:47:43 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13627 for ; Fri, 9 Aug 2002 18:47:41 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 44B754B25; Sat, 10 Aug 2002 09:47:34 +0900 (JST) To: "Mohan Parthasarathy" Cc: "Erik Nordmark" , ipng@sunroof.eng.sun.com In-reply-to: mohanp's message of Fri, 09 Aug 2002 09:53:20 MST. <416B5AF360DED54088DAD3CA8BFBEA6E1DF233@TNEXVS02.tahoenetworks.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: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Sat, 10 Aug 2002 09:47:34 +0900 Message-Id: <20020810004734.44B754B25@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >At a minimum, implementations should be able to convert the=20 >ICMP errors happening from within the IPv4 tunnel back to >ICMPV6 error and send it back to the original sender (IPv6 sender >in case of IPv6 over IPv4 tunnels). Otherwise path mtu >discovery will never work assuming you set the DF bit in >the IPv4 header. if you do this, storing the state >is not really complex I guess. if you don't set DF bit on IPv4 packet (after encapsulation), it is not mandatory to convert ICMPv4 to ICMPv6 (actually, you won't see ICMPv4 need fragment). simpler the better. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 21:18:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7A4I03U028846; Fri, 9 Aug 2002 21:18:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7A4I0EV028845; Fri, 9 Aug 2002 21:18:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7A4Ht3U028838 for ; Fri, 9 Aug 2002 21:17:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10753 for ; Fri, 9 Aug 2002 21:18:03 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12872 for ; Fri, 9 Aug 2002 21:18:02 -0700 (PDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Fri, 9 Aug 2002 21:18:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E265@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt thread-index: AcI9NJiZVtoUCn5ARU+kxC72E3Sm2AC70Wgw From: "Michel Py" To: "Robert Elz" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7A4Ht3U028839 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, What you are calling for (quoted below) is lots of changes. With that many deletions, one might say that it could be wiser to re-write [addrarch] entirely. Note that I don't oppose the idea and I acknowledge that you do have very good points, but WRT what Margaret mentioned earlier about consensus, do you think you can rally the WG behind these proposed changes? Michel. -----Original Message----- From: Robert Elz Sent: Tuesday, August 06, 2002 3:27 AM To: Thomas Narten Cc: Margaret Wasserman; Elwyn Davies; ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Mon, 05 Aug 2002 16:06:45 -0400 From: Thomas Narten Message-ID: <200208052006.g75K6kB28220@rotala.raleigh.ibm.com> | They better not be doing this. We have been over this territory a | number of times already, with some folks arguing only a misreading of | the spec would allow one to conclude that prefixes cannot be longer | than /64, There's no need to argue this (any more anyway), there are any number of messages on this (I think) and certainly other (like the 6bone) lists which state that as an absolute incontrovertible fact (no prefix length longer than 64 is allowed) - and quote the addr arch doc (and the latest draft) as justification. We really need to fix that - and also get rid of the other odds and ends in that draft thats imply make no sense when prefixes longer than 64 are being used. | If anyone thinks this is still an issue, it would be good to point out | the specific text that is believed to be unclear and suggest | replacement wording. OK (though I'm not sure "unclear" is the right description)... All this relates to draft-ietf-ipngwg-addr-arch-v3-08.txt naturally (the version dated June 29, 2002, so I believe it is the most current). The para (near the end of page 8): For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. should simply be deleted. No replacement required. Then the last line on page 8, and continuing into page 9: Modified EUI-64 format based Interface identifiers may have global scope when derived from a global token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.) or where global tokens are undesirable (e.g., temporary tokens for privacy [PRIV]). should also be deleted. No replacement is required. Then, next paragraph Modified EUI-64 format interface identifiers are formed by inverting the "u" bit (universal/local bit in IEEE EUI-64 terminology) when forming the interface identifier from IEEE EUI-64 identifiers. In the resulting Modified EUI-64 format the "u" bit is set to one (1) to indicate global scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an IEEE EUI-64 identifier are as follows: Delete the 2nd sentence, no replacement required. That leaves... Modified EUI-64 format interface identifiers are formed by inverting the "u" bit (universal/local bit in IEEE EUI-64 terminology) when forming the interface identifier from IEEE EUI-64 identifiers. The first three octets in binary of an IEEE EUI-64 identifier are as follows: Then, lower down on page 9, the paragraph The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with global scope. should simply be deleted. No replacement is required. This is perhaps the worst of everything in the draft, no matter what happens to the rest, that paragraph simply has to be deleted. This is the "we have no idea what we're going to do with this, but we are going to define it anyway" (and while doing so, ignore the fact that lots of people are ignoring us) approach. Next, at the end of page 10 (sect 2.5.4) spanning onto page 11 ... All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field. should simply be deleted. No replacement is required. The paragraph following that one would then look rather out of context (though nothing it contains is objectionable), so I would delete that one as well, it isn't required for anything. The rest of the draft is all very careful to express things in terms of variables (n m etc) and is all fine. | However, it is true that there are some places where /64 is in fact | not changable in practice (without very significant upheaval in | well-established documents). You cannot do stateless addrconf on an | Ethernet (or FDDI, or any other typical LAN) with a prefix other than | /64. I view this as a reasonable engineering compromise between an | number of tradeoffs (but won't attempt to list them here). Absolutely. That's just fine, and I don't think anyone is suggesting changing that. If you know that the link is an ethernet (etc), then you are going to have a pretty good idea that the prefix length is 64. But if you have no idea what kind of link an address happens to be connected to (so you are clearly neither the node owning the address, nor connected to the same prefix, nor the local network manager) then why should you care? Eg: munnari.oz.au's IPv6 addr (the advertised one anyway) is 2001:388:c02:4000::1:21 Do you want to guess what kind of link that is connected to, and what its prefix length happens to be ??? Is there any rational reason at all that you're ever going to care? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 9 21:45:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7A4jh3U028899; Fri, 9 Aug 2002 21:45:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7A4jhbI028898; Fri, 9 Aug 2002 21:45:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7A4jb3U028891 for ; Fri, 9 Aug 2002 21:45:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA02342 for ; Fri, 9 Aug 2002 21:45:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04794 for ; Fri, 9 Aug 2002 22:45:45 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7A4fKR18840; Fri, 9 Aug 2002 21:41:20 -0700 (PDT) From: Bill Manning Message-Id: <200208100441.g7A4fKR18840@boreas.isi.edu> Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <2B81403386729140A3A899A8B39B046405E265@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Aug 9, 2 09:18:01 pm" To: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 9 Aug 2002 21:41:20 -0700 (PDT) Cc: kre@munnari.OZ.AU, mrw@windriver.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk well Michael, the wg has a choice: proceed w/ the arch doc as defined, disenfranchising operators and the spirit of the original design goals. or. make changes to the arch doc based on operational experience. one choice will keep the IETF work relevent to operations, the other choice less so. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 05:42:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ACge3U029810; Sat, 10 Aug 2002 05:42:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7ACgevf029809; Sat, 10 Aug 2002 05:42:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ACgY3U029802 for ; Sat, 10 Aug 2002 05:42:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19978 for ; Sat, 10 Aug 2002 05:42:43 -0700 (PDT) Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27841 for ; Sat, 10 Aug 2002 05:42:43 -0700 (PDT) Received: from repligate ([67.36.184.14]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020810124242.SCMN18992.mailhost.chi1.ameritech.net@repligate> for ; Sat, 10 Aug 2002 07:42:42 -0500 Message-ID: <107101c2406b$6dc60ed0$8c56fea9@repligate> From: "Jim Fleming" To: Subject: Fw: [Admin] Warning (was: Re: [ga] 0:212 IPv8 Recommended .BIZ Registras) Date: Sat, 10 Aug 2002 07:42:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Alexander Svensson" To: "Jim Fleming" Cc: "GA List Monitoring" Sent: Saturday, August 10, 2002 6:55 AM Subject: [Admin] Warning (was: Re: [ga] 0:212 IPv8 Recommended .BIZ Registras) > > Jim, > > please keep in mind that this is a forum for DNSO work, > decidedly *not* a place to post registrar recommendations > and *not* a place for extensive discussion of the > address space (to discuss this, go to aso-policy@aso.icann.org). > Please to be warned that off-topic postings are violating > the list rules and can lead to a suspension of posting > rights. > > Regards, > /// GA List Monitor > > At 09.08.2002 17:34, Jim Fleming wrote: > >Has the ICANN Board and staff approved this ? > > > >Jim Fleming > >2002:[IPv4]:000X:03DB > >http://www.iana.org/assignments/ipv4-address-space > >http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > > > > >----- Original Message ----- > >From: "Bob Hinden" > >To: "IPv6 List" > >Sent: Friday, August 09, 2002 5:27 PM > >Subject: Changes to IPv6 Addressing Architecture Draft > > > > > >> > >> At the IPv6 working group sessions at the Yokohama IETF two changes to the > >> IP Version 6 Addressing Architecture draft > >> > >> > >> > >> were discussed. These changes were proposed based on feedback received > >> from our area director and email discussion on the mailing list. A summary > >> of the AD comments is include at the end of the email. > >> > >> The changes that were proposed at the meeting were to relax the interface > >> identifier uniqueness requirements (from the link to subnet prefix) and to > >> change the definition of Site-Local addresses to make the subnet field > >> 54-bits (and eliminate the 38-bit zero field). > >> > >> After discussing the proposed changes, a consensus was reached at the > >> Yokohama meeting to make them. The purpose of this email is to validate > >> that consensus on the mailing list and to review the specific changes to > >> the internet draft. > >> > >> The proposed changes (changed lines marked by "|") to the ID are as follows: > >> > >> Change to second sentence in the first paragraph of section 2.5.1: > >> > >> Interface identifiers in IPv6 unicast addresses are used to identify > >> interfaces on a link. They are required to be unique within a subnet | > >> prefix. They may also be unique over a broader scope. In some cases | > >> an interface's identifier will be derived directly from that > >> interface's link-layer address. The same interface identifier may be > >> used on multiple interfaces on a single node, as long as they are > >> attached to different links. > >> > >> and from section 2.5.6 where site-local is defined: > >> > >> Site-Local addresses have the following format: > >> > >> | 10 | > >> | bits | 54 bits | 64 bits | > >> +----------+-------------------------+----------------------------+ > >> |1111111011| subnet ID | interface ID | | > >> +----------+-------------------------+----------------------------+ > >> > >> Site-local addresses are designed to be used for addressing inside of > >> a site without the need for a global prefix. Although a subnet ID may | > >> be up to 54-bits long, it is expected that most globally-connected | > >> sites will use the same subnet IDs for site-local and global prefixes. | > >> > >> > >> If there is agreement with these changes I will submit a new draft (-09) > >> that the area directors can proceed with. > >> > >> Bob > >> > >> ------------------------------------------------------------------- > >> > >> Comments from Thomas Narten: > >> > >> >1) The -07 ID contains the wording: > >> > > >> > > Interface identifiers in IPv6 unicast addresses are used to identify > >> > > interfaces on a link. They are required to be unique on that link. > >> > > >> >Given the on-going issues surrounding DAD vs DIID, I felt it > >> >appropriate to check with the WG whether this wording was indeed what > >> >the WG believed the architecture should require. > >> > > >> >2) The -07 ID contains the wording: > >> > > >> > > Site-Local addresses have the following format: > >> > > > >> > > | 10 | > >> > > | bits | 38 bits | 16 bits | 64 bits | > >> > > +----------+-------------+-----------+----------------------------+ > >> > > |1111111011| 0 | subnet ID | interface ID | > >> > > +----------+-------------+-----------+----------------------------+ > >> > > >> >Given that the fixed 16-bit subnet ID in global addresses was changed > >> >to one having a flexible boundary, the subnet ID in site-locals should > >> >also not have a fixed boundary. Note that other parts of the document > >> >showing addresses were updated to use generic "m" bits, rather than > >> >fixing the field at 16 bits, under the concern that implementations > >> >*might* somehow hardcode the boundary in their implementations. > >> > > >> >Also, it might be good to clarify that the middle bits are undefined > >> >and should be 0. I.e., implementors could interpret the above words as > >> >saying the bits are defined to always be zero (as opposed to just > >> >reserved for future use and MUST be zero), which could lead > >> >implementations to somehow check that those bits are 0, and if not, do > >> >something incorrect (like signal an error). > >> > > >> >The specific text that was proposed and discussed at the Yokohama > >> >meeting addresses the main concern I had. > >> > > >> >At the meeting, there were still some folks that seemed unhappy with > >> >the proposed change. I'd be interested in understand why. Only itojun > >> >spoke up on this point, and he stated this would make site-local > >> >addresses more attractive, which he didn't consider a feature. :-) > >> > > >> >Thomas > >> > >> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPng Working Group Mailing List > >> IPng Home Page: http://playground.sun.com/ipng > >> FTP archive: ftp://playground.sun.com/pub/ipng > >> Direct all administrative requests to majordomo@sunroof.eng.sun.com > >> -------------------------------------------------------------------- > > > >-- > >This message was passed to you via the ga@dnso.org list. > >Send mail to majordomo@dnso.org to unsubscribe > >("unsubscribe ga" in the body of the message). > >Archives at http://www.dnso.org/archives.html > > At 09.08.2002 16:24, Jim Fleming wrote: > >http://www.thepricedomain.com/index.php?domainlist=biz > >http://www.Powerpipe.com $7.99 > >http://www.10-Domains.com $9.00 > >http://www.WebHero.com $9.95 > >http://www.RegisterFly.com $9.99 > >http://www.iaregistry.com $11.95 > >http://www.totalregistrations.com $12.00 > >http://www.namesecure.com $12.00 > >http://www.domaininvestigator.com $12.47 > > > >Registra...Registry...Registrar...Reseller...Webmaster...Customer > > > >Jim Fleming > >2002:[IPv4]:000X:03DB > >http://www.iana.org/assignments/ipv4-address-space > >http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > > > > > > >-- > >This message was passed to you via the ga@dnso.org list. > >Send mail to majordomo@dnso.org to unsubscribe > >("unsubscribe ga" in the body of the message). > >Archives at http://www.dnso.org/archives.html > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 05:55:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ACsx3U029834; Sat, 10 Aug 2002 05:54:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7ACsxEo029833; Sat, 10 Aug 2002 05:54:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ACsr3U029826 for ; Sat, 10 Aug 2002 05:54:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21878 for ; Sat, 10 Aug 2002 05:55:02 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00499 for ; Sat, 10 Aug 2002 05:55:02 -0700 (PDT) Received: from kenawang ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA09070; Sat, 10 Aug 2002 05:54:40 -0700 (PDT) Message-Id: <4.2.2.20020810085310.02248b10@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 10 Aug 2002 08:55:21 -0400 To: Erik Nordmark From: Margaret Wasserman Subject: Re: IPv6 MTU for tunnel pseudo interfaces Cc: itojun@iijlab.net, Pekka Savola , ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <20020808064949.85C2A4B24@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, There are many implementations that don't have the ability to reassemble a 65,353 byte packet, at least not without allocating a 64K buffer for this purpose. So, this seems to be a harsh restriction to place on RFC 2893 implementations. If we need to choose one or the other, I'd prefer limiting the MTU of these tunnels to 1280. Margaret At 08:10 AM 8/9/02 , Erik Nordmark wrote: > > since there's no standard, some implementation can be picky and > > assume MRU == MTU. maybe RFC2893 should talk more about MRU and MTU. > >How about: > A node implementing RFC 2893 MUST be able to reassemble IPv4 packets > of a size up to and including 65353 octets and MUST NOT place > any limits on the size of the received encapsulated packets. > In particular, it MUST NOT assume that the maximum size of > received packets has anything to do with the MTU for the tunnel. > >Of course, it might also make sense to add some SHOULD (or MUST?) to >section 3.2 in RFC 2893 to make IPv4 MTU discovery across the tunnel >seem less optional than what the current text says. > > Erik > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 06:50:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ADo43U029910; Sat, 10 Aug 2002 06:50:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7ADo4Pi029909; Sat, 10 Aug 2002 06:50:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ADnx3U029902 for ; Sat, 10 Aug 2002 06:49:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18775 for ; Sat, 10 Aug 2002 06:50:07 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10155; Sat, 10 Aug 2002 06:50:05 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7ADns323925; Sat, 10 Aug 2002 16:49:55 +0300 Date: Sat, 10 Aug 2002 16:49:54 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: Erik Nordmark , , Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: <4.2.2.20020810085310.02248b10@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 10 Aug 2002, Margaret Wasserman wrote: > There are many implementations that don't have the ability to > reassemble a 65,353 byte packet, at least not without allocating > a 64K buffer for this purpose. So, this seems to be a harsh > restriction to place on RFC 2893 implementations. > > If we need to choose one or the other, I'd prefer limiting the > MTU of these tunnels to 1280. Do such implementations which have problems with 64KB packets need to be able to use tunneling? Doesn't seem harsh to me (e.g. small devices like LCNA's should not have to do this), though we need analysis whether this is really a problem. > Margaret > > > At 08:10 AM 8/9/02 , Erik Nordmark wrote: > > > since there's no standard, some implementation can be picky and > > > assume MRU == MTU. maybe RFC2893 should talk more about MRU and MTU. > > > >How about: > > A node implementing RFC 2893 MUST be able to reassemble IPv4 packets > > of a size up to and including 65353 octets and MUST NOT place > > any limits on the size of the received encapsulated packets. > > In particular, it MUST NOT assume that the maximum size of > > received packets has anything to do with the MTU for the tunnel. > > > >Of course, it might also make sense to add some SHOULD (or MUST?) to > >section 3.2 in RFC 2893 to make IPv4 MTU discovery across the tunnel > >seem less optional than what the current text says. > > > > Erik > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 06:53:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ADrF3U029927; Sat, 10 Aug 2002 06:53:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7ADrFTK029926; Sat, 10 Aug 2002 06:53:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ADr83U029919 for ; Sat, 10 Aug 2002 06:53:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00862 for ; Sat, 10 Aug 2002 06:53:15 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10696 for ; Sat, 10 Aug 2002 06:53:14 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EE6464B22; Sat, 10 Aug 2002 22:53:06 +0900 (JST) To: Pekka Savola Cc: Margaret Wasserman , Erik Nordmark , ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Sat, 10 Aug 2002 16:49:54 +0300. 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: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Sat, 10 Aug 2002 22:53:06 +0900 Message-Id: <20020810135307.EE6464B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Do such implementations which have problems with 64KB packets need to be >able to use tunneling? yes. think of small devices like DSL routers at home. they terminate tunnels, and have severe memory limitations. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 06:58:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ADwZ3U029950; Sat, 10 Aug 2002 06:58:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7ADwZGL029949; Sat, 10 Aug 2002 06:58:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7ADwT3U029942 for ; Sat, 10 Aug 2002 06:58:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02001 for ; Sat, 10 Aug 2002 06:58:37 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11651; Sat, 10 Aug 2002 06:58:36 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7ADwJY24003; Sat, 10 Aug 2002 16:58:19 +0300 Date: Sat, 10 Aug 2002 16:58:19 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Margaret Wasserman , Erik Nordmark , Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: <20020810135307.EE6464B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 10 Aug 2002 itojun@iijlab.net wrote: > >Do such implementations which have problems with 64KB packets need to be > >able to use tunneling? > > yes. think of small devices like DSL routers at home. they terminate > tunnels, and have severe memory limitations. At least some of those I know have like 2 .. 8 MB of memory, of which 64KB isn't really all that much. Do you have better knowledge of such DSL routers' capabilities? And nothing says you have to be able to defragment more than one packet at the time; further, especially if such devices use confg'd tunneling, it's most probable such packets would never be sent (except in a DoS attack). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 07:09:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AE9k3U000046; Sat, 10 Aug 2002 07:09:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7AE9kbZ000045; Sat, 10 Aug 2002 07:09:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AE9e3U000038 for ; Sat, 10 Aug 2002 07:09:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03219 for ; Sat, 10 Aug 2002 07:09:32 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19315 for ; Sat, 10 Aug 2002 08:09:32 -0600 (MDT) Received: from kenawang ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA22658; Sat, 10 Aug 2002 07:09:06 -0700 (PDT) Message-Id: <4.2.2.20020810100601.00ba9f00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 10 Aug 2002 10:07:55 -0400 To: Pekka Savola From: Margaret Wasserman Subject: Re: IPv6 MTU for tunnel pseudo interfaces Cc: Erik Nordmark , , In-Reply-To: References: <4.2.2.20020810085310.02248b10@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Do such implementations which have problems with 64KB packets need to be >able to use tunneling? I'm not sure -- do you think that home gateways, cable modems, DSL modems, etc. will need to use tunneling? >Doesn't seem harsh to me (e.g. small devices like LCNA's should not have >to do this), though we need analysis whether this is really a problem. I agree that a home security system or a car radio isn't likely to start tunneling any time soon. But, most home gateways and SOHO routers are closed embedded system with no disk and/or virtual memory. Do you expect that they will need to use tunneling? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 07:13:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AEDX3U000070; Sat, 10 Aug 2002 07:13:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7AEDXZ5000069; Sat, 10 Aug 2002 07:13:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AEDM3U000062 for ; Sat, 10 Aug 2002 07:13:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21607 for ; Sat, 10 Aug 2002 07:13:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16303 for ; Sat, 10 Aug 2002 08:13:23 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7AED7E24129; Sat, 10 Aug 2002 17:13:07 +0300 Date: Sat, 10 Aug 2002 17:13:06 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: Erik Nordmark , , Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: <4.2.2.20020810100601.00ba9f00@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 10 Aug 2002, Margaret Wasserman wrote: > I agree that a home security system or a car radio isn't likely to start > tunneling any time soon. But, most home gateways and SOHO routers are closed > embedded system with no disk and/or virtual memory. Do you expect that > they will need to use tunneling? They probably need to be able to use tunneling, at least some of them. But if they're designed so that they have problems with allocating 64 KB of memory, there's something about the design that's wrong IMO. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 07:22:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AEMw3U000087; Sat, 10 Aug 2002 07:22:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7AEMvAQ000086; Sat, 10 Aug 2002 07:22:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AEMq3U000079 for ; Sat, 10 Aug 2002 07:22:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04342 for ; Sat, 10 Aug 2002 07:23:00 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21571 for ; Sat, 10 Aug 2002 08:22:59 -0600 (MDT) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA21049 for ; Sat, 10 Aug 2002 15:22:58 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:9YDcrrCmfZ7QlshBCznEU/uIcbgk/3nO@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g7AEMqpj009071 for ; Sat, 10 Aug 2002 15:22:52 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id g7AEMqJ22390 for ipng@sunroof.eng.sun.com; Sat, 10 Aug 2002 15:22:52 +0100 Date: Sat, 10 Aug 2002 15:22:52 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MTU for tunnel pseudo interfaces Message-ID: <20020810142251.GB20473@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <4.2.2.20020810085310.02248b10@mail.windriver.com> <4.2.2.20020810100601.00ba9f00@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.2.20020810100601.00ba9f00@mail.windriver.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Aug 10, 2002 at 10:07:55AM -0400, Margaret Wasserman wrote: > > > > >Do such implementations which have problems with 64KB packets need to be > >able to use tunneling? > > I'm not sure -- do you think that home gateways, cable modems, DSL > modems, etc. will need to use tunneling? There is a DSL product from 6WIND that runs 6to4; it may use other tunneling mechanisms, but I don't have the full spec to hand. This is quite a nice way to deploy IPv6 to the home until native DSL solutions arrive. It's only a niche market right now though. Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 07:25:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AEOx3U000104; Sat, 10 Aug 2002 07:24:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7AEOxUt000103; Sat, 10 Aug 2002 07:24:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AEOr3U000096 for ; Sat, 10 Aug 2002 07:24:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06315 for ; Sat, 10 Aug 2002 07:25:02 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18078 for ; Sat, 10 Aug 2002 08:25:01 -0600 (MDT) Received: from kenawang ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA25431; Sat, 10 Aug 2002 07:24:38 -0700 (PDT) Message-Id: <4.2.2.20020810102022.00baaf00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 10 Aug 2002 10:25:16 -0400 To: Pekka Savola From: Margaret Wasserman Subject: Re: IPv6 MTU for tunnel pseudo interfaces Cc: Erik Nordmark , , In-Reply-To: References: <4.2.2.20020810100601.00ba9f00@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >But if they're designed so that they have problems with allocating 64 KB >of memory, there's something about the design that's wrong IMO. It's not really a design issue, it is a cost issue... The implementations used in these boxes are quite configurable -- the person who integrates the stack into the box can make all sorts of choices about how many buffers are available of what sizes, etc. This restriction would require that the integrator allocate at least one 64K buffer (or enough buffer space in a chained buffer system) to re-assemble a 64K packet. These systems are very cost-sensitive, and vendors are very careful about limiting the memory size, especially the R/W memory size, of these devices. They will typically complain about anything that "wastes" more than ~16K of memory. What are the major down sides of limiting the MTU on these tunnels? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 07:29:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AETD3U000132; Sat, 10 Aug 2002 07:29:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7AETCtH000131; Sat, 10 Aug 2002 07:29:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AET73U000123 for ; Sat, 10 Aug 2002 07:29:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04713 for ; Sat, 10 Aug 2002 07:29:15 -0700 (PDT) Received: from webserver.redes.unb.br ([164.41.67.130]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01624 for ; Sat, 10 Aug 2002 08:29:12 -0600 (MDT) Received: from webserver.redes.unb.br (localhost.localdomain [127.0.0.1]) by webserver.redes.unb.br (8.12.5/8.12.5) with ESMTP id g7AEhLbX005989; Sat, 10 Aug 2002 11:43:21 -0300 From: "Robson Lopes Jr. Mbone" Received: (from nobody@localhost) by webserver.redes.unb.br (8.12.5/8.12.5/Submit) id g7AEhK07005988; Sat, 10 Aug 2002 11:43:20 -0300 X-Authentication-Warning: webserver.redes.unb.br: nobody set sender to lopesjr@redes.unb.br using -f Received: from 164.41.67.254 (SquirrelMail authenticated user lopesjr) by webserver.redes.unb.br with HTTP; Sat, 10 Aug 2002 11:43:20 -0300 (BRT) Message-ID: <61319.164.41.67.254.1028990600.squirrel@webserver.redes.unb.br> Date: Sat, 10 Aug 2002 11:43:20 -0300 (BRT) Subject: Config. ping6 To: In-Reply-To: References: <20020810135307.EE6464B22@coconut.itojun.org> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'm having some problems on configuring a lab linux RH 7.1 - Kernel 2.4.14: Here is the configuration of a machine with 3 interf. [root@gateway07 /root]# ifconfig eth0 Link encap:Ethernet HWaddr 00:80:5F:31:D9:DC inet addr:192.168.74.253 Bcast:192.168.74.255 Mask:255.255.255.0 inet6 addr: fe80::280:5fff:fe31:d9dc/10 Scope:Link inet6 addr: 3ffe:2b00:100:10b::24/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:280 errors:0 dropped:0 overruns:0 frame:0 TX packets:157 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0x1040 eth1 Link encap:Ethernet HWaddr 00:04:AC:25:F5:C8 inet addr:192.168.75.253 Bcast:192.168.75.255 Mask:255.255.255.0 inet6 addr: fe80::204:acff:fe25:f5c8/10 Scope:Link inet6 addr: 3ffe:2b00:100:10b::25/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:129 errors:0 dropped:0 overruns:111 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0x9000 eth2 Link encap:Ethernet HWaddr 00:04:AC:C5:43:49 inet addr:192.168.76.254 Bcast:192.168.76.255 Mask:255.255.255.0 inet6 addr: fe80::204:acff:fec5:4349/10 Scope:Link inet6 addr: 3ffe:2b00:100:10b::26/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:121 errors:0 dropped:0 overruns:0 frame:0 TX packets:134 errors:0 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0xb000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:200 errors:0 dropped:0 overruns:0 frame:0 TX packets:200 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 --------------- See the tests: --------------- root@gateway07 /root]# ping6 3ffe:2b00:0100:010b::24 PING 3ffe:2b00:0100:010b::24(3ffe:2b00:100:10b::24) from 3ffe:2b00:100:10b::25 : 56 data bytesFrom ::1: Destination unreachable: Address unreachable >From ::1: Destination unreachable: Address unreachable >From ::1: Destination unreachable: Address unreachable --- 3ffe:2b00:0100:010b::24 ping statistics --- 5 packets transmitted, 0 packets received, +3 errors, 100% packet loss [root@gateway07 /root]# ping6 3ffe:2b00:0100:010b::25 PING 3ffe:2b00:0100:010b::25(3ffe:2b00:100:10b::25) from ::1 : 56 data bytes 64 bytes from 3ffe:2b00:100:10b::25: icmp_seq=0 hops=64 time=170 usec 64 bytes from 3ffe:2b00:100:10b::25: icmp_seq=1 hops=64 time=145 usec 64 bytes from 3ffe:2b00:100:10b::25: icmp_seq=2 hops=64 time=143 usec --- 3ffe:2b00:0100:010b::25 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.143/0.152/0.170/0.018 ms [root@gateway07 /root]# ping6 3ffe:2b00:0100:010b::26 PING 3ffe:2b00:0100:010b::26(3ffe:2b00:100:10b::26) from ::1 : 56 data bytes 64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=0 hops=64 time=177 usec 64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=1 hops=64 time=145 usec 64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=2 hops=64 time=144 usec 64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=3 hops=64 time=147 usec --- 3ffe:2b00:0100:010b::26 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.144/0.153/0.177/0.016 ms [root@gateway07 /root]# ping6 -I eth0 3ffe:2b00:0100:010b::26 PING 3ffe:2b00:0100:010b::26(3ffe:2b00:100:10b::26) from ::1 eth0: 56 data bytes64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=0 hops=64 time=190 usec 64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=1 hops=64 time=162 usec 64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=2 hops=64 time=163 usec 64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=3 hops=64 time=164 usec --- 3ffe:2b00:0100:010b::26 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.162/0.169/0.190/0.019 ms -------------------------------------------------//--------------------- When I have only 1 interface the reply from the ping is: "CONNECT: CANNOT ASSIGN REQUESTED ADDRESS" ------------------------------------------------//--------------------- Any idea/suggest of what to do? Robson Lopes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 07:45:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AEjO3U000163; Sat, 10 Aug 2002 07:45:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7AEjNHi000162; Sat, 10 Aug 2002 07:45:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7AEjI3U000154 for ; Sat, 10 Aug 2002 07:45:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05994 for ; Sat, 10 Aug 2002 07:45:26 -0700 (PDT) Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24400 for ; Sat, 10 Aug 2002 07:45:26 -0700 (PDT) Received: from repligate ([67.36.184.14]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020810144525.TPGN18992.mailhost.chi1.ameritech.net@repligate>; Sat, 10 Aug 2002 09:45:25 -0500 Message-ID: <11c401c2407c$93047360$8c56fea9@repligate> From: "Jim Fleming" To: "Pekka Savola" , "Margaret Wasserman" Cc: "Erik Nordmark" , , References: <4.2.2.20020810085310.02248b10@mail.windriver.com> <4.2.2.20020810100601.00ba9f00@mail.windriver.com> Subject: Re: IPv6 MTU for tunnel pseudo interfaces Date: Sat, 10 Aug 2002 09:45:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Margaret Wasserman" > > > > >Do such implementations which have problems with 64KB packets need to be > >able to use tunneling? > > I'm not sure -- do you think that home gateways, cable modems, DSL > modems, etc. will need to use tunneling? > You might find that the view on one-side of an IPv4-based DSL modem is different from the view on the other side. From the consumer side, the DSL modem gives them access to a large, IPv4, non-TOS, transport, which may or may not be useful in passing packets from one side of the Next Generation (NG) Internet, to the other. From inside that transport or cloud, the DSL modem appears as a source or sink for IPv4 packets, and the goal is to route what comes from that modem and route to that modem based on a limited number of bits in the 160-bit IPv4 header. Between the DSL modem and the consumer's network can grow equipment which is intelligent enough to process more of the 160-bits in the IPv4 header. At some point, the IPv4, non-TOS, transport can be removed, when less and less traffic flows across that core, and instead is routed around the edges via the layer of intelligence added between those DSL modems and the user's network. Tunneling may be a misnomer, isolation may be a better term. The existing, aging, 32-bit, IPv4, non-TOS, transport, will become more and more isolated and less used, as usage of more of the bits in the 160-bit IPv4 header allow for packets to be routed around that core, thus isolating it, and not tunneling thru it. All this is happening now, the code is expanding and becoming more widely used. http://www.netfilter.org/ With only 64-bits of the 160-bit IPv4 header used for addressing. There are plenty of bits available to be used to layer around the legacy transport. That may likely become the transport-of-last-resort for some devices, which will have direct (wireless) access to more modern transports. The Next Generation Internet may tunnel back thru the legacy Internet, but that would be good to avoid, because that is viewed as a black-hole, with no hope. Jim Fleming 2002:[IPv4]:000X:03DB http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 21:44:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B4io3U001524; Sat, 10 Aug 2002 21:44:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B4ioZb001515; Sat, 10 Aug 2002 21:44:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B4ii3U001507 for ; Sat, 10 Aug 2002 21:44:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03895 for ; Sat, 10 Aug 2002 21:44:52 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10660 for ; Sat, 10 Aug 2002 21:44:51 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B4iEo20834; Sun, 11 Aug 2002 11:44:14 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7AA1nq18988; Sat, 10 Aug 2002 17:01:49 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <2B81403386729140A3A899A8B39B046405E265@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E265@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Aug 2002 17:01:49 +0700 Message-ID: <18986.1028973709@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 9 Aug 2002 21:18:01 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E265@server2000.arneill-py.sacramento.ca.us> | What you are calling for (quoted below) is lots of changes. With that | many deletions, one might say that it could be wiser to re-write | [addrarch] entirely. No, I don't think that's true, I think it is actually just moving it back to an earlier version - just from reading it it is obvious that the magic "64" has been grafted in later (we have diagrams that use m, n, etc, and then some text says "m + n = 64" - and it isn't as if that's a just a style issue, when the value is "128" (which is a fixed constant of course) the diagrams say "128 - n"). The changes are relatively minor, and affect nothing at all about the way that v6 works, or is used, or is currently deployed, or ... Note: to go to DS we have to provide evidence of at least two independent implementations of every feature of the doc. Any that aren't actually implemented are required to be removed (perhaps to another doc to recycle at PS, but more often to experimental or just the vast emptiness of space). Where are the implementations of the 'u' bit implying global uniqueness? Where are the implementations requiring /64 everywhere, everytime? If they don't exist, the IETF's rules require this stuff to be removed. | Note that I don't oppose the idea and I acknowledge that you do have | very good points, but WRT what Margaret mentioned earlier about | consensus, do you think you can rally the WG behind these proposed | changes? I have no idea. That's not easy to judge, especially when most of what I assume to be the part of the WG that doesn't want these changes is just saying nothing. What I'd like to see if for someone who actually believes the doc should remain as it is, could actually explain the reasons why. Part of the problem that this is so frustrating, is that no-one seems willing to actually explain what we're getting from these requirements. Even a pointer to an older thread on the list where this was discussed and the reasons given would do (Subject headers and approx date would be great). Without that, the impression is that everyone is just silently agreeing (other than those who say that the draft can't change because it already exists) with the points being made, but I am pretty sure that's not the case. But I have no idea at all why. Maybe someone can convince me that there's actually some benefit that I just can't see. As I recall, the only argument I've ever heard, is that the 'u' bit is important, because sometime in the future someone might come up with some scheme that will allow these "globally unique" IIDs to be treated specially for some purpose or other. And even though that's just wild speculation, I could almost buy that (I'm one of the people who doesn't mind making allowances for things that might happen in the future in general, even if we don't know what they are) - except that no-one has been able to tell me how we would ever cope with devices that simply have no idea if their MAC address is globally unique or not (and so really, in this interpretation would have to always leave the 'u' bit clear in all addresses - I can easily show that KAME would be broken according to this interpretation for example - that is, I can have it autoconfigure addresses with the 'u' bit set where the IID isn't globally unique - and I certainly can't imagine a way the KAME people could fix it, other than by never setting 'u'), and perhaps more importantly, as that one can always be hand waved away as a "configuration error" (though the imaginary protocol using this would have to deal with it, somehow) how we deal with address stability when a MAC address changes, so the IPv6 address is no longer based upon an EUI-64, though it used to be. So, let me turn the question around. Is there anyone out there who believes the draft should stay as it is (in this area) and who is willing to attempt to explain why? If there's no-one, then to me that looks like consensus for a change... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 21:45:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B4j03U001535; Sat, 10 Aug 2002 21:45:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B4j0EU001533; Sat, 10 Aug 2002 21:45:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B4in3U001516 for ; Sat, 10 Aug 2002 21:44:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03847 for ; Sat, 10 Aug 2002 21:44:58 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24618 for ; Sat, 10 Aug 2002 22:44:51 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B4iEo20837; Sun, 11 Aug 2002 11:44:14 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7ABIdq19542; Sat, 10 Aug 2002 18:18:39 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020807085415.00aa1270@mail.windriver.com> References: <4.2.2.20020807085415.00aa1270@mail.windriver.com> <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Aug 2002 18:18:39 +0700 Message-ID: <19540.1028978319@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 07 Aug 2002 09:37:33 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020807085415.00aa1270@mail.windriver.com> | No significant changes will (or should) be made to the addressing | architecture based on my personal opinions, even if a few other people | agree with me. Of course not. But it would be interesting to actually hear something from those who don't, with some kind of reasoning, rather than just assuming that they exist, which seems to be the current state of affairs. | It would require a consensus of the WG to change the addressing | architecture in the ways that I have suggested. Of course. But no greater consensus than that required to make the other two changes that Bob Hinden just proposed (based upon the Yokohama discussions). There's nothing magic about this draft, we can change it. | We have discussed these things before (on the mailing list and in person) | and, so far, there has been no WG consensus to make these sorts | of changes. No, but so far I have also failed to see any convincing (or even arguable) reasons why the change should not be made. To me, it is looking a lot like "I don't want to change it because I don't want to change it, but I won't say any more why not than that". This isn't the way to technical excellence (and here, it isn't even if if a change is being proposed which would require changes to implementations, if anything, exactly the opposite, the change would align the doc with what is actually implemented and used). | But, the semantics of the 'u' bit don't provide this... This is the theory, yes. It isn't the practice however. | The 'u' bit indicates that a particular IID has been generated from a | globally unique EUI-64 identifier. And from where does a node determine that it has a globally unique EUI-64 ? | Addresses that are generated from | other sources -- non-globally unique EUI-64s, serial numbers, random | numbers, etc. will not have the 'u' bit set. Not in practice. In practice, any address generated from a MAC addr that has the 'u' bit clear will result in an IPv6 address with the 'u' bit set. So, unless you're able to convince yourself somehow that a MAC address with the 'u' bit clear is necessarily globally unique, practice doesn't fit with the theory. | So, it can't really be used to distinguish autoconfigured addresses | from manually configured addresses No, and if you look, that's never what I said it was good for. No-one should ever look at an address and attempt to interpret the 'u' bit to mean anything at all. What it is useful for, is when I am autoconfiguring an address on a link, based upon the MAC address I am using on that link (which needs to be unique on the link for the link level to operate properly, on most of the links we're concerned with) then I set the 'u' bit, and when I am generating an address another way, I don't. Then the autoconfigured address is much less likely to fail DAD any time when the link level is correctly functional. | -- it is used to distinguish IIDs that are (or should be) | globally unique from IIDs that may not be globally unique. That's the theory. And it is unworkable. | This is a holdover from the 8+8/GRE discussions that we had a few | years back Yes, I know (or I surmised). 8+8 was discussed at some length, investigated, and discarded as unworkable. But we kept this remnant... | But there were a substantial number of people | (I was one of them) who thought that it was important to maintain the | global uniqueness of the IID, so that we might later be able to pursue | such a mechanism. Then, if you're one of them (or even if you no longer are, perhaps you can recall your thinking at the time) perhaps you could explain how this could ever work? That is, how any node could ever know when it should set the 'u' bit such that this other mechanism, if it is later invented, could actually rely upon it? And is this more or less important than the ability to remain address stability when a MAC address changes (change of technology, replacement of broken hardware, etc) ? | So, we decided that the lower 64-bits of an IPv6 should | always be a globally unique EUI-64 identifier. I don't think we ever decided that, or certainly not any time I was watching, as that never had a chance so ... | Not much later, due to the fact that [...] I suspect this "not much" must have been measurable in milliseconds or smaller... (probably without overflowing a 16 bit counter). | not all systems have EUI-64 identifiers and rising concerns | about privacy issues, we backed off of this position and decided to use | the 'u' bit to distinguish between globally unique IIDs and non-globally- | unique IIDs. And, there we stand today... Yes, this is the history as I remembered it as well (other than there ever being a time, the 8+8 proposal excepted, when we ever believed that we could have all addresses contain globally unique EUI-64's - but that detail doesn't matter at all now). What you have described however is how we got ourselves into a messy state, but without any justification at all for keeping us there. Probably it is unfair to expect you to do that, as you started this thread, this time, by proposing that all the mess be thrown away, which is something I totally agree with. But perhaps someone should be able to get to the keyboard and give some kind of justification, other than history, for keeping it? Or even, to explain what we have today that would break if we make the change? | Personally, I think that it is highly unlikely that there will be any | benefits to being able to separate the identification and topological | routing information for _some_ hosts. I agree. But even if there were, I can't see how we can ever, under any circumstances, actually implement the 'u' bit as it is currently defined, regardless of whether or not doing so would ever be useful. | So, I believe that we eliminated | the ability to implement 8+8/GRE-like mechanisms altogether when we decided | to use the 'u' bit to distinguish between the IIDs that were globally | unique and those that were not. I argued this at the time, but there | was clear WG consensus to use the 'u' bit. I recall agreeing that we should keep the 'u' bit for autoconfig purposes, so when we autoconfig things work easier. That's just fine. I don't ever recall agreeing (or ever actually hearing any WG consensus) to treating the 'u' bit as meaning that one can assume the address contains a globally unique IID. Perhaps this is a case where there was some confusion about what was actually being asked? Perhaps someone who believes that the WG actually reached that consensus can point out where in the EG list archives it happened, so I can go back and review the issue? It is kind of hard for me to do that alone, as I don't think it actually exists anywhere, in this particular form. But it is very very hard to show that something doesn't exist, and quite easy to show that it does. | I have been told, though, that there are still a significant number of | people who believe that the 'u' bit should be maintained for later use | in a system that separates ID and routing goop (as it was called in | GRE). These people were reportedly willing to accept the compromise | of splitting the address space into two portions (via the 'u' bit), | one that would have unique IIDs and one that would not. If there are | folks who still believe that this is a valuable property, could you | please speak up in support of it, and explain why? Yes, please, and also explain how it works! (Not the as yet undefined mechanism, we can punt on that for now, just how the "I know when to set the 'u' bit" works for this purpose). | At that time, it didn't seem like a big issue to add a hard /64 | boundary into the IPv6 address, because we already had several | hard boundaries in our addresses to provide separate fields for | aggregation (the TLA/SLA stuff). Well, some people thought that we did. It was always quite clear though that all of the other boundaries were not going to last. Those ones had even less immediate relevance to anything than this one does, relating only to how addresses are assigned. This one needs to go as well. Which isn't to say that most links won't get 64 bit prefixes, we want to use autoconfig, and (for the links currently defined anyway) autoconfig requires 64 bits, which is just fine. But no-one outside the link should be able to tell whether an address is one that was autoconfigured on an ethernet or whether it is one that was manually assigned on a p2p, or even if the same address is one thing one day, and the other the next. | There are some major advantages to retaining this hard /64 boundary: | | - It makes autoconfiguration simpler, since all prefixes are | /64s and all IIDs are 64-bits long. No, that's irrelevant. We can keep the /64 for autoconfig purposes (which is what I have been proposing) while not requiring it as any kind of fundamental part of the architecture. | It would require | major, and inadvisable, changes to autoconfiguration to | allow autoconfiguration using prefixes longer than /64. Not to autoconfig itself, it doesn't care - just to the currently defined mechanisms for autoconfig over X, for all the IEEE type links (and anything else we want to be compatible, so bridging can happen). And no, there is no need at all to change that. But for autoconfig to work on an ethernet (fddi, ...) doesn't require me to use a /64 for my p2p links (if you don't believe it, I can show you my configurations, where this stuff all works just fine). | - Memory systems and processors are much better at dealing with | 64-bit values than they are at dealing with longer | values. This is totally bogus. Go back a few years and you'd put in "32" there just as accurately. Routers need to be able to deal with 128 bit addresses in all instances, as they have to be able to cope with addresses on their directly attached links. Those need /128's ... A router that routed real fast when the destination is a long way away, and real slow, when it is nearby, would perhaps find some market share in the network backbones, but it is never going to be sold in the mass market. Routers can and perhaps should optimise their routing tables so they only carry the required prefix lengths (though I suspect some of the ASIC people will now be jumping up and down and saying that is too hard, there's no need to reply, I understand) - but they cannot afford to assume that only the first 64 bits of addresses matter. Ever. But even if some router was to assume that, and actually find a market, all that would mean is that that router would need to be deployed in an environment where longer prefixes aren't visible. Since I certainly don't expect any of you to ever see explicit routes to m /112 p2p links, you can deploy such routers if you want to, quite safely. You just need to number your own p2p links using /64's and assume that aggregation will take care of everything else. | But, what I think this WG needs to think about and understand is _why_ | operators are using longer prefixes on their router-to-router links. That might be reasonable. But at the same time, operators might want to understand just why this WG thinks it needs to specify that all links be /64 ? Part of the reason that any restriction gets ignored is when the people supposed to obey it don't understand why it is there, and see it as just an unnecessary interference with them doing what they want. | Is this just because that's how it has always been done? I don't think so, but even if it were, surely we should require some kind of reasonable justification in order to change people's current operating methods? We're not just making changes to make people have to change their ways, for our amusement, right? | Or are there | real technical reasons for preferring to use longer prefixes in that | case? There are two reasons sited in the /127 draft (see subject): | | - A router can easily know the address of the router | on the other end of the link... What is this | used for? How valuable is this? Not at all, that's nonsense. If you know it is a /127 (or even probably a /126) then you can most probably predict the address of the other end, but there's essentially no point in that (very little benefit) and what benefit there is is mostly for the human operator (easier to work out the ping address). That's just as easy using /64's (or /112's) and using a consistent numbering scheme though (::1 and ::2 or something). This might explain why some people do it, but it isn't a rational reason. | - /127 prefixes ping-pong attacks that were possible with | older versions of ICMP. These problems were | fixed in ICMPv3, though, so is this really likely | to be a problem for deployed IPv6 routers? I doubt it. | If there are sound reasons to use longer prefixes in some cases, we | may not want to have an addressing architecture that forbids it. But, | I haven't seen anyone speak up with those reasons. There isn't enough address space. The University of Melbourne has an IPv6 address plan (or a preliminary one anyway, given that I'm the only user there I know of at the minute, and I'm no-where near there just now, but anyway...). My dept (Comp Sci & Software Eng) has been allocated 192 SLAs to use. That's generous compared with out allocation of IPv4 addresses of course (we have about 16 /24's, that we use mostly as /26's). [Aside, 3 blocks of 64 /64's, with usage of nets in each block constrained to particular purposes, so the people who insist on filtering can apply consistent rules to whole large blocks of address space throughout the campus, rather than having to know the purpose of every individual net - that is, nets that serve open student labs get different access than nets that serve staff workstations, and those are different again from infrastructure nets (servers, and such)]. But if I have to number all my p2p links out of that space, and I have to allocate /64's to every P2P, then those 192 are all gone long before I start numbering anything other than P2P links (we have about 300 p2p links to number I think - those fit in the IPv4 space real easily, as they're almost all /32's (a few /29's), and fit easily in 2 of the /24's that we have, leaving the other 14 /24's to number 56 ethernets and such, which is just about what we need. Perhaps this is because we're one of those organisations that is in some ways like an ISP (and on the 6bone list I think it was, ISP types were just saying "allocate a /48 to use for all your P2P links" ... if I could do that there would be no issue, but I cannot). Personally I don't think that's rational address conservation for ISPs either - just because they get a /32 of which a /48 is just a small piece, doesn't mean that the /48 should be thrown away on a few dozen (or hundred) links, with 2 nodes on each. Of course, in other ways we're not an ISP, we have no customers (or not for networking services anyway) just lots of users who connect in all kinds of ways. Please, everyone, remember that when ever anything is exhaustible, the time to conserve it is when it is plentiful, or appears that way. Then conservation is usually quite easy. Once a shortage starts to manifest itself (in anything from whales, to rain forests, to IP addresses) attempting to rebuild the resource gets very very hard (and also tends to get very unfair, as there's usually no way to reclaim what has already been wasted, only to limit further consumption - which means those who get in early and waste as much as they can, can end up having major advantages forever over those who do not). Just look at IPv4 if evidence is needed. And remember that we're looking back at that with the benefit of hindsight. At the time people using class A address spaces for (relatively) small organisations didn't think they were wasting addresses, or getting some benefit over those who came later, it was just the way things were done. Now however, we know how much benefit there is to claim lots of address space as early as possible, and then to dig in and claim "we can never give this back or renumber, it has to be ours forever" (as one IPv6 operator has already started doing - this isn't imagination). Let's not be overawed by the size of 2^128 and assume it can never run out. It can, and will, if not managed sensibly. On the other hand, it is a very big number, and even with H ratios, or H factors, or whatever they're called this week, there should be plenty of address space there forever. Provided that we don't start wasting it. Requiring (not just permitting, but actually requiring) that a link that can never have more than 2 attachment points be allocated 2^64 addresses is sending a pretty big sign to everyone that address conservation is irrelevant. That's a very very poor message to send. kre ps: apologies for the lengths of these two messages, comes from having had a few days away from the net, and coming back to see this issue still being discussed, but not advanced at all - that is, all the arguments given are going one way, but there is apparently still no consensus, because there's either off list discussion (which should count for nothing at all), or people are just assuming that there is some disagreement, where none is actually being stated. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 21:45:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B4ix3U001532; Sat, 10 Aug 2002 21:44:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B4ixUT001531; Sat, 10 Aug 2002 21:44:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B4in3U001514 for ; Sat, 10 Aug 2002 21:44:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03910 for ; Sat, 10 Aug 2002 21:44:57 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA27265 for ; Sat, 10 Aug 2002 22:44:51 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B4iDo20831; Sun, 11 Aug 2002 11:44:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7ABdlq19707; Sat, 10 Aug 2002 18:39:47 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <2B81403386729140A3A899A8B39B046405E252@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E252@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Aug 2002 18:39:47 +0700 Message-ID: <19705.1028979587@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 7 Aug 2002 22:48:44 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E252@server2000.arneill-py.sacramento.ca.us> | To be honest, I think it was about time that this issue came to a head. | Because the issue is not about /127 prefixes, but it is about the | reading of [addrarch] that says (or does not) that a prefix longer than | /64 is not to be used for anycast addresses. You mean unicast. | Back to Pekka's draft: I think it would be fair to say that Pekka's | draft is valid if [addrarch] is _not_ to be modified, and needs to be | dumped if [addrarch] is to be modified. Not dumped. Modified probably. That is, that we allow prefixes of any length does not by itself mean that using /127 (which is what the draft is arguing against) is rational. I'm not convinced it is irrational (not as convinced as Pekka anyway) but on the other hand I find it very hard to come up with any convincing reason for actually using /127's. /112 allows me plenty of address space... | In other words: I personally don't care about the 'u' bit, but now is | not the time to close doors as long that big unknown about multihoming | is not settled. OK, since you're the first person (I have seen anyway) willing to actually claim that this just potentially might be useful, please explain how it can ever work. Forget the multihoming use of the thing, just explain how your implementation would ever set the 'u' bit in a way that you're able to guarantee (enough) global uniqueness that multi-homing (or anything else) would ever be able to rely upon it. Knowing that it is possible to use the thing as proposed this way would go a long way toward justifying retaining the 'u' bit as defined (and if 'u' is to be retained, then we need /64 as well, because of where the 'u' bit is positioned - if we were doing this rationally, we'd have reordered the bytes in the addresses, and made 'u' appear in the least significant octet of addresses, rather than splat in the middle). At least then we could have a reasoned cost benefit analysis. At the minute I don't believe it is even possible to use the 'u' bit for this kind of purpose, regardless of how attractive it might be to be able to do it for some application or other. | I hope you don't mind my bluntness, but you don't know yet; nobody does. | Now is not the time to close doors. Perhaps not (though this WG has been entirely willing to rule out all kinds of other things for which an immediate application hasn't been shown). But before we argue for leaving the door open, can we perhaps determine whether or not it has already closed? (slammed and double locked...) | Note about this: My reading is that there still is a semi-hard boundary | at /48, (site) and I think this is good. Please keep in mind what the boundaries are for. The /48 is an allocation size (there are also /32 and /16 and /3 that apply in that realm). That's all OK, those numbers can always be changed, almost without thought, as nothing, other than the allocation system depends upon them. We just tell the registries to allocate /32 instead of /35, and they do that (maybe they argue a bit, or something, but this is all just politics etc). This is totally different from any boundaries in addresses that can be observed or predicted by other nodes. That's the one we need to do away with. We're always going to have all kinds of allocation boundaries, we should never have any boundaries that can be observed in someone else's addresses. | Among many others, kre and I have debated over and over the issue. None | of us is wrong, and none of us is right. Let's put an end to this and | settle it. We have more important things to do. That would be nice. Unfortunately, I dont think this is just a coin toss issue - that is, one where a decision is needed, but any decision will do. There actually is right and wrong here. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 22:14:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B5Ec3U001601; Sat, 10 Aug 2002 22:14:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B5Ebq9001600; Sat, 10 Aug 2002 22:14:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B5EW3U001593 for ; Sat, 10 Aug 2002 22:14:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17071 for ; Sat, 10 Aug 2002 22:14:41 -0700 (PDT) Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04470 for ; Sat, 10 Aug 2002 23:14:37 -0600 (MDT) Received: from repligate ([67.37.189.249]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020811051432.FWBP21716.mail1-0.chcgil.ameritech.net@repligate>; Sun, 11 Aug 2002 00:14:32 -0500 Message-ID: <005b01c240f5$fb2fbc50$8c56fea9@repligate> From: "Jim Fleming" To: "Robert Elz" , "Margaret Wasserman" Cc: References: <4.2.2.20020807085415.00aa1270@mail.windriver.com> <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020805094649.024b9ed0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <4.2.2.20020804200432.024dadc0@mail.windriver.com> <19540.1028978319@munnari.OZ.AU> Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Sun, 11 Aug 2002 00:14:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Robert Elz" > Now however, we know how much benefit there is to claim lots of address > space as early as possible, and then to dig in Is that like claiming TLDs ?....and not giving them up ? Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ----- Original Message ----- From: "Robert Elz" To: "Margaret Wasserman" Cc: Sent: Saturday, August 10, 2002 6:18 AM Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt > Date: Wed, 07 Aug 2002 09:37:33 -0400 > From: Margaret Wasserman > Message-ID: <4.2.2.20020807085415.00aa1270@mail.windriver.com> > > | No significant changes will (or should) be made to the addressing > | architecture based on my personal opinions, even if a few other people > | agree with me. > > Of course not. But it would be interesting to actually hear something > from those who don't, with some kind of reasoning, rather than just > assuming that they exist, which seems to be the current state of affairs. > > | It would require a consensus of the WG to change the addressing > | architecture in the ways that I have suggested. > > Of course. But no greater consensus than that required to make the > other two changes that Bob Hinden just proposed (based upon the Yokohama > discussions). There's nothing magic about this draft, we can change it. > > | We have discussed these things before (on the mailing list and in person) > | and, so far, there has been no WG consensus to make these sorts > | of changes. > > No, but so far I have also failed to see any convincing (or even arguable) > reasons why the change should not be made. To me, it is looking a lot > like "I don't want to change it because I don't want to change it, but > I won't say any more why not than that". This isn't the way to technical > excellence (and here, it isn't even if if a change is being proposed which > would require changes to implementations, if anything, exactly the opposite, > the change would align the doc with what is actually implemented and used). > > | But, the semantics of the 'u' bit don't provide this... > > This is the theory, yes. It isn't the practice however. > > | The 'u' bit indicates that a particular IID has been generated from a > | globally unique EUI-64 identifier. > > And from where does a node determine that it has a globally unique EUI-64 ? > > | Addresses that are generated from > | other sources -- non-globally unique EUI-64s, serial numbers, random > | numbers, etc. will not have the 'u' bit set. > > Not in practice. In practice, any address generated from a MAC addr > that has the 'u' bit clear will result in an IPv6 address with the 'u' > bit set. > > So, unless you're able to convince yourself somehow that a MAC address with > the 'u' bit clear is necessarily globally unique, practice doesn't fit with > the theory. > > | So, it can't really be used to distinguish autoconfigured addresses > | from manually configured addresses > > No, and if you look, that's never what I said it was good for. No-one > should ever look at an address and attempt to interpret the 'u' bit to > mean anything at all. > > What it is useful for, is when I am autoconfiguring an address on a link, > based upon the MAC address I am using on that link (which needs to be > unique on the link for the link level to operate properly, on most of > the links we're concerned with) then I set the 'u' bit, and when I am > generating an address another way, I don't. Then the autoconfigured > address is much less likely to fail DAD any time when the link level is > correctly functional. > > | -- it is used to distinguish IIDs that are (or should be) > | globally unique from IIDs that may not be globally unique. > > That's the theory. And it is unworkable. > > | This is a holdover from the 8+8/GRE discussions that we had a few > | years back > > Yes, I know (or I surmised). 8+8 was discussed at some length, > investigated, and discarded as unworkable. But we kept this remnant... > > | But there were a substantial number of people > | (I was one of them) who thought that it was important to maintain the > | global uniqueness of the IID, so that we might later be able to pursue > | such a mechanism. > > Then, if you're one of them (or even if you no longer are, perhaps you > can recall your thinking at the time) perhaps you could explain how this > could ever work? That is, how any node could ever know when it should > set the 'u' bit such that this other mechanism, if it is later invented, > could actually rely upon it? > > And is this more or less important than the ability to remain address > stability when a MAC address changes (change of technology, replacement > of broken hardware, etc) ? > > | So, we decided that the lower 64-bits of an IPv6 should > | always be a globally unique EUI-64 identifier. > > I don't think we ever decided that, or certainly not any time I was > watching, as that never had a chance so ... > > | Not much later, due to the fact that [...] > > I suspect this "not much" must have been measurable in milliseconds > or smaller... (probably without overflowing a 16 bit counter). > > | not all systems have EUI-64 identifiers and rising concerns > | about privacy issues, we backed off of this position and decided to use > | the 'u' bit to distinguish between globally unique IIDs and non-globally- > | unique IIDs. And, there we stand today... > > Yes, this is the history as I remembered it as well (other than there > ever being a time, the 8+8 proposal excepted, when we ever believed that > we could have all addresses contain globally unique EUI-64's - but that > detail doesn't matter at all now). > > What you have described however is how we got ourselves into a messy state, > but without any justification at all for keeping us there. > > Probably it is unfair to expect you to do that, as you started this thread, > this time, by proposing that all the mess be thrown away, which is something > I totally agree with. > > But perhaps someone should be able to get to the keyboard and give some > kind of justification, other than history, for keeping it? > > Or even, to explain what we have today that would break if we make the > change? > > | Personally, I think that it is highly unlikely that there will be any > | benefits to being able to separate the identification and topological > | routing information for _some_ hosts. > > I agree. But even if there were, I can't see how we can ever, under > any circumstances, actually implement the 'u' bit as it is currently > defined, regardless of whether or not doing so would ever be useful. > > | So, I believe that we eliminated > | the ability to implement 8+8/GRE-like mechanisms altogether when we decided > | to use the 'u' bit to distinguish between the IIDs that were globally > | unique and those that were not. I argued this at the time, but there > | was clear WG consensus to use the 'u' bit. > > I recall agreeing that we should keep the 'u' bit for autoconfig > purposes, so when we autoconfig things work easier. That's just fine. > I don't ever recall agreeing (or ever actually hearing any WG consensus) > to treating the 'u' bit as meaning that one can assume the address > contains a globally unique IID. Perhaps this is a case where there > was some confusion about what was actually being asked? > > Perhaps someone who believes that the WG actually reached that consensus > can point out where in the EG list archives it happened, so I can go back > and review the issue? It is kind of hard for me to do that alone, as > I don't think it actually exists anywhere, in this particular form. But > it is very very hard to show that something doesn't exist, and quite easy > to show that it does. > > | I have been told, though, that there are still a significant number of > | people who believe that the 'u' bit should be maintained for later use > | in a system that separates ID and routing goop (as it was called in > | GRE). These people were reportedly willing to accept the compromise > | of splitting the address space into two portions (via the 'u' bit), > | one that would have unique IIDs and one that would not. If there are > | folks who still believe that this is a valuable property, could you > | please speak up in support of it, and explain why? > > Yes, please, and also explain how it works! (Not the as yet undefined > mechanism, we can punt on that for now, just how the "I know when to set > the 'u' bit" works for this purpose). > > | At that time, it didn't seem like a big issue to add a hard /64 > | boundary into the IPv6 address, because we already had several > | hard boundaries in our addresses to provide separate fields for > | aggregation (the TLA/SLA stuff). > > Well, some people thought that we did. It was always quite clear > though that all of the other boundaries were not going to last. > Those ones had even less immediate relevance to anything than this > one does, relating only to how addresses are assigned. > > This one needs to go as well. Which isn't to say that most links > won't get 64 bit prefixes, we want to use autoconfig, and (for the > links currently defined anyway) autoconfig requires 64 bits, which > is just fine. But no-one outside the link should be able to tell > whether an address is one that was autoconfigured on an ethernet > or whether it is one that was manually assigned on a p2p, or even if > the same address is one thing one day, and the other the next. > > | There are some major advantages to retaining this hard /64 boundary: > | > | - It makes autoconfiguration simpler, since all prefixes are > | /64s and all IIDs are 64-bits long. > > No, that's irrelevant. We can keep the /64 for autoconfig purposes > (which is what I have been proposing) while not requiring it as any > kind of fundamental part of the architecture. > > | It would require > | major, and inadvisable, changes to autoconfiguration to > | allow autoconfiguration using prefixes longer than /64. > > Not to autoconfig itself, it doesn't care - just to the currently defined > mechanisms for autoconfig over X, for all the IEEE type links (and anything > else we want to be compatible, so bridging can happen). And no, there is > no need at all to change that. > > But for autoconfig to work on an ethernet (fddi, ...) doesn't require me > to use a /64 for my p2p links (if you don't believe it, I can show you > my configurations, where this stuff all works just fine). > > | - Memory systems and processors are much better at dealing with > | 64-bit values than they are at dealing with longer > | values. > > This is totally bogus. Go back a few years and you'd put in "32" > there just as accurately. > > Routers need to be able to deal with 128 bit addresses in all instances, > as they have to be able to cope with addresses on their directly attached > links. Those need /128's ... A router that routed real fast when the > destination is a long way away, and real slow, when it is nearby, would > perhaps find some market share in the network backbones, but it is never > going to be sold in the mass market. > > Routers can and perhaps should optimise their routing tables so they > only carry the required prefix lengths (though I suspect some of the > ASIC people will now be jumping up and down and saying that is too > hard, there's no need to reply, I understand) - but they cannot afford > to assume that only the first 64 bits of addresses matter. Ever. > > But even if some router was to assume that, and actually find a market, > all that would mean is that that router would need to be deployed in > an environment where longer prefixes aren't visible. Since I certainly > don't expect any of you to ever see explicit routes to m /112 p2p links, > you can deploy such routers if you want to, quite safely. You just > need to number your own p2p links using /64's and assume that aggregation > will take care of everything else. > > | But, what I think this WG needs to think about and understand is _why_ > | operators are using longer prefixes on their router-to-router links. > > That might be reasonable. But at the same time, operators might want to > understand just why this WG thinks it needs to specify that all links be > /64 ? > > Part of the reason that any restriction gets ignored is when the people > supposed to obey it don't understand why it is there, and see it as just > an unnecessary interference with them doing what they want. > > | Is this just because that's how it has always been done? > > I don't think so, but even if it were, surely we should require some > kind of reasonable justification in order to change people's current > operating methods? We're not just making changes to make people have > to change their ways, for our amusement, right? > > | Or are there > | real technical reasons for preferring to use longer prefixes in that > | case? There are two reasons sited in the /127 draft (see subject): > | > | - A router can easily know the address of the router > | on the other end of the link... What is this > | used for? How valuable is this? > > Not at all, that's nonsense. If you know it is a /127 (or even probably > a /126) then you can most probably predict the address of the other end, > but there's essentially no point in that (very little benefit) and what > benefit there is is mostly for the human operator (easier to work out the > ping address). That's just as easy using /64's (or /112's) and using a > consistent numbering scheme though (::1 and ::2 or > something). > > This might explain why some people do it, but it isn't a rational reason. > > | - /127 prefixes ping-pong attacks that were possible with > | older versions of ICMP. These problems were > | fixed in ICMPv3, though, so is this really likely > | to be a problem for deployed IPv6 routers? > > I doubt it. > > | If there are sound reasons to use longer prefixes in some cases, we > | may not want to have an addressing architecture that forbids it. But, > | I haven't seen anyone speak up with those reasons. > > There isn't enough address space. > > The University of Melbourne has an IPv6 address plan (or a preliminary > one anyway, given that I'm the only user there I know of at the minute, > and I'm no-where near there just now, but anyway...). My dept (Comp > Sci & Software Eng) has been allocated 192 SLAs to use. That's > generous compared with out allocation of IPv4 addresses of course (we > have about 16 /24's, that we use mostly as /26's). > > [Aside, 3 blocks of 64 /64's, with usage of nets in each > block constrained to particular purposes, so the people who > insist on filtering can apply consistent rules to whole large > blocks of address space throughout the campus, rather than > having to know the purpose of every individual net - that is, > nets that serve open student labs get different access than > nets that serve staff workstations, and those are different again > from infrastructure nets (servers, and such)]. > > But if I have to number all my p2p links out of that space, and I have > to allocate /64's to every P2P, then those 192 are all gone long before > I start numbering anything other than P2P links (we have about 300 p2p > links to number I think - those fit in the IPv4 space real easily, as > they're almost all /32's (a few /29's), and fit easily in 2 of the /24's > that we have, leaving the other 14 /24's to number 56 ethernets and such, > which is just about what we need. > > Perhaps this is because we're one of those organisations that is in some > ways like an ISP (and on the 6bone list I think it was, ISP types were just > saying "allocate a /48 to use for all your P2P links" ... if I could do that > there would be no issue, but I cannot). Personally I don't think that's > rational address conservation for ISPs either - just because they get a /32 > of which a /48 is just a small piece, doesn't mean that the /48 should > be thrown away on a few dozen (or hundred) links, with 2 nodes on each. > > Of course, in other ways we're not an ISP, we have no customers (or not > for networking services anyway) just lots of users who connect in all kinds > of ways. > > Please, everyone, remember that when ever anything is exhaustible, the > time to conserve it is when it is plentiful, or appears that way. Then > conservation is usually quite easy. Once a shortage starts to manifest > itself (in anything from whales, to rain forests, to IP addresses) attempting > to rebuild the resource gets very very hard (and also tends to get very > unfair, as there's usually no way to reclaim what has already been wasted, > only to limit further consumption - which means those who get in early > and waste as much as they can, can end up having major advantages forever > over those who do not). > > Just look at IPv4 if evidence is needed. And remember that we're looking > back at that with the benefit of hindsight. At the time people using class A > address spaces for (relatively) small organisations didn't think they were > wasting addresses, or getting some benefit over those who came later, it > was just the way things were done. > > Now however, we know how much benefit there is to claim lots of address > space as early as possible, and then to dig in and claim "we can never give > this back or renumber, it has to be ours forever" (as one IPv6 operator > has already started doing - this isn't imagination). > > Let's not be overawed by the size of 2^128 and assume it can never run out. > It can, and will, if not managed sensibly. On the other hand, it is a > very big number, and even with H ratios, or H factors, or whatever they're > called this week, there should be plenty of address space there forever. > Provided that we don't start wasting it. > > Requiring (not just permitting, but actually requiring) that a link that > can never have more than 2 attachment points be allocated 2^64 addresses > is sending a pretty big sign to everyone that address conservation is > irrelevant. That's a very very poor message to send. > > kre > > ps: apologies for the lengths of these two messages, comes from having had > a few days away from the net, and coming back to see this issue still being > discussed, but not advanced at all - that is, all the arguments given are > going one way, but there is apparently still no consensus, because there's > either off list discussion (which should count for nothing at all), or > people are just assuming that there is some disagreement, where none is > actually being stated. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 23:12:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B6Ch3U001678; Sat, 10 Aug 2002 23:12:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B6Cgjl001677; Sat, 10 Aug 2002 23:12:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B6Cb3U001670 for ; Sat, 10 Aug 2002 23:12:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18205 for ; Sat, 10 Aug 2002 23:12:47 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26959 for ; Sat, 10 Aug 2002 23:12:45 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B6C3o22910; Sun, 11 Aug 2002 13:12:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7B6BK103689; Sun, 11 Aug 2002 13:11:20 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Pekka Savola cc: Margaret Wasserman , Erik Nordmark , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 13:11:20 +0700 Message-ID: <3687.1029046280@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 10 Aug 2002 17:13:06 +0300 (EEST) From: Pekka Savola Message-ID: | They probably need to be able to use tunneling, at least some of them. I agree. They're also one of the more likely users of unconfigured tunnels (6to4) - they get one IPv4 addr, and offer IPv6 connectivity to the end user, without requiring any other infrastructure to be operating. This sounds like a good way to encourage more users of IPv6, so we shouldn't be doing anything to make it more difficult to achieve. | But if they're designed so that they have problems with allocating 64 KB | of memory, there's something about the design that's wrong IMO. I disagree there. I also disagree that being able to reassemble one packet at a time is enough, just a small amount of IPv4 packet reordering would blow away an implementation tried to reply upon that. 64K is too big. I think 1280 is too small. As I said in a message I typed yesterday (but which would only have been sent an hour or so ago), something in the 4K-8K region sounds to me like a size I think would cope with any reasonable use (as you said, anyone sending 64K tunnelled packets is probably DoSing you anyway - not certain, but probable) without causing unnecessary IPv6 fragmentation requirements. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 23:41:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B6fP3U001722; Sat, 10 Aug 2002 23:41:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B6fO5g001721; Sat, 10 Aug 2002 23:41:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B6fI3U001714 for ; Sat, 10 Aug 2002 23:41:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24333 for ; Sat, 10 Aug 2002 23:41:26 -0700 (PDT) Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25729 for ; Sun, 11 Aug 2002 00:41:25 -0600 (MDT) Received: from repligate ([67.37.189.249]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020811064125.GTZG21716.mail1-0.chcgil.ameritech.net@repligate>; Sun, 11 Aug 2002 01:41:25 -0500 Message-ID: <007701c24102$1d9db510$8c56fea9@repligate> From: "Jim Fleming" To: "Robert Elz" , "Pekka Savola" Cc: "Margaret Wasserman" , "Erik Nordmark" , , References: <3687.1029046280@munnari.OZ.AU> Subject: Re: IPv6 MTU for tunnel pseudo interfaces Date: Sun, 11 Aug 2002 01:41:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Robert Elz" > > | They probably need to be able to use tunneling, at least some of them. > > I agree. They're also one of the more likely users of unconfigured > tunnels (6to4) - they get one IPv4 addr, and offer IPv6 connectivity to > the end user, without requiring any other infrastructure to be operating. > > This sounds like a good way to encourage more users of IPv6, so we shouldn't > be doing anything to make it more difficult to achieve. > IP"NG" and IPv6 are not the same thing.... ...as for encouraging usage of the Next Generation Internet, one way is to make sure that address space is readily available, fairly allocated, and low-cost or free. The I* society does not seem to approach things from that point of view. Therefore, people are routing around it. That is the Internet way... Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 10 23:52:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B6qk3U001754; Sat, 10 Aug 2002 23:52:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B6qkpw001753; Sat, 10 Aug 2002 23:52:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B6qe3U001746 for ; Sat, 10 Aug 2002 23:52:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16816 for ; Sat, 10 Aug 2002 23:52:49 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17761 for ; Sat, 10 Aug 2002 23:52:48 -0700 (PDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Sat, 10 Aug 2002 23:52:46 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E266@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Thread-Index: AcJA8syWproHc4YVQBu8lw7uguHnPwADSQ9w From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 To: "Robert Elz" content-class: urn:content-classes:message Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7B6qf3U001747 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, > The changes are relatively minor, and affect nothing at all > about the way that v6 works, or is used, or is currently > deployed, or ... I do not agree. When designing IPv6 ASICs, one might like the hard limit at /64, for example. > Note: to go to DS we have to provide evidence of at least > two independent implementations of every feature of the doc. > Any that aren't actually implemented are required to be > removed (perhaps to another doc to recycle at PS, but more > often to experimental or just the vast emptiness of space). > Where are the implementations of the 'u' bit implying global > uniqueness? Where are the implementations requiring /64 > everywhere, everytime? If they don't exist, the IETF's rules > require this stuff to be removed. You are trying to use the 'u' bit as a scapegoat. If there was compelling reasons to remove the hard /64 boundary, I don't think the 'u' bit would be much of a problem. > So, let me turn the question around. Is there anyone out there > who believes the draft should stay as it is (in this area) and > who is willing to attempt to explain why? > If there's no-one, then to me that looks like consensus for a > change... This is not the way it works, IMHO. If the draft is there it's because it has reached consensus. The consensus question is about the changes you suggest, not the current state of the draft. I am using /64s for ptp links. They work fine. The argument that I am wasting precious address space is fud, as my site gets a /48 anyway. Only for the very few sites that actually require more than a /48 can there be a gain using longer prefixes, and most of the time that gain is null as well because sites that require more than a /48 do have internal aggregation, and there again the /64 point to point links are lost into the internal addressing structure. For ISPs/operators, assigning /64s to ptp links wastes 1/64k of their customer address space, peanuts. Here is where I stand: the RFC says that you should use /64. The only real argument to use longer prefixes is conservation, and it's fud. The potential 25% savings in 1% of situations is not worth modifying the addressing architecture document, as respecting it costs no more than not doing it, and as it has reached consensus. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 11 00:30:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B7UQ3U001806; Sun, 11 Aug 2002 00:30:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B7UPaR001805; Sun, 11 Aug 2002 00:30:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B7UK3U001798 for ; Sun, 11 Aug 2002 00:30:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00708 for ; Sun, 11 Aug 2002 00:30:28 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14211 for ; Sun, 11 Aug 2002 00:30:12 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B7TDo25078; Sun, 11 Aug 2002 14:29:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7B6O8103947; Sun, 11 Aug 2002 13:24:08 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Andreas Herrmann" cc: ipng@sunroof.eng.sun.com Subject: Re: EUI-64 based interface identifiers In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 13:24:08 +0700 Message-ID: <3945.1029047048@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 8 Aug 2002 10:48:26 +0200 From: "Andreas Herrmann" Message-ID: | I have 2 questions regarding EUI-64 based interface | identifiers. It doesn't appear as if anyone has attempted to answer your question yet. | To avoid detection of duplicate addresses during stateless | autoconfiguration we are replacing the part 0xFFFE of the link | local address by a 16-bit value. This value is unique among all | Linuxes sharing the same network card. Sounds like an interesting technique. | This procedure does not correspond to what is written in RFC 2373 | "Appendix A: Creating EUI-64 based Interface Identifiers" and in | "http://standards.ieee.org/regauth/oui/tutorials/EUI64.html". No. It certainly isn't that. | But we are not inverting the "u" bit in the resulting interface | identifiers. Hence the resulting 64-bit interface identifiers have | local scope. If you've been following the list discussion recently, you'll see that "local scope" is a meaningless concept anyway (or rather, everything really only has local scope, global scope is meaningless.) Of course you might also understand that there are apparently some others who disagree with this viewpoint, but we don't know who or why. What is clear is that doing that essentially means you're using addresses from the "other configuration" area, and as what you're doing is "other configuration" (it isn't autoconfig as defined), that looks to be the right thing to do to me. Just expect a higher probability of a clash with some other manually configured address than you'd get with a normal autoconfig mechanism, and be able to cope with that (the probability is still likely to be quite low). | Thus I assume the above procedure -- replacing 0xFFFE by a unique | identifier and not inverting the "u" bit -- does not violate | any RFCs. | Am I right in this assumption? I believe so, yes. Not that it matters anyway, provided the user of the system is happy to have addresses used this way - it is address space assigned to that user (link locals just being the first step I assume) that is being consumed here. That is, as long as the user can override what you're doing by default, and assign addresses more in line with their address plan, this all looks just fine. | Another question is: | Do you know of any applications that rely on the part | "FFFE" of interface identifiers? E.g. network sniffers might use | the value to identify interface identifiers. Unless someone is able to say "yes" (which I truly hope no-one is going to do), this is a very hard question to answer meaningfully. I know of no-one stupid enough to do anything so absurd, but that doesn't mean that there isn't someone out there acting irrationally. But don't worry about it - if there's anyone doing that kind of weird thing, then they're also going to fail on 3041 addresses, and whenever people just configure ::1 ::2 for their systems. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 11 01:07:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B87I3U001837; Sun, 11 Aug 2002 01:07:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7B87I3f001836; Sun, 11 Aug 2002 01:07:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7B8783U001829 for ; Sun, 11 Aug 2002 01:07:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07622 for ; Sun, 11 Aug 2002 01:07:17 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22058 for ; Sun, 11 Aug 2002 02:07:15 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B86ao26315; Sun, 11 Aug 2002 15:06:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7B85s104233; Sun, 11 Aug 2002 15:05:54 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <2B81403386729140A3A899A8B39B046405E266@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E266@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 15:05:54 +0700 Message-ID: <4231.1029053154@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 10 Aug 2002 23:52:46 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E266@server2000.arneill-py.sacramento.ca.us> | I do not agree. When designing IPv6 ASICs, one might like the hard limit | at /64, for example. In that case, the ASIC won't be able to handle routing to anything on a local link, will it? All addresses on the link would look the same. That's going to make it a pretty slow router for sending to local addresses, while fast on things just passing through to somewhere else. You can buy a router like that if you like, I know I won't ever. My /112's aren't going to bother your router with its /64 assumption, and the routers I use aren't going to be bothered by my /112's. So this "64 bit is faster" argument is nonsense (or, if you prefer, FUD). | You are trying to use the 'u' bit as a scapegoat. If there was | compelling reasons to remove the hard /64 boundary, I don't think the | 'u' bit would be much of a problem. No. The only possible reason for keeping the 64 bit boundary is because that 'u' bit is there, and someone might want to interpret it. If it weren't for that, and the bits in my addresses had absolutely no interpretation available to you, then whether or not I am using a 64 bit prefix or longer is, and always will be, 100% irrelevant to you. There's no justification at all for the standard saying that everyone must do something that has no impact on anything at all. Not that it matters, as people would simply ignore it anyway. No-one outside their site would ever be able to tell the difference. The 'u' bit is the one problem for this - if people were to seriously expect to be able to look at someone else's address, and draw some kind of conclusions based upon the state of the 'u' bit, then that bit simply has to be in the IID part, it couldn't be in the prefix. That means that if we could justify keeping 'u', the hard /64 would have to stay. But it seems that even you have given up on support for 'u' ... | This is not the way it works, IMHO. If the draft is there it's because | it has reached consensus. The consensus question is about the changes | you suggest, not the current state of the draft. The draft is just a draft. The RFC it is replacing received consensus. Now it is being updated and changed. That's normal when a draft moves from PS to DS. We get a chance to review the doc, and discard the parts that have, with implementation experience, been seen to be wrong, or usless, or unimplementable. That is what is happening here, the current draft is just a work in progress, towards that update. | I am using /64s for ptp links. They work fine. The argument that I am | wasting precious address space is fud, as my site gets a /48 anyway. Who ever argued that you are wasting address space. If you want to use /64's for p2p's and they work for you, that's just fine. No-one here is attempting to require you to change that. From where did you get that impression? Or is it just easier to argue against points that weren't made than ones that were? | Only for the very few sites that actually require more than a /48 can | there be a gain using longer prefixes, If you reword that as "require more than a /48 because of they have lots of p2p links, and someone is claiming that /64 is mandatory", then yes. But the University of Melbourne, by any normal standard, will fit in a /48 just fine, it fits in a /16 for IPv4, and hasn't run out of addresses yet (things are sometimes a bit tight, and the college residences now all have numbers from other address spaces I believe, but we manage - and without NAT). If 2^16 addresses work for us now, I am pretty sure that we should be able to manage with 2^80 forever... (even using /64's for all our LAN type links, now and into the future). So, we "don't actually require" more than a /48 - you just want to force us to consume more. Why? What are you gaining from this? | and most of the time that gain is | null as well because sites that require more than a /48 do have internal | aggregation, Of course. | and there again the /64 point to point links are lost into | the internal addressing structure. No, if they're included in it, they dwarf it, and that's what would cause the "require more than a /48". Instead, the p2p links have their own aggregation hierarchy (which then can be included in the wider organisation hierarchy). That works, because it is usual for lots of p2p links to terminate at or about the same place (at one large router, headend, ...). All the routing system needs to see (other than at that box) is one route to it, for all of its p2p links. Only inside that box are its hundreds (or thousands) of p2p links ever visible (and at the far end of each individual link of course, but routing there is generally "default and me"). | For ISPs/operators, assigning /64s to ptp links wastes 1/64k of their | customer address space, peanuts. If it is all in one /48 of their /32 (which limits them to absolute max of 64K p2ps of course, which isn't a big customer base really) - but then they're going to have to be shipping around explicit routes to all of those p2p prefixes (/64's) or they're going to have to do some kind of internal aggregation inside the SLA, which of course, means less available addresses, and more wastage. It might seem like peanuts, but it all starts to count. Now if there was some technical justification for why it needed to be this way, then perhaps we could say, OK, we will be wasting some addresses, but here's what we gain from that ... Like to complete that paragraph? Currently the answer is "nothing". | Here is where I stand: the RFC says that you should use /64. The only | real argument to use longer prefixes is conservation, and it's fud. The | potential 25% savings in 1% of situations is not worth modifying the | addressing architecture document, as respecting it costs no more than | not doing it, and as it has reached consensus. That is, the technical argument for it is that we once thought that it was correct, and even though no-one now is able to explain how we reached that conclusion, we did it, and hence it must be correct forever. In that case, why aren't you opposing the proposed change of the subnet local SLA field from 16 bits to 54 (or however many it is). We once decided that 16 was the right number, and all the other bits had to be 0. The RFC says that. The potential problems with the tiny number of sites that can't fit in a 16 bit SLA is not worth modifying the addressing architecture document, ... Really! We are modifying the doc. We are producing a replacement doc. The new one will obsolete the old one. There's no cost anyone has been able to enumerate to making the change. (If one wanted to be petty, one could show that the RFC will be a couple of K bytes smaller, and so by making the change we're both making it easier to read and understand, and saving that disc space...) And no, that isn't a good argument for doing the change. The better argument is that the current doc is unimplementable, untestable, and meaningless. It is quite simply, wrong. And then we also have to follow 2026 process rules. That means documenting that all the features of the protocol are actually implemented - otherwise that MUST be removed when the doc advances to DS. Those are the rules. This stuff isn't enforced anywhere (the /64). The 'u' bit (other than the way it us used during autoconfig, which is fine, and should remain) is unused anywhere. If we want this doc to have a chance to advance, assuming the IESG follows the IETF's rules, we *have* to remove those parts. If we thought they were worth keeping, we'd be putting them in a new doc, and making that one be a PS, and leaving it there until either the parts find uses, and so qualify for advancement, or the whole thing gets ignored, and in 10 or 15 years, someone wake up, and causes the doc to move to historic. If we just think it might be a cute idea for people to play with, we'd make it be experimental (like, say A6 ... remember how that had consensus, and was documented in an RFC, and was actually implemented and used, and what happened to it???) kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 11 19:08:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7C28L3U003956; Sun, 11 Aug 2002 19:08:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7C28LNT003955; Sun, 11 Aug 2002 19:08:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7C28F3U003948 for ; Sun, 11 Aug 2002 19:08:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28584 for ; Sun, 11 Aug 2002 19:08:25 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27925 for ; Sun, 11 Aug 2002 19:08:24 -0700 (PDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Sun, 11 Aug 2002 19:08:23 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E267@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcJBDqTdnvNofGeVT/OqOenPI44FVQAky6Jg content-class: urn:content-classes:message From: "Michel Py" To: "Robert Elz" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7C28G3U003949 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is what I propose so we don't bore this WG to death: In Atlanta, both kre and I get a 5-minute slot to present. Then we ask the following question to the floor: "Let's imagine that the 'u' bit does not exist. Do we remove the parts that mandate an address to be /64, or don't we". If the floor says that we toss the /64 boundary, my vote goes to suppress the 'u' bit so this can happen. If the floor says that we keep the /64 boundary, then my vote goes to keep the 'u' bit for the time being, as it does not harm anybody. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 01:02:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7C82N3U004568; Mon, 12 Aug 2002 01:02:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7C82Mad004567; Mon, 12 Aug 2002 01:02:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7C82C3U004560 for ; Mon, 12 Aug 2002 01:02:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25147 for ; Mon, 12 Aug 2002 01:02:20 -0700 (PDT) Received: from givenchy.6wind.com ([212.234.238.114]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28509 for ; Mon, 12 Aug 2002 02:02:19 -0600 (MDT) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy.6wind.com (Postfix) with ESMTP id 0D8797DC; Mon, 12 Aug 2002 10:11:20 +0200 (CEST) Received: from 6wind.com (ksinant.6wind.com [10.0.0.101]) by intranet.6wind.com (Postfix) with ESMTP id 70B71B4FA; Mon, 12 Aug 2002 10:02:43 +0200 (CEST) Message-ID: <3D576B28.A971F28E@6wind.com> Date: Mon, 12 Aug 2002 10:00:41 +0200 From: Vladimir Ksinant X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz Cc: Pekka Savola , Margaret Wasserman , Erik Nordmark , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: IPv6 MTU for tunnel pseudo interfaces References: <3687.1029046280@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Date: Sat, 10 Aug 2002 17:13:06 +0300 (EEST) > From: Pekka Savola > Message-ID: > > | They probably need to be able to use tunneling, at least some of them. > > I agree. They're also one of the more likely users of unconfigured > tunnels (6to4) - they get one IPv4 addr, and offer IPv6 connectivity to > the end user, without requiring any other infrastructure to be operating. At the moment, my view is that SOHO routers mostly use tunneling in order to connect to IPv6 networks (6to4 or configured tunnels). It may not be the prefered way in the future, but it is often the only solution today. > | But if they're designed so that they have problems with allocating 64 KB > | of memory, there's something about the design that's wrong IMO. > > I disagree there. I also disagree that being able to reassemble one > packet at a time is enough, just a small amount of IPv4 packet reordering > would blow away an implementation tried to reply upon that. > > 64K is too big. I think 1280 is too small. As I said in a message I > typed yesterday (but which would only have been sent an hour or so ago), > something in the 4K-8K region sounds to me like a size I think would cope > with any reasonable use (as you said, anyone sending 64K tunnelled > packets is probably DoSing you anyway - not certain, but probable) without > causing unnecessary IPv6 fragmentation requirements. In DSL environments, ATM is often used in the access network. Then, the MTU is often 9180. I think 9180 should at least be supported. The MTU processing is tricky to implement today, especially when dealing with several types of encapsulation. For instance in DSL environments, a SOHO router may have to deal with PPPoE, IPSEC and 6in4 encapsulation. Having a fixed value for 6in4 tunnel would make it easier. Vladimir -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 01:25:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7C8PH3U004621; Mon, 12 Aug 2002 01:25:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7C8PGKD004620; Mon, 12 Aug 2002 01:25:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7C8PB3U004613 for ; Mon, 12 Aug 2002 01:25:11 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01015 for ; Mon, 12 Aug 2002 01:25:19 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11993 for ; Mon, 12 Aug 2002 02:25:18 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA04150; Mon, 12 Aug 2002 11:24:19 +0300 Date: Mon, 12 Aug 2002 11:24:19 +0300 Message-Id: <200208120824.LAA04150@burp.tkv.asdf.org> From: Markku Savela To: michel@arneill-py.sacramento.ca.us CC: kre@munnari.OZ.AU, mrw@windriver.com, ipng@sunroof.eng.sun.com In-reply-to: <2B81403386729140A3A899A8B39B046405E267@server2000.arneill-py.sacramento.ca.us> (michel@arneill-py.sacramento.ca.us) Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt References: <2B81403386729140A3A899A8B39B046405E267@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Michel Py" > > Here is what I propose so we don't bore this WG to death: > > In Atlanta, both kre and I get a 5-minute slot to present. Not everyone can affort to travel there... > If the floor says that we toss the /64 boundary, my vote goes to > suppress the 'u' bit so this can happen. If the floor says that we keep > the /64 boundary, then my vote goes to keep the 'u' bit for the time > being, as it does not harm anybody. I say "toss the /64 boundary from the address architecture". Return it back to original prefix=m, id=n bits format consistently. The boundary is link specific thing and should be defined in IPv6-over-FOO specs. Same with I any 'u'-bit like constructs. Getting back to voting on these issues. Perhaps it should be that only implementations should have a vote? :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 02:39:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7C9d03U004730; Mon, 12 Aug 2002 02:39:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7C9d0Jw004729; Mon, 12 Aug 2002 02:39:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7C9cs3U004722 for ; Mon, 12 Aug 2002 02:38:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25728 for ; Mon, 12 Aug 2002 02:39:03 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23593; Mon, 12 Aug 2002 03:39:01 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7C9ceL16746; Mon, 12 Aug 2002 12:38:40 +0300 Date: Mon, 12 Aug 2002 12:38:40 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Margaret Wasserman , Erik Nordmark , , Subject: Re: IPv6 MTU for tunnel pseudo interfaces In-Reply-To: <3687.1029046280@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 11 Aug 2002, Robert Elz wrote: > I disagree there. I also disagree that being able to reassemble one > packet at a time is enough, just a small amount of IPv4 packet reordering > would blow away an implementation tried to reply upon that. If the alternative to reassebling one packet at a time is discarding all of those messages, perhaps some would consider it a reasonable tradeoff. I wouldn't want to rely on it either, but it (kind of) satisfies a requirement, even if not properly. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 04:00:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CB0K3U004871; Mon, 12 Aug 2002 04:00:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CB0JaO004870; Mon, 12 Aug 2002 04:00:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CB0E3U004863 for ; Mon, 12 Aug 2002 04:00:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09996 for ; Mon, 12 Aug 2002 04:00:22 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09245 for ; Mon, 12 Aug 2002 05:00:21 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7CAxbo23894; Mon, 12 Aug 2002 17:59:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7CA8XW13720; Mon, 12 Aug 2002 17:08:33 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: michel@arneill-py.sacramento.ca.us, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208120824.LAA04150@burp.tkv.asdf.org> References: <200208120824.LAA04150@burp.tkv.asdf.org> <2B81403386729140A3A899A8B39B046405E267@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Aug 2002 17:08:33 +0700 Message-ID: <13718.1029146913@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 11:24:19 +0300 From: Markku Savela Message-ID: <200208120824.LAA04150@burp.tkv.asdf.org> | > In Atlanta, both kre and I get a 5-minute slot to present. | Not everyone can affort to travel there... Which includes me, I won't be in Atlanta. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 04:00:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CB0j3U004881; Mon, 12 Aug 2002 04:00:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CB0jvf004880; Mon, 12 Aug 2002 04:00:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CB0c3U004873 for ; Mon, 12 Aug 2002 04:00:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17346 for ; Mon, 12 Aug 2002 04:00:46 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA20701 for ; Mon, 12 Aug 2002 05:00:40 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7CAxgo23910; Mon, 12 Aug 2002 17:59:42 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7B8bs104357; Sun, 11 Aug 2002 15:37:54 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Bob Hinden cc: IPv6 List Subject: Re: Changes to IPv6 Addressing Architecture Draft In-Reply-To: <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 15:37:54 +0700 Message-ID: <4355.1029055074@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 09 Aug 2002 15:27:15 -0700 From: Bob Hinden Message-ID: <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> | If there is agreement with these changes I will submit a new draft (-09) | that the area directors can proceed with. Bob, I have no problems with either proposed change, I support both of them. By all means, submit a new draft if you like - but please don't send it back to the ADs until the other issue surrounding it has been dealt with. Since this doc is going to DS (we hope) it requires an implementation report. There is one of those already - can be found on the IETF web site, but for anyone who wants a direct URL, it is: http://www.ietf.org/IESG/Implementations/address-architecture.txt That's great. It doesn't mention either of the new features, but I would assume they can easily be added (since everyone does DAD, rather than DIID anyway, reporting it as implemented will be easy, and I doubt it will take much effort for a couple of implementation at least to test longer SLAs in SL addresses). Those need to be fixed, but should be easy. But the implementation report also lacks any mention of testing, using, or implementing the 'u' bit means "address has a globally unique IID" feature, nor the "all unicast prefixes other than 0::/3 must be /64" feature. If there are no implementations of those, then the IESG is just going to tell the WG to delete them before the doc does to DS, isn't it? Why don't we just do that now? You could include those changes in the next draft that you submit. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 05:20:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CCKb3U005014; Mon, 12 Aug 2002 05:20:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CCKbgW005013; Mon, 12 Aug 2002 05:20:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CCKU3U005006 for ; Mon, 12 Aug 2002 05:20:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22044 for ; Mon, 12 Aug 2002 05:20:37 -0700 (PDT) Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04841 for ; Mon, 12 Aug 2002 06:20:37 -0600 (MDT) Received: from repligate ([64.109.166.36]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020812122031.DCSZ18992.mailhost.chi1.ameritech.net@repligate>; Mon, 12 Aug 2002 07:20:31 -0500 Message-ID: <005c01c241fa$ab657e20$8c56fea9@repligate> From: "Jim Fleming" To: , "Markku Savela" Cc: , , "Vittorio Bertola" , "todd glassey" , "Richard Henderson" , "Kristy McKee" , , "Joop Teernstra" , "Joanna Lane" , , , , , , "Elisabeth Porteneuve" , "Alexander Svensson" , "Joe Baptista" , , , References: <2B81403386729140A3A899A8B39B046405E267@server2000.arneill-py.sacramento.ca.us> <200208120824.LAA04150@burp.tkv.asdf.org> Subject: "toss the /64 boundary from the address architecture" ?? Date: Mon, 12 Aug 2002 07:20:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Markku Savela" > > I say "toss the /64 boundary from the address architecture". Return it > back to original prefix=m, id=n bits format consistently. > 1. Do you really think that people are going to want to place their hardware-specific ids in the address fields ? 2. Have you considered the merits of placing "time-stamps" in the 128-bit DNS fields ? ....for the 4D Internet, where time becomes a dimension.... 3. Have you considered how the 128-bit DNS is used with other protocols, besides IPv6 ? 4. What has the ICANN Board and staff decided on this ?...isn't there an ASO ? 5. Have you seen a 2 dimensional object ?...such as a shadow....length and width and no depth... ...are you familiar with 3D ?....length, width, and depth ? 6. Have you read the book Flatland by Edwin Abbott ? http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=flatland 7. Have you spent much time learning about the Next Generation Internet ? ...3D and the governance structures...etc... http://www.ActiveWorlds.com http://www.OuterWorlds.com http://www.cyboria.com 8. Do you think people are stupid ?...and will jump off the I* society cliff when told to jump...? Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 06:32:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CDW53U005193; Mon, 12 Aug 2002 06:32:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CDW5ix005192; Mon, 12 Aug 2002 06:32:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CDVr3U005185 for ; Mon, 12 Aug 2002 06:31:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09272 for ; Mon, 12 Aug 2002 06:32:02 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18745 for ; Mon, 12 Aug 2002 07:32:02 -0600 (MDT) Received: from kenawang ([147.11.233.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA28391; Mon, 12 Aug 2002 06:30:32 -0700 (PDT) Message-Id: <4.2.2.20020812091932.01c3b220@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 12 Aug 2002 09:31:08 -0400 To: "Michel Py" From: Margaret Wasserman Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Cc: "Robert Elz" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E267@server2000.arneill- py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, At 10:08 PM 8/11/02 , Michel Py wrote: >Here is what I propose so we don't bore this WG to death: > >In Atlanta, both kre and I get a 5-minute slot to present. It is much better to bore the WG to death on the mailing list than it is to do it in person :-)/2. More seriously, there are three reasons why I don't think that this is a good plan: - The WG is here, on the mailing list. Only a small portion of the WG will be represented at the meeting in Atlanta. - There is no reason to wait until November for a resolution on this issue. >Then we ask the following question to the floor: > >"Let's imagine that the 'u' bit does not exist. Do we remove the parts >that mandate an address to be /64, or don't we". > >If the floor says that we toss the /64 boundary, my vote goes to >suppress the 'u' bit so this can happen. If the floor says that we keep >the /64 boundary, then my vote goes to keep the 'u' bit for the time >being, as it does not harm anybody. There is no reason not to ask these questions here, on the mailing list. The response we are looking for isn't a "vote", however... The current situation with the addressing architecture is that we have established a consensus of the WG to make two changes to the document (described in Bob's mail) and send it (back) to the IESG for consideration as a draft standard. I have not seen a level of response to this thread that would lead me to question that consensus. Have you? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 06:58:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CDwf3U005235; Mon, 12 Aug 2002 06:58:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CDwe3G005234; Mon, 12 Aug 2002 06:58:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CDwZ3U005227 for ; Mon, 12 Aug 2002 06:58:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13942 for ; Mon, 12 Aug 2002 06:58:43 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19657 for ; Mon, 12 Aug 2002 07:58:42 -0600 (MDT) Received: from kenawang ([147.11.233.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA08316; Mon, 12 Aug 2002 06:57:50 -0700 (PDT) Message-Id: <4.2.2.20020812093808.01cef220@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 12 Aug 2002 09:57:14 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Changes to IPv6 Addressing Architecture Draft Cc: Bob Hinden , IPv6 List In-Reply-To: <4355.1029055074@munnari.OZ.AU> References: <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We can only perform interoperability testing for external behaviours of boxes that are visible on the wire. This does make it fairly tricky to write an implementation checklist for something like an addressing architecture, and I think that Bob has done an outstanding job of figuring out which features do/don't have interoperability concerns. >Since this doc is going to DS (we hope) it requires an implementation >report. There is one of those already - can be found on the IETF web site, >but for anyone who wants a direct URL, it is: > http://www.ietf.org/IESG/Implementations/address-architecture.txt > >That's great. It doesn't mention either of the new features, but I >would assume they can easily be added (since everyone does DAD, rather >than DIID anyway, reporting it as implemented will be easy, and I doubt >it will take much effort for a couple of implementation at least to test >longer SLAs in SL addresses). The subnet ID changes don't affect the external behaviour of an IPv6 implementation. We were always required to perform all routing and comparisons in a CIDR-like fashion, and that hasn't changed. I agree that vendors may want to check that their configuration mechanisms don't have a problem setting subnet IDs of longer than 16-bits, but that isn't an interoperability testing issue. DAD is actually specified in the IPv6 Address Autoconfiguration spec, not in the addressing architecture, so interoperability testing of DAD isn't necessary to advance the addressing architecture. >Those need to be fixed, but should be easy. > >But the implementation report also lacks any mention of testing, using, >or implementing the 'u' bit means "address has a globally unique IID" >feature, nor the "all unicast prefixes other than 0::/3 must be /64" >feature. The Addressing Architecture doesn't specify any behaviour related to the global uniqueness of addresses with the 'u' bit set. It does have an appendix that explains how nodes that use EUI-64 identifiers or ethernet addresses should set the 'u' bit when building IIDs for autoconfiguration. I don't know whether it is necessary to provide interoperability reports on items included in appendices, but we obviously wouldn't have any trouble finding two or more implementations that set this bit correctly. >If there are no implementations of those, then the IESG is just going >to tell the WG to delete them before the doc does to DS, isn't it? I don't think that there is any interoperability-related feature in the current addressing architecture document (including the proposed changes) that isn't implemented in two or more implementations. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 07:00:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CE053U005260; Mon, 12 Aug 2002 07:00:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CE04kr005259; Mon, 12 Aug 2002 07:00:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CDxw3U005252 for ; Mon, 12 Aug 2002 06:59:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09515 for ; Mon, 12 Aug 2002 07:00:06 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26928 for ; Mon, 12 Aug 2002 06:59:55 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7CDt7a19192; Mon, 12 Aug 2002 16:55:07 +0300 Date: Mon, 12 Aug 2002 16:55:06 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: Michel Py , Robert Elz , Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020812091932.01c3b220@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 12 Aug 2002, Margaret Wasserman wrote: > At 10:08 PM 8/11/02 , Michel Py wrote: > >Here is what I propose so we don't bore this WG to death: > > > >In Atlanta, both kre and I get a 5-minute slot to present. > > It is much better to bore the WG to death on the mailing list than it > is to do it in person :-)/2. Agree :-) > More seriously, there are three reasons why I don't think that this > is a good plan: > > - The WG is here, on the mailing list. Only a small portion > of the WG will be represented at the meeting in Atlanta. > - There is no reason to wait until November for a resolution > on this issue. Also agree, the second point most of all. We shouldn't be delaying address architecture if we can avoid that. > >Then we ask the following question to the floor: > > > >"Let's imagine that the 'u' bit does not exist. Do we remove the parts > >that mandate an address to be /64, or don't we". > > > >If the floor says that we toss the /64 boundary, my vote goes to > >suppress the 'u' bit so this can happen. If the floor says that we keep > >the /64 boundary, then my vote goes to keep the 'u' bit for the time > >being, as it does not harm anybody. > > There is no reason not to ask these questions here, on the mailing list. > The response we are looking for isn't a "vote", however... Sure, and it is a bit difficult to get a feel of consensus on an issue so many people are neutral about or ignorant of. > The current situation with the addressing architecture is that we have > established a consensus of the WG to make two changes to the document > (described in Bob's mail) and send it (back) to the IESG for consideration > as a draft standard. > > I have not seen a level of response to this thread that would lead me to > question that consensus. Have you? FWIW, I agree with Robert Elz's suggestions. Perhaps this question should be posed (with appropriate executive summary and a different topic) for the w.g. members to consider (for example a week or two would probably be enough). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 08:42:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CFgk3U005394; Mon, 12 Aug 2002 08:42:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CFgjWI005393; Mon, 12 Aug 2002 08:42:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CFge3U005386 for ; Mon, 12 Aug 2002 08:42:40 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09467 for ; Mon, 12 Aug 2002 08:42:48 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21951 for ; Mon, 12 Aug 2002 09:42:48 -0600 (MDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Mon, 12 Aug 2002 08:42:46 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E268@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt content-class: urn:content-classes:message Thread-Index: AcJCBLJ9prrsoHvCQiOq9zZJeqWV/QAC6Rog From: "Michel Py" To: "Margaret Wasserman" Cc: "Robert Elz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7CFge3U005387 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > The current situation with the addressing architecture is that > we have established a consensus of the WG to make two changes > to the document (described in Bob's mail) and send it (back) > to the IESG for consideration as a draft standard. > I have not seen a level of response to this thread that would > lead me to question that consensus. Have you? No. My opinion is that the draft should be sent back to the IESG, and I apologize if I have contributed in delaying that. Ship it, by all means. Back to the issue at hand, before you got us into that swamp, the topic was about draft-savola-ipv6-127-prefixlen-04.txt. IMHO, there are two ways to look at Pekka's draft: 1. It is irrelevant, as /127 prefixes are not supposed to exist anyway. 2. OTOH, the use of /127 is widely spread and I peer with two pTLAs using /127s myself. So the question indeed is do we want an RFC that remotely suggests that there are alternative ways to what [addrch] says, although it does provide some insight into legacy practices. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 09:53:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CGrx3U005480; Mon, 12 Aug 2002 09:53:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CGrxFF005479; Mon, 12 Aug 2002 09:53:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CGrr3U005472 for ; Mon, 12 Aug 2002 09:53:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27550 for ; Mon, 12 Aug 2002 09:53:59 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09681 for ; Mon, 12 Aug 2002 10:53:59 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 12 Aug 2002 09:53:59 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24220.D9EFE3EF" Subject: RE: IPv6 MTU for tunnel pseudo interfaces x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Date: Mon, 12 Aug 2002 09:53:58 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6BC2@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 MTU for tunnel pseudo interfaces Thread-Index: AcJAB42ZLs/NvreBRFGfa3e2Fdm4XwCGPShg From: "Mohan Parthasarathy" To: Cc: "Erik Nordmark" , X-OriginalArrivalTime: 12 Aug 2002 16:53:59.0022 (UTC) FILETIME=[DA64C8E0:01C24220] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C24220.D9EFE3EF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 >=20 > >At a minimum, implementations should be able to convert the=3D20 ICMP = > >errors happening from within the IPv4 tunnel back to ICMPV6=20 > error and=20 > >send it back to the original sender (IPv6 sender in case of=20 > IPv6 over=20 > >IPv4 tunnels). Otherwise path mtu discovery will never work assuming=20 > >you set the DF bit in the IPv4 header. if you do this, storing the=20 > >state is not really complex I guess. >=20 > if you don't set DF bit on IPv4 packet (after encapsulation), > it is not mandatory to convert ICMPv4 to ICMPv6=20 > (actually, you won't > see ICMPv4 need fragment). simpler the better. >=20 I am not really sure how much more simpler it would be (it is extra lines of code). But you are arguing that doing path mtu discovery is not useful because it would make the code complex which I don't understand. -mohan > itojun >=20 ------_=_NextPart_001_01C24220.D9EFE3EF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: IPv6 MTU for tunnel pseudo interfaces

 
>
> >At a minimum, implementations should be able = to convert the=3D20 ICMP
> >errors happening from within the IPv4 tunnel = back to ICMPV6
> error and
> >send it back to the original sender (IPv6 = sender in case of
> IPv6 over
> >IPv4 tunnels). Otherwise path mtu discovery = will never work assuming
> >you set the DF bit in the IPv4 header. if = you do this, storing the
> >state is not really complex I guess.
>
>       if you don't set = DF bit on IPv4 packet (after encapsulation),
>       it is not = mandatory to convert ICMPv4 to ICMPv6
> (actually, you won't
>       see ICMPv4 need = fragment).  simpler the better.
>
I am not really sure how much more simpler it would = be (it is extra
lines of code). But you are arguing that doing path = mtu discovery
is not useful because it would make the code complex = which I
don't understand.

-mohan

> itojun
>

------_=_NextPart_001_01C24220.D9EFE3EF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 12:36:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CJal3U005820; Mon, 12 Aug 2002 12:36:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CJaluF005819; Mon, 12 Aug 2002 12:36:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CJag3U005812 for ; Mon, 12 Aug 2002 12:36:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14651 for ; Mon, 12 Aug 2002 12:36:51 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03973 for ; Mon, 12 Aug 2002 13:36:50 -0600 (MDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7CJYtjI077306; Mon, 12 Aug 2002 15:34:56 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7CJYrou048502; Mon, 12 Aug 2002 15:34:53 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7CJWu001504; Mon, 12 Aug 2002 15:32:56 -0400 Message-Id: <200208121932.g7CJWu001504@rotala.raleigh.ibm.com> To: Robert Elz cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: Message from "Mon, 05 Aug 2002 20:34:43 +0700." <15623.1028554483@munnari.OZ.AU> Date: Mon, 12 Aug 2002 15:32:56 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Personally, I am not in favor of taking out the /64 boundary. The main reason is that I do not see signficant benefits from doing so, but I do see negative consequences from revisiting the boundary. At a minimum, the discussion leading to this kind of change is likely to be divisive, and I don't see that as being particularly good way to focus this WG's cycles. Personally, I believe it is potentially useful to have 64-bit interface identifiers in all addresses. They *could* have properties associated with them, but that is mostly future work. No need to close the door prematurely. (Note: the reason the current requirement for IIDs on all addresses except those with prefix 000 has to do with that 000 addresses are reserved for things that might well conflict with interface identifiers, such as IPv4-compatable addresses). Regarding kre's argument that globally-unique IIDs are useless and should therefore be abolished, my feeling is different. First, no one can (or is) credibly arguing that if the u bit is set a certain way, the interface ID is *guaranteed* to be globally unique. (Kre seems to assume this argument as a strawman.) However, if the u bit is set a certain way, implementations could take that as a hint that the IID is *probably* unique (or supposed to be unique), and in the case that it really cares, it could take additional steps to verify uniqueness and then use addresses with that property in a possibly different way. No one is doing that today (and I'm not advocating that they do either). However, it *might* be useful to be able to do so in the future. Whether it would be worth the effort to do the check, or what the check would be, is future work that would be done in conjunction with a proposal for how to take advantage of unique IIDs. Now, normally, I tend to resist putting in hooks that *might* be used in the future, because our track record of predicting what hooks will be needed (and getting them right) is generally rather poor. In this case, however, I believe a *lot* of people (and in particular, people mostly not in the IPv6 WG) feel pretty strongly that something like 8+8/GSE should be pursued. The current Interface ID we have leaves that door somewhat open, should a proposal come forward that the community believes can be made to work. Closing that door would likely be viewed as a slap-in-the face to those who want the door left open, and will do little to build support for IPv6 among those folk. I don't see what would be gained by doing this (rather, I see only negatives). More recently, there has been a proposal (though not particularly well received by this list) to perhaps allow other different types of indentifiers. For example, there is promising work going in with regards to embedding (parts of) public keys (or the signature of a public key) into an interface identifier in order to allow a node to "prove" it "owns" a particlar address/identifier. I'm not sure how (or if) that work will gain much traction, but again, I think it would be a mistake to close that door prematurely, because it *might* be a useful approach to solving a rather hard problem for which few options seem to be available. Getting back to the observation that some in the community are assigning /127s to the p2p links, this by itself does not imply that the interface identifier concept is inherently broken and should be removed from addrarch. Even if many operators turn out in fact to number all their p2p links this way, this will be an extremely small fraction of the total number of addressable end nodes. Thus, in practice, enough end nodes may be using 64-bit IIDs in order for the uniquness properties (as described above) to be useful enough to take advatange of. Obviously, those nodes that don't follow the scheme wouldn't be able to take advatange, but that may not matter. Future work can figure that out. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 12:37:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CJbr3U005830; Mon, 12 Aug 2002 12:37:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CJbr5K005829; Mon, 12 Aug 2002 12:37:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CJbk3U005822 for ; Mon, 12 Aug 2002 12:37:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28302 for ; Mon, 12 Aug 2002 12:37:55 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04968 for ; Mon, 12 Aug 2002 13:37:54 -0600 (MDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7CJa2jI143886; Mon, 12 Aug 2002 15:36:06 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7CJa0ou078598; Mon, 12 Aug 2002 15:36:00 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7CJY4101527; Mon, 12 Aug 2002 15:34:04 -0400 Message-Id: <200208121934.g7CJY4101527@rotala.raleigh.ibm.com> To: Margaret Wasserman cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: Message from "Wed, 07 Aug 2002 09:37:33 EDT." <4.2.2.20020807085415.00aa1270@mail.windriver.com> Date: Mon, 12 Aug 2002 15:34:04 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman writes: > At that time, it didn't seem like a big issue to add a hard /64 > boundary into the IPv6 address, because we already had several > hard boundaries in our addresses to provide separate fields for > aggregation (the TLA/SLA stuff). Since then, we have removed the > other hard boundaries and moved to a CIDR-like address structure, > but we have maintained the hard /64 boundary, and required Modfied > EUI-64 IIDs for all global unicast addresses. > There are some major advantages to retaining this hard /64 boundary: > - It makes autoconfiguration simpler, since all prefixes are > /64s and all IIDs are 64-bits long. It would require > major, and inadvisable, changes to autoconfiguration to > allow autoconfiguration using prefixes longer than /64. It's more than just autoconfig. Right now, End sites can expect to get a /48, and they get use the 16 bits between a /48 and /64 anyway they care. If a site switches providers, it knows it will get 16 bits again, and it konws that it needs to (only) renumber the upper 48 bits. This is both simple and powerful. This comes in large part from the uniform /64 boundary between the adddress and the IID. If that were removed, it would potentially reopen discussion about which bits and end site should get for subnet addressing, with different people possibly being given different ranges and (even worse) different amounts. I think this would be a bad direction for us to go in. I don't see what the benefit would be, but I can surely see a number of non-productive areas we'd surely rathole on. > But, what I think this WG needs to think about and understand is _why_ > operators are using longer prefixes on their router-to-router links. This is a key question. Just because operators are doing this, doesn't mean they should or that we should just give in and say "I guess we should give in to reality". There is a cost/benefit of sticking with the /64 boundary. Before moving away from it, we really need to understand the cost/benefit of the alternative. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 12:46:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CJkX3U005873; Mon, 12 Aug 2002 12:46:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CJkWaK005872; Mon, 12 Aug 2002 12:46:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CJkR3U005865 for ; Mon, 12 Aug 2002 12:46:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29998 for ; Mon, 12 Aug 2002 12:46:36 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23867 for ; Mon, 12 Aug 2002 13:46:35 -0600 (MDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7CJj5A1023904; Mon, 12 Aug 2002 15:45:10 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7CJj4YU085852; Mon, 12 Aug 2002 13:45:04 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7CJh6D01614; Mon, 12 Aug 2002 15:43:06 -0400 Message-Id: <200208121943.g7CJh6D01614@rotala.raleigh.ibm.com> To: Bill Manning cc: mrw@windriver.com (Margaret Wasserman), kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: Message from "Wed, 07 Aug 2002 10:29:23 PDT." <200208071729.g77HTOi08207@boreas.isi.edu> Date: Mon, 12 Aug 2002 15:43:06 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Manning writes: > % If there are sound reasons to use longer prefixes in some cases, we > % may not want to have an addressing architecture that forbids it. But, > % I haven't seen anyone speak up with those reasons. > CIDR. address conservation. Just because it looks like > an in-exaustable greenfield, does not make it so. We -WILL- > run out at some point. Presumably you have read RFC 3177. Nobody disputes that we will someday run out even of IPv6 addresses. But most believe that we have enough addresses that even if we give out lots of /48s and /64s, we aren't going to run out of addresses quickly enough to worry about this. So the idea that we need to number p2p links with longer prefixes in order to conserve addresses seems pretty silly to me. There will be very few p2p links in practice compared to end sites (which will need at least a /64 in order to do stateless addrconf). Thus, my read of your comment is that your real disagreement is with the overall /64 boundary and that you would like us to revisit a number of basic decisions with the ultimate goal of giving end sites not a /48 or /64, but something much longer. Or am I misreading your words? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 12:52:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CJq53U005899; Mon, 12 Aug 2002 12:52:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CJq5b6005898; Mon, 12 Aug 2002 12:52:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CJpx3U005891 for ; Mon, 12 Aug 2002 12:51:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02751 for ; Mon, 12 Aug 2002 12:52:09 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13307 for ; Mon, 12 Aug 2002 13:52:08 -0600 (MDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7CJokjI102752; Mon, 12 Aug 2002 15:50:50 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7CJoieR014956; Mon, 12 Aug 2002 15:50:45 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7CJmmW01644; Mon, 12 Aug 2002 15:48:48 -0400 Message-Id: <200208121948.g7CJmmW01644@rotala.raleigh.ibm.com> To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: Message from "Wed, 07 Aug 2002 22:48:44 PDT." <2B81403386729140A3A899A8B39B046405E252@server2000.arneill-py.sacramento.ca.us> Date: Mon, 12 Aug 2002 15:48:48 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Note about this: My reading is that there still is a semi-hard boundary > at /48, (site) and I think this is good. If you are talking about addrarch, please point out the words that lead you think this. There is *no* technical hard boundary at /48. There is a *policy* or *allocation* boundary, and there are technical reasons why such a boundary make sense, but implementations should not have any sort of /48 boundary hard-wired into the code. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 13:09:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CK9K3U005940; Mon, 12 Aug 2002 13:09:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CK9JTE005939; Mon, 12 Aug 2002 13:09:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CK9E3U005932 for ; Mon, 12 Aug 2002 13:09:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07857 for ; Mon, 12 Aug 2002 13:09:24 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05064 for ; Mon, 12 Aug 2002 14:09:23 -0600 (MDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7CK77RY106028; Mon, 12 Aug 2002 16:07:07 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7CK76YU075426; Mon, 12 Aug 2002 14:07:06 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7CK59C01751; Mon, 12 Aug 2002 16:05:09 -0400 Message-Id: <200208122005.g7CK59C01751@rotala.raleigh.ibm.com> To: Robert Elz cc: "Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: Message from "Sat, 10 Aug 2002 17:01:49 +0700." <18986.1028973709@munnari.OZ.AU> Date: Mon, 12 Aug 2002 16:05:08 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > As I recall, the only argument I've ever heard, is that the 'u' bit is > important, because sometime in the future someone might come up with some > scheme that will allow these "globally unique" IIDs to be treated specially > for some purpose or other. And even though that's just wild speculation, > I could almost buy that (I'm one of the people who doesn't mind making > allowances for things that might happen in the future in general, even if > we don't know what they are) - except that no-one has been able to tell me > how we would ever cope with devices that simply have no idea if their > MAC address is globally unique or not (and so really, in this interpretation > would have to always leave the 'u' bit clear in all addresses - I can > easily show that KAME would be broken according to this interpretation for > example - that is, I can have it autoconfigure addresses with the 'u' bit > set where the IID isn't globally unique - and I certainly can't imagine > a way the KAME people could fix it, other than by never setting 'u'), and > perhaps more importantly, as that one can always be hand waved away as a > "configuration error" (though the imaginary protocol using this would have > to deal with it, somehow) how we deal with address stability when a MAC > address changes, so the IPv6 address is no longer based upon an EUI-64, > though it used to be. You seem to be wanting to require that if the u-bit is set, it is *guaranteed* to be globally unique. No one can make such a guarantee, of course. I have always viewed the u bit a way of indicating that the IID is probably unique, with a high degree of likelyhood. This is achieved by setting the u bit to 1, iff the ID is derived from an IEEE identifier. > So, let me turn the question around. Is there anyone out there who believes > the draft should stay as it is (in this area) and who is willing to attempt > to explain why? I've tried to do so in another note. > If there's no-one, then to me that looks like consensus for a change... Not so fast. To change the status quo, one needs more than just a couple of people saying "yes" and the vast majority of the community being silent. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 13:16:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CKG13U005986; Mon, 12 Aug 2002 13:16:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CKG12m005985; Mon, 12 Aug 2002 13:16:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CKFr3U005978 for ; Mon, 12 Aug 2002 13:15:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10332 for ; Mon, 12 Aug 2002 13:16:03 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08729 for ; Mon, 12 Aug 2002 14:16:03 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA07330; Mon, 12 Aug 2002 13:12:10 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA07942; Mon, 12 Aug 2002 13:12:09 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id NAA08013; Mon, 12 Aug 2002 13:12:50 -0700 (PDT) Date: Mon, 12 Aug 2002 13:12:50 -0700 (PDT) From: Tim Hartrick Message-Id: <200208122012.NAA08013@feller.mentat.com> To: kre@munnari.oz.au, narten@us.ibm.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > Getting back to the observation that some in the community are > assigning /127s to the p2p links, this by itself does not imply that > the interface identifier concept is inherently broken and should be > removed from addrarch. Even if many operators turn out in fact to > number all their p2p links this way, this will be an extremely small > fraction of the total number of addressable end nodes. Thus, in > practice, enough end nodes may be using 64-bit IIDs in order for the > uniquness properties (as described above) to be useful enough to take > advatange of. Obviously, those nodes that don't follow the scheme > wouldn't be able to take advatange, but that may not matter. Future > work can figure that out. > I am agreement with all the points that Thomas makes. The point above needs further emphasis. Simply because some operators use a /(n>64) for point to point links does not mean that all operators will or should do the same. I believe, that it is a good thing that implementations allow this type of flexability but the existence of that flexability in implementations doesn't require that the specifications change in order to bless the assignment of /(n>64) prefixes to point to point links. If there are implementations which "hard-code" the /64 boundary then so be it. The marketplace will sort out whether that is a good or bad thing. We have implementations of specifications which clearly work. Let's stop messing around with them and work on the things that are really critical to making IPv6 deployment possible. This isn't one of those things. Aside: When the GSE discussion was going on N years ago, I was fore square against the /64 boundary for all the reasons that others have brought up in this latest thread. That is, the dubious basis for assuming that a globally unique identifier is possible, the address space waste. etc. I lost the argument. I can live with it. It sure would be nice if decisions made in this WG had a half-life of longer than four years. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 13:18:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CKHx3U006014; Mon, 12 Aug 2002 13:17:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CKHd09006013; Mon, 12 Aug 2002 13:17:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CKHX3U006006 for ; Mon, 12 Aug 2002 13:17:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28881 for ; Mon, 12 Aug 2002 13:17:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28537 for ; Mon, 12 Aug 2002 14:17:42 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7CKE7X00428; Mon, 12 Aug 2002 13:14:07 -0700 (PDT) From: Bill Manning Message-Id: <200208122014.g7CKE7X00428@boreas.isi.edu> Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208121943.g7CJh6D01614@rotala.raleigh.ibm.com> from Thomas Narten at "Aug 12, 2 03:43:06 pm" To: narten@us.ibm.com (Thomas Narten) Date: Mon, 12 Aug 2002 13:14:07 -0700 (PDT) Cc: bmanning@ISI.EDU, mrw@windriver.com, kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % Thus, my read of your comment is that your real disagreement is with % the overall /64 boundary and that you would like us to revisit a % number of basic decisions with the ultimate goal of giving end sites % not a /48 or /64, but something much longer. % % Or am I misreading your words? I am in favor of delegating -only- the space needed. I am more concerned with a hard boundary being set, perpetuating the fiction that the address identifies the node, not where it is in the topology. Mixing these two properties has been a problem for some time. IPv6 was a chance to divorce the two. I am afraid that this is a lost opportunity. % Thomas --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 13:37:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CKb23U006068; Mon, 12 Aug 2002 13:37:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CKb2ID006067; Mon, 12 Aug 2002 13:37:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CKau3U006060 for ; Mon, 12 Aug 2002 13:36:56 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06569 for ; Mon, 12 Aug 2002 13:37:06 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19479 for ; Mon, 12 Aug 2002 13:37:05 -0700 (PDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Mon, 12 Aug 2002 13:37:03 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E26B@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt content-class: urn:content-classes:message Thread-Index: AcJCOc70dKkXUvfAQu+vgGv0+fl+5AAAbwqg From: "Michel Py" To: "Thomas Narten" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7CKau3U006061 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >> Michel Py wrote: >> Note about this: My reading is that there still is a >> semi-hard boundary at /48, (site) and I think this is good. > Thomas Narten wrote: > If you are talking about addrarch, please point out the > words that lead you think this. There is *no* technical > hard boundary at /48. There is a *policy* or *allocation* > boundary, and there are technical reasons why such a boundary > make sense, I was talking about the policy part, see below. > but implementations should not have any sort of /48 boundary > hard-wired into the code. Agree. > Right now, End sites can expect to get a /48, This is what I called earlier a semi-hard boundary. Not part of the Addressing Architecture, but assumed by many nevertheless. > and they get use the 16 bits between a /48 and /64 anyway > they care. If a site switches providers, it knows it will > get 16 bits again, and it konws that it needs to (only) > renumber the upper 48 bits. This is both simple and powerful. Yep, and the same reasoning also applies to 6to4, so people that have choose to use 6to4 as a short-term mechanism will also greatly benefit from the fact that a site, although not defined in [addrarch], is also a /48. >> But, what I think this WG needs to think about and understand >> is _why_ operators are using longer prefixes on their >> router-to-router links. > This is a key question. Just because operators are doing this, > doesn't mean they should or that we should just give in and say > "I guess we should give in to reality". "Just because _some_ operators are doing it" seems more appropriate to me. Especially on the 6bone, private discussions I had with them have shown that the use of /127s is mostly a post-cidr v4 withdrawal, and most of them would gladly renumber all their ptp links, if only they had more time. I agree with the rest of your postings. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 14:31:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CLVK3U006218; Mon, 12 Aug 2002 14:31:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CLVJE3006217; Mon, 12 Aug 2002 14:31:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CLVE3U006210 for ; Mon, 12 Aug 2002 14:31:14 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10016 for ; Mon, 12 Aug 2002 14:31:22 -0700 (PDT) Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21390 for ; Mon, 12 Aug 2002 14:31:21 -0700 (PDT) Received: from us-ea-gtwy-7.ea.unisys.com (us-ea-gtwy-7.ea.unisys.com [192.61.145.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id VAA11591; Mon, 12 Aug 2002 21:28:45 GMT Received: by us-ea-gtwy-7.ea.unisys.com with Internet Mail Service (5.5.2655.55) id ; Mon, 12 Aug 2002 16:31:19 -0500 Message-ID: From: "Sellers, Julian P" To: "'Bob Hinden'" , IPv6 List Subject: RE: Changes to IPv6 Addressing Architecture Draft Date: Mon, 12 Aug 2002 16:31:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > > Change to second sentence in the first paragraph of section 2.5.1: > > Interface identifiers in IPv6 unicast addresses are used to identify > interfaces on a link. They are required to be unique within a subnet | > prefix. They may also be unique over a broader scope. In some cases | > an interface's identifier will be derived directly from that > interface's link-layer address. The same interface identifier may be > used on multiple interfaces on a single node, as long as they are > attached to different links. The last sentence of the paragraph is no longer correct. The addresses ::1 and ::1 can be on the same link and even on the same interface. In addition, I see no need for the two sentences that precede that sentence or for the paragraph that follows it. Appendix A needs changes also. Under the heading "Links without Identifiers", I find five references to link-unique interface IDs instead of subnet-prefix-unique interface IDs. Julian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 14:39:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CLdU3U006254; Mon, 12 Aug 2002 14:39:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CLdUNN006253; Mon, 12 Aug 2002 14:39:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CLdP3U006246 for ; Mon, 12 Aug 2002 14:39:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07803 for ; Mon, 12 Aug 2002 14:39:33 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12964 for ; Mon, 12 Aug 2002 14:39:33 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 12 Aug 2002 14:41:35 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Robert Elz'" Cc: Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Mon, 12 Aug 2002 14:39:29 -0700 Message-ID: <00f501c24248$bcfa3d30$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4.2.2.20020805094649.024b9ed0@mail.windriver.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7CLdP3U006247 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > In the Yokohama meeting, Steve Deering lead a discussion on > the uniqueness of IIDs, and there was a pretty big majority > of people in the room who thought that we shouldn't even > require IIDs to > be unique on a link. But nobody asked how many of that majority had any clue about actually operating a network. The question was should we allow flexibility, and completely ignored the confusion that will be caused trying to explain to first line operators that on subnet A all addresses with the same IID map to a single node, but on subnet B they don't. They are going to have a hard enough time with multiple addresses per node, we should not be making it more complex by allowing shared IIDs on a link. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 15:56:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CMuZ3U006486; Mon, 12 Aug 2002 15:56:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CMuZWV006485; Mon, 12 Aug 2002 15:56:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CMuT3U006478 for ; Mon, 12 Aug 2002 15:56:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00316 for ; Mon, 12 Aug 2002 15:56:39 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22310 for ; Mon, 12 Aug 2002 15:56:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id D5E4A7D60; Tue, 13 Aug 2002 00:57:27 +0200 (CEST) Received: from HELL (hell.unfix.org [::ffff:10.100.13.66]) by purgatory.unfix.org (Postfix) with ESMTP id DF0917761; Tue, 13 Aug 2002 00:57:14 +0200 (CEST) From: "Jeroen Massar" To: "'Tim Hartrick'" , , Cc: , Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Tue, 13 Aug 2002 00:54:52 +0200 Organization: Unfix Message-ID: <002e01c24253$455ff2f0$420d640a@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.3416 Importance: Normal In-Reply-To: <200208122012.NAA08013@feller.mentat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Razor-id: 1b03634cd32b32559fe057da63b6935159a319e9 X-Spam-Status: No, hits=-3.4 tests=IN_REP_TO Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Hartrick wrote: > All, > > > > > Getting back to the observation that some in the community are > > assigning /127s to the p2p links, this by itself does not imply that > > the interface identifier concept is inherently broken and should be > > removed from addrarch. Even if many operators turn out in fact to > > number all their p2p links this way, this will be an extremely small > > fraction of the total number of addressable end nodes. Thus, in > I am agreement with all the points that Thomas makes. The point above > needs further emphasis. Simply because some operators use a > /(n>64) for point to point links does not mean that all operators will or > should do the same. The only reason that we use a /127 at IPng.nl is because those tunnels aren't going to be native links ever. For links that could once be turned over to native links one should use a /64, and using /64 for these people is simply a waste of space even if there is enough. Same that we give out /60's, most people behind cable modems don't even have more than 1 subnet and the project is for learning. On a side note we picked /127 & /60's before the other drafts where there ;) Also the SixXS project is going to advise /64's on tunnels and /48's as subnet blocks, though that all depends on the TLA's policy ofcourse.. it's their space in that case ;) As for my opinion on /64's per link and maybe making them smaller.... why should one.. this works perfectly. Ofcourse one could also opt for a: - pick random hostprefix of n bits (eg.. if you get a /100 from the RA, one picks ::123) - check with ND if it is in use - use it. But this is ugly, and if you once have a /80 and then go to a /100 you will have problems renumbering. As addresses will change in that case, now one can trust to have a /64 for each link. And how one picks a hostprefix... EUI-64 works great, so why change it ? Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 16:05:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CN5t3U006519; Mon, 12 Aug 2002 16:05:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CN5txt006518; Mon, 12 Aug 2002 16:05:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CN5n3U006511 for ; Mon, 12 Aug 2002 16:05:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07303 for ; Mon, 12 Aug 2002 16:05:58 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10981 for ; Mon, 12 Aug 2002 17:05:58 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA07344; Mon, 12 Aug 2002 16:05:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7CN5uI11014; Mon, 12 Aug 2002 16:05:56 -0700 X-mProtect: <200208122305> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdW0Uh2u; Mon, 12 Aug 2002 16:05:54 PDT Message-Id: <4.3.2.7.2.20020812160335.03027150@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Aug 2002 16:04:44 -0700 To: "Sellers, Julian P" From: Bob Hinden Subject: RE: Changes to IPv6 Addressing Architecture Draft Cc: IPv6 List In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Julian, Thanks for catching this. I will fix this before publishing a new ID. Bob At 02:31 PM 8/12/2002, Sellers, Julian P wrote: >Bob Hinden wrote: > > > > Change to second sentence in the first paragraph of section 2.5.1: > > > > Interface identifiers in IPv6 unicast addresses are used to identify > > interfaces on a link. They are required to be unique within a subnet | > > prefix. They may also be unique over a broader scope. In some cases | > > an interface's identifier will be derived directly from that > > interface's link-layer address. The same interface identifier may be > > used on multiple interfaces on a single node, as long as they are > > attached to different links. > >The last sentence of the paragraph is no longer correct. The addresses >::1 and ::1 can be on the same link and even on the same >interface. In addition, I see no need for the two sentences that precede >that sentence or for the paragraph that follows it. > >Appendix A needs changes also. Under the heading "Links without >Identifiers", I find five references to link-unique interface IDs instead of >subnet-prefix-unique interface IDs. > >Julian >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 16:08:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CN8e3U006553; Mon, 12 Aug 2002 16:08:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7CN8etq006552; Mon, 12 Aug 2002 16:08:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7CN8Y3U006545 for ; Mon, 12 Aug 2002 16:08:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04946 for ; Mon, 12 Aug 2002 16:08:44 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28457 for ; Mon, 12 Aug 2002 16:08:44 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 12 Aug 2002 16:10:46 -0700 Reply-To: From: "Tony Hain" To: "'Bob Hinden'" , "'IPv6 List'" Subject: RE: Changes to IPv6 Addressing Architecture Draft Date: Mon, 12 Aug 2002 16:08:39 -0700 Message-ID: <00f601c24255$33058b90$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7CN8Z3U006546 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > At the IPv6 working group sessions at the Yokohama IETF two > changes to the > IP Version 6 Addressing Architecture draft > > > > were discussed. These changes were proposed based on > feedback received > from our area director and email discussion on the mailing > list. A summary > of the AD comments is include at the end of the email. > > The changes that were proposed at the meeting were to relax > the interface > identifier uniqueness requirements (from the link to subnet > prefix) and to > change the definition of Site-Local addresses to make the > subnet field > 54-bits (and eliminate the 38-bit zero field). > > After discussing the proposed changes, a consensus was reached at the > Yokohama meeting to make them. The purpose of this email is > to validate > that consensus on the mailing list and to review the specific > changes to > the internet draft. What wasn't asked at Yokohama was how many people had operational clue about the consequences of these decisions. > > The proposed changes (changed lines marked by "|") to the ID > are as follows: > > Change to second sentence in the first paragraph of section 2.5.1: > > Interface identifiers in IPv6 unicast addresses are used to identify > interfaces on a link. They are required to be unique > within a subnet | > prefix. They may also be unique over a broader scope. In > some cases | > an interface's identifier will be derived directly from that > interface's link-layer address. The same interface > identifier may be > used on multiple interfaces on a single node, as long as they are > attached to different links. While it might sound theoretically nice to be able to reuse an IID on multiple nodes on a single subnet, the operational reality is that it will be confusing and never used in practice. It will be difficult enough to get first line operators to understand the concept of multiple addresses per node and multiple prefixes per subnet. If we allow the possibility that an IID might point to different nodes on some wires, but the same node on other wires, we will have exceeded any reasonable ability to train the operations staff. This is a bad idea that doesn't provide any compelling value to begin with, so why change it? The only reason I have heard is that changing it will make it clear that DIID is insufficient. Solving that problem is better done by stating that DAD is required, and leave this text as it was. > > and from section 2.5.6 where site-local is defined: > > Site-Local addresses have the following format: > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111011| subnet ID | interface ID > | | > +----------+-------------------------+----------------------------+ > > Site-local addresses are designed to be used for addressing > inside of > a site without the need for a global prefix. Although a > subnet ID may | > be up to 54-bits long, it is expected that most > globally-connected | > sites will use the same subnet IDs for site-local and > global prefixes. | > To be clear, I agree with the Site-local change. Tony > > If there is agreement with these changes I will submit a new > draft (-09) > that the area directors can proceed with. > > Bob > > ------------------------------------------------------------------- > > Comments from Thomas Narten: > > >1) The -07 ID contains the wording: > > > > > Interface identifiers in IPv6 unicast addresses are > used to identify > > > interfaces on a link. They are required to be unique on that > > > link. > > > >Given the on-going issues surrounding DAD vs DIID, I felt it > >appropriate to check with the WG whether this wording was > indeed what > >the WG believed the architecture should require. > > > >2) The -07 ID contains the wording: > > > > > Site-Local addresses have the following format: > > > > > > | 10 | > > > | bits | 38 bits | 16 bits | 64 bits > | > > > > +----------+-------------+-----------+----------------------------+ > > > |1111111011| 0 | subnet ID | interface > ID | > > > > > > > +----------+-------------+-----------+----------------------------+ > > > >Given that the fixed 16-bit subnet ID in global addresses > was changed > >to one having a flexible boundary, the subnet ID in > site-locals should > >also not have a fixed boundary. Note that other parts of > the document > >showing addresses were updated to use generic "m" bits, rather than > >fixing the field at 16 bits, under the concern that implementations > >*might* somehow hardcode the boundary in their implementations. > > > >Also, it might be good to clarify that the middle bits are undefined > >and should be 0. I.e., implementors could interpret the > above words as > >saying the bits are defined to always be zero (as opposed to just > >reserved for future use and MUST be zero), which could lead > >implementations to somehow check that those bits are 0, and > if not, do > >something incorrect (like signal an error). > > > >The specific text that was proposed and discussed at the Yokohama > >meeting addresses the main concern I had. > > > >At the meeting, there were still some folks that seemed unhappy with > >the proposed change. I'd be interested in understand why. > Only itojun > >spoke up on this point, and he stated this would make site-local > >addresses more attractive, which he didn't consider a feature. :-) > > > >Thomas > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 17:05:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D05W3U006674; Mon, 12 Aug 2002 17:05:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7D05Ve2006673; Mon, 12 Aug 2002 17:05:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D05Q3U006666 for ; Mon, 12 Aug 2002 17:05:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24449 for ; Mon, 12 Aug 2002 17:05:36 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23102 for ; Mon, 12 Aug 2002 17:05:36 -0700 (PDT) Received: from kenawang ([147.11.233.24]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA23536; Mon, 12 Aug 2002 17:05:01 -0700 (PDT) Message-Id: <4.2.2.20020812193702.0229b870@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 12 Aug 2002 19:57:43 -0400 To: From: Margaret Wasserman Subject: RE: Changes to IPv6 Addressing Architecture Draft Cc: "'Bob Hinden'" , "'IPv6 List'" In-Reply-To: <00f601c24255$33058b90$011aa8c0@eagleswings> References: <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >While it might sound theoretically nice to be able to reuse an IID on >multiple nodes on a single subnet, the operational reality is that it >will be confusing and never used in practice. IID uniqueness on a link is an artificial restriction: We don't check for it with DAD, and not other part of the IPv6 architecture depends on it. Leaving it in will complicate privacy addresses and some other situations, and taking it out does not actually require operators to number their networks in a confusing fashion. In practice, permanant addresses probably won't have overlapping IIDs. Autoconfigured addresses will never have overlapping IIDs because there will always be a corresponding link-local address that is check for uniqueness with DAD. And, I expect you are correct that operators will not manually configure multiple nodes on a link to use the same IID. However, there are two cases where overlapping IIDs may occur: - Randomly-generated IIDs used for privacy addresses. To prevent the possibility of overlapping IIDs in this case, we'd have to generate a link-local address and perform DAD on it (or some equivalent), in addition to performing DAD on the privacy address. - Two separate subnets that are merged onto a single physical network (due to topology changes, etc.). If these were manually configured networks, its likely that both sets of IIDs will include the same low numbers. However, the original global and site-local addresses could still be distinguished by their different subnet IDs, so why require the IIDs to change? I don't see any reason why we should keep an artificial restriction in the addressing architecture that would complicate either of these cases. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 17:59:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D0xV3U006771; Mon, 12 Aug 2002 17:59:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7D0xV9a006770; Mon, 12 Aug 2002 17:59:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D0xP3U006763 for ; Mon, 12 Aug 2002 17:59:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10159 for ; Mon, 12 Aug 2002 17:59:34 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16110 for ; Mon, 12 Aug 2002 17:59:33 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 12 Aug 2002 18:01:32 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: "'Bob Hinden'" , "'IPv6 List'" Subject: RE: Changes to IPv6 Addressing Architecture Draft Date: Mon, 12 Aug 2002 17:59:25 -0700 Message-ID: <010e01c24264$ab7157d0$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4.2.2.20020812193702.0229b870@mail.windriver.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7D0xP3U006764 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > > >While it might sound theoretically nice to be able to reuse > an IID on > >multiple nodes on a single subnet, the operational reality > is that it > >will be confusing and never used in practice. > > IID uniqueness on a link is an artificial restriction: We > don't check for it with DAD, and not other part of the IPv6 > architecture depends on it. Leaving it in will complicate > privacy addresses and some other situations, and taking it > out does not actually require operators to number their > networks in a confusing fashion. > > In practice, permanant addresses probably won't have > overlapping IIDs. Autoconfigured addresses will never have > overlapping IIDs because there will always be a corresponding > link-local address that is check for uniqueness with DAD. > And, I expect you are correct that operators will not > manually configure multiple nodes on a link to use the same IID. > > However, there are two cases where overlapping IIDs may occur: > > - Randomly-generated IIDs used for privacy addresses. > To prevent the possibility of overlapping IIDs in > this case, we'd have to generate a link-local > address and perform DAD on it (or some equivalent), > in addition to performing DAD on the privacy address. And the problem with running an additional DAD is??? LL with privacy IIDs make no sense, so why wouldn't the node just configure all the available prefixes and defend them directly? Even without the LL-DAD, the only case where a collision would not be detected is when a subnet has multiple prefixes, but nodes are not configured to use all of them. In real networks, the likelyhood that some nodes on a wire would use one prefix while others use a different one is so close to 0 that it shouldn't be special cased. > > - Two separate subnets that are merged onto a single > physical network (due to topology changes, etc.). > If these were manually configured networks, its > likely that both sets of IIDs will include the > same low numbers. However, the original global > and site-local addresses could still be distinguished > by their different subnet IDs, so why require the > IIDs to change? Because it will happen anyway to avoid the operator confusion of multiple nodes with the same IID. I can appreciate the desire to perpetuate legacy procedures and allow the concept of 2 logical subnets on the same wire, but with the IPv6 concept of multiple prefixes per subnet, that becomes a real mess. Since these are theory, what happens in the merge example if both sites were using autoconf based on configured macs of 1,2,3...? In the real world when 2 subnets are merged, one or both of them require reunmbering, so why should we change the address architecture to allow a case that might someday make creating a confusing mess easy? > > I don't see any reason why we should keep an artificial > restriction in the addressing architecture that would > complicate either of these cases. Because they are theoretical scenarios, not something that a network operator would expect to have work. > > Margaret > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 19:34:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D2Yc3U006912; Mon, 12 Aug 2002 19:34:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7D2Ycux006911; Mon, 12 Aug 2002 19:34:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D2YW3U006904 for ; Mon, 12 Aug 2002 19:34:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA09653 for ; Mon, 12 Aug 2002 19:34:41 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07977 for ; Mon, 12 Aug 2002 19:34:41 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 90E595A6A; Mon, 12 Aug 2002 22:34:40 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 12 Aug 2002 22:34:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAD vs. DIID Date: Mon, 12 Aug 2002 22:34:39 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcI/rmp70zZgfkqITKqjNTqLL8GBZgCwvUnQ From: "Bound, Jim" To: "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 13 Aug 2002 02:34:40.0436 (UTC) FILETIME=[F97EA740:01C24271] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7D2YX3U006905 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, As long as if two networks merge the following is strictly prohibited: two nodes now appear on the network with: 4ff3::2 4ff3::2 So if two networks heal or merge then DAD must be performed fixed per addr conf as you suggest. That is not what got presented at Yokohama. The other issue I have is an implementation one. If we do this and I am not 100% convinced it is required or what problem we are solving and that would be nice to see. The implementation is that if two nodes have competing implementations. If one node checks the entire address and the other does not then we could end up with in practice in the field with what I want to be prohibited. I also need to think on other architecture ramifications to current implementation like the way we account for duplicate prefixes combined with EUI. thanks /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, August 09, 2002 9:59 AM > To: Robert.Peschi@alcatel.be > Cc: ipng@sunroof.eng.sun.com > Subject: Re: DAD vs. DIID > > > > Hi Robert, > > >Maybe I am missing something here, but, if the > >Interface Identifier is not unique anymore on a > >link, what is it then supposed to identify and > >be used for ? > > The suggestion doesn't change the purpose of an IID, just > the scope of its uniqueness. > > In the current (pre-change) addressing architecture, an IID > is unique on the link. So, within the scope of a given link, > the IID can be used to identify a particular interface (and, > by extension, a given node). > > This change would modify the scope of that uniqueness to be > a subnet prefix, not the whole link. So, within a set of > interfaces using a particular subnet prefix, the IID would > identify a particular interface. Most links will have > multiple subnet prefixes in use, because they will have a > link-local prefix and a global prefix. Some links may have > many subnet prefixes in use (link-local, one or more > site-local subnets and one or more global subnets). > > Have you seen the slides that Steve Deering presented on > this subject? If they aren't already up on the IETF > proceedings page, they should be shortly. They give an > example of what this means. > > Although the wording is fairly arcane in order to be > exactly correct, the real change comes down to this: > > OLD: IIDs are required to be unique on a link. > > NEW: Only complete addresses are required to > be unique on a link. > > Relaxing the restriction to the second case makes the use of > privacy addresses easier, it doesn't require any major changes > to implementations (we are already doing Duplicate _Address_ > Detection, not Duplicate IID Detection), and it meets the > requirements to uniquely identify a node for communication. > > A side-effect of this change is that we will need to update > the Address Autoconfiguration spec to require the use of DAD > on all addresses, and not allow the currently documented > optimization to only perform DAD on the link-local address. > > I can only think of two cases where the same IID would get used > for different hosts on the same link: > > - If some hosts on the link do not configure global > addresses, but others do. > > - If there are two (or more) subnets running over the > same link, and not all of the hosts on the > link are members of both (or all) subnets. > > >Also, how would then the Link Local address be formed ? > > Not all IIDs are used to create link-local addresses. An > interface is required to have at least one link-local address, > and the IID used to create that address must be different than > the IIDs used to create link-local addresses on other interfaces > on the same link (as required by the per-subnet uniqueness clause, > and as checked by DAD). But it is not necessary, for example, to > create link-local addresses with the randomly generated IIDs used > to create privacy addresses. > > It is important for folks to understand what we are changing > here, so please let me know if any of the above is confusing > or unclear. > > Margaret > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 19:38:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D2c23U006929; Mon, 12 Aug 2002 19:38:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7D2c26v006928; Mon, 12 Aug 2002 19:38:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D2bu3U006921 for ; Mon, 12 Aug 2002 19:37:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA10192 for ; Mon, 12 Aug 2002 19:38:00 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03572 for ; Mon, 12 Aug 2002 20:38:00 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 018995A63; Mon, 12 Aug 2002 22:38:00 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 12 Aug 2002 22:37:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAD vs. DIID Date: Mon, 12 Aug 2002 22:37:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcI/vveAsEHjeJ1ERSCytzX75k6tIgCs0Ozw From: "Bound, Jim" To: "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 13 Aug 2002 02:37:59.0919 (UTC) FILETIME=[706557F0:01C24272] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7D2bv3U006922 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, August 09, 2002 12:05 PM > To: Robert.Peschi@alcatel.be > Cc: ipng@sunroof.eng.sun.com > Subject: Re: DAD vs. DIID > > > > Hi Robert, > > >Though, it is not entirely clear to me why > >the /subnet IID uniqueness rather than the /link > >uniqueness makes the case of privacy addresses easier. > > To ensure IID uniqueness on a link, a node that implements > privacy addresses would need to generate a link-local > address for each randomly generated IID (in addition to the > global address generated for privacy), perform DAD on > that address, and maintain that address for the lifetime > of the privacy address in order to respond to other nodes' > DAD messages. > > If we only require IIDs to be unique within a subnet, > a node that implements privacy addresses will only need > to generate the single privacy address and perform > DAD for that address. > > As currently document (prior to the discussed changes) > the privacy document is incompatible, in this minor way, > with the addressing architecture and the autoconfiguration > documents. We had two options for what to change: > > - Relax the uniqueness restriction in the > addressing architecture, and make > a corresponding change to the > autoconfiguration document. > -OR- > - Modify the privacy address document to > require the creation and maintenance of > link-local addresses, as described above. > > We had a consensus within the room in Yokohama to choose > the first option, and we are currently checking that > consenus with the list. We had no such consensus. In fact it was stated we had to take this to the mail list. Many of us were concerned that we wanted to know what problem we are trying to solve. That has been stated by your mail now and that is good. But now we need to discuss the ramifications on this list and if it is warranted. regards, /jim > > Margaret > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 12 19:41:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D2fb3U006951; Mon, 12 Aug 2002 19:41:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7D2faiY006950; Mon, 12 Aug 2002 19:41:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7D2fV3U006943 for ; Mon, 12 Aug 2002 19:41:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01402 for ; Mon, 12 Aug 2002 19:41:40 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA14808 for ; Mon, 12 Aug 2002 20:41:39 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2818962F6; Mon, 12 Aug 2002 22:41:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 12 Aug 2002 22:41:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAD vs. DIID Date: Mon, 12 Aug 2002 22:41:31 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcI/vveAsEHjeJ1ERSCytzX75k6tIgCs4q3g From: "Bound, Jim" To: "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 13 Aug 2002 02:41:31.0995 (UTC) FILETIME=[EECD92B0:01C24272] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7D2fV3U006944 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, To the technical discourse below. > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, August 09, 2002 12:05 PM > To: Robert.Peschi@alcatel.be > Cc: ipng@sunroof.eng.sun.com > Subject: Re: DAD vs. DIID > > > > Hi Robert, > > >Though, it is not entirely clear to me why > >the /subnet IID uniqueness rather than the /link > >uniqueness makes the case of privacy addresses easier. > > To ensure IID uniqueness on a link, a node that implements > privacy addresses would need to generate a link-local > address for each randomly generated IID (in addition to the > global address generated for privacy), perform DAD on > that address, and maintain that address for the lifetime > of the privacy address in order to respond to other nodes' > DAD messages. A global prefix can use the same link-local address EUI again. I have to now go check but I think the only requirement is not duplicate the linklocal address but the EUI of that address can be reused by non-link-local addresses. Why does this not solve the privacy issue? thanks /jim > > If we only require IIDs to be unique within a subnet, > a node that implements privacy addresses will only need > to generate the single privacy address and perform > DAD for that address. > > As currently document (prior to the discussed changes) > the privacy document is incompatible, in this minor way, > with the addressing architecture and the autoconfiguration > documents. We had two options for what to change: > > - Relax the uniqueness restriction in the > addressing architecture, and make > a corresponding change to the > autoconfiguration document. > -OR- > - Modify the privacy address document to > require the creation and maintenance of > link-local addresses, as described above. > > We had a consensus within the room in Yokohama to choose > the first option, and we are currently checking that > consenus with the list. > > Margaret > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 05:19:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DCJo3U008091; Tue, 13 Aug 2002 05:19:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DCJn2K008090; Tue, 13 Aug 2002 05:19:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DCJh3U008083 for ; Tue, 13 Aug 2002 05:19:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15007 for ; Tue, 13 Aug 2002 05:19:53 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28387 for ; Tue, 13 Aug 2002 05:19:47 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DCIxo10346; Tue, 13 Aug 2002 19:18:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DCHIW22544; Tue, 13 Aug 2002 19:17:18 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: Bob Hinden , IPv6 List Subject: Re: Changes to IPv6 Addressing Architecture Draft In-Reply-To: <4.2.2.20020812093808.01cef220@mail.windriver.com> References: <4.2.2.20020812093808.01cef220@mail.windriver.com> <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> <4.3.2.7.2.20020809151139.01fdfef8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 19:17:18 +0700 Message-ID: <22542.1029241038@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 09:57:14 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020812093808.01cef220@mail.windriver.com> | We can only perform interoperability testing for external behaviours of | boxes that are visible on the wire. True, but interoperability testing isn't required. Let me quote 2026, section 4.1.2 (part thereof) just in case anyone here isn't clear on the requirements ... [...] "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. Note: nothing requires that there be any interoperability testing, and while it is great that there has been some (lots) of v6 implementations, other protocols advance with none. What is required is that every feature be implemented in a way that is interoperable (twice, independently). Every feature, or it must be removed. There's nothing unclear about this, nor is it without good reason. This is how we get rid of the odd attachments that people just thought would be a good idea when the doc was proposed, but then no-one (except possibly the one who suggested it) ever bothered to implement. It is how all the chaff is removed. | This does make it fairly tricky to | write an implementation checklist for something like an addressing | architecture, and I think that Bob has done an outstanding job of figuring | out which features do/don't have interoperability concerns. Yes, some things are harder than others. And I agree, what's there now is pretty good - it documents all that is important (except the new stuff, which it couldn't possibly have done) which needs to be in the doc. That's great. What follows from that is that the parts that aren't documented as having been implemented, get removed from the doc, just as the process I quoted above requires. What happens to those bits afterwards is for the WG to decide. I'm not sure why we're even discussing this next part, but ... | The subnet ID changes don't affect the external behaviour of an IPv6 | implementation. Yes it does. If one implementation refused to accept a prefix with fec0::/10 which is not also fec0::/48 (which I believe was once actually implemented somewhere, I recall someone mentioning it) then it will not interoperate with anything which attempts to use the new larger SLA. | We were always required to perform all routing and | comparisons in a CIDR-like fashion, and that hasn't changed. Sure, but this has nothing to do with that. | I agree | that vendors may want to check that their configuration mechanisms don't | have a problem setting subnet IDs of longer than 16-bits, but that isn't | an interoperability testing issue. It is an implementation report issue as regards with getting this accepted as a DS (even if it gets included, it could be decided that this is a big enough change to require the doc to recycle at PS anyway. I don't think it quite goes that far, but that isn't out of the question). But what is the issue here - all we need is for two different implementations to say "We allow 54 bit SLAs for SL addresses", that goes in the implementation reports for those two implementations, and we're done ? Why would anyone want to even tempt fate just to avoid doing that? | DAD is actually specified in the IPv6 Address Autoconfiguration spec, not | in the addressing architecture, so interoperability testing of DAD isn't | necessary to advance the addressing architecture. No. But the specification of IID uniqueness is. That's why there is text in this draft being changed after all. Again, all it takes is for (at least) two implementations to say "we allow this in our code" (and I'd be surprised if there were any who don't already) and for an entry to be added to the report. This is easy, why not just do it to be complete? | The Addressing Architecture doesn't specify any behaviour related to the | global uniqueness of addresses with the 'u' bit set. No, it just says that should be set on addresses formed from IIDs with global scope. And not otherwise. The question is where are the two implementations that actually do that? And before anyone claims "mine does" first answer the question how you determine that the IID does really have global scope? | I don't think that there is any interoperability-related feature in the | current addressing architecture document (including the proposed changes) | that isn't implemented in two or more implementations. The changes should be fine - they just need to be actually documented (that is, we aren't allowed to just say "we know it is all OK", we are, or more correctly, you (with Bob & Steve) as chair are, required to actually document all of this). But for the rest of the doc, how about (sect 2.5.4)... All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Where are the two implementations that implement/enforce that feature? This is quite clearly an feature of the specification. If not, why is it there? Thus, according to 2026, we (you) are required to document the implementations of it. If there are none, 2026 requires that it be removed for the doc to go to DS. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 07:56:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEuU3U008396; Tue, 13 Aug 2002 07:56:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DEuUBc008395; Tue, 13 Aug 2002 07:56:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEuP3U008388 for ; Tue, 13 Aug 2002 07:56:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02097 for ; Tue, 13 Aug 2002 07:56:33 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17348 for ; Tue, 13 Aug 2002 08:56:28 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DEtno17236; Tue, 13 Aug 2002 21:55:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DEqRW22749; Tue, 13 Aug 2002 21:52:27 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Bound, Jim" cc: "Margaret Wasserman" , Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6D@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6D@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 21:52:27 +0700 Message-ID: <22747.1029250347@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 22:37:59 -0400 From: "Bound, Jim" Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6D@tayexc13.americas.cpqcorp.net> | We had no such consensus. Yes, in the room, there was very clear support for this. Margaret was correct. | In fact it was stated we had to take this to the mail list. Of course it was - all WG decisions get made on the list, so everything "decided" in the room has to be taken to the list. That is what is happening now... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 07:56:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEui3U008406; Tue, 13 Aug 2002 07:56:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DEui7d008405; Tue, 13 Aug 2002 07:56:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEua3U008398 for ; Tue, 13 Aug 2002 07:56:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05690 for ; Tue, 13 Aug 2002 07:56:45 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23870 for ; Tue, 13 Aug 2002 08:56:39 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DEu2o17246; Tue, 13 Aug 2002 21:56:02 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DEoKW22741; Tue, 13 Aug 2002 21:50:20 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Bound, Jim" cc: "Margaret Wasserman" , Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 21:50:20 +0700 Message-ID: <22739.1029250220@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 22:34:39 -0400 From: "Bound, Jim" Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> | As long as if two networks merge the following is strictly prohibited: | | two nodes now appear on the network with: | | 4ff3::2 | 4ff3::2 Jim, The idea is that DAD must be performed on any address before it is configured. So, that wouldn't possibly work. Of course, if someone just plugs two cable together, nodes aren't going to do doing (re-doing) DAD on their addresses (any of them, in either scenario) - this has always been recognised as one of the failure modes for DAD, but so unlikely, and so hard to fix, that it isn't worth bothering with. | The implementation is that if two nodes have competing implementations. | If one node checks the entire address and the other does not then we | could end up with in practice in the field with what I want to be | prohibited. Yes, that's true - if there are implementations replying on DIID, and checking only LL's using DAD, then such an implementation might config an address that was already in use by a node that doesn't config LL's for every address it has configured. But it seems that there aren't actually any such implementations, everyone I have seen who has reported has said they do DAD on all addresses before configuring them. The fact that everyone did that was one of the motivations for the change. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 07:56:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEuw3U008423; Tue, 13 Aug 2002 07:56:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DEuwPC008422; Tue, 13 Aug 2002 07:56:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEum3U008408 for ; Tue, 13 Aug 2002 07:56:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02166 for ; Tue, 13 Aug 2002 07:56:57 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23940 for ; Tue, 13 Aug 2002 08:56:51 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DEu4o17250; Tue, 13 Aug 2002 21:56:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DEbSW22709; Tue, 13 Aug 2002 21:37:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Tim Hartrick cc: narten@us.ibm.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208122012.NAA08013@feller.mentat.com> References: <200208122012.NAA08013@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 21:37:28 +0700 Message-ID: <22707.1029249448@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 13:12:50 -0700 (PDT) From: Tim Hartrick Message-ID: <200208122012.NAA08013@feller.mentat.com> | Simply because some operators use a /(n>64) for | point to point links does not mean that all operators will or should do the | same. Nor is anyone suggesting that. The question isn't whether it must be done that way, but whether anyone is to be permitted to. | I believe, that it is a good thing that implementations allow this | type of flexability but the existence of that flexability in implementations | doesn't require that the specifications change in order to bless the | assignment of /(n>64) prefixes to point to point links. Actually, that's exactly what 2026 requires, when all of the implementations are flexible. | If there are implementations | which "hard-code" the /64 boundary then so be it. "If" yes, but I kind of suspect that if anyone had one, or had seen one, they'd have spoken up by now. | We have implementations of specifications which clearly work. Let's stop | messing around with them and work on the things that are really critical to | making IPv6 deployment possible. This isn't one of those things. A better solution would be to stop discussing the change, and just do it. | Aside: When the GSE discussion was going on N years ago, I was fore square | against the /64 boundary for all the reasons that others have brought up in | this latest thread. That is, the dubious basis for assuming that a globally | unique identifier is possible, the address space waste. etc. I lost the | argument. I can live with it. It sure would be nice if decisions made in | this WG had a half-life of longer than four years. I'd tend to agree with you - but we've just had Thomas claim that the reason all this remains is so GSE can be revived, sometime in the future... In this case however, this doc is being advanced to DS. That's when in the process we're supposed to go back and review the doc, and make sure it contains no rubbish that people are ignoring universally. That is, this particular review is one we're supposed to make. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 07:57:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEv43U008431; Tue, 13 Aug 2002 07:57:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DEv4ZV008429; Tue, 13 Aug 2002 07:57:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEur3U008415 for ; Tue, 13 Aug 2002 07:56:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17798 for ; Tue, 13 Aug 2002 07:57:01 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05496 for ; Tue, 13 Aug 2002 08:57:00 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DEuDo17264; Tue, 13 Aug 2002 21:56:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DEFGW22685; Tue, 13 Aug 2002 21:15:16 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Thomas Narten cc: "Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208122005.g7CK59C01751@rotala.raleigh.ibm.com> References: <200208122005.g7CK59C01751@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 21:15:16 +0700 Message-ID: <22683.1029248116@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 16:05:08 -0400 From: Thomas Narten Message-ID: <200208122005.g7CK59C01751@rotala.raleigh.ibm.com> | You seem to be wanting to require that if the u-bit is set, it is | *guaranteed* to be globally unique. No one can make such a guarantee, | of course. No, as I just said in another reply, I'm trying to figure out how the IID can possibly be used (depending on any uniqueness property) when we know that that can't happen. | I have always viewed the u bit a way of indicating that | the IID is probably unique, with a high degree of likelyhood. This is | achieved by setting the u bit to 1, iff the ID is derived from an | IEEE identifier. Fine. But no-one enforces that. Nothing can rely upon it. I can trivially create addresses with u set to 1 which aren't created that way. In fact, I have just configured one ... inet6 3ffe:8001:2:181:200::2 prefixlen 64 You can probably ping6 that address. (I hope I got the right magic bit, I didn't actually calculate, and my mental arithmetic tends to be poor, the 200 contains the bit I think is 'u'). Now the question here isn't whether or not I'm ignoring the standard, clearly, as currently written, I am. The question is how is someone else supposed to tell, how, apart from the fact that the value happens to be '2' in this case, that this doesn't contain a globally unique IID ? | I've tried to do so in another note. Yes, I saw and replied. I'm not convinced, as you will have seen. | Not so fast. To change the status quo, one needs more than just a | couple of people saying "yes" and the vast majority of the community | being silent. Hmmm... First, I agree that it is hard to tell what it means when most of a list is remaining silent. It can be anything between "that is obviously OK, no-one is arguing against it, nor is anyone likely to, no need to send a message about that" to "that is obviously bogus, no-one could possibly agree with that, no need to send a message to point that out". The usual way, if a proposal has support from more than just one person, if to assume that it is supported, and say so, and then look for the reaction. Then if people disagree, there is an obvious incentive for them to say so, and why - and then there's a better possibility for a proper disciussion. On the other hand, at that point, silence does indicate consent - lacking objections, that's about the best mailing list consensus you'll ever get (of course it rarely happens, someone always objects, to everything...) I might also suggest that you contract that position to what was done with A6. It was the status quo. There there was a debate, with technical arguments both sides (I disagree with one side, but still, they were at least real arguments). Quite a few people both ways. And that's enough for the status quo to change, apparently... Here, there are still no technical arguments for why any of this is a good idea - there's the "perhaps some future use" which really should require at least some kind of suggestion of what it might be, and some kind of evidence that has some hope of being effective, and the political nonsense about /48's. And there's the counter evidence that it isn't implemented, and 2026 which says "not implemented == remove". How much simpler can this possibly be? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 07:57:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEvI3U008445; Tue, 13 Aug 2002 07:57:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DEvIAV008443; Tue, 13 Aug 2002 07:57:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEv43U008430 for ; Tue, 13 Aug 2002 07:57:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05790 for ; Tue, 13 Aug 2002 07:57:13 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01403 for ; Tue, 13 Aug 2002 07:56:47 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DEu7o17257; Tue, 13 Aug 2002 21:56:07 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DDwQW22654; Tue, 13 Aug 2002 20:58:26 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Thomas Narten cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208121934.g7CJY4101527@rotala.raleigh.ibm.com> References: <200208121934.g7CJY4101527@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 20:58:26 +0700 Message-ID: <22652.1029247106@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 15:34:04 -0400 From: Thomas Narten Message-ID: <200208121934.g7CJY4101527@rotala.raleigh.ibm.com> | It's more than just autoconfig. Right now, End sites can expect to get | a /48, and they get use the 16 bits between a /48 and /64 anyway they | care. If a site switches providers, it knows it will get 16 bits | again, and it konws that it needs to (only) renumber the upper 48 | bits. This is both simple and powerful. Yes, it is. But it is the /48 which is the crucial number there. Not /64 - that one is irrelevant. | This comes in large part from the uniform /64 boundary between the | adddress and the IID. no it doesn't. The only influence that had was on the value "48". The need for some nice fixed boundary for the purpose you elucidate is the driver for the fixed "48". If it weren't for that (and the way the earlier argument went) we'd be allocating /56's to small organisations - not because the /64 could be moved, but because 8 bits of subnet (an old class B remember) is enough for many organisations. | If that were removed, it would potentially | reopen discussion about which bits and end site should get for subnet | addressing, with different people possibly being given different | ranges and (even worse) different amounts. no it wouldn't. No-one is even contemplating removing the /64 from being required for autoconfig on an ethernet (and other LANs). That means that all a site is ever going to need to do is say "I want to use 802.x" (for any x > 2) and then they need /64 for that. Then, nothing here is influencing the expectation of 16 bit SLA space. So, there's no way that argument could happen again. | I think this would be a bad | direction for us to go in. I don't see what the benefit would be, but | I can surely see a number of non-productive areas we'd surely rathole | on. Sure, but no-one is suggesting that, so why waste time arguing against it? | This is a key question. Just because operators are doing this, doesn't | mean they should or that we should just give in and say "I guess we | should give in to reality". No. But unless you're planning on rewriting 2026 before this gets advanced to DS, don't you think you could at least pretend that you're going to do what it requires? Features that aren't implemented must be removed from the spec. It really is very simple. If you (the whole WG) like, that can get put in some other doc as a new PS, that can just sit in PS status, until you can actually find implementations of it ... | There is a cost/benefit of sticking with | the /64 boundary. Before moving away from it, we really need to | understand the cost/benefit of the alternative. The major benefit is that we avoid people pretending they're able to look inside my addresses and deduce meaning there - and then complain that I'm not obeying some standard when they're wrong. The cost? Well, I'm having a hard time finding one at all, or a measurable one anyway. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 07:57:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEvI3U008444; Tue, 13 Aug 2002 07:57:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DEvHH0008442; Tue, 13 Aug 2002 07:57:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DEv23U008425 for ; Tue, 13 Aug 2002 07:57:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05776 for ; Tue, 13 Aug 2002 07:57:11 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05372 for ; Tue, 13 Aug 2002 08:56:57 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DEuEo17267; Tue, 13 Aug 2002 21:56:14 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DDmiW22640; Tue, 13 Aug 2002 20:48:44 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Thomas Narten cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <200208121932.g7CJWu001504@rotala.raleigh.ibm.com> References: <200208121932.g7CJWu001504@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 20:48:44 +0700 Message-ID: <22638.1029246524@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 15:32:56 -0400 From: Thomas Narten Message-ID: <200208121932.g7CJWu001504@rotala.raleigh.ibm.com> | Personally, I am not in favor of taking out the /64 boundary. The main | reason is that I do not see signficant benefits from doing so, but I | do see negative consequences from revisiting the boundary. At a | minimum, the discussion leading to this kind of change is likely to be | divisive, and I don't see that as being particularly good way to focus | this WG's cycles. It would be nice to see any technical arguments at all. If we ever end up starting something that looks like a long drawn out argument, with people making technical points in different directions, then I'll gladly go away, and the status quo can remain. The problem is that I am seeing none of them. | Personally, I believe it is potentially useful to have 64-bit | interface identifiers in all addresses. Can you even hint at something where that potential could be realised? | They *could* have properties associated with them, | but that is mostly future work. And mostly this WG has tended to refuse to allow anything which is just for future potential benefit. The only major one that has been allowed has been the flow id header field - and apart from the fact that there the possible uses can be seen (though no-one is yet sure they'll be realised) - and in any case, I suspect that no-one is really sure what would be done with those 20 bits should the field be removed, they can't just vanish. I have never agreed with eliminating all that is just potential, but I would like to see at least a suggestion of what it might be useful for. I mean, how do we know now that we don't really need 72 bit interface identifiers if they're to have some other purpose? | No need to close the door prematurely. I believe the door is already closed. That is, this part of the spec isn't obeyed at all, anywhere. Even if you could find a use, it is simply too late now. | (Note: the reason the current requirement for | IIDs on all addresses except those with prefix 000 has to do with that | 000 addresses are reserved for things that might well conflict with | interface identifiers, such as IPv4-compatable addresses). Yes, of course. But one might wonder if those can manage to survive without this feature (as do multicast addresses) then how important is it ever going to be, how important can it ever be? | Regarding kre's argument that globally-unique IIDs are useless and | should therefore be abolished, That was never my argument. If we could have the things, I'd love it. The argument is that they're unimplementable, not that they wouldn't be useful if they existed. | First, no one | can (or is) credibly arguing that if the u bit is set a certain way, | the interface ID is *guaranteed* to be globally unique. That's OK - the question is how one uses an ID which we know might not be unique? | (Kre seems to assume this argument as a strawman.) Not quite. I assume that any user of the ID is either going to assume that, or that they're going to have to be able to deal with ID's that aren't unique. If the former, then I agree with you, that's not credible. If the latter, then why should we care about the 'u' bit for this purpose? All IDs would be potentially non-unique, the user has to deal. Personally, I think it is simply wrong to try and extract the ID out of the address and do anything with it at all - keep the prefix and then you do have something unique. Seems a much simpler solution to me. | However, if the u bit is set a | certain way, implementations could take that as a hint that the IID is | *probably* unique (or supposed to be unique), and in the case that it | really cares, it could take additional steps to verify uniqueness Oh good. What are those steps? This is really the crux of the matter. If there's some way you can actually discover that it is unique, then the whole thing might have some point. But please do explain the magic by which this is accomplished. | Now, normally, I tend to resist putting in hooks that *might* be used | in the future, because our track record of predicting what hooks will | be needed (and getting them right) is generally rather poor. yes, lots of people seem to agree, and that has been the general WG approach, most of the time. It is ironic, that we appear to disagree on that in general (I am more open to star gazing than many, if the cost is small, and there's a plausible potential use, then why not?) but on this issue we're each adopting the opposite (me, because I don't believe there's even a remote sniff of a chance this can ever be useful). | In this | case, however, I believe a *lot* of people (and in particular, people | mostly not in the IPv6 WG) feel pretty strongly that something like | 8+8/GSE should be pursued. Hmm ... on this same topic, I'm being told "we had that argument, it was lost, give up and accept it", get apparently for 8+8 it is OK to keep things in preparation for it to resurface in the future, even though it has been analysed into total obscurity. It is an idea that sounds great, but without some way to actually guarantee the uniqueness, fails completely. Why are we leaving open the possibility of revisiting that, but not wanting to revisit anything else? | The current Interface ID we have leaves | that door somewhat open, should a proposal come forward that the | community believes can be made to work. Closing that door would likely | be viewed as a slap-in-the face to those who want the door left open, Huh? You mean we're ignoring the technical arguments, and making decisions in order to allow people to keep on dreaming? | and will do little to build support for IPv6 among those folk. Does it matter? Perhaps there was a time when IPv6 needed support building, but hasn't it become evident to you yet that time passed? Maybe in the US where address shortages have never been as severe, it is taking longer than everywhere else, I don't know - but really now, it is too late to deny IPv6 any more, it has already happened. | More recently, there has been a proposal (though not particularly well | received by this list) to perhaps allow other different types of | indentifiers. For example, there is promising work going in with | regards to embedding (parts of) public keys (or the signature of a | public key) into an interface identifier in order to allow a node to | "prove" it "owns" a particlar address/identifier. I'm not sure how (or | if) that work will gain much traction, but again, I think it would be | a mistake to close that door prematurely, because it *might* be a | useful approach to solving a rather hard problem for which few options | seem to be available. What exactly do you thing is being proposed that would prevent any of that? If anything, removing 'u' can only help, as the way we have things now, we have one bit an an unusual position in the IID that has supposed fixed semantics, anyone else proposing new kinds of IID has to work around that. If we simply had 64 bits of IID available, then all of that should be easier, right? | Getting back to the observation that some in the community are | assigning /127s to the p2p links, this by itself does not imply that | the interface identifier concept is inherently broken and should be | removed from addrarch. It, by itself, means that the restriction that addrarch makes that all IIDs (0::/3 excepted) are 64 bits is not implemented. Combine that with the words in 2026, and you see why it has to be removed. | Even if many operators turn out in fact to | number all their p2p links this way, this will be an extremely small | fraction of the total number of addressable end nodes. Thus, in | practice, enough end nodes may be using 64-bit IIDs in order for the | uniquness properties (as described above) to be useful enough to take | advatange of. Only if you can actually define them. You also neglect dhcp - it isn't yet clear in (larger) ipv6 nets whether autoconfig will be used mostly, or whether dhcp will be (partly because dhcpv6 is only just finishing, so there have been no users to date). There's nothing here beyond speculation. | Obviously, those nodes that don't follow the scheme | wouldn't be able to take advatange, but that may not matter. Future | work can figure that out. It isn't the nodes that follow, or don't, the scheme that matter, It is what all the other nodes which assume u==1 means globally unique do, when they start getting lots of addresses with u==1 which don't have globally unique iids. That's what you have to work out how to deal with before you can think about any potential use of all of this. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 08:28:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFSC3U008580; Tue, 13 Aug 2002 08:28:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DFSCiT008579; Tue, 13 Aug 2002 08:28:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFS73U008572 for ; Tue, 13 Aug 2002 08:28:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13347 for ; Tue, 13 Aug 2002 08:28:16 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20206 for ; Tue, 13 Aug 2002 08:28:15 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id SAA05910; Tue, 13 Aug 2002 18:26:45 +0300 Date: Tue, 13 Aug 2002 18:26:45 +0300 Message-Id: <200208131526.SAA05910@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com In-reply-to: <22739.1029250220@munnari.OZ.AU> (message from Robert Elz on Tue, 13 Aug 2002 21:50:20 +0700) Subject: Re: DAD vs. DIID References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > But it seems that there aren't actually any such implementations, everyone > I have seen who has reported has said they do DAD on all addresses before > configuring them. The fact that everyone did that was one of the > motivations for the change. Here I have to raise a hand. I wrote implementation that actually followed the allowed optimization: do DAD only on link-local, and then freely combine that ID with announced prefixes WITHOUT doing a separate DAD for EACH prefix*ID combination. This is still fully allowed by current RFC's, and I still believe this is GOOD, and should not be changed. As a consequence, and observing that others may not have chosen this tactics, the code also defends plain ID, that is: if it sees a DAD for address which contains one of my ID's, it will reply to the DAD as if I had the address. I don't see any catastrophic failures resulting from it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 08:31:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFV23U008597; Tue, 13 Aug 2002 08:31:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DFV2GT008596; Tue, 13 Aug 2002 08:31:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFUv3U008589 for ; Tue, 13 Aug 2002 08:30:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14308 for ; Tue, 13 Aug 2002 08:31:06 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07959 for ; Tue, 13 Aug 2002 09:31:04 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DFUMo18379; Tue, 13 Aug 2002 22:30:24 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DEvVW22767; Tue, 13 Aug 2002 21:57:31 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: "Michel Py" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020812091932.01c3b220@mail.windriver.com> References: <4.2.2.20020812091932.01c3b220@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 21:57:31 +0700 Message-ID: <22765.1029250651@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 12 Aug 2002 09:31:08 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020812091932.01c3b220@mail.windriver.com> | The current situation with the addressing architecture is that we have | established a consensus of the WG to make two changes to the document | (described in Bob's mail) and send it (back) to the IESG for consideration | as a draft standard. >From where did we get that consensus? We're still discussing the two changes, it is clear that Tony Hain at least (maybe Jim Bound, that's less clear) is opposed to one of them. But in general most seem to support making those changes. Though that's mostly by silence - and if you believe one of Thomas' recent messages, silence is not enough to change the status quo ... (which here would be what is in addrarch-08). I don't, I think if there's support, and no stated technical objections, then changes should be made, if the silent majority see that coming and disagree, they won't remain silent. | I have not seen a level of response to this thread that would lead me to | question that consensus. Have you? I haven't seen anything in this thread that establishes any consensus for sending the doc back to the IESG yet at all. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 08:38:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFc03U008628; Tue, 13 Aug 2002 08:38:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DFc0gg008626; Tue, 13 Aug 2002 08:38:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFbs3U008618 for ; Tue, 13 Aug 2002 08:37:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14846 for ; Tue, 13 Aug 2002 08:38:03 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01248 for ; Tue, 13 Aug 2002 09:38:03 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id ECA6C6649; Tue, 13 Aug 2002 11:38:02 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 Aug 2002 11:38:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAD vs. DIID Date: Tue, 13 Aug 2002 11:38:02 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F77@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcJC2jZWx3T/1al3QQGBn7IUEPTD7QABSQEw From: "Bound, Jim" To: "Robert Elz" Cc: "Margaret Wasserman" , , X-OriginalArrivalTime: 13 Aug 2002 15:38:01.0272 (UTC) FILETIME=[682D1380:01C242DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7DFbt3U008619 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I recall many of us having concerns to review it. You included. /jim > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Tuesday, August 13, 2002 10:52 AM > To: Bound, Jim > Cc: Margaret Wasserman; Robert.Peschi@alcatel.be; > ipng@sunroof.eng.sun.com > Subject: Re: DAD vs. DIID > > > Date: Mon, 12 Aug 2002 22:37:59 -0400 > From: "Bound, Jim" > Message-ID: > <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6D@tayexc13.americas.cp > qcorp.net> > > | We had no such consensus. > > Yes, in the room, there was very clear support for this. Margaret > was correct. > > | In fact it was stated we had to take this to the mail list. > > Of course it was - all WG decisions get made on the list, so > everything > "decided" in the room has to be taken to the list. > > That is what is happening now... > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 08:38:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFcH3U008639; Tue, 13 Aug 2002 08:38:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DFcH7s008638; Tue, 13 Aug 2002 08:38:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFc93U008631 for ; Tue, 13 Aug 2002 08:38:09 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14923 for ; Tue, 13 Aug 2002 08:38:18 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19419 for ; Tue, 13 Aug 2002 09:38:17 -0600 (MDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Tue, 13 Aug 2002 08:38:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E272@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Thread-Index: AcJC2nvcIZ6iSb8dTp+s2rGIC+OTSwAAHR+g From: "Michel Py" To: "Robert Elz" , "Tim Hartrick" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7DFc93U008632 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, | Tim Hartrick wrote: | Aside: When the GSE discussion was going on N years ago, I was fore | square against the /64 boundary for all the reasons that others | have brought up in this latest thread. That is, the dubious basis | for assuming that a globally unique identifier is possible, the | address space waste. etc. I lost the argument. I can live with it. | It sure would be nice if decisions made in this WG had a half-life | of longer than four years. > kre wrote: > I'd tend to agree with you - but we've just had Thomas claim that > the reason all this remains is so GSE can be revived, sometime in > the future... I don't think that's what Thomas said. Since I probably am the one in the best position to talk about this, the current status is: - If GSE was the only way out for multihoming, I have no doubt that it would be back on the scene, despite the documented shortcomings. GSE was dismissed years ago when the collective dream that a much better multihoming solution was still there. We have since then come closer to reality. - GSE will likely not be pursued (we have talked about the possibility of reviving it three months ago and decided that we had a better mouse trap). - The perfect multihoming solution does not exist yet, and there is a general feeling that GSE is possibly unfinished, problem is that nobody has found the required breakthrough. - There is currently no use made of the 'u' bit for any current or future multihoming protocol I know of. As we have seen here in the past and more recently with support for Thomas' postings and other people contributing similar arguments, my analysis of this issue is as follows: - The 'u' bit is not a blocking reason why prefixes longer than /64 are not allowed. Regardless of the existence of the 'u' bit, there are reasons and support to keep the /64 boundary, which in turns means that there is no consensus to remove it from [addrarch]. - In the context of the /64 boundary, the existence of the 'u' bit does not bother anybody, I think. - Given the likely strong support for a "son of GSE" should it be written, it seems reasonable to leave this door open keep the 'u' bit for the time being. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 08:40:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFel3U008663; Tue, 13 Aug 2002 08:40:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DFelNG008662; Tue, 13 Aug 2002 08:40:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFeg3U008655 for ; Tue, 13 Aug 2002 08:40:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29599 for ; Tue, 13 Aug 2002 08:40:51 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10852 for ; Tue, 13 Aug 2002 08:40:51 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AE2345A3E; Tue, 13 Aug 2002 11:40:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 Aug 2002 11:40:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAD vs. DIID Date: Tue, 13 Aug 2002 11:40:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F78@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcJC3kUi1V3CuKoGSHmRVLZ/WXd4XAAAXLfg From: "Bound, Jim" To: "Markku Savela" , Cc: , , X-OriginalArrivalTime: 13 Aug 2002 15:40:50.0602 (UTC) FILETIME=[CD1AC8A0:01C242DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7DFeg3U008656 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The code I wrote for T64 does the same. /jim > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Tuesday, August 13, 2002 11:27 AM > To: kre@munnari.OZ.AU > Cc: Bound, Jim; mrw@windriver.com; Robert.Peschi@alcatel.be; > ipng@sunroof.eng.sun.com > Subject: Re: DAD vs. DIID > > > > From: Robert Elz > > > But it seems that there aren't actually any such > implementations, everyone > > I have seen who has reported has said they do DAD on all > addresses before > > configuring them. The fact that everyone did that was one of the > > motivations for the change. > > Here I have to raise a hand. I wrote implementation that actually > followed the allowed optimization: do DAD only on link-local, and then > freely combine that ID with announced prefixes WITHOUT doing a > separate DAD for EACH prefix*ID combination. > > This is still fully allowed by current RFC's, and I still believe this > is GOOD, and should not be changed. > > As a consequence, and observing that others may not have chosen this > tactics, the code also defends plain ID, that is: if it sees a DAD for > address which contains one of my ID's, it will reply to the DAD as if > I had the address. I don't see any catastrophic failures resulting > from it. > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 08:42:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFgg3U008685; Tue, 13 Aug 2002 08:42:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DFggkX008684; Tue, 13 Aug 2002 08:42:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFga3U008677 for ; Tue, 13 Aug 2002 08:42:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16592 for ; Tue, 13 Aug 2002 08:42:45 -0700 (PDT) Received: from givenchy.6wind.com ([212.234.238.114]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00775 for ; Tue, 13 Aug 2002 09:42:43 -0600 (MDT) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy.6wind.com (Postfix) with ESMTP id 1CC6E7DC; Tue, 13 Aug 2002 17:51:42 +0200 (CEST) Received: from 6wind.com (ksinant.6wind.com [10.0.0.101]) by intranet.6wind.com (Postfix) with ESMTP id E9EE7B4FA; Tue, 13 Aug 2002 17:42:51 +0200 (CEST) Message-ID: <3D59287F.529E077B@6wind.com> Date: Tue, 13 Aug 2002 17:40:47 +0200 From: Vladimir Ksinant X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markku Savela Cc: kre@munnari.OZ.AU, Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> <200208131526.SAA05910@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: > > From: Robert Elz > > > But it seems that there aren't actually any such implementations, everyone > > I have seen who has reported has said they do DAD on all addresses before > > configuring them. The fact that everyone did that was one of the > > motivations for the change. > > Here I have to raise a hand. I wrote implementation that actually > followed the allowed optimization: do DAD only on link-local, and then > freely combine that ID with announced prefixes WITHOUT doing a > separate DAD for EACH prefix*ID combination. > Our implementation also follows the optimization. Vladimir -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 08:49:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFn23U008742; Tue, 13 Aug 2002 08:49:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DFn1sH008741; Tue, 13 Aug 2002 08:49:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFmr3U008731 for ; Tue, 13 Aug 2002 08:48:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02662 for ; Tue, 13 Aug 2002 08:49:03 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08862 for ; Tue, 13 Aug 2002 09:49:02 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4A3D78CAB; Tue, 13 Aug 2002 11:49:02 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 Aug 2002 11:49:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Tue, 13 Aug 2002 11:49:01 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F79@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Thread-Index: AcJC3zqCXR8m1TZcT1+v3c10sGz3SAAAK4nw From: "Bound, Jim" To: "Robert Elz" , "Margaret Wasserman" Cc: "Michel Py" , X-OriginalArrivalTime: 13 Aug 2002 15:49:00.0757 (UTC) FILETIME=[F1428050:01C242E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7DFms3U008732 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I want to see more discussion and I believe Thomas and Tony have raised valid points. I also think this fix should solve with wording plugging two networks together. That I am thinking on how we word it. But if we are to do DAD on all bits then we can also add that when a network joins another then DAD must be done by one of them. But if all do dad on the link-local and EUI then that would work to and with the optimization many of us implementors used I am wondering if we still have the problem for a "node". The issue is for two separate nodes and I think the wordage bob sent out killed that and what I perceived steve to be arguing at Yokohoma where there was no consensus I saw as follows: Node 1 has EUI of X'c3de' Node 2 has EUI of X'c3de' That we would permit Node 1 to be 4ffe::c3de and Node 2 to be 3ffe::c3de But the words I read from Bob would not permit this? That is the heartburn I have big time. I believe that we all agreed that EUI could be duplicated by manufactures and we should prevent that as best we can with DAD. Also Thomas is correct silence has in other working groups been used to state consensus cannot be determined. My opinion is that if working group members don't respond by some amount of time then too bad they loose and we move forward. But that is not how things are being managed out of IPv6 WG in some cases and I would prefer we adhere to the same policy in all working groups in the IETF. Possibly this is an issue for the chairs to discuss with ADs to get some consensus on the state of the IETF and get a decision. regards, /jim > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Tuesday, August 13, 2002 10:58 AM > To: Margaret Wasserman > Cc: Michel Py; ipng@sunroof.eng.sun.com > Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt > > > Date: Mon, 12 Aug 2002 09:31:08 -0400 > From: Margaret Wasserman > Message-ID: <4.2.2.20020812091932.01c3b220@mail.windriver.com> > > | The current situation with the addressing architecture is > that we have > | established a consensus of the WG to make two changes to > the document > | (described in Bob's mail) and send it (back) to the IESG > for consideration > | as a draft standard. > > From where did we get that consensus? We're still discussing the > two changes, it is clear that Tony Hain at least (maybe Jim > Bound, that's > less clear) is opposed to one of them. But in general most seem to > support making those changes. > > Though that's mostly by silence - and if you believe one of Thomas' > recent messages, silence is not enough to change the status quo ... > (which here would be what is in addrarch-08). > > I don't, I think if there's support, and no stated technical > objections, > then changes should be made, if the silent majority see that > coming and > disagree, they won't remain silent. > > | I have not seen a level of response to this thread that > would lead me to > | question that consensus. Have you? > > I haven't seen anything in this thread that establishes any > consensus for > sending the doc back to the IESG yet at all. > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 08:49:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFmx3U008739; Tue, 13 Aug 2002 08:48:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DFmxML008738; Tue, 13 Aug 2002 08:48:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DFmp3U008724 for ; Tue, 13 Aug 2002 08:48:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18737 for ; Tue, 13 Aug 2002 08:48:56 -0700 (PDT) Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04372 for ; Tue, 13 Aug 2002 09:48:55 -0600 (MDT) Received: from repligate ([67.37.234.64]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020813154633.LCPR21716.mail1-0.chcgil.ameritech.net@repligate>; Tue, 13 Aug 2002 10:46:33 -0500 Message-ID: <016501c242e0$a4b1d2e0$8c56fea9@repligate> From: "Jim Fleming" To: "Bound, Jim" , "Robert Elz" Cc: "Margaret Wasserman" , , References: <9C422444DE99BC46B3AD3C6EAFC9711B020B8F77@tayexc13.americas.cpqcorp.net> Subject: Re: DAD vs. DIID Date: Tue, 13 Aug 2002 10:46:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Bound, Jim" > I recall many of us having concerns to review it. You included. > /jim > http://www.winternet.com/~mikelr/flame78.html Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 10:11:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DHBg3U008990; Tue, 13 Aug 2002 10:11:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DHBfnk008989; Tue, 13 Aug 2002 10:11:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DHBZ3U008982 for ; Tue, 13 Aug 2002 10:11:36 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21172 for ; Tue, 13 Aug 2002 10:11:46 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26719 for ; Tue, 13 Aug 2002 10:11:46 -0700 (PDT) Received: from kenawang ([147.11.233.16]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA21267; Tue, 13 Aug 2002 10:10:13 -0700 (PDT) Message-Id: <4.2.2.20020813130604.0231e740@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 13 Aug 2002 13:08:17 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Cc: Thomas Narten , "Michel Py" , ipng@sunroof.eng.sun.com In-Reply-To: <22683.1029248116@munnari.OZ.AU> References: <200208122005.g7CK59C01751@rotala.raleigh.ibm.com> <200208122005.g7CK59C01751@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >And there's the counter evidence that it isn't implemented, and 2026 which >says "not implemented == remove". What makes you say that this isn't implemented? I am very familiar with two implementations that generate IIDs from EUI-64 identifiers and set the 'u' bit accordingly, and I am sure that most other implementations do this as well. That's the only think that the addressing architecture specifies that you can/should do with the 'u' bit... Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 13 10:25:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DHPH3U009046; Tue, 13 Aug 2002 10:25:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DHPG2Z009045; Tue, 13 Aug 2002 10:25:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DHPB3U009038 for ; Tue, 13 Aug 2002 10:25:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07341 for ; Tue, 13 Aug 2002 10:25:20 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14150 for ; Tue, 13 Aug 2002 11:25:19 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7DHbNf06929 for ; Tue, 13 Aug 2002 20:37:23 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 13 Aug 2002 20:25:17 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 13 Aug 2002 20:25:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text Date: Tue, 13 Aug 2002 20:25:17 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757D3107D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcI8g0zVQkPI2LoeRkylgy0wU2k3IgGasmGA To: Cc: , X-OriginalArrivalTime: 13 Aug 2002 17:25:17.0751 (UTC) FILETIME=[649DD470:01C242EE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7DHPC3U009039 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, How about this (changes in the second sentence): "The method by which the flow state is cleared from the IPv6 nodes is to be defined by the flow state establishment method used to set up the state. This implies that IPv6 nodes unable to classify a packet to an existing flow SHOULD NOT establish any flow-specific state unless so instructed by a flow state establishment method. With some flow state establishment methods, signaling new state simultaneously clearing the old state from the new path may be sufficient. A mechanism with a sufficiently long timeout period before reusing the Flow Label values can also be used." I also fixed the grammar nit you pointed out, thanks. Jarno > -----Original Message----- > From: ext Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: 5. elokuuta 2002 16:20 > To: Rajahalme Jarno (NRC/Helsinki) > Cc: brian@hursley.ibm.com; ipng@sunroof.eng.sun.com > Subject: Re: Flow label draft issues & new text > > > Date: Mon, 5 Aug 2002 09:53:49 +0300 > From: jarno.rajahalme@nokia.com > Message-ID: > <009CA59D1752DD448E07F8EB2F911757D31059@esebe004.NOE.Nokia.com> > > | any suggestions on how to make the text clearer about this? > > brian@hursley.ibm.com said: > | Send text. > > Me and my big keyboard... > > Well.. > > The method by which the flow state is cleared from the > IPv6 nodes is > to be defined by the flow state establishment method used to set up > the state. > > That's fine. > > This implies that IPv6 nodes SHOULD NOT establish any > flow-specific state unless so instructed by a specific flow state > establishment method. > > That's fine too, provided that you assume that the reader has actually > read the definitions, and noticed: > > Flow state A control mechanism used to set up the flow > establishment method state. A flow state establishment method can > be either > - Dynamic, under source or destination node > control (e.g. RSVP), > - Quasi-dynamic, under network management > control, > - Static, through manual configuration, or > - Algorithmic (e.g. load spreading) > > (grammar nit: I don't think "either" is correct to describe a choice > among more than 2 things, make it "any of"). > > The problem is that many simply assume that they know what > all the words > mean, and treat the definitions section, like acknowledgments, and > security considerations, as something of no relevance, and skip it. > > So, perhaps add > > In particular, nodes should not simply react to observing > the flow labels of traffic passing through. This is not > a flow state establishment method, and, in particular, gives no > hint as to when packets may now be part of a different flow than > previous packets similarly labeled. > > The rest ... > > With some flow state establishment methods, > signaling new state simultaneously clearing the old state from the > new path may be sufficient. A mechanism with a sufficiently long > timeout period before reusing the Flow Label values can > also be used. > > is also OK, that's just hints to flow state setup types (ie: working > groups and the link) as to what they might like to define in > their protocols. > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 00:13:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E7Dw3U011228; Wed, 14 Aug 2002 00:13:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E7DvLg011227; Wed, 14 Aug 2002 00:13:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E7Dq3U011220 for ; Wed, 14 Aug 2002 00:13:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23683 for ; Wed, 14 Aug 2002 00:14:01 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28210 for ; Wed, 14 Aug 2002 01:13:44 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7E7Cq123856; Wed, 14 Aug 2002 14:12:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7E73dW29108; Wed, 14 Aug 2002 14:03:39 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <200208131526.SAA05910@burp.tkv.asdf.org> References: <200208131526.SAA05910@burp.tkv.asdf.org> <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Aug 2002 14:03:39 +0700 Message-ID: <29106.1029308619@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 13 Aug 2002 18:26:45 +0300 From: Markku Savela Message-ID: <200208131526.SAA05910@burp.tkv.asdf.org> | As a consequence, and observing that others may not have chosen this | tactics, the code also defends plain ID, that is: if it sees a DAD for | address which contains one of my ID's, it will reply to the DAD as if | I had the address. I don't see any catastrophic failures resulting | from it. Yes, that way should work. But can you test what happens if you configure an address on some other node (using a different implementation), that happens to be one that yor node will assign, without doing DAD on it explicitly, and then start your node after that. That's the case where there's a potential for trouble with mixed implementations I believe. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 00:31:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E7VU3U011260; Wed, 14 Aug 2002 00:31:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E7VUTd011259; Wed, 14 Aug 2002 00:31:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E7VN3U011252 for ; Wed, 14 Aug 2002 00:31:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03832 for ; Wed, 14 Aug 2002 00:31:27 -0700 (PDT) Received: from liah.itonsite.com.au (liah.itonsite.com.au [203.14.17.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15861 for ; Wed, 14 Aug 2002 01:31:26 -0600 (MDT) Received: from summit (168-82.dsl.connexus.net.au [203.34.168.82]) by liah.itonsite.com.au (8.11.3/8.11.3) with SMTP id g7E6Vei25519 for ; Wed, 14 Aug 2002 16:31:40 +1000 Reply-To: From: "cj" To: Subject: ipv4 to ipv6 conversion tool Date: Wed, 14 Aug 2002 17:33:27 +1000 Message-ID: <000201c24364$e1e691d0$96c8a8c0@star.itonsite.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk G'day folks I have just started looking into this ipv6 what I was wandering is there an ipv4 to ipv6 conversion tool. ie I type in an ipv4 ip address and it gives me the equivalent ipv6 address Thanks in advance CJ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 00:40:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E7eq3U011306; Wed, 14 Aug 2002 00:40:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E7eqNw011305; Wed, 14 Aug 2002 00:40:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E7ej3U011298 for ; Wed, 14 Aug 2002 00:40:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05389 for ; Wed, 14 Aug 2002 00:40:56 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15692 for ; Wed, 14 Aug 2002 00:40:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id g7E7fcUd017806 for ; Wed, 14 Aug 2002 16:41:38 +0900 Date: Wed, 14 Aug 2002 16:41:38 +0900 (JST) Message-Id: <20020814.164138.84861027.yoshfuji@linux-ipv6.org> To: ipng@sunroof.eng.sun.com Subject: Re: ipv4 to ipv6 conversion tool From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <000201c24364$e1e691d0$96c8a8c0@star.itonsite.com.au> References: <000201c24364$e1e691d0$96c8a8c0@star.itonsite.com.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <000201c24364$e1e691d0$96c8a8c0@star.itonsite.com.au> (at Wed, 14 Aug 2002 17:33:27 +1000), "cj" says: > ie I type in an ipv4 ip address and it gives me the equivalent ipv6 address sed 's/^/::ffff:/' --yoshfuji -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 01:00:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E80V3U011360; Wed, 14 Aug 2002 01:00:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E80VOU011358; Wed, 14 Aug 2002 01:00:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E80M3U011343 for ; Wed, 14 Aug 2002 01:00:22 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03896 for ; Wed, 14 Aug 2002 01:00:32 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27302 for ; Wed, 14 Aug 2002 02:00:24 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7E7xN106164; Wed, 14 Aug 2002 14:59:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7E7GgW29131; Wed, 14 Aug 2002 14:16:42 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: Thomas Narten , "Michel Py" , ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <4.2.2.20020813130604.0231e740@mail.windriver.com> References: <4.2.2.20020813130604.0231e740@mail.windriver.com> <200208122005.g7CK59C01751@rotala.raleigh.ibm.com> <200208122005.g7CK59C01751@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Aug 2002 14:16:42 +0700 Message-ID: <29129.1029309402@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 13 Aug 2002 13:08:17 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020813130604.0231e740@mail.windriver.com> | I am very familiar with two implementations that generate IIDs from EUI-64 | identifiers and set the 'u' bit accordingly, and I am sure that most | other implementations do this as well. | | That's the only think that the addressing architecture specifies that | you can/should do with the 'u' bit... That's fine, and I'm not advocating removing that part of the draft (nor were you when you posted your original message, I didn't think). What I want to remove are the words that say that an address with the 'u' bit set contains an IID that has global scope (which isn't actually defined anyway, that is what does "has global scope" actually mean?) That is, I have no doubt the implementations set the 'u' bit the way you say they do, so do the ones I have seen. But do they also clear the 'u' bit when the IID doesn't come from an EUI-64? None I have seen do that. That is, do as I did (and showed) in the message I sent yesterday, try configuring prefix::0200:0000:0000:0001 (or anything you like in the bottom 48-56 bits) and see if the implementations you are familiar with either reject that (give an error) or silently clear the 'u' bit. If they don't - they're not implementing 'u' the way the arch doc claims it should be implemented. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 01:00:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E80V3U011359; Wed, 14 Aug 2002 01:00:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E80USm011357; Wed, 14 Aug 2002 01:00:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E80N3U011349 for ; Wed, 14 Aug 2002 01:00:23 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03902 for ; Wed, 14 Aug 2002 01:00:33 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03968 for ; Wed, 14 Aug 2002 01:00:05 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7E7xN106167; Wed, 14 Aug 2002 14:59:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7E7W1W29158; Wed, 14 Aug 2002 14:32:01 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Tim Hartrick" , narten@us.ibm.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <2B81403386729140A3A899A8B39B046405E272@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E272@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Aug 2002 14:32:01 +0700 Message-ID: <29156.1029310321@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 13 Aug 2002 08:38:15 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E272@server2000.arneill-py.sacramento.ca.us> | - There is currently no use made of the 'u' bit for any current or | future multihoming protocol I know of. So you have no problem if the text that tells about its "global scope" gets yanked from the doc? | - The 'u' bit is not a blocking reason why prefixes longer than /64 are | not allowed. It is the only one I can see. It is also the only one I care about. That is, if you remove this 'u' stuff from the doc, the rest of the /64 becomes totally meaningless, because there's no longer any way for you to tell from outside if I am using /64 or not. Some remote node relying on the 'u' bit set, and doing things to just the IID because of that, is the only one that matters. What are these other reasons for keeping /64 (mandatory for every link)? The nonsense about /48 assignments certainly isn't it, nor is so autoconfig will work - that only needs /64 on the links where autoconfig is used. | Regardless of the existence of the 'u' bit, there are | reasons and support to keep the /64 boundary, which in turns means that | there is no consensus to remove it from [addrarch]. Again, what reasons? But I don't care too much, as if 'u' were to go, you can keep the pretense about /64 in the doc, and lots of us will just go on ignoring it. That will do you no harm, will do us no harm, and everyone will be happy, right? | - In the context of the /64 boundary, the existence of the 'u' bit does | not bother anybody, I think. It bothers me because it is an unnecessary wart on the spec. It is meaningless, useless (outside its use during autoconfig itself) and a blight on the spec. There's no point keeping it. If the issue was that we didn't want to revise the spec, having published it already, and there not being other changes to make - then OK, just perhaps if everyone understood that this was just a useless blemish, making a new doc to fix it might not be justified. But we're revising the doc, and making more substantial changes anyway. The trivial changes to address this aren't (or shouldn't) cause problems. | - Given the likely strong support for a "son of GSE" should it be | written, it seems reasonable to leave this door open keep the 'u' bit | for the time being. No, it doesn't, because no matter what kind of support and GSE descendent might receive, the 'u' bit still remains useless. If I set (or don't) the bit, then I mighht be able to trust it, but no-one else, anywhere, ever, can ever assign any meaning to it, because they can't know that they're not dealing with a bastard like me who is deliberately setting that bit to an arbitrary value. It will always be unsafe to attribute any meaning to the bit - unless you're sending extra knowledge via some other channel than the address. if you're doing that, you'd do better to send "The IID in this address is globally unique" than "You can trust the 'u' bit in this address to tell you it is globally unique", the latter is just a meaningless extra indirection. This bit simply can *never* be useful for the purposes people keep hoping that they're going to use it. It won't work. Let's just get rid of it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 01:01:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E81l3U011384; Wed, 14 Aug 2002 01:01:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E81l2t011383; Wed, 14 Aug 2002 01:01:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E81d3U011376 for ; Wed, 14 Aug 2002 01:01:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01393 for ; Wed, 14 Aug 2002 01:01:49 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23672 for ; Wed, 14 Aug 2002 01:00:01 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7E7xJ106152; Wed, 14 Aug 2002 14:59:20 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7E7J9W29141; Wed, 14 Aug 2002 14:19:09 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: jarno.rajahalme@nokia.com cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: <009CA59D1752DD448E07F8EB2F911757D3107D@esebe004.NOE.Nokia.com> References: <009CA59D1752DD448E07F8EB2F911757D3107D@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Aug 2002 14:19:09 +0700 Message-ID: <29139.1029309549@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 13 Aug 2002 20:25:17 +0300 From: jarno.rajahalme@nokia.com Message-ID: <009CA59D1752DD448E07F8EB2F911757D3107D@esebe004.NOE.Nokia.com> | How about this (changes in the second sentence): Looks OK to me. But I understood what it meant the first time, so I'm perhaps not the best judge... Do those who thought that the text perviously meant that nodes couldn't label packets they were originating still read that into this version? (Margaret, itojun .... ?) kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 01:28:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E8SH3U011478; Wed, 14 Aug 2002 01:28:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E8SGSd011477; Wed, 14 Aug 2002 01:28:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E8S93U011470 for ; Wed, 14 Aug 2002 01:28:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13116 for ; Wed, 14 Aug 2002 01:28:14 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01675 for ; Wed, 14 Aug 2002 02:28:13 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7E8Rut00936; Wed, 14 Aug 2002 17:27:56 +0900 (JST) Date: Wed, 14 Aug 2002 17:28:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt In-Reply-To: <200208062005.g76K5Yp03177@rotala.raleigh.ibm.com> References: <200208062005.g76K5Yp03177@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 236 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I'm explicitly ccing to Erik, because he may have some answers to a comment.) >>>>> On Tue, 06 Aug 2002 16:05:34 -0400, >>>>> Thomas Narten said: > Here is my long overdue review of this document. Note that since this > is document is intended to be published as Informational, no IETF Last > Call will be done, and once the remaining issues are resolved the > document can be brought before IESG as a whole. Thanks for the detailed review and comments, and sorry for not responding sooner. I've incorporated trivial editorial nits to my local copy of the draft, and I've not mentioned them in this response. > Detailed comments. > Abstract: >> A separate specification [RFC-2553] contain changes to the sockets > take out the references; saying "rfc 2553" without making it a > reference is OK. See the RFC editors guidelines on abstracts for more > details (draft-rfc-editor-rfc2223bis-02.txt). > Note: the abstract itself could really be rewritten to be more > clear/concise. I agree. How about this (which is a total rewrite of abstract): This document provides sockets APIs to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 2553. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path MTU information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. > General: it would be good to have a proper reference to the posix > standards in the references section. I.e.: >> 4.3BSD Reno sockets API in 1990. The reason is that these ancillary >> data fields are part of the Posix.1g standard and should therefore be >> adopted by most vendors. Are you suggesting to add the POSIX standard in References explicitly? Or are you suggesting to check the latest version of the standard and to rewrite the text accordingly (if necessary)? > Also, how does this align with the Austin group work and the revised > basic API? Are the documents in sync with each other? I say this > because the Basic API is apparently in alignment with the Austin Group > work. It would probably be useful to have some text saying how this > document relates to that standard. Hmm, good point. As far as I know, there has been no effort to synch the advanced API to other "official" standards. Also, rfc2292bis is not as mature as rfc2553bis; 2292bis is a total revise of RFC 2292, and backward compatibility is not provided. So, with the following point: > Early in the introduction, the document should say it is > updating/replacing the RFC 2292. I'd propose to add the following paragraph to Introduction: This document is intended to replace RFC 2292 "Advanced Sockets API for IPv6", February 1998. The revise is based on implementation experiences of the previous RFC, as well as some additional extensions that has been found as important throughout the IPv6 deployment. Note, however, that this document is still informational. Once the API specification becomes mature and is deployed among implementations, it should be incorporated to official standards, such as POSIX (refer to the document explicitly -if necessary-). Does it make sense? > Also, take a look at the most recent changes to the basic API. Do any > spill over into this document? One change to the basic API that seems > relevant to this one: >> . More alignments with [3]: >> - [3] does not contain protocol family definitions (PF_xxx). >> Replaced PF_INET6 with AF_INET6, or removed as appropriate. > This document still refernces PF_INET, etc. Okay, I've changed PF_xxx to AF_xxx at least. I'm not sure if we need more. > I note that there are some new ICMP types that have been assigned that > this document doesn't seem to reference (e.g., those greater than > 138). Should they be added? I don't think so. Since more and more new types will come, we need to make a fixed point of "feature freeze". And, at least to me, the newer types are either immature or less interesting to applications. >> are taken from http://www.iana.org/assignments/protocol-numbers. > this URL should be restricted to http://www.iana.org/numbers.html (the > URL in the document is not stable over long periods of time) Okay. The corresponding sentence is now These are taken under http://www.iana.org/numbers.html. >> We note that many of the functions and socket options defined in this >> document may have error returns that are not defined in this >> document. Many of these possible error returns will be recognized >> only as implementations proceed. > This might have been true the first time this document was > produced. Is it still true today? As I said above, rfc2292bis is not very mature yet. So, I think this paragraph is still true, at least to some extent. How about s/many/some/ here? >> 4.3BSD Reno sockets API in 1990. The reason is that these ancillary >> data fields are part of the Posix.1g standard and should therefore be >> adopted by most vendors. > why are there appendices? seems like at least some of these are part of > the spec itself. Putting them in the appendices would imply that they > perhaps aren't important. Hmm, the appendices were introduced in 2292bis-00, and I was not an editor at that time. Perhaps Erik can explain the intention. Based on my own check for the appendices, sections 22 and 23 can still be there, because they are too-detailed examples. 21.3.4 and 21.3.5 should perhaps be moved back to main sections, since they are new definitions in this API. What do you think of it, Erik? > note: "int " is used throughout. Is this a short/long int? Does this > need to be clarified, or is the current usage adequate? I've checked by grepping the entire text. I believe the current usage is okay. >> 5. Extensions to Socket Ancillary Data >> >> This specification uses ancillary data as defined in Posix.1g with >> the following compatible extensions: > should this ID also include text relative to the austin group work? I'm not sure what this comment exactly means...does the proposed change in Introduction answer to this comment? >> operation. Returning the received hop limit is useful for programs >> such as Traceroute and for IPv6 applications that need to verify that >> the received hop limit is 255 (e.g., that the packet has not been >> forwarded). > how does this help traceroute? Traceroute needs to set, not receive > the ttl. Actually, I had the same question before, and I slightly recall someone explained the intention at that time. However, I don't have a clear memory about it. I admit the description still seems odd. So, I don't mind to remove traceroute as an example, though. This feature is still useful for other purposed (as described just after this part). Unless anyone else clarifies this, I'll remove the traceroute usage. >> To specify the outgoing traffic class value, just specify the control >> information as ancillary data for sendmsg() or using setsockopt(). >> Just like the hop limit value, the interpretation of the integer >> traffic class value is >> >> x < -1: return an error of EINVAL >> x == -1: use kernel default >> 0 <= x <= 255: use x >> x >= 256: return an error of EINVAL > note that the terminology surrounding diffserv/traffic class has > changed (see RFC 3260). Is the current API still OK? there are only 64 > diffserv values now. (I think this is OK, but the authors should recheck). I've asked this to itojun, who originally proposed this socket option. Our decision is we should just go with RFC 2460 definitions (not 3260). So, the current text will not need to be revised. >> ENXIO The interface specified by ipi6_ifindex does not exist >> >> ENETDOWN The interface specified by ipi6_ifindex is not enabled for >> IPv6 use. >> > Indention not right. (too far to left) Are you talking about the space between the keyrword "EXNIO" and its description, etc? If so, I first must point out that this part is aligned with the longest keyword (EADDRNOTAVAIL). I don't mind to change the indentation policy, but is it really necessary? >> int inet6_opt_init(void *extbuf, size_t extlen); >> >> This function returns the number of bytes needed for the empty >> extension header i.e. without any options. > I don't understand this sentence. Does this then always return the > same value? And doesn't an "empty" header require 0 bytes? Or is this > actually "length remaining"? > Actully, the "length" field is weird in subsequent usages to. Is it > really a length, or an offset into the options? Calling it length is > confusing. Is it too late to change this? Yes, it always returns the same value (except -1 for errors). In our implementation, the value is 2 (the length of the "next header" and the "length" fields of an IPv6 option header), but I think the actual value can be hidden from the caller. As shown in the usage examples in Section 23, the "length" value is actually used as a kind of "offset." I don't think the current text is confusing, but we can rewrite the description using the term "offset". (It would not be too late, because the change will not break compatibility to existing implementations). Do you think we need the change? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 02:43:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E9hZ3U011641; Wed, 14 Aug 2002 02:43:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E9hZ6W011640; Wed, 14 Aug 2002 02:43:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E9hU3U011633 for ; Wed, 14 Aug 2002 02:43:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25148 for ; Wed, 14 Aug 2002 02:43:41 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20035 for ; Wed, 14 Aug 2002 02:43:40 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA07456; Wed, 14 Aug 2002 12:42:07 +0300 Date: Wed, 14 Aug 2002 12:42:07 +0300 Message-Id: <200208140942.MAA07456@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com In-reply-to: <29106.1029308619@munnari.OZ.AU> (message from Robert Elz on Wed, 14 Aug 2002 14:03:39 +0700) Subject: Re: DAD vs. DIID References: <200208131526.SAA05910@burp.tkv.asdf.org> <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> <29106.1029308619@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > > But can you test what happens if you configure an address on some other > node (using a different implementation), that happens to be one that yor > node will assign, without doing DAD on it explicitly, and then start > your node after that. I think the first discussion should be about the most common normal case: autoconfiguring using the "globally unique" EUI64 ID (or if not global, then at least ID which is supposed to be normally unique on the link). Ok, first definitions: - Node A, has "globally unigue" id = AI, implements "link local" optimization (does DAD only on fe80::AI). - Node B is the evil one :-). It has its own "globally unique" id = BI for it's link local - Prefix "P1::/64" is advertised on the link by the router. Events in order of occurrence: 1. Node B is manually configured with address "P1::AI" 2. Node B does DAD on "P1::AI" and assigns address, because node A is not yet connected. 3. Node A comes online on the link 4. Node A does DAD on "fe80::AI", and succeeds. 5. Router send RA with P1::/64 6. Node A uses P1::AI without doing DAD (and probably both A and B cannot communicate properly with this address). Some observations: - if before (6.), A did DAD on "P1::AI", it would fail and leave A without any global address to use. It's options would be a) accept the situation and be isolated b) generate temporary AIn and use "P1::AIn" (repeat until DAD succeeds) (can also redo fe80::AIn). - it seems that this is a configuration error on the node B, that should be detected and fixed. - situation does not occur in the normal autoconfiguration, where node needs to have a link local address first. The whole issue comes from the introduction of "privacy" and generated addresses. To me this is a special case, and it should solve it's own problems, and not break the normal case. And one solution is that, whatever address "Prefix::Id" you configure, you always do the DAD on linklocal "fe80::Id" (you don't need to actually generate this address, if you are not going to use it, just handle DAD as if you had it). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 03:14:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EAE53U011720; Wed, 14 Aug 2002 03:14:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EAE5RV011719; Wed, 14 Aug 2002 03:14:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EADx3U011712 for ; Wed, 14 Aug 2002 03:14:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05013 for ; Wed, 14 Aug 2002 03:14:08 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20779 for ; Wed, 14 Aug 2002 04:14:07 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id NAA07493; Wed, 14 Aug 2002 13:14:05 +0300 Date: Wed, 14 Aug 2002 13:14:05 +0300 Message-Id: <200208141014.NAA07493@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com CC: kre@munnari.OZ.AU, Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be In-reply-to: <200208140942.MAA07456@burp.tkv.asdf.org> (message from Markku Savela on Wed, 14 Aug 2002 12:42:07 +0300) Subject: Re: DAD vs. DIID References: <200208131526.SAA05910@burp.tkv.asdf.org> <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> <29106.1029308619@munnari.OZ.AU> <200208140942.MAA07456@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Markku Savela > > 5. Router send RA with P1::/64 Should be obvious to everyone, but just to be clear: that P1::/64 must naturally have A=1. If A=0, node A will never try to configure "P1::AI" and thus there is no collision. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 03:31:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EAVQ3U011760; Wed, 14 Aug 2002 03:31:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EAVQcR011759; Wed, 14 Aug 2002 03:31:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EAVK3U011752 for ; Wed, 14 Aug 2002 03:31:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05541 for ; Wed, 14 Aug 2002 03:31:29 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28157 for ; Wed, 14 Aug 2002 04:31:02 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7EAU4112659; Wed, 14 Aug 2002 17:30:05 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7EASIW29876; Wed, 14 Aug 2002 17:28:18 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <200208140942.MAA07456@burp.tkv.asdf.org> References: <200208140942.MAA07456@burp.tkv.asdf.org> <200208131526.SAA05910@burp.tkv.asdf.org> <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> <29106.1029308619@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Aug 2002 17:28:18 +0700 Message-ID: <29874.1029320898@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 14 Aug 2002 12:42:07 +0300 From: Markku Savela Message-ID: <200208140942.MAA07456@burp.tkv.asdf.org> | - Node B is the evil one :-). I don't think we need to characterize them, no deicide which is misconfigured. All that matters, is that you have shown what I thought - if we have some nodes doing DIID (optimising away some DAD checks, as has been permitted), and others doing pure DAD, we can get into problems. It is (now) also clear that we have some implementations that work both ways. That's not good. So, we need to require one or the other to avoid the problem. The Yokohama meeting room's opinion was that "just DAD on every address before assigning it" was the way to go. Sure, in your scenario, that means node A might be left with no global addr it can use. But that also might be what is intended to happen. What's important is that the clash is recognised, and reported, so it if something needs fixing, it can be fixed. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 04:26:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EBQ83U011848; Wed, 14 Aug 2002 04:26:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EBQ8wH011847; Wed, 14 Aug 2002 04:26:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EBQ23U011839 for ; Wed, 14 Aug 2002 04:26:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05712 for ; Wed, 14 Aug 2002 04:26:11 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17168 for ; Wed, 14 Aug 2002 05:26:10 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA07558; Wed, 14 Aug 2002 14:24:44 +0300 Date: Wed, 14 Aug 2002 14:24:44 +0300 Message-Id: <200208141124.OAA07558@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com In-reply-to: <29874.1029320898@munnari.OZ.AU> (message from Robert Elz on Wed, 14 Aug 2002 17:28:18 +0700) Subject: Re: DAD vs. DIID References: <200208140942.MAA07456@burp.tkv.asdf.org> <200208131526.SAA05910@burp.tkv.asdf.org> <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> <29106.1029308619@munnari.OZ.AU> <29874.1029320898@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > The Yokohama meeting room's opinion was that "just DAD on every > address before assigning it" was the way to go. But, in my honest opinion, that decision is wrong. Doing DAD on every address is in all respects more costly - implementation requires more complex code - it causes more packets on the link It should be remembered that I do not disallow configuring node A: address P1::id1 node B: address P2::id1 as long as "id1" is not configured as "autoconfigure id" to be combined with prefixes that have A=1. So, I'm kind of wondering what functionality is actually missing? I would propose following rules instead of do DAD on every address: - if id is used in autoconfigre (combine with prefix that has A=1), then doing DAD on "fe80::id" is sufficient - if id is not used in autoconfigure, it's actually part of full configured address "prefix::id", then do DAD on "prefix::id". - on receiving DAD on any X::id, there are couple of choices a) declare collision if "id" matches my id that is used in autoconfiguration b) declare collision if (a) AND "x::" is a prefix with A=1. Hoever, it is obvious that (b) is very weak, as RA for X::/64 may come later... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 09:16:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EGGk3U012876; Wed, 14 Aug 2002 09:16:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EGGko3012875; Wed, 14 Aug 2002 09:16:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EGGe3U012868 for ; Wed, 14 Aug 2002 09:16:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12988 for ; Wed, 14 Aug 2002 09:16:51 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27365 for ; Wed, 14 Aug 2002 09:16:50 -0700 (PDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Wed, 14 Aug 2002 09:16:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E27A@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Thread-Index: AcJDaUsxekvg7SVeRsSOwgSQtEjsWQAOY7fw From: "Michel Py" To: "Robert Elz" Cc: "Tim Hartrick" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7EGGf3U012869 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, | Michel Py wrote: | - There is currently no use made of the 'u' bit for any current or | future multihoming protocol I know of. > kre wrote: > So you have no problem if the text that tells about its > "global scope" gets yanked from the doc? I personally don't and in the bigger picture I would not lose sleep over it. As I said before, if there are compelling reasons to move away from the /64 hard boundary, the 'u' bit by itself does not appear to me to be a good enough reason to block that change. | - The 'u' bit is not a blocking reason why prefixes longer than | /64 are not allowed. > It is the only one I can see. It is also the only one I care > about. I think you are making a mistake here. If I may, I think that the reason you have failed to convince the WG to move away from the /64 hard boundary is *not* because you have failed to convince that we needed to get rid of the 'u' bit, but because you have failed to convince that we needed to move away from the /64 boundary as being its own issue. I might not have been clear, but the reason I support keeping the 'u' bit is *not* because I want to use it as an excuse to keep the /64 boundary, but because it makes little sense removing it as long as the /64 boundary is there. Forget about the 'u' bit. From my seat here, the hypothetical availability of a "son of GSE" is a very little factor in deciding to move away from the /64 hard boundary. If you have a case to make, make it on the real issue which is the /64 boundary. It appears to me that you are trying to modify the Addressing Architecture doc in order to allow very minor optimizations. Trying to make a comparison with IPv4: - Using a /30 on a ptp is a no-brainer. - Using a /31 is a slight enhancement. It still not is widely deployed, the reason being that, even in a v4 environment where addresses do need to be aggressively conserved, the gain from moving to /31 instead of /30 is not that significant. - Finally, there is un-numbered, and I don't see much of it and don't use it myself. Why is un-numbered to being universally used for ptp links? Because the operational annoyances resulting from using it are such a pain that they do not balance the fact that un-numbered provides unlimited ptp links without using any precious IPv4 IP addresses. In weighing the pros and cons of removing the /64 hard boundary, my opinion is that the savings that it would bring are not significant enough compared to the potential operational annoyances. I can feel your desire to produce a spec that is as perfect as it possibly could. Please keep something in mind, though: IPv6 has been designed from the ground-up with an explicit trade-off between allocation efficiency and simplicity. You call this trade-off waste, I don't. I think that removing the /64 hard boundary goes too far on the allocation efficiency side of that trade-off. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 11:09:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EI9Y3U013423; Wed, 14 Aug 2002 11:09:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EI9Y9O013422; Wed, 14 Aug 2002 11:09:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EI9S3U013415 for ; Wed, 14 Aug 2002 11:09:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24868 for ; Wed, 14 Aug 2002 11:09:37 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10439 for ; Wed, 14 Aug 2002 12:09:36 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 14 Aug 2002 11:11:40 -0700 Reply-To: From: "Tony Hain" To: , Subject: RE: ipv4 to ipv6 conversion tool Date: Wed, 14 Aug 2002 11:09:28 -0700 Message-ID: <023c01c243bd$bb24db70$011aa8c0@eagleswings> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000201c24364$e1e691d0$96c8a8c0@star.itonsite.com.au> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk cj wrote: > G'day folks > I have just started looking into this ipv6 > what I was wandering is there an ipv4 to ipv6 conversion > tool. ie I type in an ipv4 ip address and it gives me the > equivalent ipv6 address > It is clear from the question you are just starting to look at this. I would respectfully suggest you invest time in reading a couple of IPv6 books. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 19:14:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F2EC3U015380; Wed, 14 Aug 2002 19:14:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F2EBmU015379; Wed, 14 Aug 2002 19:14:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F2E63U015372 for ; Wed, 14 Aug 2002 19:14:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26850 for ; Wed, 14 Aug 2002 19:14:16 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12719 for ; Wed, 14 Aug 2002 19:14:16 -0700 (PDT) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g7F2Ags06283; Wed, 14 Aug 2002 19:10:42 -0700 (PDT) Date: Wed, 14 Aug 2002 19:10:42 -0700 From: Shannon -jj Behrens To: Robert Elz Cc: Michel Py , Tim Hartrick , narten@us.ibm.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt"Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Message-ID: <20020814191042.C5872@alicia.nttmcl.com> References: <2B81403386729140A3A899A8B39B046405E265@server2000.arneill-py.sacramento.ca.us> <18986.1028973709@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <18986.1028973709@munnari.OZ.AU>; from kre@munnari.OZ.AU on Sat, Aug 10, 2002 at 05:01:49PM +0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Without that, the impression is that everyone is just silently agreeing > (other than those who say that the draft can't change because it already > exists) with the points being made, but I am pretty sure that's not the > case. But I have no idea at all why. Maybe someone can convince me that > there's actually some benefit that I just can't see. I, for one, am silently agreeing with you. As best I can tell, here are the arguments involved (I will present each argument followed by my opinion on the argument): 1) The u bit only makes sense if we keep the 64-bit boundary, so we must keep the 64-bit boundary just in case we one day figure out how to use the u bit. This argument should be removed because even Michael Py states that it is a red herring. I.e., even Michael Py states that the strength of his argument for keeping the 64-bit boundary does not rest on the possible uses of the u bit. 3) EUI-64 is good. It shouldn't be removed! No one is advocating this. In fact, what we are advocating does not have any influence on how anyone else chooses to operate. I am simply asking for the freedom to use the last 64 bits in whatever way I choose. 3) The draft should not be updated. Instead, stability is crucial. The draft is already being updated. Furthermore, removing the 64-bit boundary does not appear to have an affect on any existing implementations. 3) Current implementations do not enforce the 64-bit boundary, nor do they enforce the uniqueness implied by the u bit. I am slightly unclear about these two points. I have seen that implementations do not inforce the uniqueness implied by the u bit; however, it has already been decided to ignore the u bit in this argument. I am not sure if implementations forbit prefixes longer than 64-bits. Based on what I have read on this list, they don't. If this is true, than it is fair to say implementation experience has proven that the 64-bit boundary is not necessary. Implementation experience is a very valid reason to update the draft. 4) Current practice does make use of prefixes longer than 64 bits. This increases the strength of the argument in number 3. Current practice should indeed have an influence on whether or not this draft should be updated. In other words, because using a /126 has been proven to be safe for point-to-point links, there is no reason to forbid it. 4) Allocation efficiency for point-to-point links. Some people feel that the the overhead of using a /64 for a point-to-point link is small, and quite justifiable if it simplifies things. Others feel that space should not be wasted, and that any simplification achieved is not justifiable, in this case. I feel that the amount of time you spend arguing a point should be based on the relative importance of the point. Having said that, I'd like to say...nothing (i.e. the importance of this point does not justify further argument) :) 5) I want to have maximum freedom with my /64. This is the most important argument, in my mind. I don't think any benefit gained from establishing a 64-bit boundary can possibly justify loosing the freedom of not being confined to that boundary. I think that this point will become increasingly important in the long run. Furthermore, I think any arguments in favor of the 64-bit boundary will likely become less important in the long run. 6) Not establishing a 64-bit boundary will make the lives of ASIC designers difficult. I know nothing about designing ASIC's. However, I presume that the header chaining used in IPv6 is an even more difficult challenge for ASIC designers. Hence, I doubt this argument has real merit. 7) Using a 64-bit boundary may permit certain memory optimizations since every prefix will be at most 64 bits long. This argument has been disproved in this thread twice. In summary, I feel that experience has shown that the 64-bit boundary is unnecessarily confining and should be removed. Best Regards, -jj -- o*s*o*pho*bi*a n. A common fear among embedded systems programmers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 20:47:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F3lE3U015702; Wed, 14 Aug 2002 20:47:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F3lEqP015701; Wed, 14 Aug 2002 20:47:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F3l83U015694 for ; Wed, 14 Aug 2002 20:47:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA12447 for ; Wed, 14 Aug 2002 20:47:19 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13741 for ; Wed, 14 Aug 2002 20:47:19 -0700 (PDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt"Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Date: Wed, 14 Aug 2002 20:47:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E280@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt"Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Thread-Index: AcJEAX2fIAYolRmQQQO0NSzPRfQOWgAB6Yiw From: "Michel Py" To: "Shannon -jj Behrens" , "Robert Elz" Cc: "Tim Hartrick" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7F3l93U015695 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have to say that jj's post is a fresh approach to this, and I welcome it. Someone has told me recently that kre and myself arguing endlessly about the issue reminded him of Karpov and Kasparov playing the same game 20 times, with some minor variants past the 50th move, and always coming to the same result: draw. > 1) The u bit only makes sense if we keep the 64-bit boundary, > so we must keep the 64-bit boundary just in case we one day > figure out how to use the u bit. This argument should be > removed because even Michael Py states that it is a red > herring. I.e., even Michael Py states that the strength of > his argument for keeping the 64-bit boundary does not rest > on the possible uses of the u bit. I need to make clear that I do *not* represent the opinion of the heirs of GSE by any means. I am in the same lack of feedback darkness about the future use of the 'u' bit than this WG is about prefixes longer than /64. So, by trying to guess the meaning of silence, we should not forget that there probably are lots of people there that still have strong feelings about this. In other words: I have tried to be intellectually unbiased about the 'u' bit issue, but please take my opinion for what's it's worth, which is basically that I don't give a hoot to it; I don't want my words to be interpreted as the opinion of multihomers. I can lead the horse to the water but I can't make it drink. That being said, allow me to renew my position that is the -09 should be shipped. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 21:52:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F4q83U015795; Wed, 14 Aug 2002 21:52:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F4q7lG015794; Wed, 14 Aug 2002 21:52:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F4q23U015787 for ; Wed, 14 Aug 2002 21:52:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA21832 for ; Wed, 14 Aug 2002 21:52:12 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14310 for ; Wed, 14 Aug 2002 22:52:07 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7F4p4119347; Thu, 15 Aug 2002 11:51:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7F4mRW03824; Thu, 15 Aug 2002 11:48:27 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Shannon -jj Behrens" , "Tim Hartrick" , narten@us.ibm.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt"Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B046405E280@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E280@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Aug 2002 11:48:27 +0700 Message-ID: <3822.1029386907@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 14 Aug 2002 20:47:17 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E280@server2000.arneill-py.sacramento.ca.us> | Someone has told me recently that kre and myself arguing endlessly | about the issue reminded him of Karpov and Kasparov playing the same | game 20 times, with some minor variants past the 50th move, and always | coming to the same result: draw. There's probably something in that... | So, by trying to guess the meaning of silence, we should not forget that | there probably are lots of people there that still have strong feelings | about this. I disagree. We should absolutely forget that. If any of those people are out there, let them speak for themselves, rather than us just assuming that surely they must exist. If someone believes they exist, but aren't on this list, then send a message to them, indicating what is being discussed and invite a reply. But let's actually look for real opinions, rather than rehashed third hand accounts of what some unknown other person's opinion just might be. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 21:59:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F4xa3U015843; Wed, 14 Aug 2002 21:59:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F4xaX7015842; Wed, 14 Aug 2002 21:59:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F4xU3U015835 for ; Wed, 14 Aug 2002 21:59:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA23346 for ; Wed, 14 Aug 2002 21:59:40 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16868 for ; Wed, 14 Aug 2002 22:59:33 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7F4wN122005; Thu, 15 Aug 2002 11:58:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7F4vXW03842; Thu, 15 Aug 2002 11:57:33 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: "Tim Hartrick" , narten@us.ibm.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <2B81403386729140A3A899A8B39B046405E27A@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E27A@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Aug 2002 11:57:33 +0700 Message-ID: <3840.1029387453@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 14 Aug 2002 09:16:47 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E27A@server2000.arneill-py.sacramento.ca.us> | I might not have been clear, but the reason I support keeping the 'u' | bit is *not* because I want to use it as an excuse to keep the /64 | boundary, but because it makes little sense removing it as long as the | /64 boundary is there. You were clear enough, I understood that. Maybe I wasn't clear enough that the 'u' but is the worst part of the draft. It (or the part of it which pretends to be visible externally) is the thing which most needs to be deleted. I don't just want it gone in order that the 64 bit boundary can go, I want it gone because it is unimplementable nonsense, which doesn't belong in the doc. It just happens that after this goes, the sole motivation for keeping fixed /64 also goes, so it may as well be removed at the same time. | It appears to me that you are trying to modify the Addressing | Architecture doc in order to allow very minor optimizations. Forget the optimisations. What I want is for it to actually describe the addressing architecture. And not something which someone believes it would be nice if it was like, but without any reasoning. I think it was Thomas who said that we don't have to adjust our docs to allow for other people ignoring them, and doing broken things. And that's certainly right. An example was the "just send 8" SMTP argument, lots of people did that, and argued for adopting it - but it is easy to show how that is technically wrong. On the other hand, if lots of people are doing things one way, and there's no technical argument to show that it should be done a different way, then it really starts to look as if the only reason for not changing is stubbornness. | In weighing the pros and cons of removing the /64 hard boundary, my | opinion is that the savings that it would bring are not significant | enough compared to the potential operational annoyances. Name one operational annoyance? That is one that my use of /112 (or someone else's use of /126 or /127) inflicts upon you, assuming that you're not the other end of the link (if you are, it is your choice to participate, no-one is compelling you to use > /64). Just one. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 22:10:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F5Al3U015889; Wed, 14 Aug 2002 22:10:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F5AkmW015888; Wed, 14 Aug 2002 22:10:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F5Ae3U015881 for ; Wed, 14 Aug 2002 22:10:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15376 for ; Wed, 14 Aug 2002 22:10:50 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21398 for ; Wed, 14 Aug 2002 23:10:43 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7F59u127139; Thu, 15 Aug 2002 12:09:57 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7F590W03877; Thu, 15 Aug 2002 12:09:00 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <200208141124.OAA07558@burp.tkv.asdf.org> References: <200208141124.OAA07558@burp.tkv.asdf.org> <200208140942.MAA07456@burp.tkv.asdf.org> <200208131526.SAA05910@burp.tkv.asdf.org> <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> <29106.1029308619@munnari.OZ.AU> <29874.1029320898@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Aug 2002 12:09:00 +0700 Message-ID: <3875.1029388140@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 14 Aug 2002 14:24:44 +0300 From: Markku Savela Message-ID: <200208141124.OAA07558@burp.tkv.asdf.org> | - implementation requires more complex code I don't know how you reach that conclusion. The DAD approach is simple to understand and to code ... any time an address is to be assigned, run the DAD algorithm (which is the same whether it is used for a pure DAD approach, or a DIID one). That's it. No need to go looking to see if it has run before, no need to invent LL addresses to run DAD on, no need to do any special case handling of incoming NS messages to see if they're DAD< and if so reply to ones that wouldn't otherwise have been replied to,... | - it causes more packets on the link This one is undisputed. I'm not aware of measurements of how many more. Do note though that typical DAD NS packets use wire bandwidth, but nothing else (no-one receives them), so they're not very costly. They're also not usually very frequent (configuring new addresses doesn't happen all that often). | So, I'm kind of wondering what functionality is actually missing? I don't think it is really a question of missing functionality, though a hint of that was presented at the WG meeting. It is more a case of there currently being two different implementations of this in the field, which don't work well together - one of those has to be picked as the correct one. | I would propose following rules instead of do DAD on every address: And this is simpler than "do DAD on every address" ? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 22:35:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F5ZZ3U015981; Wed, 14 Aug 2002 22:35:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F5ZZYY015980; Wed, 14 Aug 2002 22:35:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F5ZT3U015973 for ; Wed, 14 Aug 2002 22:35:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA28649 for ; Wed, 14 Aug 2002 22:35:39 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06131 for ; Wed, 14 Aug 2002 23:35:35 -0600 (MDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 0B47524B; Wed, 14 Aug 2002 22:35:35 -0700 (PDT) Date: Wed, 14 Aug 2002 22:35:34 -0700 From: David Terrell To: ipng@sunroof.eng.sun.com Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Message-ID: <20020815053534.GA26636@pianosa.catch22.org> Reply-To: David Terrell References: <2B81403386729140A3A899A8B39B046405E280@server2000.arneill-py.sacramento.ca.us> <3822.1029386907@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3822.1029386907@munnari.OZ.AU> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 10:20PM up 2:07, 30 users, load averages: 0.39, 0.41, 0.33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Aug 15, 2002 at 11:48:27AM +0700, Robert Elz wrote: > | So, by trying to guess the meaning of silence, we should not forget that > | there probably are lots of people there that still have strong feelings > | about this. Silence indicates [whatever I want to happen] :) > I disagree. We should absolutely forget that. If any of those people > are out there, let them speak for themselves, rather than us just assuming > that surely they must exist. If someone believes they exist, but aren't > on this list, then send a message to them, indicating what is being discussed > and invite a reply. > > But let's actually look for real opinions, rather than rehashed third > hand accounts of what some unknown other person's opinion just might be. I'd rather aggregate all my ptp links into a single /64 than some notable fraction of a /(64-48). As a user, I would file bugs against any vendor that prohibited me from doing so. As such, I'd say that codifying a hard requirement for /64 is contrary to what I would use, EUI-64 not withstanding. Clearly autoconfig and EUI-64 and whatnot all require /64s, and I don't have any issue with that. I even don't mind requiring /119s (rfc 2526). But /64? Yuck. Makes a big hole in my aggregation. -- David Terrell | "I went into Barnes and Noble to look for a Prime Minister, Nebcorp | book on A.D.D., but I got bored and left." dbt@meat.net | - Benjy Feen http://wwn.nebcorp.com/ | -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 14 23:24:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F6Ol3U016160; Wed, 14 Aug 2002 23:24:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F6OlMN016159; Wed, 14 Aug 2002 23:24:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F6Od3U016152 for ; Wed, 14 Aug 2002 23:24:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05480 for ; Wed, 14 Aug 2002 23:24:49 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15257 for ; Thu, 15 Aug 2002 00:24:49 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id XAA20532; Wed, 14 Aug 2002 23:21:15 -0700 (PDT) Received: from garcia.mentat.com (garcia [192.88.122.235]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id XAA17393; Wed, 14 Aug 2002 23:21:14 -0700 (PDT) Received: (from tim@localhost) by garcia.mentat.com (8.9.3+Sun/8.9.3) id XAA01879; Wed, 14 Aug 2002 23:21:04 -0700 (PDT) Date: Wed, 14 Aug 2002 23:21:04 -0700 (PDT) From: Tim Hartrick Message-Id: <200208150621.XAA01879@garcia.mentat.com> To: kre@munnari.oz.au, msa@burp.tkv.asdf.org Subject: Re: DAD vs. DIID Cc: Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > Ok, first definitions: > > - Node A, has "globally unigue" id = AI, implements "link local" > optimization (does DAD only on fe80::AI). > > - Node B is the evil one :-). It has its own "globally unique" id = BI > for it's link local > I agree. Our implementation won't allow an application to assign an address to an interface which has the the "u" bit set. Not even an application that has root privileges. Addresses of that form can only be assigned to interfaces if the id has been derived directly from the EUI-64 of the network interface. Yes, yes, that can be circumvented by diddling the MAC address of the network interface but requires more work. We don't allow the fumble fingered administrator to abscond with someone else's id without putting some effort into it. I would say that Node B's implementation is kind of broken. My general opinion on this topic is that all "statically" configured addresses should have DAD performed on them. This includes privacy addresses. The only addresses which don't require DAD are addresses which are derived directly from an advertised prefix and a real EUI-64 which has been used to derive a link-local address, which itself has had DAD performed on it. I have no problem with changing our implementation to do DAD on every address but I would have some serious reservations about creating and defending a link-local address associated with every privacy address. That is crazy. If complexity is the enemy then such a scheme can't be characterized as anything but an enemy. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 01:53:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F8r83U016497; Thu, 15 Aug 2002 01:53:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F8r7Cv016496; Thu, 15 Aug 2002 01:53:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F8r23U016489 for ; Thu, 15 Aug 2002 01:53:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00500 for ; Thu, 15 Aug 2002 01:53:12 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08082 for ; Thu, 15 Aug 2002 02:53:11 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id A464D8614 for ; Thu, 15 Aug 2002 10:53:08 +0200 (CEST) Received: from cyan (gateway.azr.nl [::ffff:156.83.254.8]) by purgatory.unfix.org (Postfix) with ESMTP id 31B2A7761 for ; Thu, 15 Aug 2002 10:53:01 +0200 (CEST) From: "Jeroen Massar" To: Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Thu, 15 Aug 2002 10:52:13 +0200 Organization: Unfix Message-ID: <000501c24439$0cfe1d00$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020815053534.GA26636@pianosa.catch22.org> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Razor-id: f55692731bfa811a7bde229bda20154624ba8808 X-Spam-Status: No, hits=-3.4 tests=IN_REP_TO Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My humble opinion on this matter: - Use a /64 on a link where multiple hosts could reside (ethernet, wavelan, ..) This ensures that when one needs to renumber to another provider one doesn't get a smaller prefix. And autoconfigure can work in this setup. - Use EUI-64 where possible Makes it easier to autoconfigure. But don't hesitate to use anything else if you really want to. It's your /64, *you* have to manage it, it's *your* problem. Also note that at a corporation you might not be the only one managing the network. You might go away for some reason and another person has to do the work then. - Tunnels which will never be native should use a /127 simply to conserve space. And if you really really want to use a /120 on your ethernet, have fun with it configuring all your boxes. This does imply that IPv6 stack implementors shouldn't limit, software _could_ warn though that it breaks stuff. Ofcourse one could setup DHCPv6 or something to serve /120's... Actually, that subnet is your problem, not that of the rest of the world. If it doesn't work, foo on you ;) Ofcourse these are my opinions. Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 01:59:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F8xX3U016542; Thu, 15 Aug 2002 01:59:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F8xWsr016541; Thu, 15 Aug 2002 01:59:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F8xR3U016534 for ; Thu, 15 Aug 2002 01:59:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01770 for ; Thu, 15 Aug 2002 01:59:38 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16260 for ; Thu, 15 Aug 2002 01:59:37 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7F8xYf20277; Thu, 15 Aug 2002 11:59:34 +0300 Date: Thu, 15 Aug 2002 11:59:34 +0300 (EEST) From: Pekka Savola To: Jeroen Massar cc: ipng@sunroof.eng.sun.com Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt In-Reply-To: <000501c24439$0cfe1d00$534510ac@cyan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 15 Aug 2002, Jeroen Massar wrote: > My humble opinion on this matter: > > - Use a /64 on a link where multiple hosts could reside (ethernet, > wavelan, ..) > This ensures that when one needs to renumber to another provider one > doesn't get a smaller prefix. > And autoconfigure can work in this setup. > > - Use EUI-64 where possible > Makes it easier to autoconfigure. > But don't hesitate to use anything else if you really want to. > It's your /64, *you* have to manage it, it's *your* problem. > Also note that at a corporation you might not be the only one managing > the network. > You might go away for some reason and another person has to do the > work then. Nobody is disputing this in the case of many hosts (e.g. LAN). > - Tunnels which will never be native should use a /127 simply to > conserve space. Did you read the draft? > And if you really really want to use a /120 on your ethernet, have fun > with it configuring all your boxes. > This does imply that IPv6 stack implementors shouldn't limit, software > _could_ warn though that it breaks stuff. > Ofcourse one could setup DHCPv6 or something to serve /120's... Nobody has suggested they're going to do this. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 08:30:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FFUc3U017505; Thu, 15 Aug 2002 08:30:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FFUb7J017504; Thu, 15 Aug 2002 08:30:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FFUW3U017497 for ; Thu, 15 Aug 2002 08:30:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26692 for ; Thu, 15 Aug 2002 08:30:42 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25568 for ; Thu, 15 Aug 2002 08:30:41 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 39341672D; Thu, 15 Aug 2002 11:30:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 15 Aug 2002 11:30:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAD vs. DIID Date: Thu, 15 Aug 2002 11:30:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8FC7@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcJEJG31OT7yVHzTS3SG4WMoLENvQAATBg7A From: "Bound, Jim" To: "Tim Hartrick" , , Cc: , , X-OriginalArrivalTime: 15 Aug 2002 15:30:40.0880 (UTC) FILETIME=[B6821700:01C24470] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7FFUW3U017498 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The optimizations I did for T64 were added to by our team and we as of a previous release are doing DAD for all addresses now as Tim suggests below. What drove us was Mobile IPv6 and folks creating privacy addresses. /jim > -----Original Message----- > From: Tim Hartrick [mailto:tim@mentat.com] > Sent: Thursday, August 15, 2002 2:21 AM > To: kre@munnari.oz.au; msa@burp.tkv.asdf.org > Cc: Bound, Jim; mrw@windriver.com; Robert.Peschi@alcatel.be; > ipng@sunroof.eng.sun.com > Subject: Re: DAD vs. DIID > > > > > > All, > > > > > Ok, first definitions: > > > > - Node A, has "globally unigue" id = AI, implements "link local" > > optimization (does DAD only on fe80::AI). > > > > - Node B is the evil one :-). It has its own "globally > unique" id = BI > > for it's link local > > > > I agree. Our implementation won't allow an application to > assign an address > to an interface which has the the "u" bit set. Not even an > application that > has root privileges. Addresses of that form can only be > assigned to interfaces > if the id has been derived directly from the EUI-64 of the > network interface. > Yes, yes, that can be circumvented by diddling the MAC > address of the network > interface but requires more work. We don't allow the fumble fingered > administrator to abscond with someone else's id without > putting some effort > into it. > > I would say that Node B's implementation is kind of broken. > > My general opinion on this topic is that all "statically" > configured addresses > should have DAD performed on them. This includes privacy > addresses. The > only addresses which don't require DAD are addresses which are derived > directly from an advertised prefix and a real EUI-64 which > has been used to > derive a link-local address, which itself has had DAD performed on it. > > I have no problem with changing our implementation to do DAD on every > address but I would have some serious reservations about > creating and defending > a link-local address associated with every privacy address. > That is crazy. > If complexity is the enemy then such a scheme can't be > characterized as > anything but an enemy. > > > > tim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 11:14:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FIE63U017918; Thu, 15 Aug 2002 11:14:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FIE6Sd017917; Thu, 15 Aug 2002 11:14:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FIDx3U017910 for ; Thu, 15 Aug 2002 11:13:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03425 for ; Thu, 15 Aug 2002 11:14:09 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21074 for ; Thu, 15 Aug 2002 12:14:07 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07817; Thu, 15 Aug 2002 14:12:43 -0400 (EDT) Message-Id: <200208151812.OAA07817@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Default Address Selection for IPv6 to Proposed Standard Date: Thu, 15 Aug 2002 14:12:43 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Default Address Selection for IPv6' as a Proposed Standard. This document is the product of the IP Version 6 Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary In IPv6, a node may have multiple addresses. Consequently, when initiating a communication with a destination, there is a choice as to which destination address to use (if the destination has multiple addresses listed in the DNS) as well as to which source address to use (if the initiating node has multiple addresses). This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. Working Group Summary There was consenus in the WG for this document and no issues were raised during the Last Call. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 12:08:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FJ8Y3U018341; Thu, 15 Aug 2002 12:08:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FJ8X5k018340; Thu, 15 Aug 2002 12:08:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FJ8R3U018333 for ; Thu, 15 Aug 2002 12:08:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14837 for ; Thu, 15 Aug 2002 12:08:37 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24802 for ; Thu, 15 Aug 2002 13:08:36 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7FJ8T000767; Thu, 15 Aug 2002 15:08:29 -0400 (EDT) Message-Id: <200208151908.g7FJ8T000767@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: The IESG cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com Subject: Re: Protocol Action: Default Address Selection for IPv6 to Proposed Standard In-reply-to: (Your message of "Thu, 15 Aug 2002 14:12:43 EDT.") <200208151812.OAA07817@ietf.org> Date: Thu, 15 Aug 2002 15:08:29 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk wow. Having the document be approved by IESG is not a surprise, but at the same time - the announcement is extremely misleading. Serious problems with the entire idea of address selection were repeatedly raised in WG discussions. At the very least this should have been reflected in the document announcement. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 13:13:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FKD73U018840; Thu, 15 Aug 2002 13:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FKD6Cw018839; Thu, 15 Aug 2002 13:13:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FKD03U018832 for ; Thu, 15 Aug 2002 13:13:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19996 for ; Thu, 15 Aug 2002 13:13:12 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18784 for ; Thu, 15 Aug 2002 13:13:11 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7FJwiY22765; Thu, 15 Aug 2002 21:58:44 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA27778; Thu, 15 Aug 2002 21:58:44 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7FJwc6o086065; Thu, 15 Aug 2002 21:58:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208151958.g7FJwc6o086065@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: kre@munnari.OZ.AU, Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-reply-to: Your message of Tue, 13 Aug 2002 18:26:45 +0300. <200208131526.SAA05910@burp.tkv.asdf.org> Date: Thu, 15 Aug 2002 21:58:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Here I have to raise a hand. I wrote implementation that actually followed the allowed optimization: do DAD only on link-local, and then freely combine that ID with announced prefixes WITHOUT doing a separate DAD for EACH prefix*ID combination. => so you have implemented DIID. This is still fully allowed by current RFC's, => you can't say this is *fully* allowed by current RFCs. In fact IMHO this is both allowed and forbiden so RFCs are not sound... and I still believe this is GOOD, and should not be changed. => there are two points: - RFCs don't clearly specify DAD or DIID. I believe you agree there is a real problem to fix ASAP. - we have to choose between DAD and DIID: as almost everybody implemented DAD the rough consensus is DAD. As a consequence, and observing that others may not have chosen this tactics, the code also defends plain ID, that is: if it sees a DAD for address which contains one of my ID's, it will reply to the DAD as if I had the address. => this is a good idea but is not specified at all in RFCs: you've just shown your DIID choice is not directly compatible with the common DAD choice, so something (in RFCs, not in your implementation) has to be fixed! I don't see any catastrophic failures resulting from it. => only some hundreds of junk mails in the mobile ip mailing list... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 14:41:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FLff3U019630; Thu, 15 Aug 2002 14:41:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FLffiT019629; Thu, 15 Aug 2002 14:41:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FLfZ3U019622 for ; Thu, 15 Aug 2002 14:41:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07807 for ; Thu, 15 Aug 2002 14:41:44 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01748 for ; Thu, 15 Aug 2002 15:41:43 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id AAA10192; Fri, 16 Aug 2002 00:36:43 +0300 Date: Fri, 16 Aug 2002 00:36:43 +0300 Message-Id: <200208152136.AAA10192@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: Jim.Bound@hp.com, mrw@windriver.com, Robert.Peschi@alcatel.be, ipng@sunroof.eng.sun.com In-reply-to: <3875.1029388140@munnari.OZ.AU> (message from Robert Elz on Thu, 15 Aug 2002 12:09:00 +0700) Subject: Re: DAD vs. DIID References: <200208141124.OAA07558@burp.tkv.asdf.org> <200208140942.MAA07456@burp.tkv.asdf.org> <200208131526.SAA05910@burp.tkv.asdf.org> <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> <29106.1029308619@munnari.OZ.AU> <29874.1029320898@munnari.OZ.AU> <3875.1029388140@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > Date: Wed, 14 Aug 2002 14:24:44 +0300 > From: Markku Savela > Message-ID: <200208141124.OAA07558@burp.tkv.asdf.org> > > | - implementation requires more complex code > > I don't know how you reach that conclusion. The DAD approach is > simple to understand and to code ... Yes, I guessed my claim would need some further explanations. "Complexity" can be somewhat subjective thing... > | I would propose following rules instead of do DAD on every address: > > And this is simpler than "do DAD on every address" ? Well, I tried be nice and thought to allow doing DAD on manually configured addresses. But, I can also define even simple rule that works (but, is "*really* strict ID for one node"): "regadless of address you configure, always do DAD on linklocal address using the ID-part of your address" Although, a bit longer statement, the implementation is surely at least as simple as the "do DAD on every address". Why do I think "do DAD on every address" is more complex: --------------------------------------------------------- You need to look under the hood to uncover the nasty bits... (1) By far the most displeasing fact is that, it has the "delayed failure mode": when the node comes online, it passes the DAD on link local, but there there is no guarantee that it remains fully functional later because - at any time later the link may require a use of a prefix (A=1) from RA, and when trying to make a global address with it, this can "legally fail". Node really cannot complain, it just need to have extra complexity of code to generate new id for that prefix. A node cannot decide on "autopilot" whether this is error or not. - compared to DIID, when node comes online (or an address is configured) and passes the DAD on link local, it guaranteed to be working with any announced prefix (A=1). Having to nodes trying for same link local is ALWAYS an error condition. Node does not need any additional logic for generating new ID's on RA's (although, it could, but it can also complain loudly on the error log about condition). That is, with "DIID" you can plug in a node (or configure an address) to a link and watch it autoconfigure in few seconds. If that passes, you can expect it to stay functional, with whatever prefixes the link will use now or later. (2) A minor issue, if your link has 1000 nodes doing "do DAD", a nasty node can generate nice traffic by fakin RA with multiple prefixes from different address (as every node will be doing DAD on every prefix*id combination). MINOR issue, because if bad guy gets this level access to link, you are hosed anyway... Anyway, with DIID, RA with any number of prefixes causes ZERO DAD probes. *************** Finally, the autoconfigure draft must be changed to allow only one choice. If people think "do DAD" is it, it can be implemented. It is just my opinion that DIID would be more simple. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 16:07:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FN7P3U020429; Thu, 15 Aug 2002 16:07:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FN7OsI020428; Thu, 15 Aug 2002 16:07:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FN7J3U020421 for ; Thu, 15 Aug 2002 16:07:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19540 for ; Thu, 15 Aug 2002 16:07:29 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08271 for ; Thu, 15 Aug 2002 17:07:29 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA25624 for ; Thu, 15 Aug 2002 16:07:28 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7FN7Sa26419 for ; Thu, 15 Aug 2002 16:07:28 -0700 X-mProtect: <200208152307> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdh9tmJB; Thu, 15 Aug 2002 16:07:26 PDT Message-ID: <3D5C342F.F55EC0D1@iprg.nokia.com> Date: Thu, 15 Aug 2002 16:07:27 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID References: <200208141124.OAA07558@burp.tkv.asdf.org> <200208140942.MAA07456@burp.tkv.asdf.org> <200208131526.SAA05910@burp.tkv.asdf.org> <9C422444DE99BC46B3AD3C6EAFC9711B020B8F6C@tayexc13.americas.cpqcorp.net> <22739.1029250220@munnari.OZ.AU> <29106.102 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, I have been trying to catch up by reading all the e-mails, but that's very hard these days! I think that DIID is simpler to understand and administer, and is besides much more scalable in the number of prefixes. Furthermore, try as I have to understand why anywone would prefer the DAD approach, I come up emptyhanded except for the single argument that existing implementations do DAD on every address. And I have read a lot of e-mails. Maybe everyone already agrees that DIID is more scalable. If anyone disagrees, I'd be surprised, but please remind me. Then the question is, why do so many people not care about scalability in this matter? That is for me the real puzzler. IPv6 provides so many addresses and so many prefixes that it's hard for us to understand. Therefore, I am sure we do not understand all possible uses for those many addresses and prefixes. Taking brute force unscalable approaches now, and shooting down a whole galaxy of future possibilities, is just not very sportsmanlike, much less wise or conservative with resources. This is my main concern. When I have voiced this concern, I get the answer that "We don't need that many subnet prefixes now". That is a very bad answer. There is one other abstract concern that I have, and one other very concrete concern. I believe that each of them clearly indicates the need for specifying DIID instead of DAD. The other abstract reason that bothers me about this "DAD" algorithm is that it assumes that not all nodes need to carry a link-local address to match their IID. I believe this is also a bad assumption. The link-local address has nice properties for protocol design, and offers a way to do things like Neighbor Discovery in the right way. It's easy to understand, and thus easier to get correct designs, and correct software and hardware. My belief is that the "DAD" algorithm substantially impairs the effectiveness of protocol design at this level. Simply put, it means that global IP addresses may no longer be known to satisfy properties that previously could have been established by protocol using link-local addresses. In other words, algorithms which should have been carried out with the previously useful link-local addresses would then always have to be carried out with global addresses, with the further complications arising from protection against remote attack which are enabled by globailty. If DAD proponents also wish to specify that every IID has to be associated with a link-local address, then I am thoroughly mystified, but at least the above problem goes away. The concrete reason this proposal is unwelcome for me is that it is very bad for Mobile IP. When a home agent receives a Binding Update, it has to ensure that the mobile node's home addresses remains valid on the link (the mobile node's home network). If the mobile node has not yet sent any Binding Update to the home agent, or if the last Binding Update has expired, the mobile node's addresses will remain undefended on the home network. Then, when the Binding Update is received, the first thing the home agent has to do is to ensure that the mobile node's home addresses have not been taken by some other node. If this home agent has to do this for dozens or hundreds of home addresses, it could be quite a burst of protocol. If this happens for a lot of mobile nodes at once, then the situation would just be that much (linearly) worse. Whenever a horde of mobile nodes all suddenly emerge into new radio coverage, this is quite likely to happen. Put briefly, "DAD" is "BAD" for: - scalability for subnet prefix utilization - link-local protocol design - Mobile IP - network administrator sanity (I didn't mention this, but hopefully it's obvious). As best I can tell, DIID is BAD for some existing implementations, and no other reason. In a way, this is benign, for two reasons: - Really using hundreds of subnets is not a concern with existing IPv6 deployments. Thus, if some platforms don't get it perfect just now, no worries. - By the time it really matters, the chances that existing platforms will have undergone _zero_ software upgrades is, approximately, _zero_. I hope this note will have some effect towards moderating the sentiments towards DAD that were in evidence in Yokohama. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 20:37:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G3bC3U021103; Thu, 15 Aug 2002 20:37:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7G3bCKp021102; Thu, 15 Aug 2002 20:37:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G3b63U021095 for ; Thu, 15 Aug 2002 20:37:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA16261 for ; Thu, 15 Aug 2002 20:37:17 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16311 for ; Thu, 15 Aug 2002 21:37:17 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 15 Aug 2002 20:37:16 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Aug 2002 20:37:16 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 15 Aug 2002 20:37:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD vs. DIID Date: Thu, 15 Aug 2002 20:37:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcJEmK5xh3WlfudwQEeAAZrcP0uZQAANbCDA From: "Brian Zill" To: X-OriginalArrivalTime: 16 Aug 2002 03:37:16.0715 (UTC) FILETIME=[37A697B0:01C244D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7G3b63U021096 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Maybe a summary would help: "DIID": - Nodes need to create a link-local address corresponding to every IID they use on a given link (and perform DAD on it). - Nodes don't need to perform DAD for non link-local address. - Multi-link subnet routers would have to defend link-local addresses across links, which could be considered confusing and nonsensical. "DAD": - Nodes don't need to create otherwise unnecessary link-local addresses corresponding to the IIDs they use for temporary or public-key-derived addresses. - Nodes need to perform DAD on all their addresses. - No strange consequences for multi-link subnets. As far as implementation complexity goes, it seems to me that "DAD" is far simpler, since the rule is the same for all addresses and you don't need to create extra addresses only used for doing DAD. Regarding efficiency, I think it depends upon whether a node has more prefixes or IIDs. For nodes on a link with lots of prefixes, "DIID" saves a little bandwidth by not having to do as much DAD. For nodes with lots of IIDs, "DAD" saves node resources related to configuring twice as many addresses. Offhand, I'd be tempted to give the edge to "DIID" here, but since I've seen various creative proposals for using large numbers of IIDs per node, it's not clear. My machines generally have more IIDs then prefixes. But I think the numbers have to get pretty significant in either case before these concerns begin to matter. The multi-link subnet router issue is more clear. "DAD" is a better architectural fit. Link-local addresses stay link-local and don't become these quasi-subnet-local addresses that are unique across the subnet but only reachable on-link. My take: given that it appears the majority of implementations currently do "DAD", and that "DAD" provides for a cleaner multi-link subnet architecture, I think "DAD" is the better choice. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 15 23:24:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G6OQ3U021414; Thu, 15 Aug 2002 23:24:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7G6OPpQ021413; Thu, 15 Aug 2002 23:24:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G6OK3U021406 for ; Thu, 15 Aug 2002 23:24:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14230 for ; Thu, 15 Aug 2002 23:24:31 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05119 for ; Fri, 16 Aug 2002 00:24:29 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id JAA10762; Fri, 16 Aug 2002 09:24:26 +0300 Date: Fri, 16 Aug 2002 09:24:26 +0300 Message-Id: <200208160624.JAA10762@burp.tkv.asdf.org> From: Markku Savela To: bzill@microsoft.com CC: ipng@sunroof.eng.sun.com In-reply-to: (bzill@microsoft.com) Subject: Re: DAD vs. DIID References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Brian Zill" > > My take: given that it appears the majority of implementations currently > do "DAD", and that "DAD" provides for a cleaner multi-link subnet > architecture, I think "DAD" is the better choice. Umm.. "majority of implementations"? What is this? How do you count them? When was this tally performed. Does each separate implementation count as one? Or, does the number of nodes running the implementation affect the count? Or some other weighing algorithm? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 16 00:54:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G7sU3U021537; Fri, 16 Aug 2002 00:54:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7G7sT9Y021536; Fri, 16 Aug 2002 00:54:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G7sM3U021529 for ; Fri, 16 Aug 2002 00:54:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17398 for ; Fri, 16 Aug 2002 00:54:32 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20585 for ; Fri, 16 Aug 2002 00:54:31 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7G7sPt13589; Fri, 16 Aug 2002 16:54:26 +0900 (JST) Date: Fri, 16 Aug 2002 16:54:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Brian Zill" Cc: Subject: Re: DAD vs. DIID In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 15 Aug 2002 20:37:16 -0700, >>>>> "Brian Zill" said: > My take: given that it appears the majority of implementations currently > do "DAD", and that "DAD" provides for a cleaner multi-link subnet > architecture, I think "DAD" is the better choice. (Aside from the point if multi-link subnet is a good thing or not), I tend to agree your analysis and conclusion. What is the "majority" can be controversial, but just for record, all *BSDs (actually derived from a single codebase, KAME) always do DAD for all addresses. Also, by watching the discussion so far, there seems to be no implementation except Markku's that can be called "DIID". At best, we saw implementations that enable the optimization described in RFC 2462, which I don't call DIID in this context. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 16 04:06:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GB6A3U021877; Fri, 16 Aug 2002 04:06:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7GB6AK7021876; Fri, 16 Aug 2002 04:06:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GB633U021869 for ; Fri, 16 Aug 2002 04:06:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12457 for ; Fri, 16 Aug 2002 04:06:13 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03125 for ; Fri, 16 Aug 2002 04:06:11 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 32AB74B22; Fri, 16 Aug 2002 20:06:02 +0900 (JST) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Fri, 09 Aug 2002 18:43:51 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 MTU for tunnel pseudo interfaces From: itojun@iijlab.net Date: Fri, 16 Aug 2002 20:06:02 +0900 Message-Id: <20020816110602.32AB74B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> if link MTUs are not stable enough, there will be more ICMP too big >> than we desire. >Please provide an analysis. I don't think this is the case. there was some research paper on IPv4 PMTU from aist-nara.ac.jp, i don't have a reference now. >The point is that I don't see why there should be anything >new here for tunneling. >The tradeoffs for path MTU discovery are: > - downside of ICMP error packets > - downside of additional roundtrip times due to the data packets being > lost when the packet is to big > - the benefit of making the retransmission unit the same as the loss > unit, while being able to with larger packets >If this tradeoff comes up with PMTUD makes sense when there is no >tunneling, then I don't see why the same conclusion doesn't hold >for the case of nested PMTUD using tunnels. >So I'm looking forward to your performance analysis. i think i have answered this (partially) in other emails. we are from very different assumption. >> with the cost of complexity in tunnel endpoint implementations (needs >> to maintain IPv4 path MTU and reflect it to IPv6 tunnel link MTU). >Yes. And there is additional complexity to implement PMTUD in the non-tunneling >case. Thus I think your arguments about performance and implementation >complexity can also be used to argue that we shouldn't do PMTUD at all and >instead send with 1280 bytes. requiring and maintaining PMTU for IPv4 for tunnel egress/ingress is different from requirement for PMTU for IPv6. i disagree with the above logic. >FWIW The Solaris implementation doesn't have soft state in the tunneling >pseudo-device driver. It is all reflected in the conceptual neighbor cache >for the "upper IP layer" when an ICMP too big arrives from the "lower IP >layer". then what is the IPv6 link MTU for tunnel interface, when you don't have IPv4 PMTU information? (like for the very first packet to go out from the path) >> i would really like to know how many of existing implementations follow >> this part of RFC2983. >Solaris does. *BSD and derived implementations don't (MacOS X at least, and probably JunOS and ExtremeWare). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 16 04:43:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GBhF3U022119; Fri, 16 Aug 2002 04:43:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7GBhFtd022118; Fri, 16 Aug 2002 04:43:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GBhA3U022111 for ; Fri, 16 Aug 2002 04:43:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28938 for ; Fri, 16 Aug 2002 04:43:20 -0700 (PDT) From: ashivale@ownmail.com Received: from mail003.ownmail.com (ownmail2.ownmail.com [203.199.69.135]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16311 for ; Fri, 16 Aug 2002 04:43:19 -0700 (PDT) Received: (from domains@localhost) by mail003.ownmail.com (8.10.2/8.10.2) id g7GBfbj17701; Fri, 16 Aug 2002 17:11:37 +0530 Date: Fri, 16 Aug 2002 17:11:37 +0530 Message-Id: <200208161141.g7GBfbj17701@mail003.ownmail.com> X-Originating-IP: 202.54.22.114 Reply-To: To: ipng@sunroof.eng.sun.com Subject: HTB Implementation Anomaly. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="171137167102.17697.ashivale@ownmail.com" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --171137167102.17697.ashivale@ownmail.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello Everyone!, I am facing a problem using HTB as a traffic shaper. No matter what I do, incoming traffic is not being curbed. My arrangement for simulation is as follows: 64kbps 64kbps 202.54.22.119/32<-------->202.54.22.114<-------->202.54.22.117/32 (leased line) (router) (Internal n/w) I know only egress traffic can be shaped. But as .114 is a router, all traffic coming to it from the leased line will have to go out. So the code for this is, tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip src 202.54.22.114/32 \ match ip dst 202.54.22.117/32 \ flowid 1:10 #where 1:10 class has 64kbits rate INCOMING: But the rate is not being curbed, and is around 870kbytes/sec . The ceil parameter is also not being followed. OUTGOING: All traffic obeys the ceil & rate obtained is 36kbytes/sec Please advise. Thanking you, Yours sincerely, Amit S. Shivale --171137167102.17697.ashivale@ownmail.com Content-Type: application/octet-stream; name=anonymous Content-Transfer-Encoding: BASE64 DQo= --171137167102.17697.ashivale@ownmail.com Content-Type: application/octet-stream; name=anonymous Content-Transfer-Encoding: BASE64 DQo= --171137167102.17697.ashivale@ownmail.com Content-Type: application/octet-stream; name=anonymous Content-Transfer-Encoding: BASE64 DQo= --171137167102.17697.ashivale@ownmail.com-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 16 09:15:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GGFk3U022667; Fri, 16 Aug 2002 09:15:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7GGFjF5022666; Fri, 16 Aug 2002 09:15:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GGFe3U022659 for ; Fri, 16 Aug 2002 09:15:40 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25876 for ; Fri, 16 Aug 2002 09:15:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10309 for ; Fri, 16 Aug 2002 10:15:39 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA03713; Fri, 16 Aug 2002 09:15:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7GGFcZ01101; Fri, 16 Aug 2002 09:15:38 -0700 X-mProtect: <200208161615> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdse1OOa; Fri, 16 Aug 2002 09:15:35 PDT Message-ID: <3D5D2528.D96227E8@iprg.nokia.com> Date: Fri, 16 Aug 2002 09:15:36 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Zill CC: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Brian, I haven't studied the multi-link subnet draft. But, in order to be responsive to your note before taking that time... Brian Zill wrote: > "DIID": > - Nodes need to create a link-local address > corresponding to every IID they use on a given > link (and perform DAD on it). > - Nodes don't need to perform DAD for non link-local > address. > - Multi-link subnet routers would have to defend > link-local addresses across links, which could be > considered confusing and nonsensical. It seems to me that, if you allow two nodes on the same subnet to share a link-local address, then you are really starting to eliminate the usefulness of link-local addressing. If I think about how a network protocol should work that would use link-local addresses, I do not want that protocol to know about the sub-network-layer structure of my network. It seems to me that up until recently there was always a (correct!) assumption that the addressability of a "link" was co-terminous with the addressability of the subnet using that link. In other words, the "link-local address" was equally well "subnet-local". Breaking this characteristic suddenly puts "link-local addresses" outside the scope of IP, since IP deals with putting together subnets, not structures with finer granularity. This idea of having multiple identical link-local addresses on the same subnet exposes IP to a level of structure granularity for which it is poorly equipped. In summary, I think that the sub-network definition of "link-local" address muddies the distinction between network-layer addressing and layer-2 addressing, which is a bad thing and to be avoided. I would say that multi-link routers have to defend link-local addresses across the network extent for which they were defined, which is a subnet. > "DAD": > - Nodes don't need to create otherwise unnecessary > link-local addresses corresponding to the IIDs they > use for temporary or public-key-derived addresses. > - Nodes need to perform DAD on all their addresses. > - No strange consequences for multi-link subnets. But I think the strange consequences are not at all strange, if one takes a layer-3 view of layer-3 addressing concept. Or, maybe there is a move to demote link-layer addresses to be sub-network concepts? And, please don't forget the negative impact on home agent operation. > As far as implementation complexity goes, it seems to me that "DAD" is > far simpler, since the rule is the same for all addresses and you don't > need to create extra addresses only used for doing DAD. But I have a rule which I think is better, for which DIID is far simpler. Rewording: As far as implementation complexity goes, it seems to me that "DIID" is far simpler, since the rule is the same for all addresses and you don't need to create extra protocol for coordinating all devices on a subnet. The rule is that link-local addresses are unique on a subnet. This disambiguates nodes on a subnet from the perspective of network-layer protocol, which is an appropriate function for a network-layer address. > Regarding efficiency, I think it depends upon whether a node has more > prefixes or IIDs. For nodes on a link with lots of prefixes, "DIID" > saves a little bandwidth by not having to do as much DAD. Or, in the case I was discussing, a LOT of bandwidth at an important time when responsiveness is important for the user experience, if we get to the point of utilizing IPv6 capabilities for many subnet prefixes. I'd like to keep that possibility open for the future. > For nodes > with lots of IIDs, "DAD" saves node resources related to configuring > twice as many addresses. Offhand, I'd be tempted to give the edge to > "DIID" here, but since I've seen various creative proposals for using > large numbers of IIDs per node, it's not clear. My machines generally > have more IIDs then prefixes. But I think the numbers have to get > pretty significant in either case before these concerns begin to matter. You are right. And, in fact, my understanding of IID is that each on gives another (real or virtual) _network interface_. Since multiple IIDs define multiple network interfaces, a remote node shouldn't be able to tell whether or not different IIDs belong to the "same" node. Nodes without a link-local address almost seem to not have a (real or virtual) network interface. That doesn't seem right to me. Maybe that is the flip side of an "unnumbered interface", a sort of "extraneously-numbered non-interface". > The multi-link subnet router issue is more clear. "DAD" is a better > architectural fit. Link-local addresses stay link-local and don't > become these quasi-subnet-local addresses that are unique across the > subnet but only reachable on-link. This would be wrong. A link-local address SHOULD be reachable over all parts of the subnet, and it would be the responsibility of the multi-link subnet router to make it happen. I don't think "DAD" is a better architectural fit to the IP model of subnet addressing, unless you are also willing to jettison the network-layer significance of what "link-local" address was supposed to mean. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 16 11:04:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GI4s3U022996; Fri, 16 Aug 2002 11:04:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7GI4sxe022995; Fri, 16 Aug 2002 11:04:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GI4m3U022988 for ; Fri, 16 Aug 2002 11:04:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02117 for ; Fri, 16 Aug 2002 11:04:57 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22114 for ; Fri, 16 Aug 2002 12:04:56 -0600 (MDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Date: Fri, 16 Aug 2002 11:04:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E285@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt Thread-Index: AcJEGPQwFdw/tA9VScqImwBOIEPSzABLw0gg From: "Michel Py" To: "Robert Elz" Cc: "Tim Hartrick" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7GI4m3U022989 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, > Name one operational annoyance? That is one that my use of > /112 (or someone else's use of /126 or /127) inflicts upon you, > assuming that you're not the other end of the link (if you are, > it is your choice to participate, no-one is compelling you to > use > /64). I will address this in a reply to jj later. > then it really starts to look as if the only reason for > not changing is stubbornness. About which you and I are renowned world-class contestants ;-) > Maybe I wasn't clear enough that the 'u' but is the worst > part of the draft. It (or the part of it which pretends > to be visible externally) is the thing which most needs > to be deleted. I don't just want it gone in order that the > 64 bit boundary can go, I want it gone because it is > unimplementable nonsense, which doesn't belong in the doc. I understand the point you are trying to make, but I fail to understand the urgency. Part of your procedural argument before was that the 'u' bit was not implemented and therefore should be deleted. I disagree with the phrasing; I would much rather say something like it is implemented but not used. Correct me if I'm wrong, but I think the point you are trying to make is "Let's remove this 'u' bit before someone finds a nasty/dirty use for it". Without a context, I would agree with you, but you can't ignore the bigger picture. Since you are one of the persons who understand the details of the mechanisms behind MHAP and the differences with GSE, I hope that you also understand clearly that there is currently nothing in what ipv6mh is doing that suggests this. That being said, the reason I don't see the urgency of removing the 'u' bit is that it seems to me that the only use that could be made of it would be a descendant of GSE. If that does not happen, removing the 'u' bit in three years would not be more difficult nor more work than it is today. OTOH, considering the less-than-perfect status of IPv6 multihoming today, if Mike O'Dell or one of his heirs comes with a breakthrough that addresses the documented shortcomings of GSE, the 'u' bit is likely to be re-instated even if we remove it now; that would likely bring a whole new set of issues. In other words, the pros and cons about removing the 'u' bit are: Pros: If we remove it, nobody will invent something nasty that uses it. Cons: If we remove it, nobody will invent something nice that uses it. IMHO, it is a lot easier to kill a nasty project than to remove roadblocks in the way of a nice one. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 16 15:27:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GMRa3U023606; Fri, 16 Aug 2002 15:27:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7GMRaIr023605; Fri, 16 Aug 2002 15:27:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GMRU3U023598 for ; Fri, 16 Aug 2002 15:27:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18035 for ; Fri, 16 Aug 2002 15:27:40 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26322 for ; Fri, 16 Aug 2002 16:27:38 -0600 (MDT) Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt"Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Date: Fri, 16 Aug 2002 15:27:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BCFFA@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt"Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Thread-Index: AcJEAX2fIAYolRmQQQO0NSzPRfQOWgBT+PjA From: "Michel Py" To: "Shannon -jj Behrens" , "Robert Elz" Cc: "Tim Hartrick" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7GMRU3U023599 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jj, > jj wrote: > 5) I want to have maximum freedom with my /64. > This is the most important argument, in my mind. I don't > think any benefit gained from establishing a 64-bit > boundary can possibly justify loosing the freedom of not > being confined to that boundary. You have to be careful using the word "freedom". In this case (prefixes length >64), freedom is not what you want. Freedom to subnet is what you want. There are many forms of freedom. - The freedom to subnet. - The freedom of privacy by having changing IP addresses, which requires a rather large number of bits in order to avoid both collisions and smart analysis software that identify small ranges. - The freedom to embed part of a public key in the IID. - And why not, the freedom to have an IID whose all odd bits are "1"'s, because it helps synchronizing the frames when running Ethernet over barb wire. All these pieces of freedom (purposes) need bits. There are two approaches to assign bits to a purpose: 1. Reserve some bits to one purpose and some other bits to another purpose. 2. Allow the same range of bits to be used by several purposes. Assuming that we are discussing unicast addresses, the current state of the spec is that bits 0-2 are "001", bits 3-63 are used for routing (subnetting) and bits 64-127 are used for the IID which includes other purposes such as the 'u' bit. What you are favorable to (if I understand correctly) would be to allow bits 64 to 127 (more likely, bits 64-111) to be used both for routing (subnetting) and for the IID and other purposes. 1. and 2. can be used simultaneously; the drawback of 1. is that it leads to bit depletion quickly, and the drawback of 2. is that it makes purposes that share a range of bits mutually exclusive. Back to what is being discussed or not: What is *not* being discussed is your freedom to knowingly violate the spec, by running your network over barb wire (which requires to change bits in the IID) or by subnetting above /64 (which requires changing bits in the IID). This is your very right as long as you understand what you are doing and even if you don't. What *is* being discussed is modifying the spec, so it allows you to legally run your network over barb wire (which requires to change bits in the IID) or to subnet above /64 (which requires changing bits in the IID). The point I will try to make next is why modifying the spec to allow subnetting above /64 is as irrelevant as modifying it to allow running your network over barb wire. Back to your main point: "I want to have maximum freedom with my /64." Since we are talking about subnetting, this becomes: "I want to have maximum freedom to subnet my /64." This is totally irrelevant. What everyone wants is: "I want to have maximum freedom to subnet my block." (The block that has been allocated or assigned to you). So, let's look at what you are allocated or assigned: A) You are a small LIR. If you are a small LIR, you are allocated a /32. Out of this /32, you allocate two /48s (or 1/32768th, or 0.003%) for /64 ptp links. That gives you 128K ptp links. What are these ptp links used for? For your infrastructure, and for customer links that have routed sites. The breakup of your address space is: 1x /48 for your corporate network (you are your own customer) 2x /48 for ptp links 14x /48 for misc purposes such as /64 dialup / ppp customers 65520x /48 that you assign to customer /48 sites. Freedom issues here? Not enough ptp links? Make it 8x /48s which gives you 512K ptp links, that's 0.012% of your address space. B) You are a large LIR. Same ratios as A applies. C) You are a small (read, less than 8K subnets) site. You are assigned a /48 by your LIR. Freedom problems connecting 3,000 branch offices with "only" 64K ptp links/subnets? Come on. And even if it was true, see E). Will everyone get a /48 if asking for it? Yes. A single v4 IP gives you a 6to4 /48. Freenet6 gives you a /48. Every LIR or pTLA gives you a /48. There are proposals such as Tony Hain's that give a /48 to every backyard-size lot on the planet. We are working on a scheme (see http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt ) that gives a /48 to each household out of a single /16. D) You are a large site. You are assigned a block relevant to your size, with a reasonable HD (0.80) that places you in the same situation as C. E) You did not get a block big enough? Talk to your RIR, this is a policy matter and not an addressing architecture matter. This would be Thomas' domain and I won't comment too much on it, what I hear though is that besides some kind of a policy void for NRENs, everyone gets the IPv6 address space they need, including enough to use /64s on ptp links. I have not been following closely the discussions regarding the HD concerning sites that request more than a /48, but again this is a policy matter and not an addressing architecture matter. Freedom to subnet is the topic. I don't have a freedom problem subnetting with the existing spec. I certainly would be ok with even more freedom, trouble is that modifying the spec to grant more subnetting freedom will one day or the other create an operational issue because the extra subnet bits used by this un-necessary subnetting freedom will collide with someone that wants more freedom to do something else with the IID bits. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 17 01:22:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7H8M83U024523; Sat, 17 Aug 2002 01:22:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7H8M7JP024522; Sat, 17 Aug 2002 01:22:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7H8Lv3U024512 for ; Sat, 17 Aug 2002 01:21:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11635 for ; Sat, 17 Aug 2002 01:22:07 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20222 for ; Sat, 17 Aug 2002 02:22:07 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7H8Lrt21033; Sat, 17 Aug 2002 17:21:53 +0900 (JST) Date: Sat, 17 Aug 2002 17:19:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: <4.3.2.7.2.20020802140116.02cb6270@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <4.3.2.7.2.20020802140116.02cb6270@mailhost.iprg.nokia.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 02 Aug 2002 15:16:11 -0700, >>>>> Bob Hinden said: >> we might have the following choices (I can't think of other combinations that >> make sense to me): >> 1. all are optional >> 2. load sharing is mandatory; others are optional >> 3. load sharing and router preferences are mandatory; more specific is >> optional >> 4. all are mandatory > The current proposal is to split the document and make load sharing > mandatory and router preferences and more specific routes optional. This > is choice 2. > As far as I can tell only one person has objected to this approach and has > suggested choice 3. (perhaps 4). > Are there any other objections to the current proposal? If the load sharing is mandated unconditionally, I think I would make an objection (I guess I'm not the "only one person"...). I believe we discussed this before and reached a consensus on this, so I won't repeat my points (for now). Perhaps the problem is in wording. My understanding of the MUST is "if a node implements (some parts of) the draft (which is optional), it MUST support the load-sharing algorithm". I don't see any contradiction here. However, I don't actually care about the 1 or 2 documents issue, as long as the fact that load-sharing applies to some limited (but reasonable) environments is clear. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 17 01:22:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7H8M23U024520; Sat, 17 Aug 2002 01:22:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7H8M2vC024519; Sat, 17 Aug 2002 01:22:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7H8Lr3U024505 for ; Sat, 17 Aug 2002 01:21:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09511 for ; Sat, 17 Aug 2002 01:22:03 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09650 for ; Sat, 17 Aug 2002 02:22:02 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7H8Lkt21030; Sat, 17 Aug 2002 17:21:47 +0900 (JST) Date: Sat, 17 Aug 2002 17:10:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: <200207251243.g6PChnU06633@cichlid.adsl.duke.edu> References: <200207251243.g6PChnU06633@cichlid.adsl.duke.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 82 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Since implementors' comments are required, I'll talk about a particular network stack; the one in BSDs.) >>>>> On Thu, 25 Jul 2002 08:43:49 -0400, >>>>> Thomas Narten said: >> 3.3. Destination Cache Management >> >> When host C processes a Router Advertisement and updates its >> conceptual Routing Table, it SHOULD invalidate or remove Destination >> Cache Entries and redo next-hop determination for destinations >> affected by the Routing Table changes. The host MAY implement this >> requirement by flushing its entire Destination Cache. > Seems like the above SHOULD should be a MUST, in order to meet the > principle of least astonishment. > However, the MAY seems ill-advised, as the Destination Cache may also > include other information (e.g., path MTU info?) that should not be > flushed as a side-effect of such a route change. Can the above be > implemented reasonably without resorting to just flushing the table > and rebuilding whenever a change is present? Based on my knowledge and experiences of BSD's routing architecture, this should be able to be implemented without much side effect in BSDs; we can prune a subtree, where destination caches exist, of the affected route entry in the tree-based routing table. > 4) I'm also unclear as to how easy it will be to implement the > specific lookup algorithm that type C hosts will implement. My > understandinng is that routing lookups today are done using > longest-match, where the lookup stops at a particular node in the > tree. I could imagine multiple nodes being at the same point in the > tree (i.e., corresponding to two or more instances of a prefix but > using different routers with possibly different preferences). > But the algorithm specified actually says reachable routers are to be > preferred over unreachable ones. This means that the longest-match > lookup may stop at a node with an unreachable router. What is done in > this case? Does one have to unwind the tree search to try a node > visited earlier (i.e., a shorter match?)? Is this reasonable for > implementations? [note: its not immediately clear that one can just > remove nodes from the routing tree that correspond to unreachable > routers, because one must also probe these routers in some cases.] > Another implementation complexity is due to the preferences combined > with the reachability status. Many implementations have a user-level > process which takes preferences into account and only installs the > most preferred route for a given prefix into the kernel. Hence the > kernel need not be aware of preferences. Given the reachability status > all routes need to be in the kernel since the most preferred for a > given prefix might be unreachable and a less preferred route might > exist for the identical prefix. > Q: who has implemented this draft? Can they comment on the > implementations issues mentioned above? The issue 4 would have very strong impact on BSD's routing architecture. It seems to me that will require a total revise of the architecture, and I don't think the BSD community accepts it just because of the merits described in the draft. Actually, we'd rather choose to run routing protocols than changing the basic routing architecture in the kernel. (I know the draft mentions the issue of routing protocols vs RAs, but the benefit of RAs is not convincing enough comparing to the complexity - at least to me.) Honestly, it seems to me that the "more specific routes" part of the draft is quite complicated, and I wonder how large the applicability is, particularly from implementor's point of view. For very poor environments, implementors would skip this part due to the complexity. For some rich/powerful stack, such as BSDs, implementors would rather run routing protocols as I said above. To be clear, I'm not making a strong objection to advance the draft just from the limited, personal thoughts. I've described my view on this as required, and I'm also interested how other implementors think of it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 17 04:08:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7HB8E3U024872; Sat, 17 Aug 2002 04:08:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7HB8DxT024871; Sat, 17 Aug 2002 04:08:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7HB883U024864 for ; Sat, 17 Aug 2002 04:08:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09930 for ; Sat, 17 Aug 2002 04:08:18 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08003 for ; Sat, 17 Aug 2002 04:08:17 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7HB7e127692; Sat, 17 Aug 2002 18:07:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7HB6uW17404; Sat, 17 Aug 2002 18:06:56 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: References: <4.3.2.7.2.20020802140116.02cb6270@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Aug 2002 18:06:56 +0700 Message-ID: <17402.1029582416@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 17 Aug 2002 17:19:19 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | If the load sharing is mandated unconditionally, I think I would make | an objection (I guess I'm not the "only one person"...). No, I think that meant me ... | I believe we | discussed this before and reached a consensus on this, so I won't | repeat my points (for now). I thought we had too, which is why the two docs had become one. | Perhaps the problem is in wording. My understanding of the MUST is | "if a node implements (some parts of) the draft (which is optional), | it MUST support the load-sharing algorithm". I don't see any | contradiction here. If that's the interpretation, then I also have no problems. However, that's not the impression that has been given (over and over again). The impression I keep getting is that load sharing is to be mandatory (in the sense of must be implemented). And there's no knob anywhere (other than perhaps visiting every node individually) to allow a net manager to disable it - or not without router prefs. Which is why I want router prefs to have no lesser status than load balancing. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 17 06:37:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7HDbo3U025034; Sat, 17 Aug 2002 06:37:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7HDbngx025033; Sat, 17 Aug 2002 06:37:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7HDbi3U025026 for ; Sat, 17 Aug 2002 06:37:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28523 for ; Sat, 17 Aug 2002 06:37:51 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04545 for ; Sat, 17 Aug 2002 06:37:51 -0700 (PDT) Received: from kenawang ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA09080; Sat, 17 Aug 2002 06:37:33 -0700 (PDT) Message-Id: <4.2.2.20020817091724.024e37e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 17 Aug 2002 09:38:22 -0400 To: "Brian Zill" From: Margaret Wasserman Subject: RE: DAD vs. DIID Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, Although I generally agree with your other thoughts on DIID vs. DAD, I don't understand these portions: >"DIID": > - Multi-link subnet routers would have to defend > link-local addresses across links, which could be > considered confusing and nonsensical. > >"DAD": > - No strange consequences for multi-link subnets. Why would performing DAD or DIID change the requirement for link-local address uniqueness across a subnet? And, even if it did, what does this really simplify, since site-local and global addresses will still have to be unique across a subnet? Since DAD neighbor advertisements are not sent to the target address, but are instead sent to the solicited-node multicast address derived from the target address, routers on multi-link subnets will already have to forward packets to the solicited-node multicast address between links of a multi-link subnet, so that site-local and global DAD will work. So, those routers would need to perform more complex processing, based on the target address within the NA, to _not_ forward link-local DAD packets across a multilink subnet. Am I misunderstanding something? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 18 11:42:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7IIgm3c027195; Sun, 18 Aug 2002 11:42:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7IIgm1H027194; Sun, 18 Aug 2002 11:42:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7IIgd3c027183 for ; Sun, 18 Aug 2002 11:42:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24343 for ; Sun, 18 Aug 2002 11:42:50 -0700 (PDT) Received: from basit.cc (wireless.cs.twsu.edu [156.26.10.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28172 for ; Sun, 18 Aug 2002 12:42:49 -0600 (MDT) Received: from localhost ([127.0.0.1]) by basit.cc with esmtp (Exim 4.05) id 17OxIk-0003Al-00 for ipng@sunroof.eng.sun.com; Mon, 01 Jul 2002 04:16:54 -0500 Date: Mon, 1 Jul 2002 04:16:54 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: ipng@sunroof.eng.sun.com Subject: ipv6 jumbograms Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I wonder what is the real use for jumbograms ? I read rfc2675, but it was not discussed there. Any tip ? -basit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 18 11:42:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7IIgl3c027192; Sun, 18 Aug 2002 11:42:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7IIgkdj027191; Sun, 18 Aug 2002 11:42:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7IIgc3c027177 for ; Sun, 18 Aug 2002 11:42:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14496 for ; Sun, 18 Aug 2002 11:42:49 -0700 (PDT) Received: from basit.cc (wireless.cs.twsu.edu [156.26.10.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28169 for ; Sun, 18 Aug 2002 12:42:48 -0600 (MDT) Received: from [127.0.0.1] (helo=localhost) by basit.cc with esmtp (Exim 4.10) id 17gUlB-00049w-00 for ipng@sunroof.eng.sun.com; Sun, 18 Aug 2002 13:26:45 -0500 Date: Sun, 18 Aug 2002 13:26:45 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: ipng@sunroof.eng.sun.com Subject: MPLS/IPv6 In-Reply-To: <4.2.2.20020817091724.024e37e0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Can anyone give me some pointers/urls on MPLS and IPv6 integeration (and or a possible comparasion of MPLS vs flowlabel?).. - basit Wichita state university MSCS student. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 18 19:03:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J23l3c027720; Sun, 18 Aug 2002 19:03:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J23k0U027719; Sun, 18 Aug 2002 19:03:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J23e3c027712 for ; Sun, 18 Aug 2002 19:03:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07378 for ; Sun, 18 Aug 2002 19:03:51 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17157 for ; Sun, 18 Aug 2002 19:03:50 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EEE864B22 for ; Mon, 19 Aug 2002 11:03:45 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: need clarification of "deprecated" address X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Mon, 19 Aug 2002 11:03:45 +0900 Message-Id: <20020819020346.EEE864B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we need some clarification to RFC246[12] with respect to "deprecated" address handling. first of all, definition/description of deprecated address is given in multiple places in RFC2462, namely page 3 (introduction) page 6 (terminology) page 8 (site renumbering) page 19 (address lifetime expiry) they have slightly different description with respect to deprecated address handling. second, the document does not give any guidance when TCP SYN is sent to deprecated address. take, for instance, here's the definition from page 19: > A preferred address becomes deprecated when its preferred lifetime > expires. A deprecated address SHOULD continue to be used as a source > address in existing communications, but SHOULD NOT be used in new > communications if an alternate (non-deprecated) address is available > and has sufficient scope. IP and higher layers (e.g., TCP, UDP) MUST > continue to accept datagrams destined to a deprecated address since a > deprecated address is still a valid address for the interface. An > implementation MAY prevent any new communication from using a > deprecated address, but system management MUST have the ability to > disable such a facility, and the facility MUST be disabled by > default. with TCP SYN sent from outside, it is not an existing communication. however, we have no choice on picking other addresses (since TCP requires us to swap the src/dst address). our recommendation is to explicitly state that deprecated address SHOULD NOT be used for new connection attempt (with no "if an alternate..." clause). in KAME implementation we had a configuration knob to control the behavior: if the knob is 1, we accept TCP SYN towards deprecated addresss. if 0, we send TCP RST with deprecated address as a source (since it gives a better feedback to sender than to simply drop TCP SYN attempt). recently it was found that knob = 1 is not a good idea as we have protocols that use multiple TCP sessions - for instance, suppose you are ftp server and TCP control connection attempt is sent to deprecated address. with knob = 1 we accept it. then when we are to make active TCP data connetion with EPRT (IPv6 PORT), we can't make it as we are forbidden to make TCP connection with deprecated IPv6 address as the source. itojun --- tcp_input.c /* * If deprecated address is forbidden, * we do not accept SYN to deprecated interface * address to prevent any new inbound connection from * getting established. * When we do not accept SYN, we send a TCP RST, * with deprecated source address (instead of dropping * it). We compromise it as it is much better for peer * to send a RST, and RST will be the final packet * for the exchange. * * If we do not forbid deprecated addresses, we accept * the SYN packet. RFC2462 does not suggest dropping * SYN in this case. * If we decipher RFC2462 5.5.4, it says like this: * 1. use of deprecated addr with existing * communication is okay - "SHOULD continue to be * used" * 2. use of it with new communication: * (2a) "SHOULD NOT be used if alternate address * with sufficient scope is available" * (2b) nothing mentioned otherwise. * Here we fall into (2b) case as we have no choice in * our source address selection - we must obey the peer. * * The wording in RFC2462 is confusing, and there are * multiple description text for deprecated address * handling - worse, they are not exactly the same. * I believe 5.5.4 is the best one, so we follow 5.5.4. */ if (!ip6_use_deprecated) { if ((ia6 = ip6_getdstifaddr(m)) && (ia6->ia6_flags & IN6_IFF_DEPRECATED)) { t6p = NULL; goto dropwithreset; } } -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 01:40:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J8ef3c028564; Mon, 19 Aug 2002 01:40:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J8ef73028563; Mon, 19 Aug 2002 01:40:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J8eZ3c028556 for ; Mon, 19 Aug 2002 01:40:36 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g7J8eeA15426; Mon, 19 Aug 2002 10:40:40 +0200 (MEST) Date: Mon, 19 Aug 2002 10:38:33 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 MTU for tunnel pseudo interfaces To: Margaret Wasserman Cc: Erik Nordmark , itojun@iijlab.net, Pekka Savola , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4.2.2.20020810085310.02248b10@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There are many implementations that don't have the ability to > reassemble a 65,353 byte packet, at least not without allocating > a 64K buffer for this purpose. So, this seems to be a harsh > restriction to place on RFC 2893 implementations. > > If we need to choose one or the other, I'd prefer limiting the > MTU of these tunnels to 1280. I think the right solution is to strongly recommend path MTU discovery across the tunnel which would have the effect of only using IPv4 fragmentation when the IPv4 path MTU is so small that a 1280 byte IPv6 packet can't be carried without fragmentation. But at least Itojun seems to think that doing path MTU discovery for the tunnel case isn't worth while, and I definitely need to better understand his point. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 02:28:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9SP3c028888; Mon, 19 Aug 2002 02:28:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J9SPDW028887; Mon, 19 Aug 2002 02:28:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9SK3c028880 for ; Mon, 19 Aug 2002 02:28:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21163 for ; Mon, 19 Aug 2002 02:28:30 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13875 for ; Mon, 19 Aug 2002 03:28:26 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7J9RG117493; Mon, 19 Aug 2002 16:27:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7J9QOW24670; Mon, 19 Aug 2002 16:26:24 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819020346.EEE864B22@coconut.itojun.org> References: <20020819020346.EEE864B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 16:26:24 +0700 Message-ID: <24668.1029749184@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 11:03:45 +0900 From: itojun@iijlab.net Message-ID: <20020819020346.EEE864B22@coconut.itojun.org> | second, the document does not give any guidance when TCP SYN is sent to | deprecated address. take, for instance, here's the definition from | page 19: | | with TCP SYN sent from outside, it is not an existing communication. | however, we have no choice on picking other addresses (since TCP | requires us to swap the src/dst address). I think this is actually OK. When the SYN arrives, it must be accepted, as you quoted ... IP and higher layers (e.g., TCP, UDP) MUST continue to accept datagrams destined to a deprecated address After that, TCP processes the incoming connection. That makes existing communications. Then, when replying, the SYN+ACK can be sent from the address to which it was sent (deprecated or not). So, I doubt there's actually a problem there. | our recommendation is to explicitly state that deprecated address | SHOULD NOT be used for new connection attempt (with no "if an | alternate..." clause). That's a different issue. The alternate clause is to handle the situation where only deprecated addresses exist, and a node wants to initiate new communications. Are you really recommending that a node which has only deprecated addresses is unable to iniatiate a connection? That is, it is prohibited from sending an SNMP trap (or anything like it) to inform a management station that all its addresses are deprecated (as prohibited as SHOULD NOT would make it anyway). | in KAME implementation we had a configuration knob to control | the behavior: if the knob is 1, we accept TCP SYN towards deprecated | addresss. if 0, we send TCP RST with deprecated address as a source | (since it gives a better feedback to sender than to simply drop TCP | SYN attempt). I'm not sure the knob is needed, just "1" is the setting I'd expect, always. If your DNS update hasn't filtered around the world yet, you have to expect incoming packets to deprecated addresses. | recently it was found that knob = 1 is not a good idea as we have | protocols that use multiple TCP sessions - for instance, suppose you | are ftp server and TCP control connection attempt is sent to deprecated | address. with knob = 1 we accept it. then when we are to make active | TCP data connetion with EPRT (IPv6 PORT), we can't make it as we are | forbidden to make TCP connection with deprecated IPv6 address as the | source. I think that's another example of existing communications. The rule doesn't say "existing connection". Whenever what you're doing requires use of the deprecated address, you use it. That is, if an application bind()'s to a deprecated address, the stack should simply use that. You assume the application knows what it is doing, and don't attempt to second guess. The rule against using deprecated addresses, as I understand it, is just that when there's no reason to choose one over the other, or no other reason, always use the preferred address. If there's a reason to use the deprecated address (like things will break if we don't) then use it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 02:44:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9iC3c029090; Mon, 19 Aug 2002 02:44:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J9iCdo029089; Mon, 19 Aug 2002 02:44:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9i53c029082 for ; Mon, 19 Aug 2002 02:44:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23624 for ; Mon, 19 Aug 2002 02:44:15 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27364 for ; Mon, 19 Aug 2002 03:44:14 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 64E2C4B22; Mon, 19 Aug 2002 18:44:08 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 19 Aug 2002 16:26:24 +0700. <24668.1029749184@munnari.OZ.AU> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Mon, 19 Aug 2002 18:44:08 +0900 Message-Id: <20020819094408.64E2C4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I think this is actually OK. When the SYN arrives, it must be >accepted, as you quoted ... > IP and higher layers (e.g., TCP, UDP) MUST > continue to accept datagrams destined to a deprecated address i think the sentence lacks "for existing connection" at the end. >After that, TCP processes the incoming connection. That makes existing >communications. Then, when replying, the SYN+ACK can be sent from the >address to which it was sent (deprecated or not). So, I doubt there's >actually a problem there. TCP SYN is definitely an indication of a new connection. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 02:53:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9rE3c029142; Mon, 19 Aug 2002 02:53:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J9rEcB029141; Mon, 19 Aug 2002 02:53:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9r93c029134 for ; Mon, 19 Aug 2002 02:53:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24929 for ; Mon, 19 Aug 2002 02:53:20 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29815 for ; Mon, 19 Aug 2002 02:53:18 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 60FF76A906; Mon, 19 Aug 2002 12:53:17 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5ACB86A904; Mon, 19 Aug 2002 12:53:13 +0300 (EEST) Message-ID: <3D60C12B.1070304@kolumbus.fi> Date: Mon, 19 Aug 2002 12:58:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itojun@iijlab.net Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address References: <20020819094408.64E2C4B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: >>I think this is actually OK. When the SYN arrives, it must be >>accepted, as you quoted ... >> IP and higher layers (e.g., TCP, UDP) MUST >> continue to accept datagrams destined to a deprecated address > > > i think the sentence lacks "for existing connection" at the end. Maybe not. I think the intention was for *our* node to not initiate new connections using the deprecated address, not prevent other nodes from doing so. We could make it stricter of course, by not accepting even others to initiate new connections. However, I believe this might be bad for some protocols. Say, you are doing an FTP mget * from node X, which decides to get a new RFC 3041 address in the middle of things. If I remember correctly, FTP uses a new TCP session for each new file. Your FTP session would not proceed if you refused to accept a new TCP session. >>After that, TCP processes the incoming connection. That makes existing >>communications. Then, when replying, the SYN+ACK can be sent from the >>address to which it was sent (deprecated or not). So, I doubt there's >>actually a problem there. > > > TCP SYN is definitely an indication of a new connection. Yes, but from the other end... Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 02:56:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9up3c029177; Mon, 19 Aug 2002 02:56:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J9upZ9029176; Mon, 19 Aug 2002 02:56:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9ui3c029169 for ; Mon, 19 Aug 2002 02:56:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08705 for ; Mon, 19 Aug 2002 02:56:55 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17422 for ; Mon, 19 Aug 2002 03:56:54 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5DD064B24; Mon, 19 Aug 2002 18:56:48 +0900 (JST) To: Jari Arkko Cc: ipng@sunroof.eng.sun.com In-reply-to: jari.arkko's message of Mon, 19 Aug 2002 12:58:03 +0300. <3D60C12B.1070304@kolumbus.fi> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Mon, 19 Aug 2002 18:56:48 +0900 Message-Id: <20020819095648.5DD064B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >We could make it stricter of course, by not accepting even others >to initiate new connections. However, I believe this might be bad for >some protocols. Say, you are doing an FTP mget * from node X, which decides >to get a new RFC 3041 address in the middle of things. If I remember >correctly, FTP uses a new TCP session for each new file. Your FTP >session would not proceed if you refused to accept a new TCP session. these days FTP client/server implementations are picky about endpoint address, and we need to use the same address pair for control and data connection (to avoid FTP bounce attack). therefore, FTP client side shouldn't use temporary address for the control connection. (apparently, server side shouldn't) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 02:58:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9wI3c029207; Mon, 19 Aug 2002 02:58:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J9wHCU029206; Mon, 19 Aug 2002 02:58:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9wA3c029195 for ; Mon, 19 Aug 2002 02:58:11 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g7J9wIA24294; Mon, 19 Aug 2002 11:58:18 +0200 (MEST) Date: Mon, 19 Aug 2002 11:30:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 MTU for tunnel pseudo interfaces To: itojun@iijlab.net Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020816110602.32AB74B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >If this tradeoff comes up with PMTUD makes sense when there is no > >tunneling, then I don't see why the same conclusion doesn't hold > >for the case of nested PMTUD using tunnels. > >So I'm looking forward to your performance analysis. > > i think i have answered this (partially) in other emails. > we are from very different assumption. I'm still looking for the answer. What I'm trying to understand is why the "fragmentation considered harmful" arguments (see http://research.compaq.com/wrl/techreports/abstracts/87.3.html) don't apply to the tunnel. > then what is the IPv6 link MTU for tunnel interface, when you don't > have IPv4 PMTU information? (like for the very first packet to go out > from the path) You always have IPv4 PMTU information - if there isn't information from ICMP "too big" messages, then there is the interface MTU for the outgoing IPv4 interface to bootstrap the process. This is robust since the IPv4 path MTU can never exceed this interface MTU. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 03:27:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JARN3c029322; Mon, 19 Aug 2002 03:27:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JARNa2029321; Mon, 19 Aug 2002 03:27:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JARH3c029314 for ; Mon, 19 Aug 2002 03:27:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14462 for ; Mon, 19 Aug 2002 03:27:27 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29124 for ; Mon, 19 Aug 2002 04:27:23 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JAQf102272; Mon, 19 Aug 2002 17:26:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JAMBW25113; Mon, 19 Aug 2002 17:22:11 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819094408.64E2C4B22@coconut.itojun.org> References: <20020819094408.64E2C4B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 17:22:10 +0700 Message-ID: <25111.1029752530@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 18:44:08 +0900 From: itojun@iijlab.net Message-ID: <20020819094408.64E2C4B22@coconut.itojun.org> | i think the sentence lacks "for existing connection" at the end. You're right, it does lack that. But that is not an accident, it isn't intended to have that qualification. | TCP SYN is definitely an indication of a new connection. Yes, but that isn't relevant. I think you're being too strict on what deprecated addresses should be used for, and what they shouldn't. A deprecated address is still a valid address, and can be used for anything at all. However, they're addresses that the intent is to stop using sometime soon, and if we don't want to break connections when the address becomes invalid, we should try to avoid using them when possible. But that doesn't mean that we break/refuse existing communications earlier than we need to to achieve that. If I have an address, A1, which is goingto change to A2, what I do is make A1 deprecated, and A2 preferred, and at (more or less) the same time I start announcing via the DNS the A2 address instead of the A1 address. Remote nodes will take something between hours, and days, depending on DNS TTLs to detect the change from A1 to A2 - in the interim period the only address they have is A1, that's the only one they can use. If I refuse incoming connections to my (deprecated) A1 address during this period, those remote nodes have no way to contact me. If I didn't deprecate the old address, then I'd have two preferred addresses, and connections started at my node would be just as likely to use A1 as A2, and that isn't what I want - since the address is changing, everything should use A2 in preference to A1, when that is possible. So, what I do is use A2 (the preferred address) when there's no reason to care which address is used, but I allow A1 anywhere there's a reason to prefer it (remote node has selected it, or it is in some way related to an ongoing conversation - not connection - that us using A1, like the series of connections used during FTP). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 03:29:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAT93c029342; Mon, 19 Aug 2002 03:29:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JAT9ac029341; Mon, 19 Aug 2002 03:29:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAT43c029334 for ; Mon, 19 Aug 2002 03:29:04 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13586 for ; Mon, 19 Aug 2002 03:29:14 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25790 for ; Mon, 19 Aug 2002 03:27:42 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JAQe102269; Mon, 19 Aug 2002 17:26:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JAP9W25123; Mon, 19 Aug 2002 17:25:09 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819095648.5DD064B24@coconut.itojun.org> References: <20020819095648.5DD064B24@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 17:25:09 +0700 Message-ID: <25121.1029752709@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 18:56:48 +0900 From: itojun@iijlab.net Message-ID: <20020819095648.5DD064B24@coconut.itojun.org> | these days FTP client/server implementations are picky about endpoint | address, and we need to use the same address pair for control and | data connection (to avoid FTP bounce attack). Yes, fine. (Personally I still like 3 way FTP but that's not important here). | therefore, FTP client | side shouldn't use temporary address for the control connection. No, temporary address is fine there, unless the overall FTP session will last longer than a week (the valid lifetime of a temporary address using the suggested timers) | (apparently, server side shouldn't) Yes, that one is kind of obvious - temporary addresses are for a form of identity hiding, it makes no sense to hide the identity of a server. But this isn't because of deprecated address rules, just common sense. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 03:30:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAUP3c029374; Mon, 19 Aug 2002 03:30:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JAUO8d029373; Mon, 19 Aug 2002 03:30:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAUH3c029366 for ; Mon, 19 Aug 2002 03:30:17 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15069 for ; Mon, 19 Aug 2002 03:30:27 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16518 for ; Mon, 19 Aug 2002 03:30:26 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 909084B22; Mon, 19 Aug 2002 19:30:21 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 19 Aug 2002 17:22:10 +0700. <25111.1029752530@munnari.OZ.AU> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Mon, 19 Aug 2002 19:30:21 +0900 Message-Id: <20020819103021.909084B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i guess you are confused. >But that doesn't mean that we break/refuse existing communications >earlier than we need to to achieve that. i have never said we should terminate existing connections. i suggested we should refuse new incoming connections (TCP SYN). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 03:32:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAWa3c029418; Mon, 19 Aug 2002 03:32:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JAWaow029417; Mon, 19 Aug 2002 03:32:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAWU3c029407 for ; Mon, 19 Aug 2002 03:32:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15589 for ; Mon, 19 Aug 2002 03:32:39 -0700 (PDT) Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27776 for ; Mon, 19 Aug 2002 03:32:39 -0700 (PDT) Received: from repligate ([67.36.189.68]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020819103238.STRX17521.mail1-0.chcgil.ameritech.net@repligate> for ; Mon, 19 Aug 2002 05:32:38 -0500 Message-ID: <0bcc01c2476b$c34cfab0$8c56fea9@repligate> From: "Jim Fleming" To: Subject: Fw: New draft of NIR criteria document Date: Mon, 19 Aug 2002 05:32:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Jim Fleming" To: "Geoff Huston" ; Cc: "Richard J. Sexton" ; ; ; ; ; "Joanna Lane" ; "Joe Baptista" ; "Joop Teernstra" ; ; "Richard Henderson" Sent: Monday, August 19, 2002 5:22 AM Subject: Re: New draft of NIR criteria document > With most of the allocations going to China, Korea and Japan, why would > it be a "consensus", or desirable, to base the allocator (APNIC) in Australia ? > > Also, why would a task, such as address allocation, which can be highly automated and > results in a database which can be accessed online, require so many people (33) to operate ? > > Lastly, why would people pay for 128-bit addresses, when they can get them free ? > > Jim Fleming > 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... > http://www.ican.org/what's_new!!!.htm > http://www.iana.org/assignments/ipv4-address-space > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > 4:17 CN (CHINA) > 4:43 KR (KOREA,-REPUBLIC-OF) > 4:116 JP (JAPAN) > > ----- Original Message ----- > From: "Geoff Huston" > To: > Sent: Monday, August 19, 2002 1:23 AM > Subject: RE: New draft of NIR criteria document > > > > Kosuke Ito requested some information from the APNIC Director General on > > > > "Could you clarify more about your intention why you emphasize to give ISPs > > the freedom to choose NIR or APNIC to receive the resources as in Sec. 2.5? " > > > > I would like to respond to this request, and in so doing also note that the > > NIR policy document, and indeed all APNIC policy documents are an outcome > > of peer review and the formulation of peer consensus within ourselves as a > > group - its not a case of constantly bouncing a question and answer ball > > between each APNIC Interest Group and the Director General, but instead it > > is a case of attempting to work within ourselves together to understand > > what the best answers may be. So oin that basis I'll offer my perspectives > > on a response to this question. > > > > So here's my take on NIRs and APNIC: the definition of the role of National > > Internet Registries within APNIC is an outcome of a number of issues > > concerning the diversity of national positions with respect to the > > administration of Internet Numbering Resources and, more broadly, Internet > > Service Provider regulatory frameworks across the Asia Pacific region. NIRs > > reflect the desire of some national domains to support a local > > administrative function which operates within the framework of a national > > language, national character set and a local timezone. On the other hand, > > in some environments a national framework appears to offer no particular > > benefit, and in such environments direct access to APNIC services is a > > rational and sound outcome. > > > > This might lead to the view that some countries have NIRS as an exclusive > > numbering resource administrator and some national regimes do not, but even > > that is not sufficient for our region. Within some national environments > > there is a significant level of diversity, where some local entities, and > > some multi-national entities are comfortable in dealing with APNIC > > directly, and prefer to so do, while other local entities see value in > > having a locally operated administrative function. > > > > So, as far as I can tell, there is no intent in this NIR proposal to > > substitute competition and free trade for due and proper administrative > > control over the Internet Numbering resource. There is, however, the intent > > to offer levels of choice to each entity that requires numbering resources > > that accommodates the diversity of national regimes and the diversity of > > the profile of entities and their preferences. > > > > > > kind regards, > > > > Geoff Huston > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 03:46:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAk13c029557; Mon, 19 Aug 2002 03:46:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JAk0IX029556; Mon, 19 Aug 2002 03:46:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAjs3c029549 for ; Mon, 19 Aug 2002 03:45:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01900 for ; Mon, 19 Aug 2002 03:45:58 -0700 (PDT) Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24693 for ; Mon, 19 Aug 2002 03:45:58 -0700 (PDT) Received: from repligate ([67.36.189.68]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020819104557.SXJW17521.mail1-0.chcgil.ameritech.net@repligate>; Mon, 19 Aug 2002 05:45:57 -0500 Message-ID: <0bdc01c2476d$9f8c13c0$8c56fea9@repligate> From: "Jim Fleming" To: "Robert Elz" , Cc: "Richard J. Sexton" , , , , , "Joanna Lane" , "Joe Baptista" , "Joop Teernstra" , , "Richard Henderson" , , , , , , , , , , , , , , , , References: <20020819094408.64E2C4B22@coconut.itojun.org> <25111.1029752530@munnari.OZ.AU> Subject: Re: need clarification of "deprecated" address Date: Mon, 19 Aug 2002 05:46:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Robert Elz" > > If I didn't deprecate the old address, then I'd have two preferred addresses, > and connections started at my node would be just as likely to use A1 as A2, > and that isn't what I want - since the address is changing, everything > should use A2 in preference to A1, when that is possible. > This is a rather narrow-minded view, that makes many assumptions, which do not necessarily hold, especially with 128-bit DNS and addresses. As an example, if the addresses contain **version** information and/or **time-stamps** the end-to-end agreement can be that one version of the software will use the addresses that match it until some time is reached and they roll over to the next version. With the "toy" Internet (i.e. 32-bit) addresses, there was not a lot of room to store extra information. As an example, software can look at 2002 addresses and prefer those over 2001 addresses. Next year, the software may prefer 2003, and deprecate 2001 and 2002. Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.ican.org/what's_new!!!.htm http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 03:58:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAwH3c029600; Mon, 19 Aug 2002 03:58:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JAwGCF029599; Mon, 19 Aug 2002 03:58:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JAwB3c029592 for ; Mon, 19 Aug 2002 03:58:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA03829 for ; Mon, 19 Aug 2002 03:58:21 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA17035 for ; Mon, 19 Aug 2002 04:58:20 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7JAvqw08152; Mon, 19 Aug 2002 13:57:52 +0300 Date: Mon, 19 Aug 2002 13:57:52 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Robert Elz , Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819103021.909084B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 19 Aug 2002 itojun@iijlab.net wrote: > i guess you are confused. > > >But that doesn't mean that we break/refuse existing communications > >earlier than we need to to achieve that. > > i have never said we should terminate existing connections. i suggested > we should refuse new incoming connections (TCP SYN). Note: 'communications' not 'connections'; the wording was deliberate, I think. The point (as I saw it) was that if you want to deprecate an address, you must first kill all references to that address. If incoming connection request comes in, probably either: 1) the initiator has learned the address via some means (e.g. long-running application) some time ago before the address became deprecated 2) the deprecated address is still referenced somewhere (e.g. DNS) Sending RST might be ok for a purpose "ok, I'll reset this request gracefully [compared to TCP timeout], round-robin or try some other address", but for some others like "even though you don't know my other address, I'll send a reset anyway" it may disrupt communications between the two nodes. We don't know the reasen the initiator wants to establish the connection, so we probably should play safe and allow it. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:04:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JB4U3c029634; Mon, 19 Aug 2002 04:04:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JB4UrY029633; Mon, 19 Aug 2002 04:04:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JB4O3c029626 for ; Mon, 19 Aug 2002 04:04:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21511 for ; Mon, 19 Aug 2002 04:04:34 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12809 for ; Mon, 19 Aug 2002 04:04:27 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JB3j104211; Mon, 19 Aug 2002 18:03:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JAwaW25245; Mon, 19 Aug 2002 17:58:36 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819103021.909084B22@coconut.itojun.org> References: <20020819103021.909084B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 17:58:36 +0700 Message-ID: <25243.1029754716@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 19:30:21 +0900 From: itojun@iijlab.net Message-ID: <20020819103021.909084B22@coconut.itojun.org> | i have never said we should terminate existing connections. No, I know you didn't. | i suggested we should refuse new incoming connections (TCP SYN). Yes, that is what I am arguing against. The line of reasoning seems to be if we accept a connection to a deprecated address, we may have to open a connection from a deprecated address later. we're not allowed to open a connection from a deprecated address hence we should not accept connections to deprecated addresses That's wrong because the middle point is wrong, you are allowed to open a connection from a deprecated address. You're just not supposed to do that unless there is a reason (existing communications). Note "communications" != "connection". But even if it weren't for that point, you'd just be shifting the finish line in a race condition. That is, if we accept a connection to a non-deprecated address, and that address is later deprecated (which any might be) we may have to open a connection from that address even later we're not allowed to open a connection from a deprecated address hence we should not accept connections to non-deprecated addresses and that's absurd. That is, even if we weren't allowed to open a new connection from a deprecated address (which we are, but ignoring that), that's no reason not to accept incoming connections to deprecated addresses, or to addresses that might become deprecated before the new connection has finished. Just treat a deprecated address identically to any other address, except don't choose it as the source address if there's some reasonable alternative. Or, if you like, just follow the rules in the address selection draft, and aside from that, ignore "deprecated" as it applies to addresses. kre ps: I seem to recall that all this was discussed back when deprecated addresses were invented. pps: that we're having this discussion does suggest that you're correct and the docs need clarification. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:08:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JB8V3c029663; Mon, 19 Aug 2002 04:08:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JB8VBD029662; Mon, 19 Aug 2002 04:08:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JB8O3c029655 for ; Mon, 19 Aug 2002 04:08:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18992 for ; Mon, 19 Aug 2002 04:08:34 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29289 for ; Mon, 19 Aug 2002 05:08:33 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4CD204B22; Mon, 19 Aug 2002 20:08:28 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 19 Aug 2002 17:58:36 +0700. <25243.1029754716@munnari.OZ.AU> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Mon, 19 Aug 2002 20:08:28 +0900 Message-Id: <20020819110828.4CD204B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >No, I know you didn't. > | i suggested we should refuse new incoming connections (TCP SYN). >Yes, that is what I am arguing against. >The line of reasoning seems to be > if we accept a connection to a deprecated address, we may > have to open a connection from a deprecated address later. > > we're not allowed to open a connection from a deprecated address > > hence we should not accept connections to deprecated addresses FTP story was just an example. independent from the FTP story, i am - pointing out that the current text does not give any guidance to incoming TCP SYN case, and - we should drop incoming TCP SYN to deprecated addresses. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:14:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBEA3c029698; Mon, 19 Aug 2002 04:14:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBEAR9029697; Mon, 19 Aug 2002 04:14:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBE43c029690 for ; Mon, 19 Aug 2002 04:14:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19699 for ; Mon, 19 Aug 2002 04:14:14 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA23124 for ; Mon, 19 Aug 2002 05:14:07 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JBDS104574; Mon, 19 Aug 2002 18:13:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JBDKW25352; Mon, 19 Aug 2002 18:13:20 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819110828.4CD204B22@coconut.itojun.org> References: <20020819110828.4CD204B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 18:13:20 +0700 Message-ID: <25350.1029755600@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 20:08:28 +0900 From: itojun@iijlab.net Message-ID: <20020819110828.4CD204B22@coconut.itojun.org> | - pointing out that the current text does not give any guidance | to incoming TCP SYN case, and I am not disputing that come clarifications might be needed to the text, just | - we should drop incoming TCP SYN to deprecated addresses. isn't the clarification that should be made, it should be the exact opposite of that. We should accept TCP SYN to deprecated addresses, for the reasons that Pekka just gave much more clearly than I have been able. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:18:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBII3c029740; Mon, 19 Aug 2002 04:18:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBII35029739; Mon, 19 Aug 2002 04:18:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBIA3c029732 for ; Mon, 19 Aug 2002 04:18:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20407 for ; Mon, 19 Aug 2002 04:18:21 -0700 (PDT) Received: from nebula.sm.sony.co.jp (widefw.sm.sony.co.jp [133.138.0.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22957 for ; Mon, 19 Aug 2002 05:18:20 -0600 (MDT) Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id g7JBIH219776; Mon, 19 Aug 2002 20:18:17 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.11.6/8.11.3) id g7JBHjQ01864; Mon, 19 Aug 2002 20:17:45 +0900 (JST) Date: Mon, 19 Aug 2002 20:17:45 +0900 (JST) From: Atsushi Onoe Message-Id: <200208191117.g7JBHjQ01864@nest.sm.sony.co.jp> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: Your message of "Mon, 19 Aug 2002 11:03:45 +0900" <20020819020346.EEE864B22@coconut.itojun.org> References: <20020819020346.EEE864B22@coconut.itojun.org> X-Mailer: Cue version 0.6 (020808-1118/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > recently it was found that knob = 1 is not a good idea as we have > protocols that use multiple TCP sessions - for instance, suppose you > are ftp server and TCP control connection attempt is sent to deprecated > address. with knob = 1 we accept it. then when we are to make active > TCP data connetion with EPRT (IPv6 PORT), we can't make it as we are > forbidden to make TCP connection with deprecated IPv6 address as the > source. Note that we are NOT forbidden, but just required valid reasons to do so (from the definition of 'SHOULD NOT' of RFC 2119). In your ftp scenario, you can (or should) use deprecated address to avoid service disruption. page 2 in RFC 2462: | when possible. A deprecated address should be used only by | applications that have been using it and would have difficulty | switching to another address without a service disruption. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:18:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBIb3c029757; Mon, 19 Aug 2002 04:18:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBIbTs029756; Mon, 19 Aug 2002 04:18:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBIP3c029742 for ; Mon, 19 Aug 2002 04:18:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06166 for ; Mon, 19 Aug 2002 04:18:35 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08063 for ; Mon, 19 Aug 2002 05:18:34 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 603C74B24; Mon, 19 Aug 2002 20:18:29 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 19 Aug 2002 18:13:20 +0700. <25350.1029755600@munnari.OZ.AU> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Mon, 19 Aug 2002 20:18:29 +0900 Message-Id: <20020819111829.603C74B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | - pointing out that the current text does not give any guidance > | to incoming TCP SYN case, and > >I am not disputing that come clarifications might be needed to the text, >just > > | - we should drop incoming TCP SYN to deprecated addresses. > >isn't the clarification that should be made, it should be the >exact opposite of that. We should accept TCP SYN to deprecated >addresses, for the reasons that Pekka just gave much more clearly than >I have been able. even if you don't advertise your address to public via DNS, people will try to connect (people can portscan, ping6 ff02::1, whatever). i don't agree with Pekka's take. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:23:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBNo3c029882; Mon, 19 Aug 2002 04:23:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBNn9B029881; Mon, 19 Aug 2002 04:23:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBNh3c029874 for ; Mon, 19 Aug 2002 04:23:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21283 for ; Mon, 19 Aug 2002 04:23:53 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10160 for ; Mon, 19 Aug 2002 05:23:52 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6BD6F4B22; Mon, 19 Aug 2002 20:23:46 +0900 (JST) To: Atsushi Onoe Cc: ipng@sunroof.eng.sun.com In-reply-to: onoe's message of Mon, 19 Aug 2002 20:17:45 +0900. <200208191117.g7JBHjQ01864@nest.sm.sony.co.jp> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Mon, 19 Aug 2002 20:23:46 +0900 Message-Id: <20020819112346.6BD6F4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> recently it was found that knob = 1 is not a good idea as we have >> protocols that use multiple TCP sessions - for instance, suppose you >> are ftp server and TCP control connection attempt is sent to deprecated >> address. with knob = 1 we accept it. then when we are to make active >> TCP data connetion with EPRT (IPv6 PORT), we can't make it as we are >> forbidden to make TCP connection with deprecated IPv6 address as the >> source. > >Note that we are NOT forbidden, but just required valid reasons to do so >(from the definition of 'SHOULD NOT' of RFC 2119). In your ftp scenario, >you can (or should) use deprecated address to avoid service disruption. > >page 2 in RFC 2462: >| when possible. A deprecated address should be used only by >| applications that have been using it and would have difficulty >| switching to another address without a service disruption. this may be an implementation issue, but who should decide it? in KAME case we have kernel code which forbids the use of deprecated address as a source (bind(2)) and FTP daemon cannot override it for data connecdtion. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:29:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBTl3c029912; Mon, 19 Aug 2002 04:29:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBTkPD029911; Mon, 19 Aug 2002 04:29:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBTf3c029904 for ; Mon, 19 Aug 2002 04:29:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07604 for ; Mon, 19 Aug 2002 04:29:51 -0700 (PDT) Received: from nebula.sm.sony.co.jp (widefw.sm.sony.co.jp [133.138.0.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27185 for ; Mon, 19 Aug 2002 05:29:50 -0600 (MDT) Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id g7JBTfB19899; Mon, 19 Aug 2002 20:29:41 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.11.6/8.11.3) id g7JBT8i01893; Mon, 19 Aug 2002 20:29:08 +0900 (JST) Date: Mon, 19 Aug 2002 20:29:08 +0900 (JST) From: Atsushi Onoe Message-Id: <200208191129.g7JBT8i01893@nest.sm.sony.co.jp> To: itojun@iijlab.net Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: Your message of "Mon, 19 Aug 2002 20:08:28 +0900" <20020819110828.4CD204B22@coconut.itojun.org> References: <20020819110828.4CD204B22@coconut.itojun.org> X-Mailer: Cue version 0.6 (020808-1118/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > FTP story was just an example. independent from the FTP story, i am > - pointing out that the current text does not give any guidance > to incoming TCP SYN case, and Isn't the text enough? It looks to me that incoming TCP SYN 'MUST' be allowed by default. | implementation MAY prevent any new communication from using a | deprecated address, but system management MUST have the ability to | disable such a facility, and the facility MUST be disabled by | default. > - we should drop incoming TCP SYN to deprecated addresses. I don't think so. Just the same reason of Pekka's comment. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:30:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBUX3c029925; Mon, 19 Aug 2002 04:30:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBUXnb029924; Mon, 19 Aug 2002 04:30:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBUQ3c029917 for ; Mon, 19 Aug 2002 04:30:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07823 for ; Mon, 19 Aug 2002 04:30:37 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28792 for ; Mon, 19 Aug 2002 05:30:29 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JBTd106253; Mon, 19 Aug 2002 18:29:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JBTSW25445; Mon, 19 Aug 2002 18:29:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819111829.603C74B24@coconut.itojun.org> References: <20020819111829.603C74B24@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 18:29:28 +0700 Message-ID: <25443.1029756568@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 20:18:29 +0900 From: itojun@iijlab.net Message-ID: <20020819111829.603C74B24@coconut.itojun.org> | even if you don't advertise your address to public via DNS, | people will try to connect (people can portscan, ping6 ff02::1, | whatever). I'm not sure what this has to do with anything. You're not suggesting that not using deprecated addresses is a security issue, are you? For the ff02::1 case there's no problem anyway - when (if) you reply to that, you'd use a preferred (non-deprecated) address. There there's no existing communications reason not to do so. I'm having trouble fathoming how portscan is possibly related. In general, we want connections to work, we're not looking for reasons to prevent them. The only reason that we don't send from deprecated addresses all the time (the only reason "deprecated" exists at all) is that we're looking for a graceful way to retire an old address. We can retire it (eventually) from foreign uses, bu aging it out of the DNS. That part is easy. But we have to keep the address valid while that is happening, so it can be used until it does eventually vanish. But if we just keep it valid, then there's nothing to prevent our local node (which does not look up the DNS before deciding what local address to use) from using the address that we're trying to make go away. So, we mark it as special - don't use this one if it makes no difference which address is used, use that one instead. But once again, the aim behind all of this is to keep things working as much as possible during the transition, not to find more ways to prevent communications. | i don't agree with Pekka's take. I do agree. And as I recall, it was the reasoning that was also used, and adopted, years ago. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:31:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBVH3c029942; Mon, 19 Aug 2002 04:31:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBVHnZ029941; Mon, 19 Aug 2002 04:31:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBV63c029927 for ; Mon, 19 Aug 2002 04:31:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07913 for ; Mon, 19 Aug 2002 04:31:15 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07672 for ; Mon, 19 Aug 2002 05:31:15 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5562E4B23; Mon, 19 Aug 2002 20:31:07 +0900 (JST) To: Atsushi Onoe Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com In-reply-to: onoe's message of Mon, 19 Aug 2002 20:29:08 +0900. <200208191129.g7JBT8i01893@nest.sm.sony.co.jp> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Mon, 19 Aug 2002 20:31:07 +0900 Message-Id: <20020819113107.5562E4B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> FTP story was just an example. independent from the FTP story, i am >> - pointing out that the current text does not give any guidance >> to incoming TCP SYN case, and >Isn't the text enough? It looks to me that incoming TCP SYN 'MUST' >be allowed by default. >| implementation MAY prevent any new communication from using a >| deprecated address, but system management MUST have the ability to >| disable such a facility, and the facility MUST be disabled by >| default. "new communication" isn't clear enough, IMHO. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:34:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBYG3c029998; Mon, 19 Aug 2002 04:34:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBYF9t029997; Mon, 19 Aug 2002 04:34:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBY93c029990 for ; Mon, 19 Aug 2002 04:34:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23063 for ; Mon, 19 Aug 2002 04:34:20 -0700 (PDT) Received: from nebula.sm.sony.co.jp (widefw.sm.sony.co.jp [133.138.0.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00194 for ; Mon, 19 Aug 2002 05:34:19 -0600 (MDT) Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id g7JBYHw19964; Mon, 19 Aug 2002 20:34:17 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.11.6/8.11.3) id g7JBXqc01912; Mon, 19 Aug 2002 20:33:52 +0900 (JST) Date: Mon, 19 Aug 2002 20:33:52 +0900 (JST) From: Atsushi Onoe Message-Id: <200208191133.g7JBXqc01912@nest.sm.sony.co.jp> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: Your message of "Mon, 19 Aug 2002 20:23:46 +0900" <20020819112346.6BD6F4B22@coconut.itojun.org> References: <20020819112346.6BD6F4B22@coconut.itojun.org> X-Mailer: Cue version 0.6 (020808-1118/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > this may be an implementation issue, but who should decide it? > in KAME case we have kernel code which forbids the use of deprecated > address as a source (bind(2)) and FTP daemon cannot override it for > data connecdtion. Perhaps the bind(2) with the deprecated address specified explicitly should be succeeded. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:35:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBZX3c000031; Mon, 19 Aug 2002 04:35:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBZXf5000030; Mon, 19 Aug 2002 04:35:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBZR3c000023 for ; Mon, 19 Aug 2002 04:35:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27383 for ; Mon, 19 Aug 2002 04:35:37 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14249 for ; Mon, 19 Aug 2002 05:35:30 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JBYe106468; Mon, 19 Aug 2002 18:34:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JBYTW25519; Mon, 19 Aug 2002 18:34:29 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: Atsushi Onoe , ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819112346.6BD6F4B22@coconut.itojun.org> References: <20020819112346.6BD6F4B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 18:34:29 +0700 Message-ID: <25517.1029756869@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 20:23:46 +0900 From: itojun@iijlab.net Message-ID: <20020819112346.6BD6F4B22@coconut.itojun.org> | this may be an implementation issue, but who should decide it? It was already decided long ago. The doc may need to be made clearer. | in KAME case we have kernel code which forbids the use of deprecated | address as a source (bind(2)) and FTP daemon cannot override it for | data connecdtion. That's an implementation bug (perhaps caused by doc ambiguities). Just fix it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:39:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBdA3c000086; Mon, 19 Aug 2002 04:39:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBdAPj000085; Mon, 19 Aug 2002 04:39:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBd33c000075 for ; Mon, 19 Aug 2002 04:39:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28098 for ; Mon, 19 Aug 2002 04:39:13 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11270 for ; Mon, 19 Aug 2002 05:39:12 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A103A4B22; Mon, 19 Aug 2002 20:39:04 +0900 (JST) To: Robert Elz Cc: Atsushi Onoe , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 19 Aug 2002 18:34:29 +0700. <25517.1029756869@munnari.OZ.AU> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Mon, 19 Aug 2002 20:39:04 +0900 Message-Id: <20020819113904.A103A4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | this may be an implementation issue, but who should decide it? >It was already decided long ago. The doc may need to be made clearer. "who" means "userland, or kernel". itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:43:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBh93c000127; Mon, 19 Aug 2002 04:43:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBh9BW000125; Mon, 19 Aug 2002 04:43:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBh33c000118 for ; Mon, 19 Aug 2002 04:43:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24218 for ; Mon, 19 Aug 2002 04:43:13 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA03355 for ; Mon, 19 Aug 2002 05:42:59 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JBgF106748; Mon, 19 Aug 2002 18:42:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JBgAW25564; Mon, 19 Aug 2002 18:42:10 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: Atsushi Onoe , ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819113107.5562E4B23@coconut.itojun.org> References: <20020819113107.5562E4B23@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 18:42:10 +0700 Message-ID: <25562.1029757330@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 20:31:07 +0900 From: itojun@iijlab.net Message-ID: <20020819113107.5562E4B23@coconut.itojun.org> | "new communication" isn't clear enough, IMHO. It would be hard to dispute that given the exchange of the past hour or two. How would you suggest that it be revised to have the proper effect? (That is, to explicitly allow deprecated addresses to be used, other than when it is a toss up which address to use). Do we currently have a 2462 bis draft? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 04:52:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBqJ3c000255; Mon, 19 Aug 2002 04:52:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JBqJ6T000254; Mon, 19 Aug 2002 04:52:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JBqE3c000246 for ; Mon, 19 Aug 2002 04:52:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10505 for ; Mon, 19 Aug 2002 04:52:24 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07431 for ; Mon, 19 Aug 2002 05:52:10 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JBpM107079; Mon, 19 Aug 2002 18:51:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JBp0W25638; Mon, 19 Aug 2002 18:51:00 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: Atsushi Onoe , ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <20020819113904.A103A4B22@coconut.itojun.org> References: <20020819113904.A103A4B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 18:51:00 +0700 Message-ID: <25636.1029757860@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 2002 20:39:04 +0900 From: itojun@iijlab.net Message-ID: <20020819113904.A103A4B22@coconut.itojun.org> | > | this may be an implementation issue, but who should decide it? | "who" means "userland, or kernel". Oh, sorry, I misunderstood (which I guess was obvious). For the kernel the decision is real simple I think. If it is picking a source address, don't use a deprecated one if it can avoid it (if all addresses are deprecated, or even all of the appropriate scope I think the address selection draft says, then it has no choice). Otherwise, the kernel should not even notice that an address is deprecated. Assuming there's some reasonable way to make the information available to userland, it should adopt the same policy. However, userland has done extremely poorly on address management issues to date, so I am not all that hopeful. This doesn't make a big difference really though - preventing userland from binding to a deprecated address might help very occasionally to steer the application towards a preferred address (one would hope there would be a better API for this than a syscall error...) However, apps that bind to addresses that later become deprecated still need to be dealt with. Those apps should be able to discover that the address they thought was correct, no longer is, and rebind to the new one. Of course, there aren't many such apps, most just use the address the DNS says to use for remote addresses (or one passed from the peer) and whatever address the kernel likes (or the one selected by the remote partner) for the local address. Those just keep on keeping on... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 08:34:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JFYO3c000965; Mon, 19 Aug 2002 08:34:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JFYNk6000964; Mon, 19 Aug 2002 08:34:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JFYI3c000957 for ; Mon, 19 Aug 2002 08:34:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10746 for ; Mon, 19 Aug 2002 08:34:28 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17588 for ; Mon, 19 Aug 2002 08:34:28 -0700 (PDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 19 Aug 2002 08:34:26 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Aug 2002 08:34:26 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Aug 2002 08:34:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: need clarification of "deprecated" address Date: Mon, 19 Aug 2002 08:34:25 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA807D1F9C6@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification of "deprecated" address Thread-Index: AcJHdDSjCZDzQgq5QP6eOwVkFN0PHAAIaFKw From: "Richard Draves" To: "Robert Elz" , Cc: X-OriginalArrivalTime: 19 Aug 2002 15:34:26.0257 (UTC) FILETIME=[E67EE410:01C24795] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7JFYI3c000958 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | i don't agree with Pekka's take. > > I do agree. And as I recall, it was the reasoning that was > also used, and > adopted, years ago. For the record, I agree with Pekka & kre here. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 08:36:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JFaA3c000994; Mon, 19 Aug 2002 08:36:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JFaAF3000993; Mon, 19 Aug 2002 08:36:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JFa43c000986 for ; Mon, 19 Aug 2002 08:36:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26329 for ; Mon, 19 Aug 2002 08:36:15 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18904 for ; Mon, 19 Aug 2002 08:36:15 -0700 (PDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 19 Aug 2002 08:36:13 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Aug 2002 08:36:12 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Aug 2002 08:36:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: need clarification of "deprecated" address Date: Mon, 19 Aug 2002 08:36:12 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA807D1F9C7@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification of "deprecated" address Thread-Index: AcJHdf642ROmy2abRbSBeOOD4g0Z2QAIAXgQ From: "Richard Draves" To: "Robert Elz" , Cc: "Atsushi Onoe" , X-OriginalArrivalTime: 19 Aug 2002 15:36:12.0772 (UTC) FILETIME=[25FBCA40:01C24796] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7JFa53c000987 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How would you suggest that it be revised to have the proper > effect? (That is, to explicitly allow deprecated addresses to > be used, other than when it is a toss up which address to use). Really it should point to the Default Address Selection RFC, although I suppose that would create an undesirable document dependency. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 09:18:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JGIt3c001398; Mon, 19 Aug 2002 09:18:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JGItMZ001397; Mon, 19 Aug 2002 09:18:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JGIm3c001390 for ; Mon, 19 Aug 2002 09:18:49 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g7JGIuA26460; Mon, 19 Aug 2002 18:18:56 +0200 (MEST) Date: Mon, 19 Aug 2002 18:16:49 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Thomas Narten , Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > why are there appendices? seems like at least some of these are part of > > the spec itself. Putting them in the appendices would imply that they > > perhaps aren't important. > > Hmm, the appendices were introduced in 2292bis-00, and I was not an > editor at that time. Perhaps Erik can explain the intention. Based > on my own check for the appendices, sections 22 and 23 can still be > there, because they are too-detailed examples. 21.3.4 and 21.3.5 > should perhaps be moved back to main sections, since they are new > definitions in this API. What do you think of it, Erik? Those are actually mentioned in section 5. Perhaps the whole definition should be moved to section 5, but for consistency section 21.3 should say something about them since it talks about the use of the different CMSG macros. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 09:27:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JGRn3c001441; Mon, 19 Aug 2002 09:27:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JGRnGa001440; Mon, 19 Aug 2002 09:27:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JGRg3c001433 for ; Mon, 19 Aug 2002 09:27:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10522 for ; Mon, 19 Aug 2002 09:27:53 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20176 for ; Mon, 19 Aug 2002 09:27:53 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7JGMi027453; Mon, 19 Aug 2002 12:22:45 -0400 (EDT) Message-Id: <200208191622.g7JGMi027453@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-reply-to: (Your message of "Mon, 19 Aug 2002 17:22:10 +0700.") <25111.1029752530@munnari.OZ.AU> Date: Mon, 19 Aug 2002 12:22:44 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A deprecated address is still a valid address, and can be used for > anything at all. > > However, they're addresses that the intent is to stop using sometime > soon, and if we don't want to break connections when the address becomes > invalid, we should try to avoid using them when possible. > > But that doesn't mean that we break/refuse existing communications > earlier than we need to to achieve that. > > If I have an address, A1, which is goingto change to A2, what I do is > make A1 deprecated, and A2 preferred, and at (more or less) the same > time I start announcing via the DNS the A2 address instead of the A1 > address. > > Remote nodes will take something between hours, and days, depending > on DNS TTLs to detect the change from A1 to A2 - in the interim period the > only address they have is A1, that's the only one they can use. entirely agree. and it's also not reasonable to assume that every application component that has knowledge of an old address is periodically checking DNS - the app might not even be getting its addresses from DNS, and there might not be a reliable DNS name that is bound to the node the app wants to talk to. deprecated addresses should stop working only when the network stops forwarding those packets to hosts - there's no need for hosts to break them prematurely. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 11:53:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JIrU3c001992; Mon, 19 Aug 2002 11:53:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JIrTX9001991; Mon, 19 Aug 2002 11:53:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JIrO3c001984 for ; Mon, 19 Aug 2002 11:53:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04938 for ; Mon, 19 Aug 2002 11:53:35 -0700 (PDT) Received: from webserver.redes.unb.br ([164.41.67.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13512 for ; Mon, 19 Aug 2002 12:53:32 -0600 (MDT) Received: from webserver.redes.unb.br (localhost.localdomain [127.0.0.1]) by webserver.redes.unb.br (8.12.5/8.12.5) with ESMTP id g7JJ4XbX024621 for ; Mon, 19 Aug 2002 16:04:33 -0300 From: "Robson Lopes Jr. Mbone" Received: (from nobody@localhost) by webserver.redes.unb.br (8.12.5/8.12.5/Submit) id g7JJ4WJp024620; Mon, 19 Aug 2002 16:04:32 -0300 X-Authentication-Warning: webserver.redes.unb.br: nobody set sender to lopesjr@redes.unb.br using -f Received: from 200.163.15.40 (SquirrelMail authenticated user lopesjr) by webserver.redes.unb.br with HTTP; Mon, 19 Aug 2002 16:04:32 -0300 (BRT) Message-ID: <4671.200.163.15.40.1029783872.squirrel@webserver.redes.unb.br> Date: Mon, 19 Aug 2002 16:04:32 -0300 (BRT) Subject: Performance IPv6 To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know about studies of performance / QoS in IPv6? I'd like to read/get something real about results in IPv6 performance. If there are any problem with IPv6 in this aspect. Thanks, Robson Loppes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 11:56:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JIuV3c002036; Mon, 19 Aug 2002 11:56:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JIuVm5002035; Mon, 19 Aug 2002 11:56:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JIuO3c002025 for ; Mon, 19 Aug 2002 11:56:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19141 for ; Mon, 19 Aug 2002 11:56:35 -0700 (PDT) Received: from webserver.redes.unb.br ([164.41.67.130]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15642 for ; Mon, 19 Aug 2002 12:56:20 -0600 (MDT) Received: from webserver.redes.unb.br (localhost.localdomain [127.0.0.1]) by webserver.redes.unb.br (8.12.5/8.12.5) with ESMTP id g7JJ7ObX024660 for ; Mon, 19 Aug 2002 16:07:25 -0300 From: "Robson Lopes Jr. Mbone" Received: (from nobody@localhost) by webserver.redes.unb.br (8.12.5/8.12.5/Submit) id g7JJ7MXU024659; Mon, 19 Aug 2002 16:07:22 -0300 X-Authentication-Warning: webserver.redes.unb.br: nobody set sender to lopesjr@redes.unb.br using -f Received: from 200.163.15.40 (SquirrelMail authenticated user lopesjr) by webserver.redes.unb.br with HTTP; Mon, 19 Aug 2002 16:07:22 -0300 (BRT) Message-ID: <4719.200.163.15.40.1029784042.squirrel@webserver.redes.unb.br> Date: Mon, 19 Aug 2002 16:07:22 -0300 (BRT) Subject: QoS IPv6 To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to know about any studies of performance / QoS in IPv6. Does anyone have something "real" (not theorical)? Are there any problem with IPv6 in this aspect? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 13:48:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JKmI3c002470; Mon, 19 Aug 2002 13:48:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JKmISL002469; Mon, 19 Aug 2002 13:48:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JKmB3c002462 for ; Mon, 19 Aug 2002 13:48:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29177 for ; Mon, 19 Aug 2002 13:48:22 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01707 for ; Mon, 19 Aug 2002 13:48:22 -0700 (PDT) Received: from localhost ([2001:4f8:3:e:44c8:b3b1:424:fc4f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7JKm9t32344; Tue, 20 Aug 2002 05:48:10 +0900 (JST) Date: Tue, 20 Aug 2002 05:48:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 19 Aug 2002 18:16:49 +0200 (CEST), >>>>> Erik Nordmark said: >> > why are there appendices? seems like at least some of these are part of >> > the spec itself. Putting them in the appendices would imply that they >> > perhaps aren't important. >> >> Hmm, the appendices were introduced in 2292bis-00, and I was not an >> editor at that time. Perhaps Erik can explain the intention. Based >> on my own check for the appendices, sections 22 and 23 can still be >> there, because they are too-detailed examples. 21.3.4 and 21.3.5 >> should perhaps be moved back to main sections, since they are new >> definitions in this API. What do you think of it, Erik? > Those are actually mentioned in section 5. Ah, yes, I missed that part. > Perhaps the whole definition should be moved to section 5, but for consistency > section 21.3 should say something about them since it talks about the > use of the different CMSG macros. Okay, then I'll move the new definitions to Section 5, and change Section 21.3 so that it will only contain possible implementation examples and usages. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 15:35:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JMZf3c003194; Mon, 19 Aug 2002 15:35:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JMZf8B003193; Mon, 19 Aug 2002 15:35:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JMZY3c003177 for ; Mon, 19 Aug 2002 15:35:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13096 for ; Mon, 19 Aug 2002 15:35:44 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02876 for ; Mon, 19 Aug 2002 15:35:40 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7JMZRU09244; Tue, 20 Aug 2002 00:35:27 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA08238; Tue, 20 Aug 2002 00:35:27 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7JMZP6o000680; Tue, 20 Aug 2002 00:35:25 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208192235.g7JMZP6o000680@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Atsushi Onoe , ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-reply-to: Your message of Mon, 19 Aug 2002 20:23:46 +0900. <20020819112346.6BD6F4B22@coconut.itojun.org> Date: Tue, 20 Aug 2002 00:35:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: this may be an implementation issue, but who should decide it? in KAME case we have kernel code which forbids the use of deprecated address as a source (bind(2)) and FTP daemon cannot override it for data connecdtion. => IMHO this is an implementation bug: deprecated != invalid. Regards Francis.Dupont@enst-bretagne.fr PS: bind(2) should be the only common way to use a deprecated address as a source address of a new "connection". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 16:26:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JNQM3c003411; Mon, 19 Aug 2002 16:26:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JNQLfG003410; Mon, 19 Aug 2002 16:26:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JNQE3c003403 for ; Mon, 19 Aug 2002 16:26:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27523 for ; Mon, 19 Aug 2002 16:26:25 -0700 (PDT) Received: from coconut.itojun.org ([202.232.15.92]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15023 for ; Mon, 19 Aug 2002 17:26:24 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id CC7994B23; Tue, 20 Aug 2002 08:26:10 +0900 (JST) To: Francis Dupont Cc: Atsushi Onoe , ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Tue, 20 Aug 2002 00:35:25 +0200. <200208192235.g7JMZP6o000680@givry.rennes.enst-bretagne.fr> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Tue, 20 Aug 2002 08:26:10 +0900 Message-Id: <20020819232610.CC7994B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> In your previous mail you wrote: >> this may be an implementation issue, but who should decide it? >> in KAME case we have kernel code which forbids the use of deprecated >> address as a source (bind(2)) and FTP daemon cannot override it for >> data connecdtion. >=> IMHO this is an implementation bug: deprecated != invalid. latest KAME tree permits bind(deprecated address), while older tree (like *BSD) does not. i'll need to dig commit logs again to understand the reasoning for the change (maybe i made the change and forgot). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 19 18:16:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K1GC3c003814; Mon, 19 Aug 2002 18:16:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7K1GCRa003813; Mon, 19 Aug 2002 18:16:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K1G43c003806; Mon, 19 Aug 2002 18:16:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05773; Mon, 19 Aug 2002 18:16:08 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10319; Mon, 19 Aug 2002 18:16:03 -0700 (PDT) Received: from kenawang ([147.11.233.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA25602; Mon, 19 Aug 2002 18:14:24 -0700 (PDT) Message-Id: <4.2.2.20020819211305.0284a1b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 19 Aug 2002 21:15:13 -0400 To: Erik Nordmark From: Margaret Wasserman Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Cc: Robert Elz , Dave Thaler , "Charles E. Perkins" , itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group In-Reply-To: References: <"Your message with ID" <770.1023183551@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:26 AM 6/4/02 , Erik Nordmark wrote: > > | My preference is that we just ban DAD optimization in all cases. > > > > That's certainly an option. The "new prefix causes several thousand > > nodes to all attempt DAD at the same time" argument is the one which > > makes me hesitant to simply support this without further investigation. If thousands of nodes are involved, the DAD optimization may not be enough to fix this problem. Instead, we might need some sort of random delay on the creation of addresses when a new prefix is received. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 01:29:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K8Tw3c005396; Tue, 20 Aug 2002 01:29:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7K8TwwU005395; Tue, 20 Aug 2002 01:29:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K8Th3c005380; Tue, 20 Aug 2002 01:29:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07086; Tue, 20 Aug 2002 01:29:55 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26912; Tue, 20 Aug 2002 01:29:53 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA28974; Tue, 20 Aug 2002 11:29:40 +0300 Date: Tue, 20 Aug 2002 11:29:40 +0300 Message-Id: <200208200829.LAA28974@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <4.2.2.20020819211305.0284a1b0@mail.windriver.com> (message from Margaret Wasserman on Mon, 19 Aug 2002 21:15:13 -0400) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <"Your message with ID" <770.1023183551@munnari.OZ.AU> <4.2.2.20020819211305.0284a1b0@mail.windriver.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Margaret Wasserman > > > That's certainly an option. The "new prefix causes several thousand > > > nodes to all attempt DAD at the same time" argument is the one which > > > makes me hesitant to simply support this without further investigation. > > If thousands of nodes are involved, the DAD optimization may not be > enough to fix this problem. Umm? DAD optimization definitely removes the quoted problem. When optimized, DAD is only done on the link local address when a node is attached (or booted) to the network. > Instead, we might need some sort of random delay on the creation of > addresses when a new prefix is received. The random delay is already specified for DAD in the boot/attach process. The delay is less suitable for DAD's done on RA. In optimized environment, addresses are useable immediately after RA. With non-optimized and delayed DAD, we would have undetermined gap after RA, when an address retrieved from DNS might not work. I would like my network to be as deterministic as possible, avoid randomness when not absolutely necessary. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 05:51:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KCpG3c006312; Tue, 20 Aug 2002 05:51:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KCpGCc006311; Tue, 20 Aug 2002 05:51:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KCp03c006293; Tue, 20 Aug 2002 05:51:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21367; Tue, 20 Aug 2002 05:51:11 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11966; Tue, 20 Aug 2002 06:50:55 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7KCnr127380; Tue, 20 Aug 2002 19:49:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7KCnSW29294; Tue, 20 Aug 2002 19:49:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: mrw@windriver.com, Erik.Nordmark@Sun.COM, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <200208200829.LAA28974@burp.tkv.asdf.org> References: <200208200829.LAA28974@burp.tkv.asdf.org> <"Your message with ID" <770.1023183551@munnari.OZ.AU> <4.2.2.20020819211305.0284a1b0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Aug 2002 19:49:28 +0700 Message-ID: <29292.1029847768@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 20 Aug 2002 11:29:40 +0300 From: Markku Savela Message-ID: <200208200829.LAA28974@burp.tkv.asdf.org> | The delay is less suitable for DAD's done on RA. In optimized | environment, addresses are useable immediately after RA. That's true, but I'm not sure this is important. | With | non-optimized and delayed DAD, we would have undetermined gap after | RA, when an address retrieved from DNS might not work. If you're sticking things in the DNS simultaneously with RA, or even before the RA is issued, then yes, I'd expect breakage. But I can't imagine why anyone would do that. Usually, I'd expect, you'd advertise the new prefix (via RA) then after that's done, advertise the new addresses in the DNS - either by manually waiting for the RA to take effect (which might involve waiting a few RA transmit cycles - some hosts might be busy and miss the first RA after all) and then editing the DNS, or by using dynamic DNS, and having each host update its own address(es) as they are installed in the host. | I would like my | network to be as deterministic as possible, avoid randomness when not | absolutely necessary. The way to achieve that is to test that the hosts have picked up the new prefix before advertising it in the DNS, not by assuming that every host will necessarily have the address available the instant that the RA is transmitted. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 06:16:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KDGi3c006632; Tue, 20 Aug 2002 06:16:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KDGiXv006631; Tue, 20 Aug 2002 06:16:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KDGV3c006616; Tue, 20 Aug 2002 06:16:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25571; Tue, 20 Aug 2002 06:16:42 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24937; Tue, 20 Aug 2002 07:16:40 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA29174; Tue, 20 Aug 2002 16:15:37 +0300 Date: Tue, 20 Aug 2002 16:15:37 +0300 Message-Id: <200208201315.QAA29174@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: mrw@windriver.com, Erik.Nordmark@Sun.COM, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <29292.1029847768@munnari.OZ.AU> (message from Robert Elz on Tue, 20 Aug 2002 19:49:28 +0700) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200208200829.LAA28974@burp.tkv.asdf.org> <"Your message with ID" <770.1023183551@munnari.OZ.AU> <4.2.2.20020819211305.0284a1b0@mail.windriver.com> <29292.1029847768@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > If you're sticking things in the DNS simultaneously with RA, or even > before the RA is issued, then yes, I'd expect breakage. But I can't > imagine why anyone would do that. But, this is exactly the normal situation. The prefix, that is announced in RA, is one the global prefixes for link. I assume global addresses are in the DNS. It can be just situation that router was temporarily down and then came online/reachable again. At least in our system, application can connect to an global address, but if there is no route, the connect can be on hold for a while in wait for router advertisement. If such arrives, onlink route for the prefix is intalled, and immediately also the connections are activated (SYN packets sent causing the Neighbor solitications for the destionations). Now, if the other hosts are delaying their replies, I may get unreachable... perhaps not a big deal, but still not pretty either. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 06:40:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KDeM3c006821; Tue, 20 Aug 2002 06:40:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KDeLtg006820; Tue, 20 Aug 2002 06:40:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KDe93c006805; Tue, 20 Aug 2002 06:40:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19338; Tue, 20 Aug 2002 06:40:04 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12590; Tue, 20 Aug 2002 07:40:02 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7KDdxU04285; Tue, 20 Aug 2002 15:39:59 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA14560; Tue, 20 Aug 2002 15:39:59 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7KDdw6o002495; Tue, 20 Aug 2002 15:39:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208201339.g7KDdw6o002495@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: Erik Nordmark , Robert Elz , Dave Thaler , "Charles E. Perkins" , itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Mon, 19 Aug 2002 21:15:13 EDT. <4.2.2.20020819211305.0284a1b0@mail.windriver.com> Date: Tue, 20 Aug 2002 15:39:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Instead, we might need some sort of random delay on the creation of addresses when a new prefix is received. => IMHO the delay should be in the DAD itself. We already got a random delay between 0 and MAX_RTR_SOLICITATION_DELAY for the first DAD on an interface, why not require it in all cases? Another detail: before doing DAD, the solicited group must be joined and this is another cause of collisions when implementations are buggy (i.e., no new report should be sent because the node is already a member of the group). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 07:10:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KEAi3c007118; Tue, 20 Aug 2002 07:10:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KEAimm007117; Tue, 20 Aug 2002 07:10:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KEAW3c007102; Tue, 20 Aug 2002 07:10:32 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06608; Tue, 20 Aug 2002 07:10:41 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00591; Tue, 20 Aug 2002 08:10:40 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA29298; Tue, 20 Aug 2002 17:10:31 +0300 Date: Tue, 20 Aug 2002 17:10:31 +0300 Message-Id: <200208201410.RAA29298@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200208201339.g7KDdw6o002495@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 20 Aug 2002 15:39:58 +0200) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200208201339.g7KDdw6o002495@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Francis Dupont > Another detail: before doing DAD, the solicited group must be joined > and this is another cause of collisions when implementations are buggy > (i.e., no new report should be sent because the node is already a member > of the group). What report? Solicited node is LINKLOCAL group, there is no need to send any joins on those? Or is some weird multilink hack again breaking the basic assumptions about Link Local? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 07:27:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KERj3c007380; Tue, 20 Aug 2002 07:27:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KERjUb007379; Tue, 20 Aug 2002 07:27:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KERW3c007364; Tue, 20 Aug 2002 07:27:32 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02553; Tue, 20 Aug 2002 07:27:42 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10982; Tue, 20 Aug 2002 08:27:40 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7KERbU09998; Tue, 20 Aug 2002 16:27:37 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA15065; Tue, 20 Aug 2002 16:27:38 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7KERb6o002654; Tue, 20 Aug 2002 16:27:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208201427.g7KERb6o002654@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Tue, 20 Aug 2002 17:10:31 +0300. <200208201410.RAA29298@burp.tkv.asdf.org> Date: Tue, 20 Aug 2002 16:27:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: What report? Solicited node is LINKLOCAL group, there is no need to send any joins on those? Or is some weird multilink hack again breaking the basic assumptions about Link Local? => from RFC 2710: MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1). Francis.Dupont@enst-bretagne.fr PS: the reason is that layer-2 devices need to know if they can remove multicast packets to nodes which are not listening for them (cf draft-ietf-magma-snoop-02.txt). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 08:00:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KF0M3c007768; Tue, 20 Aug 2002 08:00:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KF0MP9007767; Tue, 20 Aug 2002 08:00:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KF063c007751; Tue, 20 Aug 2002 08:00:06 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12162; Tue, 20 Aug 2002 08:00:16 -0700 (PDT) Received: from mail2 ([149.99.32.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01495; Tue, 20 Aug 2002 09:00:15 -0600 (MDT) Received: from atp (unverified [149.99.32.50]) by mail2 (Rockliffe SMTPRA 4.2.2) with ESMTP id ; Tue, 20 Aug 2002 08:29:54 -0700 Message-ID: <2011843.1029855891531.JavaMail.Administrator@atp> Date: Tue, 20 Aug 2002 08:04:51 -0700 (PDT) From: bkhabs Reply-To: bkhabs@nc.rr.com To: Francis.Dupont@enst-bretagne.fr, msa@burp.tkv.asdf.org Subject: Re: Re: [mobile-ip] RE: RFC 2462 DAD optimization Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: E-mailanywhere V2.0 (Windows) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >On Tue, 20 Aug 2002 17:10:31 0300 Markku Savela wrote. >> From: Francis Dupont > >> Another detail: before doing DAD, the solicited group must be joined >> and this is another cause of collisions when implementations are buggy >> (i.e., no new report should be sent because the node is already a member >> of the group). > >What report? Solicited node is LINKLOCAL group, there is no need to >send any joins on those? Or is some weird multilink hack again >breaking the basic assumptions about Link Local? RFC 2710 requires that nodes listening to a multicast group of scope 2 or greater (excluding ALL-NODES) to participate in the MLD protocol. It is intended to allow for proper behavior with the use of IGMP/MLD snooping switches. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 09:52:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KGq23c008409; Tue, 20 Aug 2002 09:52:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KGq1Vo008408; Tue, 20 Aug 2002 09:52:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KGpu3c008401 for ; Tue, 20 Aug 2002 09:51:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23226 for ; Tue, 20 Aug 2002 09:52:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29896 for ; Tue, 20 Aug 2002 10:52:05 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA01826 for ; Tue, 20 Aug 2002 09:52:00 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7KGq0h19979 for ; Tue, 20 Aug 2002 09:52:00 -0700 X-mProtect: <200208201652> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7fbHgh; Tue, 20 Aug 2002 09:51:57 PDT Message-ID: <3D6273AD.897D2187@iprg.nokia.com> Date: Tue, 20 Aug 2002 09:51:58 -0700 From: Mukesh Gupta Organization: Nokia IPRG X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: RFC2473: Why is the tunnel unidirectional Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I am not able to understand why the IPv6 tunnel is a unidirectional mechanism as specified in section 3 of RFC 2473. Here is the text which is not making sense to me. === An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow takes place in one direction between the IPv6 tunnel entry-point and exit-point nodes (see Fig.1). Bi-directional tunneling is achieved by merging two unidirectional mechanisms, that is, configuring two tunnels, each in opposite direction to the other - the entry-point node of one tunnel is the exit-point node of the other tunnel (see Fig.2). === Does it mean that we will have to configure 2 tunnels on each end point in order to create a virtual point to point link between the two systems. That's not the case for GRE for IPv4. Help would be highly appreciated. regards Mukesh -- ****************************************************************** It is a mistake to look too far ahead.Only one link in the chain of destiny can be handled at a time. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 11:38:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KIcw3c008815; Tue, 20 Aug 2002 11:38:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KIcvaq008814; Tue, 20 Aug 2002 11:38:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KIcq3c008807 for ; Tue, 20 Aug 2002 11:38:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06733 for ; Tue, 20 Aug 2002 11:39:02 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26269 for ; Tue, 20 Aug 2002 12:39:02 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 20 Aug 2002 11:39:01 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 20 Aug 2002 11:39:01 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Aug 2002 11:39:00 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 20 Aug 2002 11:39:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD vs. DIID Date: Tue, 20 Aug 2002 11:39:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcJE7ZSYcbyct3LwS9iDn2ehG3wMHwDimgjg From: "Brian Zill" To: "Markku Savela" Cc: X-OriginalArrivalTime: 20 Aug 2002 18:39:00.0839 (UTC) FILETIME=[D9DFBF70:01C24878] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7KIcq3c008808 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > > > From: "Brian Zill" > > > > My take: given that it appears the majority of > > implementations currently do "DAD", and that "DAD" > > provides for a cleaner multi-link subnet architecture, > > I think "DAD" is the better choice. > > Umm.. "majority of implementations"? What is this? How do you > count them? When was this tally performed. I just went by the ones I know about. Judging from the messages on this thread, there are only one or two implementations doing "DIID". Note that I said "it appears", I didn't claim to have conducted an exhaustive poll. > Does each separate implementation count as one? Or, does the > number of nodes running the implementation affect the count? > Or some other weighing algorithm? Well, I had just been considering each separate implementation. Weighing them by existing node count would shift things even more clearly in the "DAD" direction since both KAME and us do "DAD". --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 12:17:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KJH33c008954; Tue, 20 Aug 2002 12:17:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KJH2Xg008953; Tue, 20 Aug 2002 12:17:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KJGu3c008946 for ; Tue, 20 Aug 2002 12:16:56 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21017 for ; Tue, 20 Aug 2002 12:17:07 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20167 for ; Tue, 20 Aug 2002 13:17:06 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 20 Aug 2002 12:17:06 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Aug 2002 12:17:05 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 20 Aug 2002 12:17:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD vs. DIID Date: Tue, 20 Aug 2002 12:17:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcJFQIV4Ffg41eGwQ2GkRY65ByXpRADOGRjw From: "Brian Zill" To: "Charles E. Perkins" Cc: X-OriginalArrivalTime: 20 Aug 2002 19:17:05.0591 (UTC) FILETIME=[2BB13C70:01C2487E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7KJGv3c008947 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie, > I haven't studied the multi-link subnet draft. But, in order > to be responsive to your note before taking that time... I guess we're just going to have to disagree about link-local vs. subnet-local. These are two distinct scopes and should be treated as such by the architecture. One shouldn't assume that because you can reach a node via a global address in the same subnet prefix as you that you can also reach it via a link-local address. "DIID" breaks this by making the false assumption that these scopes are equivalent. The whole point of multi-link subnet routers is to allow multiple links, of possibly different physical characteristics, MTUs, etc, to belong to the same subnet. And to do it in an architecturally consistent way. A multi-link subnet router is a real router that drops the hop count between links. It leaves link-local addresses as unique on their link, as it should. Maybe we should define unicast address prefixes for each scope as we have for multicast, so there would be subnet-local unicast addresses. That would allow people who want to do things on a subnet, rather than link, basis to do so. > And, please don't forget the negative impact on home agent operation. You would have the same problem with "DIID" if the mobile node has a large number of home addresses that differed in the IID part. As I noted in my earlier mail, there are plenty of creative proposals for using lots of IIDs per node, just as I suspect there are some for using lots of prefixes per subnet. Let's not break the architecture here over a optimization that has a lot of questionable assumptions in it. If we can't live with "DAD", then I'd much prefer we revise the whole duplicate address detection mechanism. Currently DAD has two serious flaws and one major inconvienience: It doesn't protect against duplicate addresses on reconnected networks (something I would think would happen a lot on some types of wireless links), it doesn't document a recourse to take when your only address is a duplicate (retry with a random address is the obvious solution, but that isn't standardized like EUI-64 is), and it takes longer than we would like. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 13:10:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KKAc3c009107; Tue, 20 Aug 2002 13:10:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KKAct7009106; Tue, 20 Aug 2002 13:10:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KKAW3c009099 for ; Tue, 20 Aug 2002 13:10:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26674 for ; Tue, 20 Aug 2002 13:10:43 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01540 for ; Tue, 20 Aug 2002 13:10:42 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7KKATU08151; Tue, 20 Aug 2002 22:10:30 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA17640; Tue, 20 Aug 2002 22:10:30 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7KKAR6o003422; Tue, 20 Aug 2002 22:10:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208202010.g7KKAR6o003422@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Atsushi Onoe , ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-reply-to: Your message of Tue, 20 Aug 2002 08:26:10 +0900. <20020819232610.CC7994B23@coconut.itojun.org> Date: Tue, 20 Aug 2002 22:10:27 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >=> IMHO this is an implementation bug: deprecated != invalid. latest KAME tree permits bind(deprecated address), while older tree (like *BSD) does not. i'll need to dig commit logs again to understand the reasoning for the change (maybe i made the change and forgot). => IMHO the deprecated flag should be used only in source address selection. BTW for invalidated addresses I don't know if connections should be eagerly dropped (with some kind of notification to all PCBs) or lazily dropped (i.e., destroyed only when they show some kind of activity). I implemented both solutions in the past... Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 13:40:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KKeg3c009213; Tue, 20 Aug 2002 13:40:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KKegUm009211; Tue, 20 Aug 2002 13:40:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KKeb3c009204 for ; Tue, 20 Aug 2002 13:40:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05717 for ; Tue, 20 Aug 2002 13:40:48 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09104 for ; Tue, 20 Aug 2002 14:40:48 -0600 (MDT) Received: from kenawang ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA00574; Tue, 20 Aug 2002 13:40:12 -0700 (PDT) Message-Id: <4.2.2.20020820163740.027d1e90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 20 Aug 2002 16:41:05 -0400 To: "Brian Zill" From: Margaret Wasserman Subject: RE: DAD vs. DIID Cc: "Charles E. Perkins" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:17 PM 8/20/02 , Brian Zill wrote: >Hi Charlie, > > > I haven't studied the multi-link subnet draft. But, in order > > to be responsive to your note before taking that time... > >I guess we're just going to have to disagree about link-local vs. >subnet-local. These are two distinct scopes and should be treated as >such by the architecture. One shouldn't assume that because you can >reach a node via a global address in the same subnet prefix as you that >you can also reach it via a link-local address. "DIID" breaks this by >making the false assumption that these scopes are equivalent. I agree that link-local and subnet-local would be different scopes. What surprised me is the assumption that a subnet scope would be "larger" than a link-local scope. I've had experience running multiple subnets on a single L2 link, but I have not had experience running a single subnet across multiple L2 links. So, while you indicate that a link-local address may not be able to reach all nodes on a subnet, isn't it also true that a subnet-local address may not be able to reach all of the nodes on a link? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 15:11:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KMBf3c009583; Tue, 20 Aug 2002 15:11:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KMBeTE009582; Tue, 20 Aug 2002 15:11:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KMBX3c009575 for ; Tue, 20 Aug 2002 15:11:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09734 for ; Tue, 20 Aug 2002 15:11:43 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [202.232.15.92]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28262 for ; Tue, 20 Aug 2002 16:11:41 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 17D334B22; Wed, 21 Aug 2002 07:11:35 +0900 (JST) To: Robert Elz Cc: Atsushi Onoe , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 19 Aug 2002 18:42:10 +0700. <25562.1029757330@munnari.OZ.AU> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Wed, 21 Aug 2002 07:11:35 +0900 Message-Id: <20020820221135.17D334B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i now understood all the reasoning for accepting TCP SYN to deprecated address, and corrected netbsd. ok. > | "new communication" isn't clear enough, IMHO. >It would be hard to dispute that given the exchange of the past >hour or two. >How would you suggest that it be revised to have the proper effect? >(That is, to explicitly allow deprecated addresses to be used, other >than when it is a toss up which address to use). >Do we currently have a 2462 bis draft? here are my proposed changes. itojun RFC2462 page 3: > in arbitrary communication is unrestricted. Later, an address becomes > "deprecated" in anticipation that its current interface binding will > become invalid. While in a deprecated state, the use of an address is > discouraged, but not strictly forbidden. New communication (e.g., > the opening of a new TCP connection) should use a preferred address > when possible. A deprecated address should be used only by > applications that have been using it and would have difficulty > switching to another address without a service disruption. the last sentence does not meet people's understand. append ", or there is no other choice than to use deprecated address". or, since this is introduction section, we shouldn't go into this detail here. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 15:47:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KMlm3c009663; Tue, 20 Aug 2002 15:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KMlm74009662; Tue, 20 Aug 2002 15:47:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KMlg3c009655 for ; Tue, 20 Aug 2002 15:47:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09189 for ; Tue, 20 Aug 2002 15:47:53 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07989 for ; Tue, 20 Aug 2002 16:47:53 -0600 (MDT) Received: from ieee.org ([12.248.77.94]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020820224751.YKVX1746.rwcrmhc51.attbi.com@ieee.org> for ; Tue, 20 Aug 2002 22:47:51 +0000 Message-ID: <3D62C704.27A1ECC1@ieee.org> Date: Tue, 20 Aug 2002 17:47:32 -0500 From: Peter Lei X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address [multihomed case] References: <20020820221135.17D334B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Consider a multi-homed host using a multi-homed transport protocol (such as SCTP) having multiple valid addresses but also having a deprecated address-- from what I understand from this thread, -- we need to allow binding of the deprecated address on the host -- we need to accept connections to the deprecated address I've made these changes in the SCTP stack this is distributed along with KAME. However, should any new connections (SCTP associations) FROM this host to a peer list the deprecated address as part of the association? Given the existing text and this discussion, it seems that it should not, as other preferred address(es) are available. Of course unless as qualified by the proposed text below-- that it is the only address available (eg. the host is single homed/has a single valid address which happens to be a deprecated address). Comments? --peter itojun@iijlab.net wrote: > > i now understood all the reasoning for accepting TCP SYN to deprecated > address, and corrected netbsd. ok. > > > | "new communication" isn't clear enough, IMHO. > >It would be hard to dispute that given the exchange of the past > >hour or two. > >How would you suggest that it be revised to have the proper effect? > >(That is, to explicitly allow deprecated addresses to be used, other > >than when it is a toss up which address to use). > >Do we currently have a 2462 bis draft? > > here are my proposed changes. > > itojun > > RFC2462 > page 3: > > > in arbitrary communication is unrestricted. Later, an address becomes > > "deprecated" in anticipation that its current interface binding will > > become invalid. While in a deprecated state, the use of an address is > > discouraged, but not strictly forbidden. New communication (e.g., > > the opening of a new TCP connection) should use a preferred address > > when possible. A deprecated address should be used only by > > applications that have been using it and would have difficulty > > switching to another address without a service disruption. > > the last sentence does not meet people's understand. append > ", or there is no other choice than to use deprecated address". > > or, since this is introduction section, we shouldn't go into this > detail here. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 16:08:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KN8c3c009755; Tue, 20 Aug 2002 16:08:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KN8cZ9009754; Tue, 20 Aug 2002 16:08:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KN8W3c009747 for ; Tue, 20 Aug 2002 16:08:33 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21154; Tue, 20 Aug 2002 19:08:43 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g7KN8h45019085; Tue, 20 Aug 2002 19:08:43 -0400 (EDT) Message-Id: <200208202308.g7KN8h45019085@thunk.east.sun.com> From: Bill Sommerfeld To: Peter Lei cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address [multihomed case] In-Reply-To: Your message of "Tue, 20 Aug 2002 17:47:32 CDT." <3D62C704.27A1ECC1@ieee.org> Reply-to: sommerfeld@east.sun.com Date: Tue, 20 Aug 2002 19:08:43 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, should any new connections (SCTP associations) FROM this host to > a peer list the deprecated address as part of the association? Given the > existing text and this discussion, it seems that it should not, as other > preferred address(es) are available. Of course unless as qualified by the > proposed text below-- that it is the only address available (eg. the host > is single homed/has a single valid address which happens to be a deprecated > address). Does SCTP provide some way to describe a preferred order over the addresses, or is the address set inherently unordered? Does it provide a way to delete an address from an active connection? If there is an ordering, pushing deprecateds to the bottom of the barrel (and deleting them when they expire) sounds most robust and in keeping with the rest of the discussion on this thread. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 16:35:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KNZq3c009874; Tue, 20 Aug 2002 16:35:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KNZpDV009873; Tue, 20 Aug 2002 16:35:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KNZj3c009866 for ; Tue, 20 Aug 2002 16:35:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29555 for ; Tue, 20 Aug 2002 16:35:57 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23358 for ; Tue, 20 Aug 2002 17:35:55 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 20 Aug 2002 16:35:55 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Aug 2002 16:35:53 -0700 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.2966); Tue, 20 Aug 2002 16:35:53 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 20 Aug 2002 16:35:53 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 20 Aug 2002 16:35:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD vs. DIID Date: Tue, 20 Aug 2002 16:37:18 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10738420A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID thread-index: AcJIil9JL9AWsGM9SCGAeQToRNPCRgAF01UQ From: "Dave Thaler" To: "Margaret Wasserman" , "Brian Zill" Cc: "Charles E. Perkins" , X-OriginalArrivalTime: 20 Aug 2002 23:35:54.0410 (UTC) FILETIME=[5396F8A0:01C248A2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7KNZk3c009867 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] [...] > So, while you indicate that a link-local address may not be able to > reach all nodes on a subnet, isn't it also true that a subnet-local > address may not be able to reach all of the nodes on a link? Since the boundary of a zone goes through a node, not through a link (ref: scoped addr arch doc), then no it is not true. The "subnet-local" scope contains all interfaces on the link regardless of what addresses are on those interfaces. However, there are no subnet-local unicast addresses (only multicast ones) so the question is moot in practice. The closest question you could construct in practice is: "If a link has multiple subnet prefixes assigned to it, and I source from a global address in one of them, and the destination is a subnet-local multicast group, will another machine on the same link, which does not have an address in the same prefix, receive the packet." The answer is yes it will (so the answer to your question is: no, not true). -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 20:20:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L3KB3c010586; Tue, 20 Aug 2002 20:20:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7L3KACM010585; Tue, 20 Aug 2002 20:20:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L3K53c010578 for ; Tue, 20 Aug 2002 20:20:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26635 for ; Tue, 20 Aug 2002 20:20:17 -0700 (PDT) Received: from sngrel5.hp.com (sngrel5.hp.com [192.6.86.210]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24586 for ; Tue, 20 Aug 2002 20:20:11 -0700 (PDT) Received: from ctss11.sgp.hp.com (ctss11.sgp.hp.com [15.85.49.5]) by sngrel5.hp.com (Postfix) with ESMTP id 99F6CA5 for ; Wed, 21 Aug 2002 11:20:08 +0800 (SGP) Received: from XAUBRG1.AUS.HP.COM (xaubrg1.aus.hp.com [15.23.69.35]) by ctss11.sgp.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail BPI enabled) with SMTP id LAA08151 for ; Wed, 21 Aug 2002 11:20:06 +0800 (SGP) Received: from 15.23.69.35 by XAUBRG1.AUS.HP.COM (InterScan E-Mail VirusWall NT); Wed, 21 Aug 2002 13:20:05 +1000 Received: by xaubrg1.aus.hp.com with Internet Mail Service (5.5.2656.59) id ; Wed, 21 Aug 2002 13:20:05 +1000 Message-ID: From: "SEENYEN,GENE (HP-Australia,ex3)" To: ipng@sunroof.eng.sun.com Subject: About Link-Local address prefix. Date: Wed, 21 Aug 2002 13:20:30 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I hope someone would be able to help me out here. I have a query regarding what is documented and known as the prefix for the Link-Local addresses. It is generally defined as FE80::/10 but looking at RFC2464 it says in section 5. 5 Link-Local Addresses The IPv6 link-local address [AARCH] for an Ethernet interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+ Here the prefix is FE80::/64. I know that FE80::/10 and FE80::/64 are the same and that in practice FE80::/10 currently means FE80:/64 with the node's EUI-64 in the bottom 64 bits but what I am not sure is how the /64 is achieved. Does the /64 refer to the 10 MSB bits + the 54 bits which are all 0 or does the /64 mean the 64 Interface identifier bits? Also why use either FE80::/10 or FE80::/64 as the Link local address instead of having just one? Thanks for the help Gene - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 21:14:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L4Eh3c010683; Tue, 20 Aug 2002 21:14:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7L4Eh1A010682; Tue, 20 Aug 2002 21:14:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L4Ec3c010675 for ; Tue, 20 Aug 2002 21:14:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03480 for ; Tue, 20 Aug 2002 21:14:48 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA21330 for ; Tue, 20 Aug 2002 22:14:47 -0600 (MDT) Received: from ieee.org ([12.248.77.94]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020821041446.LMRG1186.rwcrmhc52.attbi.com@ieee.org>; Wed, 21 Aug 2002 04:14:46 +0000 Message-ID: <3D63139F.4CEBE6DE@ieee.org> Date: Tue, 20 Aug 2002 23:14:23 -0500 From: Peter Lei X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address [multihomed case] References: <200208202308.g7KN8h45019085@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > However, should any new connections (SCTP associations) FROM this host to > > a peer list the deprecated address as part of the association? Given the > > existing text and this discussion, it seems that it should not, as other > > preferred address(es) are available. Of course unless as qualified by the > > proposed text below-- that it is the only address available (eg. the host > > is single homed/has a single valid address which happens to be a deprecated > > address). > > Does SCTP provide some way to describe a preferred order over the > addresses, or is the address set inherently unordered? Does it > provide a way to delete an address from an active connection? > > If there is an ordering, pushing deprecateds to the bottom of the > barrel (and deleting them when they expire) sounds most robust and in > keeping with the rest of the discussion on this thread. > > - Bill I agree, but the address list is unordered (there is no implied preference order), hence my thought that they should probably not be included in the list. And yes, there is a way to delete an address from an active association, but that is currently an I-D and not part of RFC 2960; hence, for existing association(s) that have addresses that become deprecated, then expire, there is a mechanism to delete them from the association(s). --peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 22:28:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L5SO3c010788; Tue, 20 Aug 2002 22:28:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7L5SOtM010787; Tue, 20 Aug 2002 22:28:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L5SJ3c010780 for ; Tue, 20 Aug 2002 22:28:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09494 for ; Tue, 20 Aug 2002 22:28:29 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA18568 for ; Tue, 20 Aug 2002 23:28:28 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7L5S4q31250; Wed, 21 Aug 2002 08:28:04 +0300 Date: Wed, 21 Aug 2002 08:28:03 +0300 (EEST) From: Pekka Savola To: Dave Thaler cc: Margaret Wasserman , Brian Zill , "Charles E. Perkins" , Subject: RE: DAD vs. DIID In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC10738420A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 20 Aug 2002, Dave Thaler wrote: > > -----Original Message----- > > From: Margaret Wasserman [mailto:mrw@windriver.com] > [...] > > So, while you indicate that a link-local address may not be able to > > reach all nodes on a subnet, isn't it also true that a subnet-local > > address may not be able to reach all of the nodes on a link? >[...] > The closest question you could > construct in practice is: "If a link has multiple subnet prefixes > assigned to it, and I source from a global address in one of them, and > the destination is a subnet-local multicast group, will another machine > on the same link, which does not have an address in the same prefix, > receive the packet." The answer is yes it will (so the answer to your > question is: no, not true). I'll try to answer from a different perspective. If the destination is a subnet-local multicast group, it may not reach all of the nodes on a link. This is because nodes, currently, do not even know of such a multicast group much less join it. In theory it should go to every node, I think. Is there something I've missed? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 22:58:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L5wx3c010866; Tue, 20 Aug 2002 22:58:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7L5wwdd010865; Tue, 20 Aug 2002 22:58:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L5wr3c010858 for ; Tue, 20 Aug 2002 22:58:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA13764 for ; Tue, 20 Aug 2002 22:59:04 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18583 for ; Tue, 20 Aug 2002 22:58:57 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7L5w9l02163; Wed, 21 Aug 2002 12:58:10 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7L5vtW07639; Wed, 21 Aug 2002 12:57:55 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "SEENYEN,GENE (HP-Australia,ex3)" cc: ipng@sunroof.eng.sun.com Subject: Re: About Link-Local address prefix. In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Aug 2002 12:57:55 +0700 Message-ID: <7637.1029909475@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 21 Aug 2002 13:20:30 +1000 From: "SEENYEN,GENE (HP-Australia,ex3)" Message-ID: | Does the /64 refer to the 10 MSB bits + the 54 bits which are all 0 Yes, the prefix length always counts bits from the leftmost in a 128 bit address, regardless of how many of those have known fixed values in any particular case. | Also why use either FE80::/10 or FE80::/64 as the Link local | address instead of having just one? It depends upon the context which is better. All addresses that are FE80::/10 are link local. So, if you are wanting to test whether an addr is LL or not, that's what you'd be using. On the other hand, a prefix assigned to (most) nets is a /64, so when assigning a LL prefix to a LAN (or other net) you need to assign the /64 (you can, if you like, think of this as being one subnet out of the LL space - except that it is the only one defined, none of the others are available for use, or would mean anything if they were). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 20 23:12:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L6CI3c010919; Tue, 20 Aug 2002 23:12:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7L6CI7o010918; Tue, 20 Aug 2002 23:12:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L6CD3c010911 for ; Tue, 20 Aug 2002 23:12:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA23528 for ; Tue, 20 Aug 2002 23:12:24 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23291 for ; Tue, 20 Aug 2002 23:12:14 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7L6BGl11300; Wed, 21 Aug 2002 13:11:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7L6AxW07743; Wed, 21 Aug 2002 13:10:59 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Margaret Wasserman cc: "Brian Zill" , "Charles E. Perkins" , ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <4.2.2.20020820163740.027d1e90@mail.windriver.com> References: <4.2.2.20020820163740.027d1e90@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Aug 2002 13:10:59 +0700 Message-ID: <7741.1029910259@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 20 Aug 2002 16:41:05 -0400 From: Margaret Wasserman Message-ID: <4.2.2.20020820163740.027d1e90@mail.windriver.com> | What surprised me is the assumption that a subnet scope would be "larger" | than a link-local scope. I've had experience running multiple subnets | on a single L2 link, but I have not had experience running a single | subnet across multiple L2 links. Let me try to answer this a different way. That is, while it is certainly possible to run multiple subnets over an L2, this doesn't make them have smaller scope than the L2. The nodes that are only in one of the subnets are that way by choice - they could be in any of them. Any packet on the link is available to all of the nodes connected to it (this is more or less the canonical definition of the link layer). So, you can't be connected to a link and be in a smaller scope, unless you're looking inside L2 (or lower) protocols, at L3 and above, the link is the basic unit. | So, while you indicate that a link-local address may not be able to | reach all nodes on a subnet, isn't it also true that a subnet-local | address may not be able to reach all of the nodes on a link? So, no, it is able to - though it may be that some of the nodes might not choose to receive it. On the other hand, a multi-link subnet (which as a concept takes some grasping, I'm not yet sure I'm convinced of the need) binds multiple links (unitary objects) into one L3 object. Here it is clear that it is possible to have internal divisions, and that one link would be a smaller thing than than a subnet. On the other hand, I'm not sure that I would treat the needs of multi-link subnets as being compelling enough to prefer DAD over DIID if there were other compelling arguments in favour of DIID. That's because I'm not sure I see multi-link as all that compelling without this extra issue. But, here I don't see compelling arguments for DIID, if anything, even without multi-link DAD seems like a better choice. Given that, then that DAD also doesn't shut the door on multi-link is just another factor in its favour. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 05:17:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LCHO3c012175; Wed, 21 Aug 2002 05:17:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LCHOXD012174; Wed, 21 Aug 2002 05:17:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LCHI3c012167 for ; Wed, 21 Aug 2002 05:17:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21813 for ; Wed, 21 Aug 2002 05:17:28 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10965 for ; Wed, 21 Aug 2002 06:17:28 -0600 (MDT) Received: from kenawang ([147.11.233.10]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA19819; Wed, 21 Aug 2002 05:16:55 -0700 (PDT) Message-Id: <4.2.2.20020821075348.02878b30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 21 Aug 2002 08:16:14 -0400 To: "Dave Thaler" From: Margaret Wasserman Subject: RE: DAD vs. DIID Cc: "Brian Zill" , "Charles E. Perkins" , In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC10738420A@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dave, I'm not talking about the limited way in which the "subnet-local" multicast scope works today, but about the definition of a subnet. The word "subnet" means a group of nodes that share a common global prefix, including subnet ID. The fact that we don't have a multicast mechanism to successfully reach this group of nodes doesn't change the definition of "subnet". So, a subnet may include all of the nodes on a single link -- this will be the most common case, where all of the nodes are generating addresses from a single set of RAs. A subnet may also include a subset of nodes on a single link, if there is more than one prefix in use on the link, and not all nodes use all of the prefixes. Iff we adopt the multi-link subnet proposal, a subnet may also include a set of nodes that share a subnet prefix across multiple links. Still without any requirement that the subnet contain all of the nodes on each link. I agree that it would be quite tricky to use an IPv6 multicast address to reach a particular subnet, given how multicast addresses are constructed. There is no way for a given node to determine whether a subnet-local multicast is intended for any of its subnets. Besides, as Pekka pointed out, none of the nodes on the link will have joined the subnet-local multicast group, so the traffic actually won't reach any of them. IPv4 did have a concept of subnet-local broadcast (i.e. 128.224.4.255), but the ability to address all of the nodes on a single subnet is apparently lacking in IPv6. I don't consider this a big problem, but we shouldn't pretend that "subnet-local" multicast is possible, since it isn't. Margaret At 07:37 PM 8/20/02 , Dave Thaler wrote: > > -----Original Message----- > > From: Margaret Wasserman [mailto:mrw@windriver.com] >[...] > > So, while you indicate that a link-local address may not be able to > > reach all nodes on a subnet, isn't it also true that a subnet-local > > address may not be able to reach all of the nodes on a link? > >Since the boundary of a zone goes through a node, not through a link >(ref: scoped addr arch doc), then no it is not true. The "subnet-local" > >scope contains all interfaces on the link regardless of what addresses >are on those interfaces. > >However, there are no subnet-local unicast addresses (only multicast >ones) >so the question is moot in practice. The closest question you could >construct in practice is: "If a link has multiple subnet prefixes >assigned to it, and I source from a global address in one of them, and >the destination is a subnet-local multicast group, will another machine >on the same link, which does not have an address in the same prefix, >receive the packet." The answer is yes it will (so the answer to your >question is: no, not true). > >-Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 06:30:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDUi3c012913; Wed, 21 Aug 2002 06:30:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LDUib8012912; Wed, 21 Aug 2002 06:30:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDUI3c012889 for ; Wed, 21 Aug 2002 06:30:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13571 for ; Wed, 21 Aug 2002 06:30:28 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01621 for ; Wed, 21 Aug 2002 07:30:27 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LDSOn05764; Wed, 21 Aug 2002 09:28:25 -0400 Message-Id: <200208211328.g7LDSOn05764@cichlid.adsl.duke.edu> To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: Message from itojun@iijlab.net of "Wed, 21 Aug 2002 07:11:35 +0900." <20020820221135.17D334B22@coconut.itojun.org> Date: Wed, 21 Aug 2002 09:28:24 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As one of the authors of the text being discussed, I can confirm that the intent for the "SHOULD NOT use deprecated address as source" was for "active opens" only, not on (say) passive opens. itojun@iijlab.net writes: > RFC2462 > page 3: > > in arbitrary communication is unrestricted. Later, an address becomes > > "deprecated" in anticipation that its current interface binding will > > become invalid. While in a deprecated state, the use of an address is > > discouraged, but not strictly forbidden. New communication (e.g., > > the opening of a new TCP connection) should use a preferred address > > when possible. A deprecated address should be used only by > > applications that have been using it and would have difficulty > > switching to another address without a service disruption. > the last sentence does not meet people's understand. append > ", or there is no other choice than to use deprecated address". > or, since this is introduction section, we shouldn't go into this > detail here. The introduction shouldn't/needn't be the definitive text. But if we can make it more clear, we should. How about changing: (e.g.,the opening of a new TCP connection) to (e.g., an active open of a new TCP connection) I'm assuming that "active open" vs. "passive open" terminology is well-understood (I think it's in RFC 1122). Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 06:54:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDsB3c013431; Wed, 21 Aug 2002 06:54:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LDsB10013430; Wed, 21 Aug 2002 06:54:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDs53c013423 for ; Wed, 21 Aug 2002 06:54:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10911 for ; Wed, 21 Aug 2002 06:54:15 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00068 for ; Wed, 21 Aug 2002 06:54:14 -0700 (PDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LDpjb06007; Wed, 21 Aug 2002 09:51:45 -0400 Message-Id: <200208211351.g7LDpjb06007@cichlid.adsl.duke.edu> To: Keith Moore cc: The IESG , RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com Subject: Re: Protocol Action: Default Address Selection for IPv6 to Proposed Standard In-Reply-To: Message from Keith Moore of "Thu, 15 Aug 2002 15:08:29 EDT." <200208151908.g7FJ8T000767@astro.cs.utk.edu> Date: Wed, 21 Aug 2002 09:51:45 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > wow. Having the document be approved by IESG is not a surprise, but > at the same time - the announcement is extremely misleading. > Serious problems with the entire idea of address selection were repeatedly > raised in WG discussions. At the very least this should have been reflected > in the document announcement. I guess you might understand how this happened. The writeup that eventually goes out is written up before the IESG actually formally considers the document. At the time of the writing, there didn't seem to be issues. :-) Note that it was the IESG that raised some issues, and a side-effect of that was that there was quite a lot of mailing list discussion on the point you mention. So yes, the writeup is inaccurate and should have been updated before going out. I.e., if I were writing it now, it would say something like: Working Group Summary There was rough consenus in the WG for this document and no issues were raised during the original Last Call. During IESG review, several issues were raised, in particular the question of whether temporary addresses should be chosen over public ones by default. Subsequent WG discussion voiced general concerns about address selection and the possible problems for applications that could result when IPv6 nodes must chose among multiple addresses, whose long-term stability or global usability cannot be depended on. This concern may be documented in more detail in future documents. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 06:57:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDvZ3c013454; Wed, 21 Aug 2002 06:57:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LDvXO0013453; Wed, 21 Aug 2002 06:57:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDvQ3c013446 for ; Wed, 21 Aug 2002 06:57:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20596 for ; Wed, 21 Aug 2002 06:57:35 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [202.232.15.92]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14323 for ; Wed, 21 Aug 2002 07:57:33 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EC9204B23; Wed, 21 Aug 2002 22:57:26 +0900 (JST) To: Thomas Narten Cc: ipng@sunroof.eng.sun.com In-reply-to: narten's message of Wed, 21 Aug 2002 09:28:24 -0400. <200208211328.g7LDSOn05764@cichlid.adsl.duke.edu> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Wed, 21 Aug 2002 22:57:26 +0900 Message-Id: <20020821135727.EC9204B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >How about changing: > (e.g.,the opening of a new TCP connection) >to > (e.g., an active open of a new TCP connection) >I'm assuming that "active open" vs. "passive open" terminology is >well-understood (I think it's in RFC 1122). it certainly make things better. i would like to see description in page 3 much shortened to avoid (possible) inconsistencies. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 07:34:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LEYI3c013499; Wed, 21 Aug 2002 07:34:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LEYIrw013498; Wed, 21 Aug 2002 07:34:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LEYC3c013491 for ; Wed, 21 Aug 2002 07:34:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18999 for ; Wed, 21 Aug 2002 07:34:22 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03877; Wed, 21 Aug 2002 08:34:20 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LEWCl06421; Wed, 21 Aug 2002 10:32:12 -0400 Message-Id: <200208211432.g7LEWCl06421@cichlid.adsl.duke.edu> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Wed, 14 Aug 2002 17:28:03 +0900." Date: Wed, 21 Aug 2002 10:32:12 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've incorporated trivial editorial nits to my local copy of the > draft, and I've not mentioned them in this response. Sounds good. > I agree. How about this (which is a total rewrite of abstract): > This document provides sockets APIs to support "advanced" IPv6 > applications, as a supplement to a separate specification, RFC 2553. > The expected applications include Ping, Traceroute, routing daemons > and the like, which typically use raw sockets to access IPv6 or ICMPv6 > header fields. This document proposes some portable interfaces for > applications that use raw sockets under IPv6. There are other > features of IPv6 that some applications will need to access: interface > identification (specifying the outgoing interface and determining the > incoming interface), IPv6 extension headers, and path MTU information. > This document provides API access to these features too. Additionally, > some extended interfaces to libraries for the "r" commands are > defined. The extension will provide better backward compatibility to > existing implementations that are not IPv6-capable. Works for me! > > General: it would be good to have a proper reference to the posix > > standards in the references section. I.e.: > >> 4.3BSD Reno sockets API in 1990. The reason is that these ancillary > >> data fields are part of the Posix.1g standard and should therefore be > >> adopted by most vendors. > Are you suggesting to add the POSIX standard in References explicitly? > Or are you suggesting to check the latest version of the standard and > to rewrite the text accordingly (if necessary)? Definitely suggesting the first. I'm asking about the second. I wonder, for example, whether someone familiar with the POSIX/Austin Group work has reviewed the document. My concern is that there may be some fairly trivial inconsistencies with this document and the basic API. It would be nice to try and fix those (if they exist). Can anyone speak to this point? > > Also, how does this align with the Austin group work and the revised > > basic API? Are the documents in sync with each other? I say this > > because the Basic API is apparently in alignment with the Austin Group > > work. It would probably be useful to have some text saying how this > > document relates to that standard. > Hmm, good point. As far as I know, there has been no effort to synch > the advanced API to other "official" standards. Also, rfc2292bis is > not as mature as rfc2553bis; 2292bis is a total revise of RFC 2292, > and backward compatibility is not provided. So, with the following > point: > > Early in the introduction, the document should say it is > > updating/replacing the RFC 2292. > I'd propose to add the following paragraph to Introduction: > This document is intended to replace RFC 2292 "Advanced Sockets API > for IPv6", February 1998. The revise is based on implementation > experiences of the previous RFC, as well as some additional > extensions that has been found as important throughout the IPv6 > deployment. Note, however, that this document is still > informational. Once the API specification becomes mature and is > deployed among implementations, it should be incorporated to official > standards, such as POSIX (refer to the document explicitly -if > necessary-). Generally looks good, but I might reword it a bit as: This document updates and replaces RFC 2292. This revision is based on implementation experience of the RFC 2292, as well as some additional extensions that have been found to be useful through the IPv6 deployment. Note, however, that further work on this document may still be needed. Once the API specification becomes mature and is deployed among implementations, it may be formally standardized by a more appropriate body, such as has been done with the Basic API [RFC XXX] > > Also, take a look at the most recent changes to the basic API. Do any > > spill over into this document? One change to the basic API that seems > > relevant to this one: > >> . More alignments with [3]: > >> - [3] does not contain protocol family definitions (PF_xxx). > >> Replaced PF_INET6 with AF_INET6, or removed as appropriate. > > This document still refernces PF_INET, etc. > Okay, I've changed PF_xxx to AF_xxx at least. I'm not sure if we need > more. Nor do I. That's why I'm thinking it would be good if someone familiar with the Austin work/basic API could review the document from this perspective (if this hasn't been done yet). > > I note that there are some new ICMP types that have been assigned that > > this document doesn't seem to reference (e.g., those greater than > > 138). Should they be added? > I don't think so. Since more and more new types will come, we need to > make a fixed point of "feature freeze". And, at least to me, the > newer types are either immature or less interesting to applications. OK. > >> We note that many of the functions and socket options defined in this > >> document may have error returns that are not defined in this > >> document. Many of these possible error returns will be recognized > >> only as implementations proceed. > > This might have been true the first time this document was > > produced. Is it still true today? > As I said above, rfc2292bis is not very mature yet. So, I think this > paragraph is still true, at least to some extent. How about > s/many/some/ here? OK > >> 5. Extensions to Socket Ancillary Data > >> > >> This specification uses ancillary data as defined in Posix.1g with > >> the following compatible extensions: > > should this ID also include text relative to the austin group work? > I'm not sure what this comment exactly means...does the proposed > change in Introduction answer to this comment? I'm asking whether at this point in time we should be referencing the posix.1g work as what we want to align with, or whether its the newer revision that has been formally adopted by the Austin Group. Presumably, they are not the same. > >> operation. Returning the received hop limit is useful for programs > >> such as Traceroute and for IPv6 applications that need to verify that > >> the received hop limit is 255 (e.g., that the packet has not been > >> forwarded). > > how does this help traceroute? Traceroute needs to set, not receive > > the ttl. > Actually, I had the same question before, and I slightly recall > someone explained the intention at that time. However, I don't have a > clear memory about it. I admit the description still seems odd. > So, I don't mind to remove traceroute as an example, though. This > feature is still useful for other purposed (as described just after > this part). Unless anyone else clarifies this, I'll remove the > traceroute usage. works for me. > >> To specify the outgoing traffic class value, just specify the control > >> information as ancillary data for sendmsg() or using setsockopt(). > >> Just like the hop limit value, the interpretation of the integer > >> traffic class value is > >> > >> x < -1: return an error of EINVAL > >> x == -1: use kernel default > >> 0 <= x <= 255: use x > >> x >= 256: return an error of EINVAL > > note that the terminology surrounding diffserv/traffic class has > > changed (see RFC 3260). Is the current API still OK? there are only 64 > > diffserv values now. (I think this is OK, but the authors should recheck). > I've asked this to itojun, who originally proposed this socket > option. Our decision is we should just go with RFC 2460 definitions > (not 3260). So, the current text will not need to be revised. OK. > >> ENXIO The interface specified by ipi6_ifindex does not exist > >> > >> ENETDOWN The interface specified by ipi6_ifindex is not enabled for > >> IPv6 use. > >> > > Indention not right. (too far to left) > Are you talking about the space between the keyrword "EXNIO" and its > description, etc? If so, I first must point out that this part is > aligned with the longest keyword (EADDRNOTAVAIL). I don't mind to > change the indentation policy, but is it really necessary? This is minor formatting issue. In the ID, the terms "ENXIO" and "ENETDOWN" are all the way at the left margin. But all the other text in the document is indented 3 spaces. This seems to be an exception here. > >> int inet6_opt_init(void *extbuf, size_t extlen); > >> > >> This function returns the number of bytes needed for the empty > >> extension header i.e. without any options. > > I don't understand this sentence. Does this then always return the > > same value? And doesn't an "empty" header require 0 bytes? Or is this > > actually "length remaining"? > > Actully, the "length" field is weird in subsequent usages to. Is it > > really a length, or an offset into the options? Calling it length is > > confusing. Is it too late to change this? > Yes, it always returns the same value (except -1 for errors). In our > implementation, the value is 2 (the length of the "next header" and > the "length" fields of an IPv6 option header), but I think the actual > value can be hidden from the caller. Right. If the function always returns the same value by definition, why return a value at all? > As shown in the usage examples in Section 23, the "length" value is > actually used as a kind of "offset." I don't think the current text > is confusing, but we can rewrite the description using the term > "offset". (It would not be too late, because the change will not > break compatibility to existing implementations). Do you think we > need the change? Personally, I think the term "offset" would be clearer since that is indeed what the variable seems to be holding.. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 07:35:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LEZr3c013518; Wed, 21 Aug 2002 07:35:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LEZrR4013517; Wed, 21 Aug 2002 07:35:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LEZj3c013510 for ; Wed, 21 Aug 2002 07:35:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00766 for ; Wed, 21 Aug 2002 07:35:55 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03317 for ; Wed, 21 Aug 2002 08:35:54 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7LEZm017440; Wed, 21 Aug 2002 10:35:48 -0400 (EDT) Message-Id: <200208211435.g7LEZm017440@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten cc: Keith Moore , The IESG , RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com Subject: Re: Protocol Action: Default Address Selection for IPv6 to Proposed Standard In-reply-to: (Your message of "Wed, 21 Aug 2002 09:51:45 EDT.") <200208211351.g7LDpjb06007@cichlid.adsl.duke.edu> Date: Wed, 21 Aug 2002 10:35:48 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I guess you might understand how this happened. The writeup that > eventually goes out is written up before the IESG actually formally > considers the document. At the time of the writing, there didn't seem > to be issues. :-) you're right, that does make sense... how soon I forget :) thanks for reassuring me that this discussion did not get ignored. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 07:42:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LEgt3c013550; Wed, 21 Aug 2002 07:42:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LEgs5d013549; Wed, 21 Aug 2002 07:42:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LEgn3c013542 for ; Wed, 21 Aug 2002 07:42:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11031 for ; Wed, 21 Aug 2002 07:42:59 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09443 for ; Wed, 21 Aug 2002 08:42:58 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LEdjR06644; Wed, 21 Aug 2002 10:39:51 -0400 Message-Id: <200208211439.g7LEdjR06644@cichlid.adsl.duke.edu> To: jarno.rajahalme@nokia.com cc: kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: Message from jarno.rajahalme@nokia.com of "Tue, 13 Aug 2002 20:25:17 +0300." <009CA59D1752DD448E07F8EB2F911757D3107D@esebe004.NOE.Nokia.com> Date: Wed, 21 Aug 2002 10:39:45 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > "The method by which the flow state is cleared from the IPv6 nodes > is to be defined by the flow state establishment method used to set > up the state. This implies that IPv6 nodes unable to classify a > packet to an existing flow SHOULD NOT establish any flow-specific > state unless so instructed by a flow state establishment > method. With some flow state establishment methods, signaling new > state simultaneously clearing the old state from the new path may be > sufficient. A mechanism with a sufficiently long timeout period > before reusing the Flow Label values can also be used." How does the above text relate to the idea (which I thought the WG was interested in) in allowing the Flow Label field to be used for load balancing (i.e., hash the src/dest/label to select the next-hop when there are more than one). Seems like load balancing might not be allowed by the above wording. Is that the intent? Note in the case of simple load balancing, there is no flow state establishment method. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 08:18:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LFIU3c013618; Wed, 21 Aug 2002 08:18:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LFIUAo013617; Wed, 21 Aug 2002 08:18:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LFIP3c013610 for ; Wed, 21 Aug 2002 08:18:25 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19155 for ; Wed, 21 Aug 2002 08:18:35 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18754 for ; Wed, 21 Aug 2002 09:18:33 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LFGMw06977; Wed, 21 Aug 2002 11:16:22 -0400 Message-Id: <200208211516.g7LFGMw06977@cichlid.adsl.duke.edu> To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: Message from Markku Savela of "Tue, 13 Aug 2002 18:26:45 +0300." <200208131526.SAA05910@burp.tkv.asdf.org> Date: Wed, 21 Aug 2002 11:16:21 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela writes: > As a consequence, and observing that others may not have chosen this > tactics, the code also defends plain ID, that is: if it sees a DAD for > address which contains one of my ID's, it will reply to the DAD as if > I had the address. I don't see any catastrophic failures resulting > from it. But I assume we are all in agreement that this is not supported by any of the relevant specs. It is not necessarily forbidden by any spec, but it is not suggested that this be done in any spec. Yours is the first implementation that I've heard that has done this. Note: one thing we could all be better about is defining just what "DAD vs. DIID" means. Some people seem to think that that DIID means "for every address, also create a link-local address and run DAD on it too." This in general, will achieve DIID. But this is not required by the specs today, and folks have consistently objected that requiring every address also be assigned a corresponding LL address is being unreasonable. There are also other ways of achieving DIID. There is also Markku's variant. One could also imagine modifying ND so that comparisons were done on the IID part alone (in some or all cases). But this has the issue of possibly not being backwards compatable with existing implementations. Some also seem to be saying (???) that if one runs DAD on all addresses, that's DIID. But I don't think so. That just means you are doing DAD on all addresses. You can still end up with different nodes using different addresses but sharing an IID (I'm not saying this is necessarily good/desirable, but it is not ruled out). So for those who are advocating some sort of DIID, please be very clear about what it is you are calling for. Just saying "I'm for DIID" isn't specific enough. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 08:18:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LFIu3c013628; Wed, 21 Aug 2002 08:18:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LFIt6X013627; Wed, 21 Aug 2002 08:18:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LFIn3c013620 for ; Wed, 21 Aug 2002 08:18:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29431 for ; Wed, 21 Aug 2002 08:18:59 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13184 for ; Wed, 21 Aug 2002 09:18:58 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LFH2j06987; Wed, 21 Aug 2002 11:17:02 -0400 Message-Id: <200208211517.g7LFH2j06987@cichlid.adsl.duke.edu> To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: Message from Markku Savela of "Wed, 14 Aug 2002 12:42:07 +0300." <200208140942.MAA07456@burp.tkv.asdf.org> Date: Wed, 21 Aug 2002 11:17:02 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The whole issue comes from the introduction of "privacy" and generated > addresses. Actually, not so. The issue can also comes up with DHCP-assigned addresses. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 08:31:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LFVg3c013696; Wed, 21 Aug 2002 08:31:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LFVgpp013695; Wed, 21 Aug 2002 08:31:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LFVa3c013688 for ; Wed, 21 Aug 2002 08:31:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22412 for ; Wed, 21 Aug 2002 08:31:46 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04756 for ; Wed, 21 Aug 2002 09:31:44 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA07185; Wed, 21 Aug 2002 08:31:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7LFVXc16431; Wed, 21 Aug 2002 08:31:33 -0700 X-mProtect: <200208211531> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQE9xEd; Wed, 21 Aug 2002 08:31:32 PDT Message-ID: <3D63B254.9A0E83B1@iprg.nokia.com> Date: Wed, 21 Aug 2002 08:31:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Zill CC: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Brian, As I wrote before, but perhaps buried in other text, I think that IP should only be concerned about the "subnet-local" concept, not the "link-local" concept, if we are to use those terms as distinguishable concepts. When the link-local addresses were being first discussed, I don't remember any discussion that suggested that a "link" should have a different extent than a "subnet". It seems to me that all IP-level protocols need to have "subnet-local" addressing, not the newer proposed definition for "link-local". As I tried to point out in my previous message, IP doesn't have any business messing around with details about how the subnet is actually constructed. Thus, to restate, I believe that "link-local" addresses are not required to traverse the entire extent of the physical medium on which a subnet is defined, then they are useless for IP protocols. Perhaps it would be better to rename these addresses (FE80::/10) to be called "subnet-local". Do you have examples of protocols that properly use "link-local" addresses instead of "subnet-local" protocols? It seems to me that DAD, multicast, router advertisements, and Mobile IP all need to have the "subnet-local" property, and I can't think of any network-layer use for the non-network-layer definition of "link-local". Regards, Charlie P. Brian Zill wrote: > > Hi Charlie, > > > I haven't studied the multi-link subnet draft. But, in order > > to be responsive to your note before taking that time... > > I guess we're just going to have to disagree about link-local vs. > subnet-local. These are two distinct scopes and should be treated as > such by the architecture. One shouldn't assume that because you can > reach a node via a global address in the same subnet prefix as you that > you can also reach it via a link-local address. "DIID" breaks this by > making the false assumption that these scopes are equivalent. > > The whole point of multi-link subnet routers is to allow multiple links, > of possibly different physical characteristics, MTUs, etc, to belong to > the same subnet. And to do it in an architecturally consistent way. A > multi-link subnet router is a real router that drops the hop count > between links. It leaves link-local addresses as unique on their link, > as it should. > > Maybe we should define unicast address prefixes for each scope as we > have for multicast, so there would be subnet-local unicast addresses. > That would allow people who want to do things on a subnet, rather than > link, basis to do so. > > > And, please don't forget the negative impact on home agent operation. > > You would have the same problem with "DIID" if the mobile node has a > large number of home addresses that differed in the IID part. As I > noted in my earlier mail, there are plenty of creative proposals for > using lots of IIDs per node, just as I suspect there are some for using > lots of prefixes per subnet. Let's not break the architecture here over > a optimization that has a lot of questionable assumptions in it. > > If we can't live with "DAD", then I'd much prefer we revise the whole > duplicate address detection mechanism. Currently DAD has two serious > flaws and one major inconvienience: It doesn't protect against duplicate > addresses on reconnected networks (something I would think would happen > a lot on some types of wireless links), it doesn't document a recourse > to take when your only address is a duplicate (retry with a random > address is the obvious solution, but that isn't standardized like EUI-64 > is), and it takes longer than we would like. > > --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 08:50:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LFoG3c013845; Wed, 21 Aug 2002 08:50:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LFoGXW013844; Wed, 21 Aug 2002 08:50:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LFo93c013837 for ; Wed, 21 Aug 2002 08:50:09 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22370 for ; Wed, 21 Aug 2002 08:50:19 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09133 for ; Wed, 21 Aug 2002 09:50:18 -0600 (MDT) Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.05) id 17hXkP-000DkK-00; Wed, 21 Aug 2002 16:50:17 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA55170; Wed, 21 Aug 2002 16:50:14 +0100 Message-ID: <3D63B6D1.CEA7B7BE@hursley.ibm.com> Date: Wed, 21 Aug 2002 17:50:41 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Thomas Narten CC: jarno.rajahalme@nokia.com, kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <200208211439.g7LEdjR06644@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's a matter of interpretation (you could ask the same question about some ways of using the flow label for diffserv classification). In my interpretation, a server load balancing mechanism that recognizes and caches new labels is a flow state establishment method. Brian Thomas Narten wrote: > > > "The method by which the flow state is cleared from the IPv6 nodes > > is to be defined by the flow state establishment method used to set > > up the state. This implies that IPv6 nodes unable to classify a > > packet to an existing flow SHOULD NOT establish any flow-specific > > state unless so instructed by a flow state establishment > > method. With some flow state establishment methods, signaling new > > state simultaneously clearing the old state from the new path may be > > sufficient. A mechanism with a sufficiently long timeout period > > before reusing the Flow Label values can also be used." > > How does the above text relate to the idea (which I thought the WG was > interested in) in allowing the Flow Label field to be used for load > balancing (i.e., hash the src/dest/label to select the next-hop when > there are more than one). Seems like load balancing might not be > allowed by the above wording. Is that the intent? > > Note in the case of simple load balancing, there is no flow state > establishment method. > > Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 11:04:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LI4K3c014329; Wed, 21 Aug 2002 11:04:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LI4Jdk014328; Wed, 21 Aug 2002 11:04:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LI4E3c014321 for ; Wed, 21 Aug 2002 11:04:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28046 for ; Wed, 21 Aug 2002 11:04:24 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27300 for ; Wed, 21 Aug 2002 12:04:23 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LI2Hx01655; Wed, 21 Aug 2002 14:02:18 -0400 Message-Id: <200208211802.g7LI2Hx01655@cichlid.adsl.duke.edu> To: "Charles E. Perkins" cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: Message from "Charles E. Perkins" of "Wed, 21 Aug 2002 08:31:32 PDT." <3D63B254.9A0E83B1@iprg.nokia.com> Date: Wed, 21 Aug 2002 14:02:17 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Charles E. Perkins" writes: > When the link-local addresses were being first discussed, > I don't remember any discussion that suggested that a > "link" should have a different extent than a "subnet". Note: the term "subnet-local" has a specific meaning with regards to multicast. Subnet-local != link-local (per addrarch). For unicast, things are less clear. That is, for unicast, there is link-local, site-local, and global. That's it. There is no "subnet-local" definition per se (note that RFC 2460 does not define the term "subnet"). My assumption has been that when folks talk about scoping, they generally assume the scope boundaries for unicast and multicast are the same (i.e., site-local multicast corresponds to a site in unicast). This may not be a requirement per se, but I would think that having two different notions of what the "site" boundaries were would at best be confusing. But looking at addr-arch, I see it contains the wording: > Currently IPv6 continues the IPv4 model that a subnet prefix is > associated with one link. Multiple subnet prefixes may be assigned > to the same link. So this could lead one to conclude that unicast "subnet" means "link". And link has a *very* specific meaning (per 2460): link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. So, per the current specs, I conclude that in the case of unicast, "subnet" is equivalent to "link". Personally, I much prefer that "link" be used then because it's much more precise, and because "subnet" in multicast terms is different than "subnet" in unicast terms. This is confusing. > Do you have examples of protocols that properly use "link-local" > addresses instead of "subnet-local" protocols? It seems to me that > DAD, multicast, router advertisements, and Mobile IP all need to > have the "subnet-local" property, and I can't think of any > network-layer use for the non-network-layer definition of > "link-local". I think we are in agreement so long as "subnet-local" == "link-local". Again, I think it would be better to stick with the latter terminology, as it is more clearly defined, and at present, the two terms seem to be equivalent. If you look at the revised addr-arch document, however, it contains the words: 2.7 Multicast Addresses ... subnet-local scope is given a different and larger value than link-local to enable possible support for subnets that span multiple links. But this leaves open the question about whether "subnet" == "link" is really still supposed to be the case with unicast addresses. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 11:07:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LI7c3c014354; Wed, 21 Aug 2002 11:07:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LI7c3r014353; Wed, 21 Aug 2002 11:07:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LI7W3c014346 for ; Wed, 21 Aug 2002 11:07:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16528 for ; Wed, 21 Aug 2002 11:07:42 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27042 for ; Wed, 21 Aug 2002 12:07:41 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LI5UF01672; Wed, 21 Aug 2002 14:05:30 -0400 Message-Id: <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> To: Brian E Carpenter cc: jarno.rajahalme@nokia.com, kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: Message from Brian E Carpenter of "Wed, 21 Aug 2002 17:50:41 +0200." <3D63B6D1.CEA7B7BE@hursley.ibm.com> Date: Wed, 21 Aug 2002 14:05:30 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It's a matter of interpretation (you could ask the same question > about some ways of using the flow label for diffserv > classification). It would be far better if different readers didn't have to think too hard about this. General comment. IMO, what is needed is a very short and simple specification that says exactly what hosts (and routers) are supposed to implement today. And *nothing* more. In particular, no weasle wording that requires laywerish reading of the text to decide what the intent is or what may or may not be allowed in the future. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 12:37:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LJbf3c014616; Wed, 21 Aug 2002 12:37:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LJbeM3014615; Wed, 21 Aug 2002 12:37:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LJbX3c014608 for ; Wed, 21 Aug 2002 12:37:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28043 for ; Wed, 21 Aug 2002 12:37:43 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13524 for ; Wed, 21 Aug 2002 12:37:42 -0700 (PDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7LJZke02247; Wed, 21 Aug 2002 15:35:47 -0400 Message-Id: <200208211935.g7LJZke02247@cichlid.adsl.duke.edu> To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: Message from itojun@iijlab.net of "Wed, 21 Aug 2002 22:57:26 +0900." <20020821135727.EC9204B23@coconut.itojun.org> Date: Wed, 21 Aug 2002 15:35:46 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > >How about changing: > > (e.g.,the opening of a new TCP connection) > >to > > (e.g., an active open of a new TCP connection) > >I'm assuming that "active open" vs. "passive open" terminology is > >well-understood (I think it's in RFC 1122). > it certainly make things better. i would like to see description > in page 3 much shortened to avoid (possible) inconsistencies. I'd prefer not shortening this text, as it is explanatory/introductory for the novice reader. But, it should not be the definitive text. Looking further in the document, there is specific text that says: > 5.5.4. Address Lifetime Expiry > > A preferred address becomes deprecated when its preferred lifetime > expires. A deprecated address SHOULD continue to be used as a source > address in existing communications, but SHOULD NOT be used in new > communications if an alternate (non-deprecated) address is available > and has sufficient scope. IP and higher layers (e.g., TCP, UDP) MUST > continue to accept datagrams destined to a deprecated address since a > deprecated address is still a valid address for the interface. An > implementation MAY prevent any new communication from using a > deprecated address, but system management MUST have the ability to > disable such a facility, and the facility MUST be disabled by > default. > > An address (and its association with an interface) becomes invalid > when its valid lifetime expires. An invalid address MUST NOT be used > as a source address in outgoing communications and MUST NOT be > recognized as a destination on a receiving interface. I would prefer clarifying the text here. How about changing the first paragraph as follows: A preferred address becomes deprecated when its preferred lifetime expires. A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used to initiate new communications if an alternate (non-deprecated) address of sufficient scope can easily be used instead. Note that the feasibility of initiating new communication using a non-deprecated address may be an application-specific decision, as only the application may have knowledge about whether the (now) deprecated address was (or still is) in use by the application. IP and higher layers (e.g., TCP, UDP) MUST continue to accept and process datagrams destined to a deprecated address as normal since a deprecated address is still a valid address for the interface. In the case of TCP, this means TCP SYN segments sent to a deprecated address are responded to using the deprecated address as a source address in the corresponding SYN-ACK (if the connection would otherwise be allowed). An implementation MAY prevent any new communication from using a deprecated address, but system management MUST have the ability to disable such a facility, and the facility MUST be disabled by default. Would this address your concerns? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 14:46:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LLkX3c014917; Wed, 21 Aug 2002 14:46:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LLkXLo014916; Wed, 21 Aug 2002 14:46:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LLkR3c014909 for ; Wed, 21 Aug 2002 14:46:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02430 for ; Wed, 21 Aug 2002 14:46:37 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11118 for ; Wed, 21 Aug 2002 15:46:35 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id AAA31478; Thu, 22 Aug 2002 00:46:24 +0300 Date: Thu, 22 Aug 2002 00:46:24 +0300 Message-Id: <200208212146.AAA31478@burp.tkv.asdf.org> From: Markku Savela To: narten@us.ibm.com CC: ipng@sunroof.eng.sun.com In-reply-to: <200208211516.g7LFGMw06977@cichlid.adsl.duke.edu> (message from Thomas Narten on Wed, 21 Aug 2002 11:16:21 -0400) Subject: Re: DAD vs. DIID References: <200208211516.g7LFGMw06977@cichlid.adsl.duke.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Thomas Narten > > Note: one thing we could all be better about is defining just what > "DAD vs. DIID" means. I had my implementation before the term "DIID" was coined. I suppose, in the effect, if I have the "id defense mode" turned on, it is very close. The main fact is that my version is just an implementation based on the autoconfigure RFC, taking the allowed DAD optimization (= do DAD on link-local, combine id with announced prefixes without doing DAD on those combinations). Some want to disallow the DAD optimization. I would like to present another proposal: ******************************************** leave autoconfigure basicly RFC as it is now ******************************************** Autoconfigururation deals only with an ID that is assigned to host and is combined with announced prefixes (A=1). If host does this, it must do DAD on link-local and doing DAD other addresses based on same ID is not required. I think autoconfiguration should be the normal mode how IPv6 nodes get their addresses. Anything else is to be treated *exceptional*, and such other mechanisms have to define their own ways of avoiding address collisions. For example, - if address is not link local, they could do DAD on corresponding link local, or - they could assign the ID from a range that is not used by the autoconfigure (put asides id range 1-1024 or somesuch for the purpose). - they guarantee that the prefix part of the address is never announced on the link with A=1 (this also guarantees that address never going to collide with autoconfigured addresses). - just hope you are lucky - etc. I have explained in other messages, that the "Do DAD on every combined address" has some unpleasant features, caused by the "delayed fail mode". This adds complexity, compared to the "optimized DAD", where you do it once, and if passed, you don't have to worry about it. Choosing this does not require a change in any stacks that do DAD on all addresses (KAME, Microsoft). It only affects abnormal address configurations. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 16:26:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LNQl3c015103; Wed, 21 Aug 2002 16:26:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LNQlV4015102; Wed, 21 Aug 2002 16:26:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LNQe3c015095 for ; Wed, 21 Aug 2002 16:26:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04562 for ; Wed, 21 Aug 2002 16:26:51 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [202.232.15.92]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12127 for ; Wed, 21 Aug 2002 16:26:50 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 31FD74B22; Thu, 22 Aug 2002 08:26:44 +0900 (JST) To: Thomas Narten Cc: ipng@sunroof.eng.sun.com In-reply-to: narten's message of Wed, 21 Aug 2002 15:35:46 -0400. <200208211935.g7LJZke02247@cichlid.adsl.duke.edu> 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: need clarification of "deprecated" address From: itojun@iijlab.net Date: Thu, 22 Aug 2002 08:26:44 +0900 Message-Id: <20020821232644.31FD74B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> it certainly make things better. i would like to see description >> in page 3 much shortened to avoid (possible) inconsistencies. >I'd prefer not shortening this text, as it is explanatory/introductory >for the novice reader. But, it should not be the definitive text. hmm. as long as there's no inconsistency, i'm okay. >Looking further in the document, there is specific text that says: > >> 5.5.4. Address Lifetime Expiry >> >I would prefer clarifying the text here. How about changing the first >paragraph as follows: > > A preferred address becomes deprecated when its preferred lifetime > expires. A deprecated address SHOULD continue to be used as a > source address in existing communications, but SHOULD NOT be used > to initiate new communications if an alternate (non-deprecated) > address of sufficient scope can easily be used instead. Note that > the feasibility of initiating new communication using a > non-deprecated address may be an application-specific decision, as > only the application may have knowledge about whether the (now) > deprecated address was (or still is) in use by the application. > IP and higher layers (e.g., TCP, UDP) MUST continue to accept and > process datagrams destined to a deprecated address as normal since > a deprecated address is still a valid address for the > interface. In the case of TCP, this means TCP SYN segments sent to > a deprecated address are responded to using the deprecated address > as a source address in the corresponding SYN-ACK (if the > connection would otherwise be allowed). An implementation MAY > prevent any new communication from using a deprecated address, but > system management MUST have the ability to disable such a > facility, and the facility MUST be disabled by default. > >Would this address your concerns? looks great! itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 22:47:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M5l73c015636; Wed, 21 Aug 2002 22:47:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7M5l7dv015635; Wed, 21 Aug 2002 22:47:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M5kv3c015618 for ; Wed, 21 Aug 2002 22:46:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA06261 for ; Wed, 21 Aug 2002 22:47:07 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11205 for ; Wed, 21 Aug 2002 23:47:07 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 21 Aug 2002 22:47:07 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Aug 2002 22:47:06 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 Aug 2002 22:47:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 21 Aug 2002 22:47:06 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Wed, 21 Aug 2002 22:46:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD vs. DIID Date: Wed, 21 Aug 2002 19:31:26 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384218@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID thread-index: AcJJDJSlOPzD29Z+TkGCj2brAyJh5QAdkEiw From: "Dave Thaler" To: "Margaret Wasserman" Cc: "Charles E. Perkins" , X-OriginalArrivalTime: 22 Aug 2002 05:46:54.0603 (UTC) FILETIME=[521C9DB0:01C2499F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7M5kw3c015620 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Margaret Wasserman [mailto:mrw@windriver.com] [...] > I'm not talking about the limited way in which the "subnet-local" > multicast scope works today, but about the definition of a subnet. > > The word "subnet" means a group of nodes that share a common global > prefix, including subnet ID. The fact that we don't have a multicast > mechanism to successfully reach this group of nodes doesn't change > the definition of "subnet". > > So, a subnet may include all of the nodes on a single link -- this will > be the most common case, where all of the nodes are generating addresses > from a single set of RAs. > > A subnet may also include a subset of nodes on a single link, if there > is more than one prefix in use on the link, and not all nodes use all > of the prefixes. All of them have interfaces in the subnet scope zone, regardless of whether or not they use addresses in the subnet prefix. > Iff we adopt the multi-link subnet proposal, a subnet may also include > a set of nodes that share a subnet prefix across multiple links. Still > without any requirement that the subnet contain all of the nodes on > each link. But still true that all of those nodes have interfaces in the subnet scope zone regardless of what addresses they have. > I agree that it would be quite tricky to use an IPv6 multicast address > to reach a particular subnet, given how multicast addresses are > constructed. There is no way for a given node to determine whether > a subnet-local multicast is intended for any of its subnets. I disagree. Nodes don't have subnets, nodes have interfaces and addresses. There is a way for a given node to determine whether a subnet-local multicast is intended for any of its interfaces, which is that it's intended for it if the node has joined that subnet-local multicast address on a given interface. > Besides, > as Pekka pointed out, none of the nodes on the link will have joined > the subnet-local multicast group, so the traffic actually won't reach > any of them. Eh? It will reach all of them, and will be received by the IPv6 layer as long as it has joined the group. If it hasn't joined the group, then it's not supposed to be received by that node. That's why it's called multicast, not broadcast. > IPv4 did have a concept of subnet-local broadcast (i.e. 128.224.4.255), > but the ability to address all of the nodes on a single subnet is > apparently lacking in IPv6. I don't consider this a big problem, Here we agree in concept, but I would nitpick with your terminology. IPv4 does not have a concept of "subnet-local" (as defined by the scoped Addrarch) broadcast, it's really network-prefix-local broadcast, and IPv6 doesn't have such a thing. > but > we shouldn't pretend that "subnet-local" multicast is possible, since > it isn't. "Subnet-local" multicast is indeed possible. "Network-prefix-local" multicast is not possible. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 21 22:47:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M5l63c015633; Wed, 21 Aug 2002 22:47:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7M5l6Dt015632; Wed, 21 Aug 2002 22:47:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M5kv3c015619 for ; Wed, 21 Aug 2002 22:46:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA20981 for ; Wed, 21 Aug 2002 22:47:08 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11209 for ; Wed, 21 Aug 2002 23:47:07 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 21 Aug 2002 22:47:07 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 21 Aug 2002 22:47:06 -0700 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Aug 2002 22:47:06 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 21 Aug 2002 22:47:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 21 Aug 2002 22:47:06 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Wed, 21 Aug 2002 22:46:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD vs. DIID Date: Wed, 21 Aug 2002 19:46:32 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384219@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID thread-index: AcJJKATA+EhtFLpuTi2W4t/2W5kW8QAXAMog From: "Dave Thaler" To: "Charles E. Perkins" Cc: X-OriginalArrivalTime: 22 Aug 2002 05:46:55.0009 (UTC) FILETIME=[525A9110:01C2499F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7M5kw3c015621 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] [...] > As I wrote before, but perhaps buried in other text, > I think that IP should only be concerned about the > "subnet-local" concept, not the "link-local" concept, > if we are to use those terms as distinguishable concepts. > When the link-local addresses were being first discussed, > I don't remember any discussion that suggested that a > "link" should have a different extent than a "subnet". > > It seems to me that all IP-level protocols need to > have "subnet-local" addressing, not the newer proposed > definition for "link-local". It's defined today as non-routed. You're proposing to route link-local addresses, so you're the one with the "new proposed definition" :) > As I tried to point out > in my previous message, IP doesn't have any business > messing around with details about how the subnet is > actually constructed. Here we disagree. A multi-link subnet router does that (as do IPv4 ARP proxies today, for that matter). > Thus, to restate, I believe that "link-local" addresses > are not required to traverse the entire extent of the > physical medium on which a subnet is defined, then they > are useless for IP protocols. Could not parse the above. Maybe you meant "I believe that IF ..."? ^^ > Perhaps it would be > better to rename these addresses (FE80::/10) to be > called "subnet-local". That's what your position boils down to, yes. (I pointed this out on this list prior to last IETF.) At this point I am undecided on this issue, other than deciding that if fe80::/10 is not subnet-local, DAD is cleaner than DIID. > Do you have examples of protocols that properly use > "link-local" addresses instead of "subnet-local" > protocols? It seems to me that DAD, multicast, > router advertisements, and Mobile IP all need to > have the "subnet-local" property, and I can't think > of any network-layer use for the non-network-layer > definition of "link-local". For unicast link-local addresses, I can't either right offhand, although I can't say one might not exist. I agree that DAD on *non-link-local* addresses needs to have the subnet-local property, but unfortunately DAD is currently defined using multicast scope 2 rather than 3 as it should have been. This means workarounds are required, but this is orthogonal to whether fe80::/10 should be left as link-local or changed to be subnet-local. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 00:34:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M7Y63c015983; Thu, 22 Aug 2002 00:34:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7M7Y5uK015982; Thu, 22 Aug 2002 00:34:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M7Xx3c015975 for ; Thu, 22 Aug 2002 00:34:00 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA15313 for ; Thu, 22 Aug 2002 00:34:08 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26652 for ; Thu, 22 Aug 2002 01:34:07 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7M7Xgc12364; Thu, 22 Aug 2002 10:33:42 +0300 Date: Thu, 22 Aug 2002 10:33:42 +0300 (EEST) From: Pekka Savola To: Dave Thaler cc: Margaret Wasserman , "Charles E. Perkins" , Subject: RE: DAD vs. DIID In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC107384218@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 21 Aug 2002, Dave Thaler wrote: > > Besides, > > as Pekka pointed out, none of the nodes on the link will have joined > > the subnet-local multicast group, so the traffic actually won't reach > > any of them. > > Eh? It will reach all of them, ^^^^^^^^^^^^^^^^^ > and will be received by the IPv6 layer > as long as it has joined the group. If it hasn't joined the group, then > it's not supposed to be received by that node. That's why it's called > multicast, not broadcast. Please compare this to your message a few days back (and remember the context of all-nodes -multicast addresses): >> So, while you indicate that a link-local address may not be able to >> reach all nodes on a subnet, isn't it also true that a subnet-local >> address may not be able to reach all of the nodes on a link? [...] > The answer is yes it will (so the answer to your > question is: no, not true). If all nodes in the subnet have not joined the subnet-local multicast group, all nodes in the subnet will not be reachable through it. There's some bad miscommunication here. Therefore if you specify "all-nodes-in-subnet" multicast address, it is completely useless for that purpose unless you create some very dirty hacks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 00:38:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M7cm3c016019; Thu, 22 Aug 2002 00:38:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7M7cmMK016018; Thu, 22 Aug 2002 00:38:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M7cf3c016011 for ; Thu, 22 Aug 2002 00:38:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16046 for ; Thu, 22 Aug 2002 00:38:50 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03823 for ; Thu, 22 Aug 2002 00:38:49 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7M7cZt50964; Thu, 22 Aug 2002 16:38:36 +0900 (JST) Date: Thu, 22 Aug 2002 16:38:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt In-Reply-To: <200208211432.g7LEWCl06421@cichlid.adsl.duke.edu> References: <200208211432.g7LEWCl06421@cichlid.adsl.duke.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 134 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 21 Aug 2002 10:32:12 -0400, >>>>> Thomas Narten said: >> I agree. How about this (which is a total rewrite of abstract): (snip) > Works for me! Okay, I'll replace abstract with the proposed one. >> Are you suggesting to add the POSIX standard in References explicitly? >> Or are you suggesting to check the latest version of the standard and >> to rewrite the text accordingly (if necessary)? > Definitely suggesting the first. Okay. I'll do that like in the basic API draft. > I'm asking about the second. I wonder, for example, whether someone > familiar with the POSIX/Austin Group work has reviewed the document. > My concern is that there may be some fairly trivial inconsistencies > with this document and the basic API. It would be nice to try and fix > those (if they exist). Can anyone speak to this point? Hmm, I think there are no more "trivial" inconsistencies, but I'll hear from others for a while. > Generally looks good, but I might reword it a bit as: > This document updates and replaces RFC 2292. This revision is > based on implementation experience of the RFC 2292, as well as > some additional extensions that have been found to be useful > through the IPv6 deployment. Note, however, that further work on > this document may still be needed. Once the API specification > becomes mature and is deployed among implementations, it may be > formally standardized by a more appropriate body, such as has been > done with the Basic API [RFC XXX] Okay. I'll put it to the draft. >> >> 5. Extensions to Socket Ancillary Data >> >> >> >> This specification uses ancillary data as defined in Posix.1g with >> >> the following compatible extensions: >> > should this ID also include text relative to the austin group work? >> I'm not sure what this comment exactly means...does the proposed >> change in Introduction answer to this comment? > I'm asking whether at this point in time we should be referencing the > posix.1g work as what we want to align with, or whether its the newer > revision that has been formally adopted by the Austin > Group. Presumably, they are not the same. Okay, perhaps we need comments from experts on this area. Or is it possible to get the latest work of the Austin Group on the web? >> >> ENXIO The interface specified by ipi6_ifindex does not exist >> >> >> >> ENETDOWN The interface specified by ipi6_ifindex is not enabled for >> >> IPv6 use. >> >> >> > Indention not right. (too far to left) > This is minor formatting issue. In the ID, the terms "ENXIO" and > "ENETDOWN" are all the way at the left margin. But all the other > text in the document is indented 3 spaces. This seems to be an > exception here. Ah, I see. I'll fix them. (actually, this is not the only exception. The document also has the same indentation violation in sections 1, 4, 5, 12, 17, and 18. I'll fix them too. >> >> int inet6_opt_init(void *extbuf, size_t extlen); >> >> >> >> This function returns the number of bytes needed for the empty >> >> extension header i.e. without any options. >> > I don't understand this sentence. Does this then always return the >> > same value? And doesn't an "empty" header require 0 bytes? Or is this >> > actually "length remaining"? >> > Actully, the "length" field is weird in subsequent usages to. Is it >> > really a length, or an offset into the options? Calling it length is >> > confusing. Is it too late to change this? >> Yes, it always returns the same value (except -1 for errors). In our >> implementation, the value is 2 (the length of the "next header" and >> the "length" fields of an IPv6 option header), but I think the actual >> value can be hidden from the caller. > Right. If the function always returns the same value by definition, > why return a value at all? Because the actual value may be different among implementations, and the value is transparently used in the succeeding calls to inet6_opt_append(), etc. I believe even an implementation that does not return a constant value without breaking the specification. >> As shown in the usage examples in Section 23, the "length" value is >> actually used as a kind of "offset." I don't think the current text >> is confusing, but we can rewrite the description using the term >> "offset". (It would not be too late, because the change will not >> break compatibility to existing implementations). Do you think we >> need the change? > Personally, I think the term "offset" would be clearer since that is > indeed what the variable seems to be holding.. So, perhaps we can improve the wording by saying - the return value of inet6_opt_xxx is expected to be used transparently, and the application should not care about the exact value. - in a sequence of calling inet6_opt_xxx, the 'prevlen' arguments are used as a kind of offset. but, again, the application should not care about the exact value. - (additionally) the return value of inet6_opt_init() may or may not be constant. in any case, the application should not make any assumption on the actual return value. Also, if necessary, I don't mind to change the parameter name 'prevlen' to (e.g.) 'offset'. Does this make sense? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 02:18:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M9In3c016424; Thu, 22 Aug 2002 02:18:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7M9In89016423; Thu, 22 Aug 2002 02:18:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M9If3c016416 for ; Thu, 22 Aug 2002 02:18:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00270 for ; Thu, 22 Aug 2002 02:18:52 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06513 for ; Thu, 22 Aug 2002 02:18:52 -0700 (PDT) Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.05) id 17ho77-00062m-00; Thu, 22 Aug 2002 10:18:49 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA49968; Thu, 22 Aug 2002 10:18:49 +0100 Message-ID: <3D64AC95.1C7A11F6@hursley.ibm.com> Date: Thu, 22 Aug 2002 11:19:17 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Thomas Narten CC: jarno.rajahalme@nokia.com, kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > > It's a matter of interpretation (you could ask the same question > > about some ways of using the flow label for diffserv > > classification). > > It would be far better if different readers didn't have to think too > hard about this. General comment. IMO, what is needed is a very short > and simple specification that says exactly what hosts (and routers) > are supposed to implement today. And *nothing* more. That is what it is supposed to be. I'm particularly concerned that people building hardware classifiers should know what to do. > In particular, no > weasle wording that requires laywerish reading of the text to decide > what the intent is or what may or may not be allowed in the future. It is not supposed to be weasel words. It's supposed to be a minimal set of conditions. Personally, I was quite happy with the -02 version, but I don't think any of the recent changes are harmful. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 05:48:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MCme3c016946; Thu, 22 Aug 2002 05:48:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MCmeOP016945; Thu, 22 Aug 2002 05:48:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MCmY3c016938 for ; Thu, 22 Aug 2002 05:48:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17370 for ; Thu, 22 Aug 2002 05:48:45 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20752 for ; Thu, 22 Aug 2002 06:48:27 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7MClml02286; Thu, 22 Aug 2002 19:47:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7MClbW13424; Thu, 22 Aug 2002 19:47:37 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: Brian E Carpenter , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> References: <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Aug 2002 19:47:37 +0700 Message-ID: <13422.1030020457@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 21 Aug 2002 14:05:30 -0400 From: Thomas Narten Message-ID: <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> [quoting Brian] | > It's a matter of interpretation (you could ask the same question | > about some ways of using the flow label for diffserv | > classification). Actually, my take would be that what the text is attempting to restrict is the forming of state - not using the flow label. So, using (a hash of) the flow label for choosing among alternate equivalent routes would be just fine - as no state is being left behind when that's done. The issue is creating some kind of state (memory if you like) when there's no defined way to delete it. | It would be far better if different readers didn't have to think too | hard about this. True. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 05:58:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MCwO3c016978; Thu, 22 Aug 2002 05:58:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MCwOEJ016977; Thu, 22 Aug 2002 05:58:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MCwI3c016970 for ; Thu, 22 Aug 2002 05:58:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19217 for ; Thu, 22 Aug 2002 05:58:29 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18996 for ; Thu, 22 Aug 2002 06:56:41 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7MCtkl02557; Thu, 22 Aug 2002 19:55:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7MCtaW13435; Thu, 22 Aug 2002 19:55:36 +0700 (ICT) From: Robert Elz To: "Charles E. Perkins" cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <3D63B254.9A0E83B1@iprg.nokia.com> References: <3D63B254.9A0E83B1@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Aug 2002 19:55:36 +0700 Message-ID: <13433.1030020936@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 21 Aug 2002 08:31:32 -0700 From: "Charles E. Perkins" Message-ID: <3D63B254.9A0E83B1@iprg.nokia.com> | As I tried to point out | in my previous message, IP doesn't have any business | messing around with details about how the subnet is | actually constructed. I think there's a chasm between uses of the term "subnet" occuring here. The subnet in the sense that is bring proposed in multi-link-subnets is something that's being defined by the IP layer - IP has never used the term in the ISO sense, that's what "link" means. As I understand it, here a "subnet" is simply "the collection of nodes that can be addressed using the same prefix" (where that prefix is not an aggregate of others). That is, one might define prefix::/64 and address a collection of nodes out of that prefix, that's the subnet. Traditional IP has said that the nodes so addressed all have to be connected to the same link. But that's certainly for the IP layer to define, it isn't fixed in concrete by someone else. Whether that traditional definition should be changed or not is the topic of the multi-link-subnet draft (I think) - and I'm not taking a position on that here - but we certainly need to make sure that we're all using the terminology the same way. kre ps: there is absolutely no need to have a concept of "subnet local" addressing, or scope, in order to make any of this work, if making it work was to happen. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 06:07:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MD7d3c017017; Thu, 22 Aug 2002 06:07:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MD7d6i017016; Thu, 22 Aug 2002 06:07:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MD7X3c017009 for ; Thu, 22 Aug 2002 06:07:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01144 for ; Thu, 22 Aug 2002 06:07:44 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07421 for ; Thu, 22 Aug 2002 06:07:44 -0700 (PDT) Received: from kenawang ([147.11.233.21]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA02788; Thu, 22 Aug 2002 06:06:52 -0700 (PDT) Message-Id: <4.2.2.20020822082847.028a19a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 22 Aug 2002 09:01:39 -0400 To: "Dave Thaler" From: Margaret Wasserman Subject: RE: DAD vs. DIID Cc: "Charles E. Perkins" , In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC107384218@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > but > > we shouldn't pretend that "subnet-local" multicast is possible, since > > it isn't. > >"Subnet-local" multicast is indeed possible. >"Network-prefix-local" multicast is not possible. While I'm not sure that I agree with the terminology, since this is a change from the common use of the word "subnet", and doesn't really agree with the use of the term "subnet ID" in the addrarch, I now understand your distinction. I don't think that we should overload the term "subnet" in this way, so we should probably change one of these terms. Using your terminology (I hope)... A "subnet" is defined to be a scope that encompasses one or more links. It can be as small as a single link, or as large as a whole site. The definition of a "subnet" is not related to how network prefixes are configured on those links and/or nodes. In particular, it has no special relationship to the "subnet ID" of a unicast address. In IPv6, we have the ability to send subnet-local multicast traffic, but not subnet-local unicast traffic. The point of "multi-link subnets" (let me know if I'm wrong) is to allow a network prefix to span multiple links. So, really, we are talking about "multi-link network prefixes", not subnets at all. In order to make "multi-link network prefixes" work properly with mechanisms such as DAD and RA, we need to forward certain link-local multicast packets between those links. This makes "multi-link network prefixes" more messy and complex than they would be if they'd been planned into the architecture from the beginning. Folks have discussed the fact that subnet-local multicast addresses should really have been used for DAD, RA, etc. But, this doesn't necessarily make sense. If you buy-in to the concept of "multi-link subnet prefixes", you'd want these messages to span all of the links that are intended to share a set of network prefixes. It isn't clear to me that this is the same set of links that would comprise a single multicast subnet, but you could probably define it that way, if desired. But, even if it would help to use subnet-local multicast, we couldn't change this now for two reasons: 1 - These mechanisms are already widely implemented using link-local multicast addresss. 2 - We haven't defined the equivalent of a subnet-local all-nodes multicast address and/or a subnet-local solicited-nodes multicast address. So, we don't currently have the means to reach the right sets of nodes at the subnet-local scope. The addrarch, ND and autoconf RFCs currently make the architectural assumption that a full unicast network prefix (site-local and/or global prefix PLUS subnet ID) will only span a single link, which is, apparently, in no way related to what scope a subnet-local multicast packet will span. Do you agree? So, really, the question is: Do we want to modify the IPv6 architecture so that a single unicast network prefix can span more than one link? By definition, a subnet already spans multiple links. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 06:12:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MDCa3c017062; Thu, 22 Aug 2002 06:12:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MDCald017061; Thu, 22 Aug 2002 06:12:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MDCU3c017054 for ; Thu, 22 Aug 2002 06:12:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22483 for ; Thu, 22 Aug 2002 06:12:41 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14437 for ; Thu, 22 Aug 2002 06:10:43 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7MD9el03072; Thu, 22 Aug 2002 20:09:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7MD9OW13448; Thu, 22 Aug 2002 20:09:24 +0700 (ICT) From: Robert Elz To: Markku Savela cc: narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <200208212146.AAA31478@burp.tkv.asdf.org> References: <200208212146.AAA31478@burp.tkv.asdf.org> <200208211516.g7LFGMw06977@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Aug 2002 20:09:24 +0700 Message-ID: <13446.1030021764@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 22 Aug 2002 00:46:24 +0300 From: Markku Savela Message-ID: <200208212146.AAA31478@burp.tkv.asdf.org> | The main fact is that my version is just an implementation based on | the autoconfigure RFC, taking the allowed DAD optimization (= do DAD | on link-local, combine id with announced prefixes without doing DAD on | those combinations). The problem is that this only works if no-one is allowed to create addresses that don't have link local - otherwise the order in which the addresses are created makes a race condition wrt DAD. | Some want to disallow the DAD optimization. I would like to present | another proposal: | | ******************************************** | leave autoconfigure basicly RFC as it is now | ******************************************** That doesn't work. Something has to solve the problem that has been identified. | I think autoconfiguration should be the normal mode how IPv6 nodes get | their addresses. Autoconfiguration has always been planned as just one way that addresses can be allocated. It may turn out to be the most common, but it certainly shouldn't yet be being elevated to the status of being the "normal" way. | - just hope you are lucky Well, I'm not sure if you were in Yokohama, but Steve Deering started to make a proposal along those lines. It was going to be essential if the DIID proposal was adopted (I'll let Steve explain it, and why, if he feels inclined) - it kind of just fell by the wayside, when DAD was preferred by just about everyone in the room. | Choosing this does not require a change in any stacks that do DAD on | all addresses (KAME, Microsoft). It only affects abnormal address | configurations. Obviously you can define "abnormal" so as anything affected fits, but certainly KAME (and I suspect Microsoft) would need to change, as it allows addresses that aren't based upon a LL address to be defined. Such addresses are subject to DAD, so that's OK, they won't be duplicates, but the IID part isn't defended against attempts to re-use it in other addresses (different prefix). They would need to change. It is true that there's a tiny chance that when a new prefix is advertised, a node will fail to be able to assign it, because some other node had already assigned itself that prefix with the node's IID (the chance of this in reality seem about as great as the chances of duplicate 3041 addresses, assuming good random number generators, but never mind). DIID would avoid that tiny possibility. On the other hand, DIID forbids subnets being merged into one link, if they happen to have nodes assigned with the same IID (like "1"). There is no problem with uniqueness of the addresses, the prefixes differ, but because the IIDs don't, DIID would prohibit them from being used on the same link. I know which of those I believe is the more likely to actually happen in practice, and which is the more serious if it does happen - and it isn't the first in either case. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 06:46:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MDko3c017179; Thu, 22 Aug 2002 06:46:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MDkniL017178; Thu, 22 Aug 2002 06:46:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MDki3c017171 for ; Thu, 22 Aug 2002 06:46:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01403 for ; Thu, 22 Aug 2002 06:46:53 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27185 for ; Thu, 22 Aug 2002 06:46:52 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA32302; Thu, 22 Aug 2002 16:45:22 +0300 Date: Thu, 22 Aug 2002 16:45:22 +0300 Message-Id: <200208221345.QAA32302@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: narten@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <13446.1030021764@munnari.OZ.AU> (message from Robert Elz on Thu, 22 Aug 2002 20:09:24 +0700) Subject: Re: DAD vs. DIID References: <200208212146.AAA31478@burp.tkv.asdf.org> <200208211516.g7LFGMw06977@cichlid.adsl.duke.edu> <13446.1030021764@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > > | The main fact is that my version is just an implementation based on > | the autoconfigure RFC, taking the allowed DAD optimization (= do DAD > | on link-local, combine id with announced prefixes without doing DAD on > | those combinations). > > The problem is that this only works if no-one is allowed to create > addresses that don't have link local - otherwise the order in which > the addresses are created makes a race condition wrt DAD. It can be made to work, if those who want to define addresses without corresponding link local, take care of not tresspassing the addresses generated by autoconfigure process. I listed some examples of approaches. "DIID" or equivalent is one possible apporach, but I'm not proposing proposing that. I just want to keep the autoconfigure DAD optimization as allowed. Other address configuration MUST take that into account. > Obviously you can define "abnormal" so as anything affected fits, but > certainly KAME (and I suspect Microsoft) would need to change, as it > allows addresses that aren't based upon a LL address to be defined. Yes, my stack allows defining any address manually. I don't code programs that pretend to be more clever than the user. I assume if the user wants some specific address, then he/she will get it (if it passes DAD). In manual configuration I assume user KNOWS from that the address will not collide with autoconfigured (as a root you can always shoot your foot). > Such addresses are subject to DAD, so that's OK, they won't be duplicates, > but the IID part isn't defended against attempts to re-use it in other > addresses (different prefix). I'm not proposing defending plain ID part (that is just an option that is available). > On the other hand, DIID forbids subnets being merged into one link, if > they happen to have nodes assigned with the same IID (like "1"). There > is no problem with uniqueness of the addresses, the prefixes differ, but > because the IIDs don't, DIID would prohibit them from being used on the > same link. If you have two subnets with different prefixes. Apparently you then have a router on both subnets which announce their prefixes. When you merge the subnets, ALL nodes will see both routers and will autoconfigure both prefixes with all of their addresses. Yes, in this case if two nodes happen to have same id, doing DAD on all addresses would detect the collision. But, you are hosed anyway, as those same nodes are also using the same link local address (they have same id, they are on same link => both have fe80::id, and Neighbor discovery breaks totally for them...). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 06:49:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MDnj3c017199; Thu, 22 Aug 2002 06:49:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MDnik7017198; Thu, 22 Aug 2002 06:49:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MDnd3c017191 for ; Thu, 22 Aug 2002 06:49:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21361 for ; Thu, 22 Aug 2002 06:49:49 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20365 for ; Thu, 22 Aug 2002 07:49:45 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA32325; Thu, 22 Aug 2002 16:49:37 +0300 Date: Thu, 22 Aug 2002 16:49:37 +0300 Message-Id: <200208221349.QAA32325@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: narten@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <13446.1030021764@munnari.OZ.AU> (message from Robert Elz on Thu, 22 Aug 2002 20:09:24 +0700) Subject: Re: DAD vs. DIID References: <200208212146.AAA31478@burp.tkv.asdf.org> <200208211516.g7LFGMw06977@cichlid.adsl.duke.edu> <13446.1030021764@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk a clarification... > Yes, in this case if two nodes happen to have same id, doing DAD on > all addresses would detect the collision. But, you are hosed anyway, > as those same nodes are also using the same link local address (they > have same id, they are on same link => both have fe80::id, and > Neighbor discovery breaks totally for them...). Naturally, if the id=1 is not used in autoconfiguration, then there is no problem, since neither host combines the announced prefixes with this particular id. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 07:11:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MEAx3c017274; Thu, 22 Aug 2002 07:10:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MEAxJq017273; Thu, 22 Aug 2002 07:10:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MEAq3c017266 for ; Thu, 22 Aug 2002 07:10:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08826 for ; Thu, 22 Aug 2002 07:11:02 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15224 for ; Thu, 22 Aug 2002 07:11:01 -0700 (PDT) Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.05) id 17hsfr-000A1K-00; Thu, 22 Aug 2002 15:10:59 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA63364; Thu, 22 Aug 2002 15:10:57 +0100 Message-ID: <3D64F10D.969CDB75@hursley.ibm.com> Date: Thu, 22 Aug 2002 16:11:25 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Robert Elz CC: Thomas Narten , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> <13422.1030020457@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Wed, 21 Aug 2002 14:05:30 -0400 > From: Thomas Narten > Message-ID: <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> > > [quoting Brian] > | > It's a matter of interpretation (you could ask the same question > | > about some ways of using the flow label for diffserv > | > classification). > > Actually, my take would be that what the text is attempting to restrict > is the forming of state - not using the flow label. So, using (a hash of) > the flow label for choosing among alternate equivalent routes would be > just fine - as no state is being left behind when that's done. The issue > is creating some kind of state (memory if you like) when there's no defined > way to delete it. Well yes, although I've not been sure from the start of this discussion why that is any business of *this* working group. Worrying about that really belongs to whatever WG standardizes a specific use of the label. All we need to do, imho, is establish the appropriate boundary conditions, and that is what the current text aims to do. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 08:53:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MFrm3c017381; Thu, 22 Aug 2002 08:53:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MFrmIq017380; Thu, 22 Aug 2002 08:53:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MFrg3c017373 for ; Thu, 22 Aug 2002 08:53:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09861 for ; Thu, 22 Aug 2002 08:53:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01546 for ; Thu, 22 Aug 2002 09:53:52 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA01020; Thu, 22 Aug 2002 08:53:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7MFrpk30258; Thu, 22 Aug 2002 08:53:51 -0700 X-mProtect: <200208221553> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8UaTnj; Thu, 22 Aug 2002 08:53:49 PDT Message-ID: <3D65090B.871E6BEC@iprg.nokia.com> Date: Thu, 22 Aug 2002 08:53:47 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID References: <3D63B254.9A0E83B1@iprg.nokia.com> <13433.1030020936@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Robert, Robert Elz wrote: > Date: Wed, 21 Aug 2002 08:31:32 -0700 > From: "Charles E. Perkins" > Message-ID: <3D63B254.9A0E83B1@iprg.nokia.com> > > | As I tried to point out > | in my previous message, IP doesn't have any business > | messing around with details about how the subnet is > | actually constructed. > ................... > As I understand it, here a "subnet" is simply "the collection of nodes > that can be addressed using the same prefix" (where that prefix is not > an aggregate of others). That is the meaning I have been using. That is the meaning which is useful for IP. However, I would typically allow for a subnet to be an aggregate of other subnets. In which case, I would define a link-local address to be local to the longest prefix (not having subaggregated subnets). With this definition, the link-local address is again useful for IP. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 09:23:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MGNP3c017476; Thu, 22 Aug 2002 09:23:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MGNPqs017475; Thu, 22 Aug 2002 09:23:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MGNJ3c017468 for ; Thu, 22 Aug 2002 09:23:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09605 for ; Thu, 22 Aug 2002 09:23:30 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22217 for ; Thu, 22 Aug 2002 10:23:28 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 22 Aug 2002 09:23:27 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Aug 2002 09:23:27 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 22 Aug 2002 09:23:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD vs. DIID Date: Thu, 22 Aug 2002 09:23:27 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA807D1FA14@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcJJ4tR+DuRoB/ovSaCTZ8njGi4eQAAFUC2Q From: "Richard Draves" To: "Markku Savela" , Cc: , X-OriginalArrivalTime: 22 Aug 2002 16:23:27.0372 (UTC) FILETIME=[3EC6ACC0:01C249F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7MGNJ3c017469 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, my stack allows defining any address manually. I don't > code programs that pretend to be more clever than the user. I > assume if the user wants some specific address, then he/she > will get it (if it passes DAD). In manual configuration I > assume user KNOWS from that the address will not collide with > autoconfigured (as a root you can always shoot your foot). This doesn't make sense. Manually-configured addresses the ones that most need DAD, because humans are the part of the system that is most likely to screw up and inadvertently configure a duplicate. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 11:08:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MI8f3c017805; Thu, 22 Aug 2002 11:08:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MI8e9Y017804; Thu, 22 Aug 2002 11:08:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MI8Z3c017797 for ; Thu, 22 Aug 2002 11:08:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27119 for ; Thu, 22 Aug 2002 11:08:45 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25008 for ; Thu, 22 Aug 2002 12:08:43 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id VAA32613; Thu, 22 Aug 2002 21:08:40 +0300 Date: Thu, 22 Aug 2002 21:08:40 +0300 Message-Id: <200208221808.VAA32613@burp.tkv.asdf.org> From: Markku Savela To: richdr@microsoft.com CC: kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <7695E2F6903F7A41961F8CF888D87EA807D1FA14@red-msg-06.redmond.corp.microsoft.com> (richdr@microsoft.com) Subject: Re: DAD vs. DIID References: <7695E2F6903F7A41961F8CF888D87EA807D1FA14@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Richard Draves" > > Yes, my stack allows defining any address manually. I don't > > code programs that pretend to be more clever than the user. I > > assume if the user wants some specific address, then he/she > > will get it (if it passes DAD). In manual configuration I > > assume user KNOWS from that the address will not collide with > > autoconfigured (as a root you can always shoot your foot). > > This doesn't make sense. Manually-configured addresses the ones that > most need DAD, because humans are the part of the system that is most > likely to screw up and inadvertently configure a duplicate. Umm.. I specifically said: "if it passes DAD". What other tests I'm supposed to do when a user manually configures full address for the node? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 11:21:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MILe3c017843; Thu, 22 Aug 2002 11:21:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MILeJl017842; Thu, 22 Aug 2002 11:21:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MILY3c017835 for ; Thu, 22 Aug 2002 11:21:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01287 for ; Thu, 22 Aug 2002 11:21:45 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28345 for ; Thu, 22 Aug 2002 12:21:44 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 22 Aug 2002 11:21:43 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Aug 2002 11:21:43 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 22 Aug 2002 11:21:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD vs. DIID Date: Thu, 22 Aug 2002 11:21:48 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEE5A@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD vs. DIID Thread-Index: AcJKBvmlAE9aY8GwQhO3Vdjss7zheAAAVZKA From: "Richard Draves" To: "Markku Savela" Cc: , , X-OriginalArrivalTime: 22 Aug 2002 18:21:43.0260 (UTC) FILETIME=[C44141C0:01C24A08] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7MILZ3c017836 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Yes, my stack allows defining any address manually. I don't > > > code programs that pretend to be more clever than the user. I > > > assume if the user wants some specific address, then he/she > > > will get it (if it passes DAD). In manual configuration I > > > assume user KNOWS from that the address will not collide with > > > autoconfigured (as a root you can always shoot your foot). > > > > This doesn't make sense. Manually-configured addresses the > ones that > > most need DAD, because humans are the part of the system > that is most > > likely to screw up and inadvertently configure a duplicate. > > Umm.. I specifically said: "if it passes DAD". What other > tests I'm supposed to do when a user manually configures full > address for the node? You say "I assume the user KNOWS" and "as a root you can always shoot your foot". I don't understand the details of your implementation, but from your description it sounds like you are assuming a knowledgeable user and if the user is wrong then the user is screwed. My point is that assuming users behave correctly is bad design. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 22 11:42:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MIgo3c018195; Thu, 22 Aug 2002 11:42:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MIgnVJ018194; Thu, 22 Aug 2002 11:42:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MIgi3c018187 for ; Thu, 22 Aug 2002 11:42:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08301 for ; Thu, 22 Aug 2002 11:42:54 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28250 for ; Thu, 22 Aug 2002 12:42:53 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id VAA32666; Thu, 22 Aug 2002 21:42:50 +0300 Date: Thu, 22 Aug 2002 21:42:50 +0300 Message-Id: <200208221842.VAA32666@burp.tkv.asdf.org> From: Markku Savela To: richdr@microsoft.com CC: ipng@sunroof.eng.sun.com In-reply-to: <7695E2F6903F7A41961F8CF888D87EA8063CEE5A@red-msg-06.redmond.corp.microsoft.com> (richdr@microsoft.com) Subject: Re: DAD vs. DIID References: <7695E2F6903F7A41961F8CF888D87EA8063CEE5A@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Richard Draves" > You say "I assume the user KNOWS" and "as a root you can always shoot > your foot". I don't understand the details of your implementation, but > from your description it sounds like you are assuming a knowledgeable > user and if the user is wrong then the user is screwed. My point is that > assuming users behave correctly is bad design. A bit off topic, but as a Linux user who occasionally is forced to use Microsoft products... Yes, I have painfully experienced the philosophy: "user doesn't know anything, program knows better", and have hard time turning a lot of automation off the applications, before they become usable. :-) However, back to topic... ...at least in my view, the normal IPv6 way is the "autoconfiguration", especially for clueless users. I consider manual configuration of address to be rather extreme rare case, which normal users don't need to worry about. If this is not true, one of rather important IPv6 design goals has failed! My point is that autoconfiguration with DAD optimization has been in RFC for long time. Anyone designing alternate address configuration mechanisms should take (and should have taken) this fact into design. To get forward on this, can we go through other existing address configuration mechanisms, and see how they can avoid colliding with *autoconfigured* addresses. - user manually configures address (avoidance: just hope you are lucky :-) - DHCP (avoidance suggestions: (a) don't advertise prefix with A=1 on the link, all addressess are from DHCP or manual. (b) have two prefixes on the link, advertise only one with A=1, and give DCHP addresses from the other (c) allocate DHCP address with ID range such that is not used by the default autoconfigure (should not be difficult to find). I don't know others at the moment. In my view, the "collision avoidance" policy can be locally agreed on the site (or for a link). Taylor it to the local needs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 00:17:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7N7Hr3c020529; Fri, 23 Aug 2002 00:17:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7N7HrKA020528; Fri, 23 Aug 2002 00:17:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7N7Hm3c020521 for ; Fri, 23 Aug 2002 00:17:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13792 for ; Fri, 23 Aug 2002 00:17:57 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA06885 for ; Fri, 23 Aug 2002 01:17:55 -0600 (MDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7N7HuV18086 for ; Fri, 23 Aug 2002 10:17:56 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 Aug 2002 10:17:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 23 Aug 2002 10:17:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text Date: Fri, 23 Aug 2002 10:17:53 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198137@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcJJIN5xGyn5q8/TTVe6m9aRXOycBwBUh8/Q To: Cc: , , , , X-OriginalArrivalTime: 23 Aug 2002 07:17:54.0134 (UTC) FILETIME=[32A8AF60:01C24A75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7N7Hm3c020522 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Current text has the following paragraph in section 2 (Introduction): "The minimum level of IPv6 flow support consists of labeling the flows. IPv6 source nodes can label known flows (e.g. TCP connections, RTP streams), even if the node itself would not require any flow- specific treatment. Doing this enables load spreading and receiver oriented resource reservations, for example. Requirements for flow labeling are given in section 4." >From the above it should be clear that the intent of the draft is to explicitly allow for load balancing, or "load spreading". Currently, the text in "Terminology and Definitions" defining "flow state establishment method" includes "algorithmic" methods for establishing flow state. The problem with this is that load balancing does not need any flow-specific state, but state per interface (this state could be algorithmically generated, but it is not flow-specific state). Indeed, it would be rather dangerous if a router would create new flow-specific state for every different packet header it is forwarding. To make the draft clear and explicit, I think we need to remove the algorithmic flow state establishment method, and maybe clearly state somewhere that load balancing does not need flow-specific state. As far as I recall, the only motivation to add the algorithmic definition was to allow for load spreading. After these changes the draft would (still) define what we want, but there would be no room for multiple interpretations. Regards, Jarno > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: 21. elokuuta 2002 17:40 > To: Rajahalme Jarno (NRC/Helsinki) > Cc: kre@munnari.OZ.AU; brian@hursley.ibm.com; ipng@sunroof.eng.sun.com > Subject: Re: Flow label draft issues & new text > > > > "The method by which the flow state is cleared from the IPv6 nodes > > is to be defined by the flow state establishment method used to set > > up the state. This implies that IPv6 nodes unable to classify a > > packet to an existing flow SHOULD NOT establish any flow-specific > > state unless so instructed by a flow state establishment > > method. With some flow state establishment methods, signaling new > > state simultaneously clearing the old state from the new path may be > > sufficient. A mechanism with a sufficiently long timeout period > > before reusing the Flow Label values can also be used." > > How does the above text relate to the idea (which I thought the WG was > interested in) in allowing the Flow Label field to be used for load > balancing (i.e., hash the src/dest/label to select the next-hop when > there are more than one). Seems like load balancing might not be > allowed by the above wording. Is that the intent? > > Note in the case of simple load balancing, there is no flow state > establishment method. > > Thomas > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 01:16:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7N8Gb3c020661; Fri, 23 Aug 2002 01:16:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7N8GZ4Z020660; Fri, 23 Aug 2002 01:16:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7N8GT3c020653 for ; Fri, 23 Aug 2002 01:16:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19458 for ; Fri, 23 Aug 2002 01:16:38 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28276 for ; Fri, 23 Aug 2002 02:16:13 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7N8FUl04005; Fri, 23 Aug 2002 15:15:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7N7n0W21713; Fri, 23 Aug 2002 14:49:00 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: Thomas Narten , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: <3D64F10D.969CDB75@hursley.ibm.com> References: <3D64F10D.969CDB75@hursley.ibm.com> <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> <13422.1030020457@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 14:49:00 +0700 Message-ID: <21711.1030088940@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 22 Aug 2002 16:11:25 +0200 From: Brian E Carpenter Message-ID: <3D64F10D.969CDB75@hursley.ibm.com> | Well yes, although I've not been sure from the start of this discussion | why that is any business of *this* working group. Even before I deleted your quote from my earlier message, I wasn't sure what the "that" which shouldn't be this WG's business was supposed to be. Once again, as I understand it, the point is to prevent nodes from gathering state about flows that they have no setup/protocol/definition of (which is needed, because there's no way to flush that). A rule like this, one which applies in the absence of any flow setup, can't really go in some flow specification doc, can it? So, it can't really be specified by diffserv, intserv, mpls, or anyone else who may have an interest in the flow label. They can specify how to use it when the protocol they define is being used, but they can't really specify how to not use it when it isn't. That is, you wouldn't want intserv telling diffserv that the flow label can't be used like foobar, would you? The general prohibition needs to be in the general flow label spec. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 01:16:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7N8GM3c020651; Fri, 23 Aug 2002 01:16:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7N8GLYW020650; Fri, 23 Aug 2002 01:16:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7N8GG3c020643 for ; Fri, 23 Aug 2002 01:16:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19452 for ; Fri, 23 Aug 2002 01:16:25 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12406 for ; Fri, 23 Aug 2002 01:16:18 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7N8FWl04026; Fri, 23 Aug 2002 15:15:32 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7N8FNW21740; Fri, 23 Aug 2002 15:15:23 +0700 (ICT) From: Robert Elz To: Markku Savela cc: narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <200208221345.QAA32302@burp.tkv.asdf.org> References: <200208221345.QAA32302@burp.tkv.asdf.org> <200208212146.AAA31478@burp.tkv.asdf.org> <200208211516.g7LFGMw06977@cichlid.adsl.duke.edu> <13446.1030021764@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 15:15:23 +0700 Message-ID: <21738.1030090523@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 22 Aug 2002 16:45:22 +0300 From: Markku Savela Message-ID: <200208221345.QAA32302@burp.tkv.asdf.org> | It can be made to work, if those who want to define addresses without | corresponding link local, take care of not tresspassing the addresses | generated by autoconfigure process. Yes, it can be made to work. But as things are now, it doesn't just work, and no finessing of the definitions will make it so. Some implementations have to change. The question is which. | "DIID" or equivalent is one possible apporach, but I'm not proposing | proposing that. I just want to keep the autoconfigure DAD optimization | as allowed. Other address configuration MUST take that into account. But they haven't, because no-one really understood what that meant before. The docs don't make it explicit, and if you don't understand the problem (which I think no-one did initially), you're not going to go and do the extra work to implement it. So, we clearly need to amend the docs. Now we understand more about what that optimisation really means is required, it is understandable that people are questioning its benefits, isn't it? And the general opinion seems to be that the optimisation is just too costly, and the benefits it produces not great enough, that it just isn't worth the bother, and the easiest simplest, and cleanest solution is simply to recognise that we made a mistake, we attempted to optimise before we had things correct, and that was wrong - delete the optimisation and get things correct. And DIIDD isn't just one possible approach, for the optimisation to work, DIIDD, or something with the same effect, is required. That is, if I am allowed to configure addresses without DAD, and I want some assurance that they won't be duplicates, I have to be certain that the IID isn't in use by any other node, for any purpose at all. To get that I need DIIDD. How it is implemented wouldn't be crucial, but the functionality must be there. | In manual configuration I assume user KNOWS from that the | address will not collide with autoconfigured (as a root you can always | shoot your foot). This is a particularly bad assumption - though I believe you mean that the user will suffer the consequences by not getting the address assigned if a mistake is made. But you really shouldn't be writing off manually configured addresses as a weird special case, I kind of suspect that most servers will get that kind of address, as having addresses that just randomly change whenever the hardware is upgraded isn't a solution that works. | I'm not proposing defending plain ID part (that is just an option that | is available). It is the only option (other than "just ignore the problem") that actually works. | If you have two subnets with different prefixes. Apparently you then | have a router on both subnets which announce their prefixes. When you | merge the subnets, ALL nodes will see both routers and will | autoconfigure both prefixes with all of their addresses. Again, you keep assuming that autoconf is being used. It *isn't*. Other nodes on the link are doing autoconf, the ones I'm concerned about aren't. | Yes, in this case if two nodes happen to have same id, doing DAD on | all addresses would detect the collision. But, you are hosed anyway, | as those same nodes are also using the same link local address (they | have same id, they are on same link => both have fe80::id, and | Neighbor discovery breaks totally for them...). msa@burp.tkv.asdf.org said: | a clarification... | Naturally, if the id=1 is not used in autoconfiguration, then there is no | problem, since neither host combines the announced prefixes with this | particular id. But let's assume the id isn't one, but is 206:5bff:feda:45ad (that happens to be the low 64 bits of an IPv6 address for my laptop). When I'm home, I can use that address, or I can plug in a wireless card (I have one of those 100 wired/802.11 wireless hubs, that merges them all together). When I'm using wireless, the natural IID would be different - but if I allow that, when I switch from wireless to wired (or perhaps more likely, when I unplug the wire, and go wireless) all my connections will break. So, what I want to do, is just move the IID from the wired interface to the wireless one. Note how much it looks like a normal auto-configured address? All this probably works OK if I start from the wired IID (which the one above is), but if I happened to start from the wireless one, and then switch to wired, and since I am wired, I pop the wireless card, and plug that into another system ... now that other system can't get my global address, it can and should fail, but it can still get its LL address (I won't be using the magic IID for LL addresses, my wired card will have its own auto-configured LL, my wireless will have its own, I don't run connections from LL addresses, so I don't care how frequently those things alter). On the new laptop, the one that now has the wireless card, I can easily configure a new global address, either using a different IID, or using a different prefix (in fact, if I have multiple prefixes, it is quite possible that it managed to autoconfig its address in some of them, as I might have only needed to retain one for my purposes - and even if I didn't, I could just add an extra prefix to the net so there would certainly be a global prefix that I'm not using (since I switched to using configured addresses, I will have disabled autoconf). All in all requiring IIDs to be unique on a link (any of the IIDs) imposes too many restrictions on operation of the net. Its benefit is tiny (the packet benefit isn't worth counting, the possibility of suddenly not being able to get a new address is too miniscule to worry about). Always do DAD, no optimisation allowed, is the best approach. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 01:17:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7N8H43c020674; Fri, 23 Aug 2002 01:17:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7N8H3Is020673; Fri, 23 Aug 2002 01:17:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7N8Gt3c020666 for ; Fri, 23 Aug 2002 01:16:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19524 for ; Fri, 23 Aug 2002 01:17:05 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27457 for ; Fri, 23 Aug 2002 02:16:11 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7N8FVl04012; Fri, 23 Aug 2002 15:15:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7N7hjW21706; Fri, 23 Aug 2002 14:43:45 +0700 (ICT) From: Robert Elz To: Charlie Perkins cc: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <3D65090B.871E6BEC@iprg.nokia.com> References: <3D65090B.871E6BEC@iprg.nokia.com> <3D63B254.9A0E83B1@iprg.nokia.com> <13433.1030020936@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 14:43:45 +0700 Message-ID: <21704.1030088625@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 22 Aug 2002 08:53:47 -0700 From: Charlie Perkins Message-ID: <3D65090B.871E6BEC@iprg.nokia.com> | That is the meaning I have been using. | That is the meaning which is useful for IP. Yes, but in this case, IP certainly does have a role in "messing around with the details of how the subnet is actually constructed" as it is IP that is defining the thing. | However, I would typically allow for a subnet to be | an aggregate of other subnets. I'm not opposing that, I just don't want to think about what it would mean for this right now (I suspect, probably nothing). | In which case, I would | define a link-local address to be local to the longest | prefix (not having subaggregated subnets). With this | definition, the link-local address is again useful for IP. As long as we're going to keep the term "link local" I think it really needs to be in some way related to a link. And I think addresses that only work on a link (are never routed) are useful to IP. I suspect that things are getting stuck on the concept of requiring routing to reach a node whose address would have (IPv4 world, initial IPv6 too) have made one assume that it was necessarily on the same link - that is, it has the same prefix as I have. I'm still unsure whether we need such a thing, I guess I should go back and read the multi-link subnet draft again, and see if there's enough there to inspire me (the why, not the how). But I certainly don't see it as being fundamentally opposed to the nature of IP for the "one prefix implies one link" rule to be abolished. Really, while it was sort of there in theory, IPv4 never enforced that anyway, it was not at all uncommon for a router to carve a piece out of a prefix that applied to a link, and route packets to nodes in that piece (implementing it on the link using proxy-arp). It seems that this is just being recognised now, rather than silently tolerated (and with that, the need for proxy-ND removed). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 04:09:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NB9X3c020969; Fri, 23 Aug 2002 04:09:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NB9XGC020968; Fri, 23 Aug 2002 04:09:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NB9Q3c020961 for ; Fri, 23 Aug 2002 04:09:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19664 for ; Fri, 23 Aug 2002 04:09:35 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16546 for ; Fri, 23 Aug 2002 05:09:35 -0600 (MDT) Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.05) id 17iCJp-000CRO-00; Fri, 23 Aug 2002 12:09:33 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA64944; Fri, 23 Aug 2002 12:09:33 +0100 Message-ID: <3D661807.80077AD4@hursley.ibm.com> Date: Fri, 23 Aug 2002 13:09:59 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Robert Elz CC: Thomas Narten , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <3D64F10D.969CDB75@hursley.ibm.com> <200208211805.g7LI5UF01672@cichlid.adsl.duke.edu> <13422.1030020457@munnari.OZ.AU> <21711.1030088940@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Thu, 22 Aug 2002 16:11:25 +0200 > From: Brian E Carpenter > Message-ID: <3D64F10D.969CDB75@hursley.ibm.com> > > | Well yes, although I've not been sure from the start of this discussion > | why that is any business of *this* working group. > > Even before I deleted your quote from my earlier message, I wasn't sure > what the "that" which shouldn't be this WG's business was supposed to be. > > Once again, as I understand it, the point is to prevent nodes from > gathering state about flows that they have no setup/protocol/definition > of (which is needed, because there's no way to flush that). > > A rule like this, one which applies in the absence of any flow setup, > can't really go in some flow specification doc, can it? So, it can't > really be specified by diffserv, intserv, mpls, or anyone else who may > have an interest in the flow label. > > They can specify how to use it when the protocol they define is being > used, but they can't really specify how to not use it when it isn't. > That is, you wouldn't want intserv telling diffserv that the flow label > can't be used like foobar, would you? > > The general prohibition needs to be in the general flow label spec. To be clear, I'm not objecting to the proposed text, because I think it's harmless (i.e. it doesn't appear to prevent any of the uses of the flow label that seem likely to get standardised in future). And it's good advice (because an implementation that ignores it may get unpredictable results). But I have a little difficulty in seeing it as effective use of virtual ink. However my real concern right now is to avoid continuing to embellish the draft, because I'm afraid of it becoming restrictive. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 04:30:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NBUQ3c021023; Fri, 23 Aug 2002 04:30:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NBUQie021022; Fri, 23 Aug 2002 04:30:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NBUI3c021015 for ; Fri, 23 Aug 2002 04:30:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17660 for ; Fri, 23 Aug 2002 04:30:28 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29100 for ; Fri, 23 Aug 2002 04:30:27 -0700 (PDT) Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.05) id 17iCdy-000D4W-00; Fri, 23 Aug 2002 12:30:22 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA46040; Fri, 23 Aug 2002 12:30:22 +0100 Message-ID: <3D661CE8.35495DA6@hursley.ibm.com> Date: Fri, 23 Aug 2002 13:30:48 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: narten@us.ibm.com, aconta@txc.com, deering@cisco.com, kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <009CA59D1752DD448E07F8EB2F911757198137@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... jarno.rajahalme@nokia.com wrote: > > Thomas, > > Current text has the following paragraph in section 2 (Introduction): > > "The minimum level of IPv6 flow support consists of labeling the > flows. IPv6 source nodes can label known flows (e.g. TCP connections, > RTP streams), even if the node itself would not require any flow- > specific treatment. Doing this enables load spreading and receiver > oriented resource reservations, for example. Requirements for flow > labeling are given in section 4." > > >From the above it should be clear that the intent of the draft is to explicitly allow for load balancing, or "load spreading". > > Currently, the text in "Terminology and Definitions" defining "flow state establishment > method" includes "algorithmic" methods for establishing flow state. > > The problem with this is that load balancing does not need any flow-specific state, but > state per interface (this state could be algorithmically generated, but it is not > flow-specific state). Not true; server load balancing solutions definitely do detect flows and establish corresponding state. Indeed they *must* do so (to direct all packets from a given transport session to the same host). > Indeed, it would be rather dangerous if a router would create new flow-specific state for > every different packet header it is forwarding. It would be useless too. But who suggested such a thing? > > To make the draft clear and explicit, I think we need to remove the algorithmic flow state > establishment method, I would agree with that. However, if you do, I would also remove the "(e.g. RSVP)" in the reference to dynamic flow state establishment. As I just mentioned, some load balancers do dynamically detect flow state. > and maybe clearly state somewhere that load balancing does not need flow-specific state. Definitely not, since it isn't true. > As far as I recall, the only motivation to add the algorithmic definition was to allow for > load spreading. After these changes the draft would (still) define what we want, but there > would be no room for multiple interpretations. Yes, after the first change (delete "algorithmic"). But your second proposed change would make the document inaccurate. Brian > > Regards, > > Jarno > > > -----Original Message----- > > From: ext Thomas Narten [mailto:narten@us.ibm.com] > > Sent: 21. elokuuta 2002 17:40 > > To: Rajahalme Jarno (NRC/Helsinki) > > Cc: kre@munnari.OZ.AU; brian@hursley.ibm.com; ipng@sunroof.eng.sun.com > > Subject: Re: Flow label draft issues & new text > > > > > > > "The method by which the flow state is cleared from the IPv6 nodes > > > is to be defined by the flow state establishment method used to set > > > up the state. This implies that IPv6 nodes unable to classify a > > > packet to an existing flow SHOULD NOT establish any flow-specific > > > state unless so instructed by a flow state establishment > > > method. With some flow state establishment methods, signaling new > > > state simultaneously clearing the old state from the new path may be > > > sufficient. A mechanism with a sufficiently long timeout period > > > before reusing the Flow Label values can also be used." > > > > How does the above text relate to the idea (which I thought the WG was > > interested in) in allowing the Flow Label field to be used for load > > balancing (i.e., hash the src/dest/label to select the next-hop when > > there are more than one). Seems like load balancing might not be > > allowed by the above wording. Is that the intent? > > > > Note in the case of simple load balancing, there is no flow state > > establishment method. > > > > Thomas > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 05:11:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NCBB3c021090; Fri, 23 Aug 2002 05:11:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NCBBsr021089; Fri, 23 Aug 2002 05:11:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NCB53c021082 for ; Fri, 23 Aug 2002 05:11:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11022 for ; Fri, 23 Aug 2002 05:11:15 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20085 for ; Fri, 23 Aug 2002 06:11:08 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7NCANl05572; Fri, 23 Aug 2002 19:10:24 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7NCA0W23077; Fri, 23 Aug 2002 19:10:00 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: jarno.rajahalme@nokia.com, narten@us.ibm.com, aconta@txc.com, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: <3D661CE8.35495DA6@hursley.ibm.com> References: <3D661CE8.35495DA6@hursley.ibm.com> <009CA59D1752DD448E07F8EB2F911757198137@esebe004.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 19:10:00 +0700 Message-ID: <23075.1030104600@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 23 Aug 2002 13:30:48 +0200 From: Brian E Carpenter Message-ID: <3D661CE8.35495DA6@hursley.ibm.com> | Not true; server load balancing solutions definitely do detect flows | and establish corresponding state. Indeed they *must* do so (to direct | all packets from a given transport session to the same host). That's true for v4, and the way things are currently done - but using the flow label with v6, it doesn't need to be. That is, the router can hash the source addr, and flow label, modulo the number of paths/destinations and pick the N'th of those based upon the hash. It can repeat that, deterministically, as required, and needs no state at all. Perhaps what is relevant here is what is meant by "state" - which I interpret as some record in the router of a particular packet that has gone before (that is, after the packet no longer exists in the router, there is some memory left behind that shows that it passed through). The idea is that without some specific flow processing method, routers shouldn't use the flow label to form such state (if the router wants, it could still go hunt for the port numbers, and use that) because without a way to flush that state, doing so might interfere with some defined use of the flow label for other purposes. That is, in basic (non flow processing supporting) systems, the flow label should be treated as semantic free as possible, otherwise later designers of flow mechanisms are going to have to work around brain damage that exists. | > and maybe clearly state somewhere that load balancing does not need | > flow-specific state. | Definitely not, since it isn't true. It is if they use the flow label for balancing (that is, the packet flow labels are the state, but they're maintained by the source host, not by the router). If they're not using the flow label, then they're irrelevant to this draft. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 06:40:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NDen3c021205; Fri, 23 Aug 2002 06:40:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NDemNd021204; Fri, 23 Aug 2002 06:40:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NDef3c021197 for ; Fri, 23 Aug 2002 06:40:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16030 for ; Fri, 23 Aug 2002 06:40:50 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21603 for ; Fri, 23 Aug 2002 07:40:49 -0600 (MDT) Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.05) id 17iEgC-0003Uw-00; Fri, 23 Aug 2002 14:40:48 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA66860; Fri, 23 Aug 2002 14:40:46 +0100 Message-ID: <3D663B79.F67AE35@hursley.ibm.com> Date: Fri, 23 Aug 2002 15:41:13 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Robert Elz CC: jarno.rajahalme@nokia.com, narten@us.ibm.com, aconta@txc.com, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <3D661CE8.35495DA6@hursley.ibm.com> <009CA59D1752DD448E07F8EB2F911757198137@esebe004.ntc.nokia.com> <23075.1030104600@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't disagree with anything that you say, but it doesn't change my view of what should be in the document (i.e. nothing specific about load balancing). Brian Robert Elz wrote: > > Date: Fri, 23 Aug 2002 13:30:48 +0200 > From: Brian E Carpenter > Message-ID: <3D661CE8.35495DA6@hursley.ibm.com> > > | Not true; server load balancing solutions definitely do detect flows > | and establish corresponding state. Indeed they *must* do so (to direct > | all packets from a given transport session to the same host). > > That's true for v4, and the way things are currently done - but using the > flow label with v6, it doesn't need to be. > > That is, the router can hash the source addr, and flow label, modulo the > number of paths/destinations and pick the N'th of those based upon the > hash. It can repeat that, deterministically, as required, and needs no > state at all. > > Perhaps what is relevant here is what is meant by "state" - which I > interpret as some record in the router of a particular packet that has > gone before (that is, after the packet no longer exists in the router, > there is some memory left behind that shows that it passed through). > > The idea is that without some specific flow processing method, routers > shouldn't use the flow label to form such state (if the router wants, > it could still go hunt for the port numbers, and use that) because without > a way to flush that state, doing so might interfere with some defined > use of the flow label for other purposes. > > That is, in basic (non flow processing supporting) systems, the flow label > should be treated as semantic free as possible, otherwise later designers > of flow mechanisms are going to have to work around brain damage that exists. > > | > and maybe clearly state somewhere that load balancing does not need > | > flow-specific state. > | Definitely not, since it isn't true. > > It is if they use the flow label for balancing (that is, the packet flow > labels are the state, but they're maintained by the source host, not by > the router). > > If they're not using the flow label, then they're irrelevant to this draft. > > kre -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 23 06:58:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NDwA3c021265; Fri, 23 Aug 2002 06:58:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NDwAvR021264; Fri, 23 Aug 2002 06:58:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NDw43c021257 for ; Fri, 23 Aug 2002 06:58:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13325 for ; Fri, 23 Aug 2002 06:58:14 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28149 for ; Fri, 23 Aug 2002 07:58:08 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7NDvUl23995; Fri, 23 Aug 2002 20:57:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7NDv2W23622; Fri, 23 Aug 2002 20:57:02 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: jarno.rajahalme@nokia.com, narten@us.ibm.com, aconta@txc.com, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: <3D663B79.F67AE35@hursley.ibm.com> References: <3D663B79.F67AE35@hursley.ibm.com> <3D661CE8.35495DA6@hursley.ibm.com> <009CA59D1752DD448E07F8EB2F911757198137@esebe004.ntc.nokia.com> <23075.1030104600@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 20:57:02 +0700 Message-ID: <23620.1030111022@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 23 Aug 2002 15:41:13 +0200 From: Brian E Carpenter Message-ID: <3D663B79.F67AE35@hursley.ibm.com> | I don't disagree with anything that you say, but it doesn't | change my view of what should be in the document (i.e. | nothing specific about load balancing). That's fine, I agree with that. What does need to be there is something more general that says what shouldn't be done, without (seeming to) prohibit what is still OK - without getting to specific cases. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 26 08:28:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QFSn3c028954; Mon, 26 Aug 2002 08:28:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QFSn83028953; Mon, 26 Aug 2002 08:28:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QFSh3c028946 for ; Mon, 26 Aug 2002 08:28:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08828 for ; Mon, 26 Aug 2002 08:28:53 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10230 for ; Mon, 26 Aug 2002 08:28:53 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7QFLoh21241; Mon, 26 Aug 2002 17:21:50 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA06736; Mon, 26 Aug 2002 17:21:50 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7QFLm6o023885; Mon, 26 Aug 2002 17:21:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208261521.g7QFLm6o023885@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Markku Savela , narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-reply-to: Your message of Fri, 23 Aug 2002 15:15:23 +0700. <21738.1030090523@munnari.OZ.AU> Date: Mon, 26 Aug 2002 17:21:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Always do DAD, no optimisation allowed, is the best approach. => I fully agree and I'd like to see according specifications updated ASAP. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 26 10:41:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHfl3c029917; Mon, 26 Aug 2002 10:41:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QHflXB029916; Mon, 26 Aug 2002 10:41:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.37]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHfg3c029909 for ; Mon, 26 Aug 2002 10:41:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7QHfpkT006761 for ; Mon, 26 Aug 2002 10:41:51 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27661 for ; Mon, 26 Aug 2002 11:41:46 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7C6BB3847; Mon, 26 Aug 2002 13:41:45 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 26 Aug 2002 13:41:45 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Protocol Action: Default Address Selection for IPv6 to Proposed Standard Date: Mon, 26 Aug 2002 13:41:45 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B914A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: Default Address Selection for IPv6 to Proposed Standard Thread-Index: AcJEj4VgqZBI3gAxRiupegEpA4aA4QImEW6w From: "Bound, Jim" To: "Keith Moore" , "The IESG" Cc: "RFC Editor" , "Internet Architecture Board" , X-OriginalArrivalTime: 26 Aug 2002 17:41:45.0099 (UTC) FILETIME=[D87DEDB0:01C24D27] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7QHfg3c029910 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree 100%. This did not have consenus on some key parts. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, August 15, 2002 3:08 PM > To: The IESG > Cc: RFC Editor; Internet Architecture Board; ipng@sunroof.eng.sun.com > Subject: Re: Protocol Action: Default Address Selection for IPv6 to > Proposed Standard > > > wow. Having the document be approved by IESG is not a surprise, but > at the same time - the announcement is extremely misleading. > > Serious problems with the entire idea of address selection > were repeatedly > raised in WG discussions. At the very least this should have > been reflected > in the document announcement. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 26 10:47:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHlG3c029963; Mon, 26 Aug 2002 10:47:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QHlFNX029962; Mon, 26 Aug 2002 10:47:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.26]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHlA3c029955 for ; Mon, 26 Aug 2002 10:47:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7QHlJu9023553 for ; Mon, 26 Aug 2002 10:47:19 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00693 for ; Mon, 26 Aug 2002 11:47:14 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id BCEB05A44; Mon, 26 Aug 2002 13:47:13 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 26 Aug 2002 13:47:13 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: need clarification of "deprecated" address Date: Mon, 26 Aug 2002 13:47:12 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B914B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification of "deprecated" address Thread-Index: AcJHcpKw06c3Tgm8T4edBHHS9WBy5wFtbsnA From: "Bound, Jim" To: , "Robert Elz" Cc: X-OriginalArrivalTime: 26 Aug 2002 17:47:13.0208 (UTC) FILETIME=[9C0F6380:01C24D28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7QHlA3c029956 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Itojun I think? I believe the way it should be is that once an address is deprecated no new existing connections should be started (via the SYN) I think we want to keep the wording as SHOULD NOT or SHOULD if we change. In case there is the non normal case that it must be permitted. So I think the basic wording is correct? /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Monday, August 19, 2002 7:08 AM > To: Robert Elz > Cc: ipng@sunroof.eng.sun.com > Subject: Re: need clarification of "deprecated" address > > > >No, I know you didn't. > > > | i suggested we should refuse new incoming > connections (TCP SYN). > > >Yes, that is what I am arguing against. > > >The line of reasoning seems to be > > > if we accept a connection to a deprecated address, we may > > have to open a connection from a deprecated address later. > > > > we're not allowed to open a connection from a deprecated address > > > > hence we should not accept connections to deprecated addresses > > FTP story was just an example. independent from the > FTP story, i am > - pointing out that the current text does not give any guidance > to incoming TCP SYN case, and > - we should drop incoming TCP SYN to deprecated addresses. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 26 10:48:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHmF3c029983; Mon, 26 Aug 2002 10:48:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QHmEMg029982; Mon, 26 Aug 2002 10:48:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHm83c029975 for ; Mon, 26 Aug 2002 10:48:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27599 for ; Mon, 26 Aug 2002 10:48:17 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01448 for ; Mon, 26 Aug 2002 11:48:16 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E4A964722; Mon, 26 Aug 2002 13:48:15 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 26 Aug 2002 13:48:15 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: need clarification of "deprecated" address Date: Mon, 26 Aug 2002 13:48:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B914C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification of "deprecated" address Thread-Index: AcJHdUb4ZHIaWudvRb2xcD3uRaZVmAFs2LpA From: "Bound, Jim" To: , "Robert Elz" Cc: "Atsushi Onoe" , X-OriginalArrivalTime: 26 Aug 2002 17:48:15.0647 (UTC) FILETIME=[C146D2F0:01C24D28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7QHm83c029976 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think a bit more clarity on what "new" means would be useful for sure. I don't see that as a showstopper for us and I think we are all in violent agreement here???? /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Monday, August 19, 2002 7:39 AM > To: Robert Elz > Cc: Atsushi Onoe; ipng@sunroof.eng.sun.com > Subject: Re: need clarification of "deprecated" address > > > > | this may be an implementation issue, but who should decide it? > >It was already decided long ago. The doc may need to be > made clearer. > > "who" means "userland, or kernel". > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 26 10:50:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHoV3c000017; Mon, 26 Aug 2002 10:50:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QHoVRc000016; Mon, 26 Aug 2002 10:50:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.26]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHoP3c000009 for ; Mon, 26 Aug 2002 10:50:25 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7QHoYu9024334 for ; Mon, 26 Aug 2002 10:50:35 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02517 for ; Mon, 26 Aug 2002 11:50:29 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 901CF64AF; Mon, 26 Aug 2002 13:50:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 26 Aug 2002 13:50:28 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: need clarification of "deprecated" address Date: Mon, 26 Aug 2002 13:50:27 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B914D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification of "deprecated" address Thread-Index: AcJHdf642ROmy2abRbSBeOOD4g0Z2QAIAXgQAWS2XuA= From: "Bound, Jim" To: "Richard Draves" , "Robert Elz" , Cc: "Atsushi Onoe" , X-OriginalArrivalTime: 26 Aug 2002 17:50:28.0005 (UTC) FILETIME=[102B0D50:01C24D29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7QHoP3c000010 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this has nothing to do with default address selection in the IP layer and addr conf which is where it is set. Also the discussion is for incoming transport layer connections for TCP, SCTP, and I think we need to consider connectionless too. Sure for applications but I don't think that is the discussion. /jim > -----Original Message----- > From: Richard Draves [mailto:richdr@microsoft.com] > Sent: Monday, August 19, 2002 11:36 AM > To: Robert Elz; itojun@iijlab.net > Cc: Atsushi Onoe; ipng@sunroof.eng.sun.com > Subject: RE: need clarification of "deprecated" address > > > > How would you suggest that it be revised to have the proper > > effect? (That is, to explicitly allow deprecated addresses to > > be used, other than when it is a toss up which address to use). > > Really it should point to the Default Address Selection RFC, > although I > suppose that would create an undesirable document dependency. > > Rich > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 26 10:52:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHqn3c000059; Mon, 26 Aug 2002 10:52:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QHqm3T000058; Mon, 26 Aug 2002 10:52:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.37]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHqh3c000051 for ; Mon, 26 Aug 2002 10:52:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7QHqrkT008675 for ; Mon, 26 Aug 2002 10:52:53 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07652 for ; Mon, 26 Aug 2002 10:52:47 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 70931644A; Mon, 26 Aug 2002 13:52:47 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 26 Aug 2002 13:52:47 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: need clarification of "deprecated" address [multihomed case] Date: Mon, 26 Aug 2002 13:52:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B914E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification of "deprecated" address [multihomed case] Thread-Index: AcJInvJwMe5AOHQ7QZC9YEx5ujn2vgEilwDw From: "Bound, Jim" To: , "Peter Lei" Cc: X-OriginalArrivalTime: 26 Aug 2002 17:52:47.0206 (UTC) FILETIME=[63237060:01C24D29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7QHqh3c000052 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this would all have to be done out of band just like tcp from addr conf like daemon that listens to the RAs and/or timers. /jim > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Tuesday, August 20, 2002 7:09 PM > To: Peter Lei > Cc: ipng@sunroof.eng.sun.com > Subject: Re: need clarification of "deprecated" address [multihomed > case] > > > > However, should any new connections (SCTP associations) > FROM this host to > > a peer list the deprecated address as part of the > association? Given the > > existing text and this discussion, it seems that it should > not, as other > > preferred address(es) are available. Of course unless as > qualified by the > > proposed text below-- that it is the only address available > (eg. the host > > is single homed/has a single valid address which happens to > be a deprecated > > address). > > Does SCTP provide some way to describe a preferred order over the > addresses, or is the address set inherently unordered? Does it > provide a way to delete an address from an active connection? > > If there is an ordering, pushing deprecateds to the bottom of the > barrel (and deleting them when they expire) sounds most robust and in > keeping with the rest of the discussion on this thread. > > - Bill > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 26 10:53:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHrI3c000072; Mon, 26 Aug 2002 10:53:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QHrI4n000071; Mon, 26 Aug 2002 10:53:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHrB3c000064 for ; Mon, 26 Aug 2002 10:53:11 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00020 for ; Mon, 26 Aug 2002 10:53:20 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21202 for ; Mon, 26 Aug 2002 11:53:20 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E898E644A; Mon, 26 Aug 2002 13:53:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 26 Aug 2002 13:53:19 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: need clarification of "deprecated" address [multihomed case] Date: Mon, 26 Aug 2002 13:53:19 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B914F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification of "deprecated" address [multihomed case] Thread-Index: AcJIydAJqN65cflsSPSdUnc0IIBonAEX57mA From: "Bound, Jim" To: "Peter Lei" , Cc: X-OriginalArrivalTime: 26 Aug 2002 17:53:19.0489 (UTC) FILETIME=[76616F10:01C24D29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7QHrB3c000065 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk which ID is this? thanks /jim > -----Original Message----- > From: Peter Lei [mailto:peter.lei@ieee.org] > Sent: Wednesday, August 21, 2002 12:14 AM > To: sommerfeld@east.sun.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: need clarification of "deprecated" address [multihomed > case] > > > > > However, should any new connections (SCTP associations) > FROM this host to > > > a peer list the deprecated address as part of the > association? Given the > > > existing text and this discussion, it seems that it > should not, as other > > > preferred address(es) are available. Of course unless as > qualified by the > > > proposed text below-- that it is the only address > available (eg. the host > > > is single homed/has a single valid address which happens > to be a deprecated > > > address). > > > > Does SCTP provide some way to describe a preferred order over the > > addresses, or is the address set inherently unordered? Does it > > provide a way to delete an address from an active connection? > > > > If there is an ordering, pushing deprecateds to the bottom of the > > barrel (and deleting them when they expire) sounds most > robust and in > > keeping with the rest of the discussion on this thread. > > > > - Bill > > I agree, but the address list is unordered (there is no > implied preference > order), hence my thought that they should probably not be > included in the > list. > > And yes, there is a way to delete an address from an active > association, > but that is currently an I-D and not part of RFC 2960; hence, > for existing > association(s) that have addresses that become deprecated, > then expire, > there is a mechanism to delete them from the association(s). > > --peter > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 00:18:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R7Ihwf001779; Tue, 27 Aug 2002 00:18:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7R7Ihp6001778; Tue, 27 Aug 2002 00:18:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R7Ibwf001771 for ; Tue, 27 Aug 2002 00:18:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02555 for ; Tue, 27 Aug 2002 00:18:47 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06506 for ; Tue, 27 Aug 2002 01:18:46 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KLSTJ7L8AU9I56K0@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Tue, 27 Aug 2002 17:18:31 +1000 Received: from thwack (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id ED26512C00A; Tue, 27 Aug 2002 17:18:25 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 311A512C007; Tue, 27 Aug 2002 16:47:25 +1000 (EST) Date: Tue, 27 Aug 2002 16:47:20 +1000 From: Greg Daley Subject: Proposal: DAD Optimization using Multicast Listener Discovery To: ipng@sunroof.eng.sun.com, greg.daley@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D6B2078.8030506@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Everyone, I've been thinking about how we can use MLD to determine if anyone else is defending an address using DAD. The MLD RFC indicates that a node's link-scope multicast addresses except all-nodes link-scope must be joined using MLD. Since the router receives MLD reports from all devices it knows whether a multicast group is active on the subnet (or should that be link(s)?) for which it is the Querier. If there are no listeners for the solicited-node multicast of the tentative address, then no-one may be DAD defending the address(es) associated with this multicast group. Therefore no-one may have one of these addresses. This means that a node which is aware that it is the first to join this group does not have to complete DAD, because there are can be no other devices which have this address configured. The mechanism I propose to do this for a host to send an extension of an MLD query message, specifying the group which the host wishes to join. The Router which holds a list of all the multicast groups sends back a UNKNOWN_GROUP indication in a (modified) MLD report message if the address is unknown. Reception this message may be used to finish DAD early. If the group is currently active at the Router (and the router responds with an ACTIVE_GROUP message), or if the router does not respond within the timeout period, DAD must be completed in accordance with RFC 2462. In all cases (on timeout, or reception of a response from the Router) an MLD Report is sent from the host to join the multicast group. Backoff mechanisms to prevent DoS on the nodes and Router are being considered. Our team will try to have a draft for discussion within a couple of days. Greg Daley Centre for Telecommunications and Information Engineering Monash University -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 02:14:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9Eiwf001965; Tue, 27 Aug 2002 02:14:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7R9EiiL001964; Tue, 27 Aug 2002 02:14:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9EWwf001949; Tue, 27 Aug 2002 02:14:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13780; Tue, 27 Aug 2002 02:14:42 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18087; Tue, 27 Aug 2002 03:14:39 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA18501; Tue, 27 Aug 2002 12:14:34 +0300 Date: Tue, 27 Aug 2002 12:14:34 +0300 Message-Id: <200208270914.MAA18501@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200208201427.g7KERb6o002654@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 20 Aug 2002 16:27:37 +0200) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200208201427.g7KERb6o002654@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Returning to this.. > From: Francis Dupont > > => from RFC 2710: > > MLD messages ARE sent for multicast addresses whose scope is 2 > (link-local), including Solicited-Node multicast addresses [ADDR- > ARCH], except for the link-scope, all-nodes address (FF02::1). > > Francis.Dupont@enst-bretagne.fr > > PS: the reason is that layer-2 devices need to know if they can > remove multicast packets to nodes which are not listening for them > (cf draft-ietf-magma-snoop-02.txt). In my view this is crap! Why must IP layer bend over so much for some kludgy layer-2 devices? If there are such devices, they could quite easily detect the equivalent of solicited node participants from the normal ND traffic! I'm going to ingore RFC 2710 on this point. I do not send MLD for link local multicast groups. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 02:18:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9ICwf002016; Tue, 27 Aug 2002 02:18:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7R9IBhE002015; Tue, 27 Aug 2002 02:18:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9I4wf002002; Tue, 27 Aug 2002 02:18:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14081; Tue, 27 Aug 2002 02:18:14 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20006; Tue, 27 Aug 2002 03:18:05 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 53DE54B25; Tue, 27 Aug 2002 18:17:46 +0900 (JST) To: Markku Savela Cc: Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: msa's message of Tue, 27 Aug 2002 12:14:34 +0300. <200208270914.MAA18501@burp.tkv.asdf.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: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Tue, 27 Aug 2002 18:17:46 +0900 Message-Id: <20020827091746.53DE54B25@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> PS: the reason is that layer-2 devices need to know if they can >> remove multicast packets to nodes which are not listening for them >> (cf draft-ietf-magma-snoop-02.txt). > >In my view this is crap! Why must IP layer bend over so much for some >kludgy layer-2 devices? If there are such devices, they could quite >easily detect the equivalent of solicited node participants from the >normal ND traffic! because otherwise multicast traffic will be flooded to every switch ports. >I'm going to ingore RFC 2710 on this point. I do not send MLD for link >local multicast groups. then your device will have trouble operating on coming switches that support MLD snooping, and it will be very difficult to track the issue down (extraordinary support load to your colleagues). i suggest you to follow RFC2710. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 02:33:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9Xgwf002381; Tue, 27 Aug 2002 02:33:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7R9XfAE002380; Tue, 27 Aug 2002 02:33:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9XTwf002364; Tue, 27 Aug 2002 02:33:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13547; Tue, 27 Aug 2002 02:33:39 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09089; Tue, 27 Aug 2002 03:33:38 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA18566; Tue, 27 Aug 2002 12:33:34 +0300 Date: Tue, 27 Aug 2002 12:33:34 +0300 Message-Id: <200208270933.MAA18566@burp.tkv.asdf.org> From: Markku Savela To: itojun@iijlab.net CC: Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <20020827091746.53DE54B25@coconut.itojun.org> Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <20020827091746.53DE54B25@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: itojun@iijlab.net > >I'm going to ingore RFC 2710 on this point. I do not send MLD for link > >local multicast groups. > > then your device will have trouble operating on coming switches > that support MLD snooping, and it will be very difficult to > track the issue down (extraordinary support load to your colleagues). > i suggest you to follow RFC2710. Although, I don't see much sense in using MLD other link local multicast groups, I'm here primarily talking about the solicited node groups. In my view, sending MLD on those is waste, because the *SAME* information is quite clearly available to the "snoopers" from the neighbor discovery traffic (DAD, NA, NS). In my system MLD is a separate component, I would like to be able to use IPv6 stack *without* MLD. (Which it does quite well, unless these layer-2 kludges come in and mess things). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 06:32:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RDW2wf003513; Tue, 27 Aug 2002 06:32:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RDVamL003512; Tue, 27 Aug 2002 06:31:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RDVUwf003505 for ; Tue, 27 Aug 2002 06:31:30 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12981 for ; Tue, 27 Aug 2002 06:31:41 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07435 for ; Tue, 27 Aug 2002 07:31:39 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7RDUil29907; Tue, 27 Aug 2002 20:30:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7RDUDW14128; Tue, 27 Aug 2002 20:30:13 +0700 (ICT) From: Robert Elz To: "Bound, Jim" cc: "Richard Draves" , itojun@iijlab.net, "Atsushi Onoe" , ipng@sunroof.eng.sun.com Subject: Re: need clarification of "deprecated" address In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B020B914D@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B020B914D@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 2002 20:30:13 +0700 Message-ID: <14126.1030455013@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 26 Aug 2002 13:50:27 -0400 From: "Bound, Jim" Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B914D@tayexc13.americas.cpqcorp.net> Jim, all of this was pretty much settled almost a week ago, all that remains is to get the text modified (but as I don't think there's a new version of this doc in the works right now, I'm not sure when that will happen). Even the new text has been agreed, I believe. But ... | this has nothing to do with default address selection in the IP layer The address selection draft is more than that, but "this" had everything to do with address selection - the "default" case is the one where not using a deprecated address is the correct answer, in other cases it isn't, and that's why perhaps mention about not using deprecated addresses might be better in the default addr selection doc, and no-where else. Unfortunately while putting it there is easy (for Rich) that doesn't by itself get rid of the text from 2462. And that text was the problem. | Also the discussion is for incoming transport layer connections for TCP, Yes, but that was influenced by a decision made about what was legal for outgoing connections, based upon one reading of the doc. The implementation has been fixed since, and new text for the doc to avoid it in future agreed. | SCTP, and I think we need to consider connectionless too. Yes, all the same issues (approximately) apply to connectionless. | Sure for applications but I don't think that is the discussion. They were part of it. You probably needed to read all of the messages, more carefully, before replying. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 07:40:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7REeuwf003675; Tue, 27 Aug 2002 07:40:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7REetqF003674; Tue, 27 Aug 2002 07:40:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7REeowf003667 for ; Tue, 27 Aug 2002 07:40:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02693 for ; Tue, 27 Aug 2002 07:41:01 -0700 (PDT) Received: from dot-god.com (d150-250-196.home.cgocable.net [24.150.250.196]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26490 for ; Tue, 27 Aug 2002 07:41:00 -0700 (PDT) Received: from localhost (baptista@localhost) by dot-god.com (8.11.4/8.11.4) with ESMTP id g7REfvT11448 for ; Tue, 27 Aug 2002 10:41:57 -0400 Date: Tue, 27 Aug 2002 10:41:57 -0400 (EDT) From: Joe Baptista To: Subject: IPv6 Interview Questions and critic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi: I'm doing an article on IPv6 and am looking for comments - here is a portion on IPv6 which relates to the privacy issue ... any comments, crtics or interviews welcomed. -- snip As you know IPv6 is a suite of protocols for the network layer of the Internet which uses IPv4 gateways. It's purpose is to expand address space. At this time IPv6 comes prepackaged with all popular operating systems. This includes all flavours of unix , windows and Mac OS. IPv6 is designed to solve many of the problems of the current version of IPv4 with regard to address depletion. The goal is to use IPv6 to expand the capabilities of the Internet to enable a variety of valuable peer-to-peer and mobile applications. According to many industry pundits it is the future of networking. However IPv6 has many privacy issues. IPv6 address space uses an ID (indentifier) derived from your hardware or phone. "That allows your packets to be traced back to your PC or cell-phone" said . fears abuse as a hardware ID wired into the ipv6 protocol can be used to determine the manufacturer, make and model number, and value of the hardware equipment being used by the end user. Ipv6 empowers the business community by providing a means of identifying and tracking users. Under Ipv6 users can be tracked and income demographics determined through hardware identification. Many members of the networking community have addressed concerns that the technology could result in potential abuse and warns users to think twice before they buy themselves a used Lap-Top computer and inherit all the prior surfing history of the previous user? Ipv6 uses 128 bits to provide addressing, routing and identification information on a computer. The 128-bits are divided into the left-64 and the right-64. Ipv6 uses the right 64 bits to store an IEEE defined global identifier (EUI64). This identifier is composed of company id value assigned to a manufacturer by the IEEE Registration Authority. The 64-bit identifier is a concatenation of the 24-bit company_id value and a 40-bit extension identifier assigned by the organization with that company_id assignment. The 48-bit MAC address of your network interface card is also used to make up the EUI64. -- snip Cheers Joe Baptista -- Planet Communications & Computing Facility a division of The dot.GOD Registry, Limited -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 08:04:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RF4Vwf003748; Tue, 27 Aug 2002 08:04:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RF4VZZ003747; Tue, 27 Aug 2002 08:04:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RF4Pwf003740 for ; Tue, 27 Aug 2002 08:04:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06509 for ; Tue, 27 Aug 2002 08:04:35 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00653 for ; Tue, 27 Aug 2002 09:04:35 -0600 (MDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7RF4PnO087616; Tue, 27 Aug 2002 11:04:25 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g7RF4OE3082610; Tue, 27 Aug 2002 09:04:24 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7REwHY27762; Tue, 27 Aug 2002 10:58:18 -0400 Message-Id: <200208271458.g7REwHY27762@rotala.raleigh.ibm.com> To: Joe Baptista cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic In-Reply-To: Message from "Tue, 27 Aug 2002 10:41:57 EDT." Date: Tue, 27 Aug 2002 10:58:17 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joe Baptista writes: > However IPv6 has many privacy issues. Actually, your note mentions 1 (not many) issues. Morever, the issue you raise is false as stated. > IPv6 address space uses an ID > (indentifier) derived from your hardware or phone. "That allows your > packets to be traced back to your PC or cell-phone" said . > fears abuse as a hardware ID wired into the ipv6 protocol can > be used to determine the manufacturer, make and model number, and value > of the hardware equipment being used by the end user. Seems to me that your " " is not particularly knowledgable about this issue. You might ask your source if they are familiar with RFC 3041. An IPv6 address can, in some cases, include an identifier derived from a hardware address. But this is not *required*. Moreover, there are examples where including such an identifier in an address poses no privacy issue. Servers, for instance, publish their address so that anyone can contact the server. In this case, there isn't an issue if the server address happens to contain a permanent identifier. In cases where using a permanent identifier is a problem, RFC 3041 addresses should be used. You might want to ask client vendors like Microsoft what they think of this issue (my understanding is they have already implemented RFC 3041). > Ipv6 empowers the business community by providing a means of identifying > and tracking users. Under Ipv6 users can be tracked and income > demographics determined through hardware identification. See above comment. > Many members of the networking community have addressed concerns that the > technology could result in potential abuse and warns users to > think twice before they buy themselves a used Lap-Top computer and inherit > all the prior surfing history of the previous user? Those "many members" might want to look at RFC 3041. > Ipv6 uses 128 bits to provide addressing, routing and identification > information on a computer. The 128-bits are divided into the left-64 and > the right-64. Ipv6 uses the right 64 bits to store an IEEE defined global > identifier (EUI64). This identifier is composed of company id value > assigned to a manufacturer by the IEEE Registration Authority. In some cases. Again, see above. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 11:12:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RIChwf004472; Tue, 27 Aug 2002 11:12:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RIChD7004471; Tue, 27 Aug 2002 11:12:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.26]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RICcwf004464 for ; Tue, 27 Aug 2002 11:12:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7RICmu9015712 for ; Tue, 27 Aug 2002 11:12:48 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00408 for ; Tue, 27 Aug 2002 12:12:42 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 27 Aug 2002 11:12:41 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Aug 2002 11:12:42 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 27 Aug 2002 11:12:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 27 Aug 2002 11:12:41 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Tue, 27 Aug 2002 11:12:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6728.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Proposal: DAD Optimization using Multicast Listener Discovery Date: Tue, 27 Aug 2002 11:12:41 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384234@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal: DAD Optimization using Multicast Listener Discovery Thread-Index: AcJNmj2sz+wuhk6UTduv6H78rTl9VwAWoIvg From: "Dave Thaler" To: Cc: X-OriginalArrivalTime: 27 Aug 2002 18:12:41.0372 (UTC) FILETIME=[555475C0:01C24DF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7RICcwf004465 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > > I've been thinking about how we can use MLD to > determine if anyone else is defending an address using DAD. > > The MLD RFC indicates that a node's link-scope multicast > addresses except all-nodes link-scope must be joined > using MLD. > > Since the router receives MLD reports from all devices it > knows whether a multicast group is active on the subnet > (or should that be link(s)?) for which it is the Querier. There is no requirement today that a router keep any state on link-scoped groups. Hence, in general the router does not know the information you're assuming. Furthermore, there is a proposal under discussion to not do DAD, except on manually assigned addresses. If this proposal is accepted, there's little benefit to trying to optimize DAD any further (certainly not worth asking routers to start keeping extra state). -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 11:19:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RIJwwf004534; Tue, 27 Aug 2002 11:19:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RIJvsR004533; Tue, 27 Aug 2002 11:19:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RIJqwf004526 for ; Tue, 27 Aug 2002 11:19:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05349 for ; Tue, 27 Aug 2002 11:20:02 -0700 (PDT) From: Jonne.Soininen@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05061 for ; Tue, 27 Aug 2002 12:20:01 -0600 (MDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7RIK3V12669 for ; Tue, 27 Aug 2002 21:20:03 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 27 Aug 2002 21:20:00 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Aug 2002 21:20:00 +0300 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Aug 2002 13:19:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 Interview Questions and critic Date: Tue, 27 Aug 2002 11:19:28 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBDA62@mvebe001.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Interview Questions and critic Thread-Index: AcJN21ly3KW1NSeiSd+cHLy/WuaXygAGmAxQ To: , Cc: X-OriginalArrivalTime: 27 Aug 2002 18:19:29.0075 (UTC) FILETIME=[48570030:01C24DF6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7RIJqwf004527 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I just want to underline what Thomas is saying. See bellow: > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: Tuesday, August 27, 2002 7:58 AM > To: Joe Baptista > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 Interview Questions and critic > > > Joe Baptista writes: > > > However IPv6 has many privacy issues. > > Actually, your note mentions 1 (not many) issues. Morever, the issue > you raise is false as stated. > > > IPv6 address space uses an ID > > (indentifier) derived from your hardware or phone. "That > allows your > > packets to be traced back to your PC or cell-phone" said . > > fears abuse as a hardware ID wired into the ipv6 > protocol can > > be used to determine the manufacturer, make and model > number, and value > > of the hardware equipment being used by the end user. > > Seems to me that your " " is not particularly > knowledgable about this issue. You might ask your source if they are > familiar with RFC 3041. I agree with Thomas. In cellular networks (at least in the 3GPP specified ones), the Interface Identifier is given by the GGSN, picked by the phone, or RFC3041 type IDs are used. So, this statement does not apply to those. Cheers, Jonne. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 11:57:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RIvGwf004661; Tue, 27 Aug 2002 11:57:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RIvFOf004660; Tue, 27 Aug 2002 11:57:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RIuowf004629; Tue, 27 Aug 2002 11:56:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27554; Tue, 27 Aug 2002 11:57:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28269; Tue, 27 Aug 2002 12:57:00 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Subject: Nomcom call for volunteers Date: Tue, 27 Aug 2002 14:44:44 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 15:46:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RMkEwf005942; Tue, 27 Aug 2002 15:46:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RMkDpD005941; Tue, 27 Aug 2002 15:46:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.37]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RMk8wf005934 for ; Tue, 27 Aug 2002 15:46:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7RMkJkT016087 for ; Tue, 27 Aug 2002 15:46:19 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17085 for ; Tue, 27 Aug 2002 15:46:14 -0700 (PDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KLTPW8KFRQ9I56SS@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 28 Aug 2002 08:45:12 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id DAEA320006; Wed, 28 Aug 2002 08:45:11 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 6147820006; Wed, 28 Aug 2002 08:45:07 +1000 (EST) Date: Wed, 28 Aug 2002 08:45:02 +1000 From: Greg Daley Subject: Re: Proposal: DAD Optimization using Multicast Listener Discovery To: Dave Thaler Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D6C00EE.1040300@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <2E33960095B58E40A4D3345AB9F65EC107384234@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dave, > There is no requirement today that a router keep any state > on link-scoped groups. Hence, in general the router does > not know the information you're assuming. What's being proposed is an optimization. If the router does not understand the request, or does not want to process such messages, then DAD continues as normal. Since the nodes are forced to perform MLD for the solicited-node address, the issue of whether the Querier Router actually keeps state is implementation dependent, IMHO. > Furthermore, there is a proposal under discussion to > not do DAD, except on manually assigned addresses. > If this proposal is accepted, there's little benefit to > trying to optimize DAD any further (certainly not worth > asking routers to start keeping extra state). Until there's consensus in the WG, I suggest that there's a great deal of benefit in assessing ways to remove the delay issues in DAD, without killing it. I'll send out the draft soon so you can have a look at it before you make a final decision ;-) Greg Daley -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 27 16:09:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RN9Swf006190; Tue, 27 Aug 2002 16:09:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RN9SYq006189; Tue, 27 Aug 2002 16:09:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RN9Mwf006182 for ; Tue, 27 Aug 2002 16:09:22 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06348 for ; Tue, 27 Aug 2002 16:09:33 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13007 for ; Tue, 27 Aug 2002 17:09:32 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA24608; Tue, 27 Aug 2002 16:09:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7RN9VY09939; Tue, 27 Aug 2002 16:09:31 -0700 X-mProtect: <200208272309> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.56.167, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVfvhgi; Tue, 27 Aug 2002 16:09:29 PDT Message-Id: <4.3.2.7.2.20020827155644.02ba0eb8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Aug 2002 16:07:07 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Consensus on IPv6 Addressing Architecture Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 working group chairs belive there is a consensus to adopt the changes proposed to the mailing list on 09 August 2002 and to advance the document to Draft Standard. The discussion on the mailing was subsequent to a discussion at the Yokohama IETF. The changes were to modify the interface identifier uniqueness requirements (from link to subnet prefix) and to change the definition of Site-Local addresses to make the subnet field 54-bits (and eliminate the 38-bit zero field). There was no disagreement to the subnet field change. There was a discussion about the interface identifier uniqueness change. One issue raised was about the operational complexity of having different nodes using the same interface identifier (in different subnet-prefixes). The following text (changed lines marked by "|") resolves this issue: 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet | prefix. It is recommended that the same interface identifier not be | assigned to different nodes on a link. They may also be unique over | a broader scope. In some cases an interface's identifier will be derived directly from that interface's link-layer address. The same interface identifier may be used on multiple interfaces on a single node, as long as they are attached to different subnets. | The recommendation in the third sentence should accommodate the desired behavior while still relaxing the uniqueness requirement. Subsequent to discussion on the proposed changes, questions were raised about the necessity of 64-bit interface identifiers and the /64 boundary in IPv6 unicast addresses. The chairs reading of the discussion is that we do not believe there is a consensus to make changes in this part of the IPv6 addressing architecture and the document can proceed. A new version of the draft (-09) has been submitted to be published as an Internet Draft. A few minor changes to the document were made in Appendix A to make the text consistent with the interface identifier uniqueness change. The IPv6 working group chairs believe there is a consensus to advance this document to Draft Standard and plan to notify the Internet ADs accordingly. Bob Hinden, Steve Deering, Margaret Wasserman IPv6 Working Group Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 28 00:40:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7S7enwf006939; Wed, 28 Aug 2002 00:40:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7S7enlZ006938; Wed, 28 Aug 2002 00:40:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7S7ehwf006931 for ; Wed, 28 Aug 2002 00:40:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17445 for ; Wed, 28 Aug 2002 00:40:53 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21298 for ; Wed, 28 Aug 2002 01:40:39 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (dhcp253.cc.psu.ac.th [192.168.2.253]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7S7dkU14918; Wed, 28 Aug 2002 14:39:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7S2QvW17340; Wed, 28 Aug 2002 09:26:57 +0700 (ICT) From: Robert Elz To: "Dave Thaler" cc: greg.daley@eng.monash.edu.au, ipng@sunroof.eng.sun.com Subject: Re: Proposal: DAD Optimization using Multicast Listener Discovery In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC107384234@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC107384234@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Aug 2002 09:26:57 +0700 Message-ID: <17338.1030501617@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 27 Aug 2002 11:12:41 -0700 From: "Dave Thaler" Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384234@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> | Furthermore, there is a proposal under discussion to | not do DAD, except on manually assigned addresses. I think "under discussion" is a little much for that. There was such a proposal, but it really only existed (I believe) because it was the only practical way to make DIID work. When there was almost no support for DIID, that proposal became unnecessary, and since then (during the WG meeting at Yokohama, where this was raised, and then forgotten) there has been no discussion at all that I'm aware of. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 28 01:00:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7S809wf007023; Wed, 28 Aug 2002 01:00:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7S8090f007022; Wed, 28 Aug 2002 01:00:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7S803wf007013 for ; Wed, 28 Aug 2002 01:00:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22161 for ; Wed, 28 Aug 2002 01:00:13 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09896 for ; Wed, 28 Aug 2002 02:00:06 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KLU98CMK6C9DJN8U@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 28 Aug 2002 17:58:36 +1000 Received: from thwack (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id D7B0412C00A; Wed, 28 Aug 2002 17:58:35 +1000 (EST) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 9490312C008; Wed, 28 Aug 2002 17:58:33 +1000 (EST) Date: Wed, 28 Aug 2002 17:58:33 +1000 From: Brett Pentland Subject: Re: Proposal: DAD Optimization using Multicast Listener Discovery X-Sender: "Brett Pentland" To: Robert Elz Cc: Dave Thaler , greg.daley@eng.monash.edu.au, ipng@sunroof.eng.sun.com Message-id: <3D6C82A9.B3B53FCC@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en]C-CCK-MCD monwin/025 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <2E33960095B58E40A4D3345AB9F65EC107384234@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <17338.1030501617@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Tue, 27 Aug 2002 11:12:41 -0700 > From: "Dave Thaler" > Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384234@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> > > | Furthermore, there is a proposal under discussion to > | not do DAD, except on manually assigned addresses. > > I think "under discussion" is a little much for that. There was > such a proposal, but it really only existed (I believe) because it > was the only practical way to make DIID work. When there was almost > no support for DIID, that proposal became unnecessary, and since then > (during the WG meeting at Yokohama, where this was raised, and then > forgotten) there has been no discussion at all that I'm aware of. > > kre > I don't understand how not doing DAD relates to DIID. I thought (possibly mistakenly) that the proposal that Steve Deering presented was to do with eliminating the delay introduced DAD for addresses that are unlikely to conflict with others, allowing faster aquisition of new addresses (helpful for mobile nodes). Brett. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 28 01:57:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7S8vewf007135; Wed, 28 Aug 2002 01:57:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7S8vdfj007134; Wed, 28 Aug 2002 01:57:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7S8vYwf007127 for ; Wed, 28 Aug 2002 01:57:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21688 for ; Wed, 28 Aug 2002 01:57:41 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20563 for ; Wed, 28 Aug 2002 01:57:38 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (dhcp253.cc.psu.ac.th [192.168.2.253]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7S8uxU22119; Wed, 28 Aug 2002 15:56:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7S8upW19669; Wed, 28 Aug 2002 15:56:51 +0700 (ICT) From: Robert Elz To: Brett Pentland cc: Dave Thaler , greg.daley@eng.monash.edu.au, ipng@sunroof.eng.sun.com Subject: Re: Proposal: DAD Optimization using Multicast Listener Discovery In-Reply-To: <3D6C82A9.B3B53FCC@eng.monash.edu.au> References: <3D6C82A9.B3B53FCC@eng.monash.edu.au> <2E33960095B58E40A4D3345AB9F65EC107384234@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <17338.1030501617@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Aug 2002 15:56:51 +0700 Message-ID: <19667.1030525011@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 28 Aug 2002 17:58:33 +1000 From: Brett Pentland Message-ID: <3D6C82A9.B3B53FCC@eng.monash.edu.au> | I don't understand how not doing DAD relates to DIID. I thought | (possibly mistakenly) that the proposal that Steve Deering presented was | to do with eliminating the delay introduced DAD for addresses that are | unlikely to conflict with others, allowing faster aquisition of new | addresses (helpful for mobile nodes). Yes, it did all that. But it turns out that to make DIID really work, it would be close to essential to do this. Just why is no longer really relevant (Steve can explain if he feels inclined). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 28 11:27:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SIRNwf008232; Wed, 28 Aug 2002 11:27:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SIRNgb008231; Wed, 28 Aug 2002 11:27:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SIRHwf008224 for ; Wed, 28 Aug 2002 11:27:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09887 for ; Wed, 28 Aug 2002 11:27:27 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07710 for ; Wed, 28 Aug 2002 12:27:26 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 11:27:25 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Aug 2002 11:27:25 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 28 Aug 2002 11:27:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 11:27:05 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Wed, 28 Aug 2002 11:27:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6728.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Proposal: DAD Optimization using Multicast Listener Discovery Date: Wed, 28 Aug 2002 11:27:02 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC108744DA8@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal: DAD Optimization using Multicast Listener Discovery Thread-Index: AcJOcQoHTXgYw+3mRvO7p16My9vM+gATz8Cg From: "Dave Thaler" To: "Robert Elz" , "Brett Pentland" Cc: , X-OriginalArrivalTime: 28 Aug 2002 18:27:03.0839 (UTC) FILETIME=[81D03AF0:01C24EC0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7SIRHwf008225 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz [mailto:kre@munnari.OZ.AU] [...] > | I don't understand how not doing DAD relates to DIID. I thought > | (possibly mistakenly) that the proposal that Steve Deering presented was > | to do with eliminating the delay introduced DAD for addresses that are > | unlikely to conflict with others, allowing faster aquisition of new > | addresses (helpful for mobile nodes). > > Yes, it did all that. But it turns out that to make DIID really work, > it would be close to essential to do this. Just why is no longer really > relevant (Steve can explain if he feels inclined). I agree with Brett. I still strongly support Steve's proposal with DAD. It reduces the startup delay in most scenarios. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 28 16:28:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SNS1wf009055; Wed, 28 Aug 2002 16:28:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SNS0GN009054; Wed, 28 Aug 2002 16:28:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SNRswf009044 for ; Wed, 28 Aug 2002 16:27:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18692 for ; Wed, 28 Aug 2002 16:28:04 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29729 for ; Wed, 28 Aug 2002 17:28:03 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7600F91F8; Wed, 28 Aug 2002 19:28:03 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 28 Aug 2002 19:28:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: need clarification of "deprecated" address Date: Wed, 28 Aug 2002 19:28:02 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B9177@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification of "deprecated" address Thread-Index: AcJNzqNDRLJMHpJOTA2zpV6xco8F1wBG4CFQ From: "Bound, Jim" To: "Robert Elz" Cc: "Richard Draves" , , "Atsushi Onoe" , X-OriginalArrivalTime: 28 Aug 2002 23:28:03.0373 (UTC) FILETIME=[8E226DD0:01C24EEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7SNRswf009045 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, Not disagreeing there is affect to address selection. But no one should assume address selection will be widely deployed at this time. That remains to be seen. I think it will personally. My issue is what we do with a deprecated address in our stacks regarding behavior and that resolution is not driven by address selection. That is all. regards, /jim > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Tuesday, August 27, 2002 9:30 AM > To: Bound, Jim > Cc: Richard Draves; itojun@iijlab.net; Atsushi Onoe; > ipng@sunroof.eng.sun.com > Subject: Re: need clarification of "deprecated" address > > > Date: Mon, 26 Aug 2002 13:50:27 -0400 > From: "Bound, Jim" > Message-ID: > <9C422444DE99BC46B3AD3C6EAFC9711B020B914D@tayexc13.americas.cp > qcorp.net> > > Jim, all of this was pretty much settled almost a week ago, > all that remains > is to get the text modified (but as I don't think there's a > new version of > this doc in the works right now, I'm not sure when that will happen). > > Even the new text has been agreed, I believe. But ... > > | this has nothing to do with default address selection in > the IP layer > > The address selection draft is more than that, but "this" had > everything > to do with address selection - the "default" case is the one where not > using a deprecated address is the correct answer, in other > cases it isn't, > and that's why perhaps mention about not using deprecated > addresses might > be better in the default addr selection doc, and no-where else. > Unfortunately while putting it there is easy (for Rich) that > doesn't by > itself get rid of the text from 2462. And that text was the problem. > > | Also the discussion is for incoming transport layer > connections for TCP, > > Yes, but that was influenced by a decision made about what > was legal for > outgoing connections, based upon one reading of the doc. > The implementation > has been fixed since, and new text for the doc to avoid it in > future agreed. > > | SCTP, and I think we need to consider connectionless too. > > Yes, all the same issues (approximately) apply to connectionless. > > | Sure for applications but I don't think that is the discussion. > > They were part of it. You probably needed to read all of > the messages, > more carefully, before replying. > > kre > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 01:47:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7T8lWwf009770; Thu, 29 Aug 2002 01:47:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7T8lW9W009769; Thu, 29 Aug 2002 01:47:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7T8lQwf009762 for ; Thu, 29 Aug 2002 01:47:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09169 for ; Thu, 29 Aug 2002 01:47:37 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04011 for ; Thu, 29 Aug 2002 02:47:36 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KLVP7IAEL090QH0M@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 29 Aug 2002 18:46:51 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 583B620015; Thu, 29 Aug 2002 18:46:50 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 788A320005; Thu, 29 Aug 2002 16:52:43 +1000 (EST) Date: Thu, 29 Aug 2002 16:52:43 +1000 From: Greg Daley Subject: Draft for DAD optimization using Multicast Listener Discovery To: ipng@sunroof.eng.sun.com Cc: richard.nelson@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D6DC4BB.7040405@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We've just submitted the draft for the idea for DAD optimization proposed earlier in the week. If you're interested, it is also available at the following URL: http://www.ctie.monash.edu.au/ipv6/draft-daley-ipv6-mcast-dad-00.txt Greg Daley Centre for Telecommunications and Information Engineering Monash University -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 04:46:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TBk5wf010122; Thu, 29 Aug 2002 04:46:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TBk5Zl010121; Thu, 29 Aug 2002 04:46:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TBjvwf010111 for ; Thu, 29 Aug 2002 04:45:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14480 for ; Thu, 29 Aug 2002 04:46:08 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28562 for ; Thu, 29 Aug 2002 04:46:07 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16679; Thu, 29 Aug 2002 07:44:36 -0400 (EDT) Message-Id: <200208291144.HAA16679@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-09.txt Date: Thu, 29 Aug 2002 07:44:36 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-09.txt Pages : 26 Date : 2002-8-28 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v3-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-28160328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-28160328.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 04:45:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TBjxwf010119; Thu, 29 Aug 2002 04:45:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TBjwQg010113; Thu, 29 Aug 2002 04:45:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TBjpwf010104 for ; Thu, 29 Aug 2002 04:45:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18204 for ; Thu, 29 Aug 2002 04:46:02 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23217 for ; Thu, 29 Aug 2002 04:46:01 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16662; Thu, 29 Aug 2002 07:44:29 -0400 (EDT) Message-Id: <200208291144.HAA16662@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2096-update-01.txt Date: Thu, 29 Aug 2002 07:44:29 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Forwarding Table MIB Author(s) : M. Wasserman Filename : draft-ietf-ipv6-rfc2096-update-01.txt Pages : 30 Date : 2002-8-28 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets, in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2096-update-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-28160315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2096-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-28160315.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 12:04:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJ4twf010923; Thu, 29 Aug 2002 12:04:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJ4tqZ010922; Thu, 29 Aug 2002 12:04:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJ4nwf010908 for ; Thu, 29 Aug 2002 12:04:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13803 for ; Thu, 29 Aug 2002 12:05:00 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06344 for ; Thu, 29 Aug 2002 13:04:59 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g7TJ4rW4017065; Thu, 29 Aug 2002 12:04:53 -0700 (PDT) Received: from [10.34.255.54] (stealth-10-34-255-54.cisco.com [10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AEM77117; Thu, 29 Aug 2002 12:03:12 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 29 Aug 2002 12:04:50 -0700 To: Joe Baptista From: Steve Deering Subject: Re: IPv6 Interview Questions and critic Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:41 AM -0400 8/27/02, Joe Baptista wrote: >However IPv6 has many privacy issues. IPv6 address space uses an ID >(indentifier) derived from your hardware or phone. "That allows your >packets to be traced back to your PC or cell-phone" said . > fears abuse as a hardware ID wired into the ipv6 protocol can >be used to determine the manufacturer, make and model number, and value >of the hardware equipment being used by the end user. Joe, This issue was addressed a *long* time ago -- please see http://playground.sun.com/ipv6/specs/ipv6-address-privacy.html from November of 1999. Your source has either a very shallow or out-of-date understanding of IPv6, or some reason to want to propagate misinformation. Thanks for checking here. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 12:10:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJAlwf010997; Thu, 29 Aug 2002 12:10:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJAlmI010996; Thu, 29 Aug 2002 12:10:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJAfwf010989 for ; Thu, 29 Aug 2002 12:10:41 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15700 for ; Thu, 29 Aug 2002 12:10:52 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22176 for ; Thu, 29 Aug 2002 13:10:51 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7TJAWe07283; Thu, 29 Aug 2002 22:10:32 +0300 Date: Thu, 29 Aug 2002 22:10:32 +0300 (EEST) From: Pekka Savola To: Steve Deering cc: Joe Baptista , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 29 Aug 2002, Steve Deering wrote: > At 10:41 AM -0400 8/27/02, Joe Baptista wrote: > >However IPv6 has many privacy issues. IPv6 address space uses an ID > >(indentifier) derived from your hardware or phone. "That allows your > >packets to be traced back to your PC or cell-phone" said . > > fears abuse as a hardware ID wired into the ipv6 protocol can > >be used to determine the manufacturer, make and model number, and value > >of the hardware equipment being used by the end user. > > Joe, > > This issue was addressed a *long* time ago -- please see > http://playground.sun.com/ipv6/specs/ipv6-address-privacy.html > from November of 1999. Your source has either a very shallow > or out-of-date understanding of IPv6, or some reason to want to > propagate misinformation. Thanks for checking here. Only parts of "this issue" were properly fixed. Indeed, some (mostly related to user tracking) seem to be unfixable. Thanks for checking the rfc3041 considered harmful draft. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 12:16:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJGqwf011081; Thu, 29 Aug 2002 12:16:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJGqgE011080; Thu, 29 Aug 2002 12:16:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJGkwf011073 for ; Thu, 29 Aug 2002 12:16:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24418 for ; Thu, 29 Aug 2002 12:16:57 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29793 for ; Thu, 29 Aug 2002 12:16:57 -0700 (PDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7TJGm8v041004; Thu, 29 Aug 2002 15:16:48 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g7TJGlse128056; Thu, 29 Aug 2002 13:16:47 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7TJDeX03287; Thu, 29 Aug 2002 15:13:40 -0400 Message-Id: <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> To: Pekka Savola cc: Steve Deering , Joe Baptista , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic In-Reply-To: Message from "Thu, 29 Aug 2002 22:10:32 +0300." Date: Thu, 29 Aug 2002 15:13:40 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Only parts of "this issue" were properly fixed. Indeed, some (mostly > related to user tracking) seem to be unfixable. Please clarify. Are there existing problems in IPv6 that we have neglected to fix that you believe we can fix? Or are there all sorts of problems in general (not IPv6-specific) that are hard and not easily fixable (a position I would agree with). Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 12:23:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJNrwf011146; Thu, 29 Aug 2002 12:23:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJNrOS011145; Thu, 29 Aug 2002 12:23:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJNlwf011138 for ; Thu, 29 Aug 2002 12:23:47 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19372 for ; Thu, 29 Aug 2002 12:23:59 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26238 for ; Thu, 29 Aug 2002 12:23:58 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 781E34237; Thu, 29 Aug 2002 14:23:58 -0500 (CDT) Received: from anw.zk3.dec.com (band.zk3.dec.com [16.140.128.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id B2139C7F; Thu, 29 Aug 2002 14:23:57 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7TJNq00001631664; Thu, 29 Aug 2002 15:23:52 -0400 (EDT) Message-ID: <3D6E74C7.5010705@hp.com> Date: Thu, 29 Aug 2002 15:23:51 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on IPv6 Addressing Architecture References: <4.3.2.7.2.20020827155644.02ba0eb8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob I've been trying to figure all the imlication of the change and have the following comments. Bob Hinden wrote: > The following text (changed lines marked by "|") resolves this issue: > > 2.5.1 Interface Identifiers > > Interface identifiers in IPv6 unicast addresses are used to identify > interfaces on a link. They are required to be unique within a subnet | > prefix. Would it possible to add "for the link" at the end of this sentence. I think it would clarify where the subnet prefix is applicable in normal situations. It still leave door open for multi-link subnets. > It is recommended that the same interface identifier not be | > assigned to different nodes on a link. They may also be unique over | > a broader scope. In some cases an interface's identifier will be > derived directly from that interface's link-layer address. The same > interface identifier may be used on multiple interfaces on a single > node, as long as they are attached to different subnets. | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think the last sentence here clashes with the first statement of the paragraph. Interfaces are not attached to subnets, they are attached to links... Thanks --vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 12:29:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJTnwf011192; Thu, 29 Aug 2002 12:29:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJTeRq011191; Thu, 29 Aug 2002 12:29:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJTZwf011184 for ; Thu, 29 Aug 2002 12:29:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22611 for ; Thu, 29 Aug 2002 12:29:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29279 for ; Thu, 29 Aug 2002 12:29:45 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7TJRUj07473; Thu, 29 Aug 2002 22:27:30 +0300 Date: Thu, 29 Aug 2002 22:27:30 +0300 (EEST) From: Pekka Savola To: Thomas Narten cc: Steve Deering , Joe Baptista , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 29 Aug 2002, Thomas Narten wrote: > > Only parts of "this issue" were properly fixed. Indeed, some (mostly > > related to user tracking) seem to be unfixable. > > Please clarify. Are there existing problems in IPv6 that we have > neglected to fix that you believe we can fix? > > Or are there all sorts of problems in general (not IPv6-specific) that > are hard and not easily fixable (a position I would agree with). Belief that by randomly regenerating only the interface identifier part of the address will give you privacy is IMO false. How much this will help you depends on the circumstances. It could help a lot in some cases (e.g. when the prefix changes rapidly too), close to zero in others (e.g. when your prefix is nearly static). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 12:37:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJblwf011241; Thu, 29 Aug 2002 12:37:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJbkPS011240; Thu, 29 Aug 2002 12:37:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJbdwf011233 for ; Thu, 29 Aug 2002 12:37:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25804 for ; Thu, 29 Aug 2002 12:37:50 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08014 for ; Thu, 29 Aug 2002 13:37:50 -0600 (MDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g7TJbIJO001626; Thu, 29 Aug 2002 15:37:18 -0400 (EDT) Date: Thu, 29 Aug 2002 15:37:18 -0400 (EDT) From: Scott Bradner Message-Id: <200208291937.g7TJbIJO001626@newdev.harvard.edu> To: narten@us.ibm.com, pekkas@netcore.fi Subject: Re: IPv6 Interview Questions and critic Cc: baptista@dot-god.com, deering@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas asked for IPv6 specific problems - it seems like you are complaining about how teh basic Internet works - maybe I'm missing it but what is IPv6 specific in your problem other than the ability (not in IPv4) to have a random host-part of the address when you start a session? Scott ---- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 15:32:53 2002 X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Thu, 29 Aug 2002 22:27:30 +0300 (EEST) From: Pekka Savola To: Thomas Narten cc: Steve Deering , Joe Baptista , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 29 Aug 2002, Thomas Narten wrote: > > Only parts of "this issue" were properly fixed. Indeed, some (mostly > > related to user tracking) seem to be unfixable. > > Please clarify. Are there existing problems in IPv6 that we have > neglected to fix that you believe we can fix? > > Or are there all sorts of problems in general (not IPv6-specific) that > are hard and not easily fixable (a position I would agree with). Belief that by randomly regenerating only the interface identifier part of the address will give you privacy is IMO false. How much this will help you depends on the circumstances. It could help a lot in some cases (e.g. when the prefix changes rapidly too), close to zero in others (e.g. when your prefix is nearly static). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 12:52:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJq1wf011320; Thu, 29 Aug 2002 12:52:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJq1pO011319; Thu, 29 Aug 2002 12:52:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJptwf011312 for ; Thu, 29 Aug 2002 12:51:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05864 for ; Thu, 29 Aug 2002 12:52:06 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22299 for ; Thu, 29 Aug 2002 13:52:05 -0600 (MDT) Received: from kenawang ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA17956; Thu, 29 Aug 2002 12:51:10 -0700 (PDT) Message-Id: <4.2.2.20020829154541.02cb7340@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Aug 2002 15:52:13 -0400 To: Pekka Savola From: Margaret Wasserman Subject: Re: IPv6 Interview Questions and critic Cc: Thomas Narten , Steve Deering , Joe Baptista , In-Reply-To: References: <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, >How much this will help you depends on the circumstances. It could help a >lot in some cases (e.g. when the prefix changes rapidly too), close to >zero in others (e.g. when your prefix is nearly static). How is this different than a case where someone uses a static (or "nearly static") IPv4 address to track a user's connections? Any static address can be used for tracking purposes. The use of temporary addresses in IPv6 will make it somewhat harder for servers to track information about individual IPv6 hosts. They could still store tracking information based on the prefix, but they would not know if the prefix refers to a single host or a large multi-user network. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 12:57:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJvGwf011366; Thu, 29 Aug 2002 12:57:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJvGPn011365; Thu, 29 Aug 2002 12:57:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJvAwf011358 for ; Thu, 29 Aug 2002 12:57:10 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29252 for ; Thu, 29 Aug 2002 12:57:22 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19648 for ; Thu, 29 Aug 2002 13:57:21 -0600 (MDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7TJvKDf060700 for ; Thu, 29 Aug 2002 15:57:20 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g7TJvn7c096216 for ; Thu, 29 Aug 2002 13:57:49 -0600 To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Subject: Comments on draft-ietf-ipv6-scope-api-00.txt X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 5.0.7 |March 21, 2001) at 08/29/2002 03:57:05 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 5.0.7 |March 21, 2001) at 08/29/2002 03:57:05 PM, Serialize complete at 08/29/2002 03:57:05 PM, S/MIME Sign failed at 08/29/2002 03:57:05 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V60_M14TT_08092002NP Release Candidate|August 09, 2002) at 08/29/2002 13:57:19, Serialize complete at 08/29/2002 13:57:19 Message-ID: Date: Thu, 29 Aug 2002 15:57:17 -0400 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While working on supporting and exploiting the scoped address architecture, I've noticed I need several new APIs to implement the support within applications and library routines. For instance, I've found that I need versions of inet_pton() and inet_ntop() which support scoped addresses. I guess one option here would be to deprecate both of these APIs and instead use getnameinfo() and getaddrinfo() to perform the function, but that just doesn't feel right when processing link-local addresses or multicast addresses. I've also found a need for APIs to map a scope zone index to a scope zone name and vice-versa, similar to how if_nametoindex() and if_indextoname() work for interface indices and names. How are others dealing with supporting scoped addresses within their applications and library routines? While I could define proprietary API extensions to support these functions (and will have to if there are no standard ones available), it seems to me that others who implement the scoped address architecture will need similar APIs. Is this something which needs addressing, and if so should the APIs be standardized? If the answers are yes, then it would seem to me the logical home would be the new scoped address API draft. Is anyone actively working to update this draft to include new scope-aware APIs? If not, and if there is interest, I'd be willing to take a stab at defining the API extensions needed to support the scoped address architecture. Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 13:10:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKAlwf011453; Thu, 29 Aug 2002 13:10:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TKAkBH011452; Thu, 29 Aug 2002 13:10:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKAfwf011445 for ; Thu, 29 Aug 2002 13:10:41 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11753 for ; Thu, 29 Aug 2002 13:10:53 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27453 for ; Thu, 29 Aug 2002 14:10:52 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g7TKAcds015881; Thu, 29 Aug 2002 13:10:38 -0700 (PDT) Received: from [10.34.255.54] (stealth-10-34-255-54.cisco.com [10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AEM78978; Thu, 29 Aug 2002 13:08:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 29 Aug 2002 13:10:36 -0700 To: Pekka Savola From: Steve Deering Subject: Re: IPv6 Interview Questions and critic Cc: Thomas Narten , Joe Baptista , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:27 PM +0300 8/29/02, Pekka Savola wrote: >Belief that by randomly regenerating only the interface identifier part of >the address will give you privacy is IMO false. Pekka, I don't think anyone has made such a broad claim. The random interface ID mechanism addresses the specific privacy concerns raised by using IIDs derived from IEEE-802 or EUI-64 addresses (or other factory-assigned serial numbers), such as those concerns mentioned in Joe's message: At 10:41 AM -0400 8/27/02, Joe Baptista wrote: > fears abuse as a hardware ID wired into the ipv6 protocol can >be used to determine the manufacturer, make and model number, and value >of the hardware equipment being used by the end user. >... >...Under Ipv6 users can be tracked and income >demographics determined through hardware identification. >... > warns users to think twice before they buy themselves a used >Lap-Top computer and inherit all the prior surfing history of the >previous user... Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 13:11:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKBjwf011470; Thu, 29 Aug 2002 13:11:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TKBjgg011469; Thu, 29 Aug 2002 13:11:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKBcwf011462 for ; Thu, 29 Aug 2002 13:11:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03728 for ; Thu, 29 Aug 2002 13:11:50 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01629 for ; Thu, 29 Aug 2002 14:11:48 -0600 (MDT) Received: from cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA00331; Thu, 29 Aug 2002 16:11:22 -0400 (EDT) Message-ID: <3D6E7FEA.80204@cisco.com> Date: Thu, 29 Aug 2002 16:11:22 -0400 From: Josh Littlefield User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Pekka Savola , Thomas Narten , Steve Deering , Joe Baptista , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic References: <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> <4.2.2.20020829154541.02cb7340@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: >>How much this will help you depends on the circumstances. It could help a >>lot in some cases (e.g. when the prefix changes rapidly too), close to >>zero in others (e.g. when your prefix is nearly static). > > The use of temporary addresses in IPv6 will make it somewhat harder for > servers to track information about individual IPv6 hosts. They could > still store tracking information based on the prefix, but they would > not know if the prefix refers to a single host or a large multi-user > network. I think perhaps the point is that if users (households, for example) are assigned prefixes, rather than addresses, then if that prefix assignment is pretty static, having a random interface identifier does little to hide the identity of the household. So, while random interface identifiers may make the full address in IPv6 less predictable than in IPv4, the prefix assignment policies of the network provider may make that a cause the upper 64 bits to be just as identifying as typical IPv4 addresses. I'm not sure it's likely to be worse than v4, but I think its unlikely to be any better since we're recommending households get assigned a subnet in v6, the way they are assigned an address in v4. It depends on the amount of prefix affinity the network provider enforces/allows. -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 13:24:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKOXwf011573; Thu, 29 Aug 2002 13:24:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TKOXIE011572; Thu, 29 Aug 2002 13:24:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKORwf011565 for ; Thu, 29 Aug 2002 13:24:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07590 for ; Thu, 29 Aug 2002 13:24:39 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24151 for ; Thu, 29 Aug 2002 14:24:39 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7TKOH3x004841; Thu, 29 Aug 2002 13:24:17 -0700 (PDT) Received: from [10.34.255.54] (stealth-10-34-255-54.cisco.com [10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AEM79368; Thu, 29 Aug 2002 13:22:39 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <3D6E7FEA.80204@cisco.com> References: <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> <4.2.2.20020829154541.02cb7340@mail.windriver.com> <3D6E7FEA.80204@cisco.com> Date: Thu, 29 Aug 2002 13:24:17 -0700 To: Josh Littlefield From: Steve Deering Subject: Re: IPv6 Interview Questions and critic Cc: Margaret Wasserman , Pekka Savola , Thomas Narten , Joe Baptista , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:11 PM -0400 8/29/02, Josh Littlefield wrote: >I'm not sure it's likely to be worse than v4, but I think its unlikely to be any better since we're recommending households get assigned a subnet in v6, the way they are assigned an address in v4. One somewhat mitigating factor (regardless of IP version) would be the growth of the number of Internet users and devices within a household (i.e., it won't be just a single PC), which would dilute the ability to identify a particular device or user by prefix alone. However, there'll still probably be lots of other ways for web sites, etc. to correlate different sessions back to a single user or device, e.g., through the use of cookies or statistical correlation or whatever. If you really need or want anonymity, you'll probably have to do it with the help of services (anonymizers) specifically designed for that purpose. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 13:30:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKU9wf011628; Thu, 29 Aug 2002 13:30:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TKU9BD011627; Thu, 29 Aug 2002 13:30:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKU4wf011620 for ; Thu, 29 Aug 2002 13:30:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14840 for ; Thu, 29 Aug 2002 13:30:16 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12630 for ; Thu, 29 Aug 2002 13:30:15 -0700 (PDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id QAA23363 for ; Thu, 29 Aug 2002 16:30:14 -0400 (EDT) From: "Subrata Goswami" Cc: Subject: RE: IPv6 Interview Questions and critic Date: Thu, 29 Aug 2002 13:30:07 -0700 Message-ID: <00e901c24f9a$ddf40570$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does not the telephone network (both wireless and wireline) all ready track the user more completely than IPv6? -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Steve Deering Sent: Thursday, August 29, 2002 1:11 PM To: Pekka Savola Cc: Thomas Narten; Joe Baptista; ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic At 10:27 PM +0300 8/29/02, Pekka Savola wrote: >Belief that by randomly regenerating only the interface identifier part of >the address will give you privacy is IMO false. Pekka, I don't think anyone has made such a broad claim. The random interface ID mechanism addresses the specific privacy concerns raised by using IIDs derived from IEEE-802 or EUI-64 addresses (or other factory-assigned serial numbers), such as those concerns mentioned in Joe's message: At 10:41 AM -0400 8/27/02, Joe Baptista wrote: > fears abuse as a hardware ID wired into the ipv6 protocol can >be used to determine the manufacturer, make and model number, and value >of the hardware equipment being used by the end user. >... >...Under Ipv6 users can be tracked and income >demographics determined through hardware identification. >... > warns users to think twice before they buy themselves a used >Lap-Top computer and inherit all the prior surfing history of the >previous user... Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 13:40:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKeFwf011680; Thu, 29 Aug 2002 13:40:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TKeFjf011679; Thu, 29 Aug 2002 13:40:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKeAwf011672 for ; Thu, 29 Aug 2002 13:40:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19353 for ; Thu, 29 Aug 2002 13:40:22 -0700 (PDT) Received: from roam.psg.com (wireless251.east.isi.edu [65.123.202.251]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22299 for ; Thu, 29 Aug 2002 14:40:21 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17kW5S-0006bg-00; Thu, 29 Aug 2002 13:40:19 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Subrata Goswami" Cc: Subject: RE: IPv6 Interview Questions and critic References: <00e901c24f9a$ddf40570$0200a8c0@SGOSWAMIPCL> Message-Id: Date: Thu, 29 Aug 2002 13:40:19 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does not the telephone network (both wireless and wireline) all ready > track the user more completely than IPv6? i don't think the goal here is to emulate the phone network, let alone it's possible mis-features. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 13:46:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKk8wf011735; Thu, 29 Aug 2002 13:46:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TKk810011734; Thu, 29 Aug 2002 13:46:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKk2wf011727 for ; Thu, 29 Aug 2002 13:46:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21652 for ; Thu, 29 Aug 2002 13:46:14 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17818 for ; Thu, 29 Aug 2002 14:46:11 -0600 (MDT) Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.6.R) for ; Thu, 29 Aug 2002 22:49:31 +0200 Message-ID: <001f01c24f9d$83cc0180$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: "Margaret Wasserman" , Cc: "Pekka Savola" , "Thomas Narten" , "Steve Deering" , "Joe Baptista" , References: <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> <4.2.2.20020829154541.02cb7340@mail.windriver.com> <3D6E7FEA.80204@cisco.com> Subject: Re: IPv6 Interview Questions and critic Date: Thu, 29 Aug 2002 22:49:03 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Josh, That's a very good rational. But also we can consider IPsec. In IPv4 world, most of the users don't have an IPsec capable router in their access to the ISP network. In IPv6, they have the option to enable it or not, but the security features are at least there. Also, the users always have the option to use proxies, personal firewalls, or anything like that, same as today is already being used. And of course, we need to consider the lots of advantages that IPv6 bring, specially for the home users, things like autoconfiguration, that will facilitate their life. Regards, Jordi ----- Original Message ----- From: "Josh Littlefield" To: "Margaret Wasserman" Cc: "Pekka Savola" ; "Thomas Narten" ; "Steve Deering" ; "Joe Baptista" ; Sent: Thursday, August 29, 2002 10:11 PM Subject: Re: IPv6 Interview Questions and critic > Margaret Wasserman wrote: > >>How much this will help you depends on the circumstances. It could help a > >>lot in some cases (e.g. when the prefix changes rapidly too), close to > >>zero in others (e.g. when your prefix is nearly static). > > > > The use of temporary addresses in IPv6 will make it somewhat harder for > > servers to track information about individual IPv6 hosts. They could > > still store tracking information based on the prefix, but they would > > not know if the prefix refers to a single host or a large multi-user > > network. > > I think perhaps the point is that if users (households, for example) are > assigned prefixes, rather than addresses, then if that prefix assignment is > pretty static, having a random interface identifier does little to hide the > identity of the household. > > So, while random interface identifiers may make the full address in IPv6 > less predictable than in IPv4, the prefix assignment policies of the network > provider may make that a cause the upper 64 bits to be just as identifying > as typical IPv4 addresses. > > I'm not sure it's likely to be worse than v4, but I think its unlikely to be > any better since we're recommending households get assigned a subnet in v6, > the way they are assigned an address in v4. It depends on the amount of > prefix affinity the network provider enforces/allows. > > -josh > > -- > ===================================================================== > Josh Littlefield Cisco Systems, Inc. > joshl@cisco.com 250 Apollo Drive > tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 13:49:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKnNwf011767; Thu, 29 Aug 2002 13:49:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TKnNnI011766; Thu, 29 Aug 2002 13:49:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKnHwf011759 for ; Thu, 29 Aug 2002 13:49:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22887 for ; Thu, 29 Aug 2002 13:49:30 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08906 for ; Thu, 29 Aug 2002 14:49:29 -0600 (MDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id QAA27371 for ; Thu, 29 Aug 2002 16:49:28 -0400 (EDT) From: "Subrata Goswami" Cc: Subject: RE: IPv6 Interview Questions and critic Date: Thu, 29 Aug 2002 13:49:20 -0700 Message-ID: <00ea01c24f9d$8d74d860$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was just pointing out that user tracking at large scale has a precedence. I do not remember recommending emulating the PSTN. -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Randy Bush Sent: Thursday, August 29, 2002 1:40 PM To: Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Interview Questions and critic > Does not the telephone network (both wireless and wireline) all ready > track the user more completely than IPv6? i don't think the goal here is to emulate the phone network, let alone it's possible mis-features. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 13:55:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKtNwf011847; Thu, 29 Aug 2002 13:55:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TKtNJG011846; Thu, 29 Aug 2002 13:55:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TKtGwf011826 for ; Thu, 29 Aug 2002 13:55:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25743 for ; Thu, 29 Aug 2002 13:55:28 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22289 for ; Thu, 29 Aug 2002 14:55:25 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.187.230) by smtp1.libero.it (6.5.028) id 3D6B8BC4001004EA; Thu, 29 Aug 2002 22:55:02 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 85D5D296DC; Thu, 29 Aug 2002 22:43:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 400BE28F76; Thu, 29 Aug 2002 22:43:34 +0200 (CEST) Date: Thu, 29 Aug 2002 22:43:34 +0200 (CEST) From: Mauro Tortonesi To: Steve Deering Cc: Joe Baptista , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 29 Aug 2002, Steve Deering wrote: > At 10:41 AM -0400 8/27/02, Joe Baptista wrote: > >However IPv6 has many privacy issues. IPv6 address space uses an ID > >(indentifier) derived from your hardware or phone. "That allows your > >packets to be traced back to your PC or cell-phone" said . > > fears abuse as a hardware ID wired into the ipv6 protocol can > >be used to determine the manufacturer, make and model number, and value > >of the hardware equipment being used by the end user. > > Joe, > > This issue was addressed a *long* time ago -- please see > http://playground.sun.com/ipv6/specs/ipv6-address-privacy.html > from November of 1999. Your source has either a very shallow > or out-of-date understanding of IPv6, or some reason to want to > propagate misinformation. Thanks for checking here. i don't think so. even if rfc3041 effectively solves the problem of traceability at the network layer, there are still many security problems to be solved. please take a look at this paper, which provides a somewhat more articulated explanation of the problem, a few proposal to address it and an excellent bibliography: ftp://ftp.cs.unibo.it/pub/techreports/2002-08.ps.gz -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it mauro.tortonesi@ing.unife.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 14:22:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TLM5wf012018; Thu, 29 Aug 2002 14:22:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TLM5Jd012017; Thu, 29 Aug 2002 14:22:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TLM0wf012009 for ; Thu, 29 Aug 2002 14:22:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07496 for ; Thu, 29 Aug 2002 14:22:10 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05565 for ; Thu, 29 Aug 2002 15:22:04 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7TLLg3x006804; Thu, 29 Aug 2002 14:21:42 -0700 (PDT) Received: from [10.34.255.54] (stealth-10-34-255-54.cisco.com [10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AEM81252; Thu, 29 Aug 2002 14:20:04 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 29 Aug 2002 14:21:42 -0700 To: Mauro Tortonesi From: Steve Deering Subject: Re: IPv6 Interview Questions and critic Cc: Joe Baptista , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:43 PM +0200 8/29/02, Mauro Tortonesi wrote: >On Thu, 29 Aug 2002, Steve Deering wrote: > > At 10:41 AM -0400 8/27/02, Joe Baptista wrote: > > > ...IPv6 address space uses an ID > > >(indentifier) derived from your hardware or phone. "That allows your > > >packets to be traced back to your PC or cell-phone" said . > > > fears abuse as a hardware ID wired into the ipv6 protocol can > > >be used to determine the manufacturer, make and model number, and value > > >of the hardware equipment being used by the end user. > > > > This issue was addressed a *long* time ago -- please see > > http://playground.sun.com/ipv6/specs/ipv6-address-privacy.html > > from November of 1999. > >i don't think so. even if rfc3041 effectively solves the problem of >traceability at the network layer, there are still many security problems >to be solved. Mauro, I believe RFC3041 solves the security problems that arise specifically from using an "ID derived from your hardware or phone", by simply not using such an ID. That's all I was talking about, and that's the topic of the referenced Privacy Statement (and the topic of Joe Baptista's article). Of course there are still many other traceability/privacy/security issues to be solved (none of which, I believe, are specific to IPv6), and I apologize if I gave the impression that I was asserting otherwise. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 15:10:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TMA3wf012218; Thu, 29 Aug 2002 15:10:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TMA2NM012217; Thu, 29 Aug 2002 15:10:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TM9rwf012206 for ; Thu, 29 Aug 2002 15:09:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11815 for ; Thu, 29 Aug 2002 15:10:04 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27859 for ; Thu, 29 Aug 2002 16:10:02 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7TM9f016395; Thu, 29 Aug 2002 18:09:42 -0400 (EDT) Message-Id: <200208292209.g7TM9f016395@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mauro Tortonesi cc: Steve Deering , Joe Baptista , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic In-reply-to: (Your message of "Thu, 29 Aug 2002 22:43:34 +0200.") Date: Thu, 29 Aug 2002 18:09:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk it's certainly the case that neither IPv4 nor IPv6 is perfectly untracable. frankly, it's difficult to see how the network can be made untracable given that - we're doing routing using network addresses that are organized (at least loosely) according to network topology, and which need to be relatively stable - and we haven't found a way to route opaque addresses (i.e. addresses that aren't organized according to network topology that scales.) - many useful applications need to be able to accept unsolicited traffic - there's no way to locate services on a large scale without stable names (at some level) being associated with those services - at some level the user's network terminal is necessarily going to interact/authenticate with a network element that is not under that user's control, and which therefore may not be trustworthy. but this isn't really an IPv4 vs. IPv6 issue. IPv6 provides more ability to protect users' privacy than IPv4. Keth -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 16:17:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TNHUwf012410; Thu, 29 Aug 2002 16:17:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TNHU0Z012409; Thu, 29 Aug 2002 16:17:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TNHOwf012402 for ; Thu, 29 Aug 2002 16:17:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01568 for ; Thu, 29 Aug 2002 16:17:35 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02208 for ; Thu, 29 Aug 2002 16:17:34 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E283F4B22 for ; Fri, 30 Aug 2002 08:17:27 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: another input to IPv6 addressing architecture From: itojun@iijlab.net Date: Fri, 30 Aug 2002 08:17:27 +0900 Message-Id: <20020829231727.E283F4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i have another input to IPv6 addressing architecture, which is very securty-sensitive. please review and integrate it before publishing the next one. draft-itojun-v6ops-v4mapped-harmful-00.txt itojun --- 4. Suggested protocol change o In IPv4 address architecture document [Hinden, 1998] explicitly state that IPv4 mapped address is for use within basic API [Gilligan, 1999] , and basic API only. Forbid any other uses. o Move any document that suggests the use of IPv4 mapped address on wire to historic, due to security reasons. The above change will remove the threat due to the use of IPv4 mapped address on wire. Another way is to deprecate RFC2553 section 3.7, however, due to the wide deployment of applications that use IPv6 basic API, the option is not feasible. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 23:16:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U6GJwf013221; Thu, 29 Aug 2002 23:16:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7U6GJ21013220; Thu, 29 Aug 2002 23:16:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U6GEwf013213 for ; Thu, 29 Aug 2002 23:16:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7U6GPJf004790 for ; Thu, 29 Aug 2002 23:16:25 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22466 for ; Fri, 30 Aug 2002 00:16:19 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7U6G1t12640; Fri, 30 Aug 2002 09:16:02 +0300 Date: Fri, 30 Aug 2002 09:16:01 +0300 (EEST) From: Pekka Savola To: Steve Deering cc: Thomas Narten , Joe Baptista , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 29 Aug 2002, Steve Deering wrote: > At 10:27 PM +0300 8/29/02, Pekka Savola wrote: > >Belief that by randomly regenerating only the interface identifier part of > >the address will give you privacy is IMO false. > > Pekka, > > I don't think anyone has made such a broad claim. > > The random interface ID mechanism addresses the specific privacy > concerns raised by using IIDs derived from IEEE-802 or EUI-64 > addresses (or other factory-assigned serial numbers), such as those > concerns mentioned in Joe's message: [...] Ok, sorry -- I didn't read the scope of Joe's claims carefully enough. Whether RFC3041 is too complex mechanism for some of the needs is a different thing though. I think "randomizing" your MAC address once and for all (or every time your computer restarts or whatever) should be enough for most. But I think that's implied if not written in the RFC. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 29 23:18:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U6Iwwf013262; Thu, 29 Aug 2002 23:18:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7U6IwC1013261; Thu, 29 Aug 2002 23:18:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U6Iqwf013250 for ; Thu, 29 Aug 2002 23:18:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09795 for ; Thu, 29 Aug 2002 23:19:03 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06937 for ; Fri, 30 Aug 2002 00:19:02 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7U6IeJ12666; Fri, 30 Aug 2002 09:18:41 +0300 Date: Fri, 30 Aug 2002 09:18:40 +0300 (EEST) From: Pekka Savola To: Scott Bradner cc: narten@us.ibm.com, , , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: <200208291937.g7TJbIJO001626@newdev.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 29 Aug 2002, Scott Bradner wrote: > Thomas asked for IPv6 specific problems - it seems like you are > complaining about how teh basic Internet works - maybe I'm missing it > but what is IPv6 specific in your problem other than the ability > (not in IPv4) to have a random host-part of the address when > you start a session? I do not see real problems with the protocol, but mainly how it's used (and how it's advocated to solve some problems like privacy). If ISP's assign /48 prefixes to homes, those will be trackable. RIR's also have expressed a requirement to have contact information etc. for every prefix in the WHOIS database. > >From owner-ipng@sunroof.eng.sun.com Thu Aug 29 15:32:53 2002 > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > Date: Thu, 29 Aug 2002 22:27:30 +0300 (EEST) > From: Pekka Savola > To: Thomas Narten > cc: Steve Deering , Joe Baptista , > > Subject: Re: IPv6 Interview Questions and critic > In-Reply-To: <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-ipng@sunroof.eng.sun.com > Precedence: bulk > > On Thu, 29 Aug 2002, Thomas Narten wrote: > > > Only parts of "this issue" were properly fixed. Indeed, some (mostly > > > related to user tracking) seem to be unfixable. > > > > Please clarify. Are there existing problems in IPv6 that we have > > neglected to fix that you believe we can fix? > > > > Or are there all sorts of problems in general (not IPv6-specific) that > > are hard and not easily fixable (a position I would agree with). > > Belief that by randomly regenerating only the interface identifier part of > the address will give you privacy is IMO false. > > How much this will help you depends on the circumstances. It could help a > lot in some cases (e.g. when the prefix changes rapidly too), close to > zero in others (e.g. when your prefix is nearly static). > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 00:29:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U7Tswf013357; Fri, 30 Aug 2002 00:29:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7U7TsQG013356; Fri, 30 Aug 2002 00:29:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U7Tnwf013349 for ; Fri, 30 Aug 2002 00:29:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25139 for ; Fri, 30 Aug 2002 00:29:58 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA00174 for ; Fri, 30 Aug 2002 01:29:56 -0600 (MDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id DA67A16; Fri, 30 Aug 2002 00:29:54 -0700 (PDT) Date: Fri, 30 Aug 2002 00:29:54 -0700 From: David Terrell To: Pekka Savola Cc: Joe Baptista , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic Message-ID: <20020830072954.GA9698@pianosa.catch22.org> Reply-To: David Terrell References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:20AM up 2 days, 31 mins, 14 users, load averages: 0.49, 0.36, 0.32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Aug 29, 2002 at 10:10:32PM +0300, Pekka Savola wrote: > On Thu, 29 Aug 2002, Steve Deering wrote: > > This issue was addressed a *long* time ago -- please see > > http://playground.sun.com/ipv6/specs/ipv6-address-privacy.html > > from November of 1999. Your source has either a very shallow > > or out-of-date understanding of IPv6, or some reason to want to > > propagate misinformation. Thanks for checking here. > > Only parts of "this issue" were properly fixed. Indeed, some (mostly > related to user tracking) seem to be unfixable. > > Thanks for checking the rfc3041 considered harmful draft. Interesting read. A few points -- The idea that attackers could use privacy addresses to obscure the source of attacks is interesting, but that's really an artifact of the /64 prefix per link; conversely, uRPF checks should be enough to quickly locate an administrative contact for the site in question at least -- spoofed packets are a problem when you cannot identify the source at all. It would be nice to see CPE routers perhaps track ethernet addresses and map privacy addresses to local interfaces and log that information to a local host for perusal later during a security incident analysis, but otherwise I don't see how 3041 isn't an adequate answer to the specific problem of "privacy in IPv6 as related to using EUI-64", not the wider problem of "general privacy in IPv6." That's a much harder problem to solve. -- David Terrell | "... a grandiose, wasteful drug war that will never dbt@meat.net | be won as long as so many Americans need to Nebcorp Prime Minister | anesthetize themselves to get through the day." http://wwn.nebcorp.com/ | -Camille Paglia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 00:39:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U7dJwf013383; Fri, 30 Aug 2002 00:39:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7U7dJp6013382; Fri, 30 Aug 2002 00:39:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U7dDwf013375 for ; Fri, 30 Aug 2002 00:39:13 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7U7dNJf015996 for ; Fri, 30 Aug 2002 00:39:23 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22221 for ; Fri, 30 Aug 2002 00:39:17 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7U7cph07288; Fri, 30 Aug 2002 09:38:51 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA20721; Fri, 30 Aug 2002 09:38:51 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7U7cn6o037339; Fri, 30 Aug 2002 09:38:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208300738.g7U7cn6o037339@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Thomas Narten cc: Pekka Savola , Steve Deering , Joe Baptista , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic In-reply-to: Your message of Thu, 29 Aug 2002 15:13:40 EDT. <200208291913.g7TJDeX03287@rotala.raleigh.ibm.com> Date: Fri, 30 Aug 2002 09:38:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Only parts of "this issue" were properly fixed. Indeed, some (mostly > related to user tracking) seem to be unfixable. Please clarify. Are there existing problems in IPv6 that we have neglected to fix that you believe we can fix? Or are there all sorts of problems in general (not IPv6-specific) that are hard and not easily fixable (a position I would agree with). => the second IMHO. In fact the real problem (true anonymity) is very hard to solve (and is not even IP-specific). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 00:52:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U7qqwf013438; Fri, 30 Aug 2002 00:52:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7U7qqcU013437; Fri, 30 Aug 2002 00:52:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U7qkwf013430 for ; Fri, 30 Aug 2002 00:52:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7U7quuH021331 for ; Fri, 30 Aug 2002 00:52:56 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29195 for ; Fri, 30 Aug 2002 01:52:50 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7U7qV413501; Fri, 30 Aug 2002 10:52:31 +0300 Date: Fri, 30 Aug 2002 10:52:31 +0300 (EEST) From: Pekka Savola To: David Terrell cc: Joe Baptista , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: <20020830072954.GA9698@pianosa.catch22.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 30 Aug 2002, David Terrell wrote: > > Thanks for checking the rfc3041 considered harmful draft. > > Interesting read. A few points -- > The idea that attackers could use privacy addresses to obscure the > source of attacks is interesting, but that's really an artifact of > the /64 prefix per link; conversely, uRPF checks should be enough to > quickly locate an administrative contact for the site in question > at least -- spoofed packets are a problem when you cannot identify > the source at all. Experience has shown (i.e. looking how far wrongly source addressed packets arrive in our network) that uRPF or any kind of acl'ing is not all that commonplace. > It would be nice to see CPE routers perhaps track ethernet addresses > and map privacy addresses to local interfaces and log that information > to a local host for perusal later during a security incident analysis, > but otherwise I don't see how 3041 isn't an adequate answer to the > specific problem of "privacy in IPv6 as related to using EUI-64", > not the wider problem of "general privacy in IPv6." That's a much > harder problem to solve. I think the problem is more of a generic sort. Consider often-seen discussion: Q: IPv6 address is quite long, it has MAC-address based part etc. Isn't it trackable..? A: Look at RFC3041! I.e. RFC3041 is often provided as a patch-all for everything about privacy. When people use RFC3041, they may think they're "safe". That's wrong. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 00:59:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U7xFwf013463; Fri, 30 Aug 2002 00:59:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7U7xFVQ013462; Fri, 30 Aug 2002 00:59:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U7xAwf013455 for ; Fri, 30 Aug 2002 00:59:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01545 for ; Fri, 30 Aug 2002 00:59:20 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03064 for ; Fri, 30 Aug 2002 01:59:19 -0600 (MDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 8EE6216; Fri, 30 Aug 2002 00:59:18 -0700 (PDT) Date: Fri, 30 Aug 2002 00:59:18 -0700 From: David Terrell To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic Message-ID: <20020830075917.GA12303@pianosa.catch22.org> Reply-To: David Terrell References: <20020830072954.GA9698@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:57AM up 2 days, 1:08, 11 users, load averages: 0.31, 0.29, 0.31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Aug 30, 2002 at 10:52:31AM +0300, Pekka Savola wrote: > > but otherwise I don't see how 3041 isn't an adequate answer to the > > specific problem of "privacy in IPv6 as related to using EUI-64", > > not the wider problem of "general privacy in IPv6." That's a much > > harder problem to solve. > > I think the problem is more of a generic sort. Consider > often-seen discussion: > > Q: IPv6 address is quite long, it has MAC-address based part etc. Isn't > it trackable..? > A: Look at RFC3041! > > I.e. RFC3041 is often provided as a patch-all for everything about > privacy. When people use RFC3041, they may think they're "safe". That's > wrong. The solution there is not to bash 3041, it's to come up with a more broad-based anonymity architecture. In the meantime, every time someone pops up saying "oh no, hardware based addresses reveal your secret MAC ADDRESS", 3041 is an answer. It's not a great answer, but it's a pretty stupid question. -- David Terrell | "To increase the hype, I'm gonna release a bunch Nebcorp PM | of BLT variants (NetBLT, FreeBLT, BLT386, etc) dbt@meat.net | and create artificial rivalries." wwn.nebcorp.com | - Brian Swetland (www.openblt.org) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 01:47:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U8lZwf013543; Fri, 30 Aug 2002 01:47:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7U8lYQ7013542; Fri, 30 Aug 2002 01:47:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U8lTwf013535 for ; Fri, 30 Aug 2002 01:47:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13309 for ; Fri, 30 Aug 2002 01:47:39 -0700 (PDT) Received: from babingka.lava.net (babingka.lava.net [64.65.64.26]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20686 for ; Fri, 30 Aug 2002 01:47:39 -0700 (PDT) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by babingka.lava.net (Postfix) with ESMTP id C7EB1133B0; Thu, 29 Aug 2002 22:47:38 -1000 (HST) Date: Thu, 29 Aug 2002 22:47:38 -1000 (HST) From: Antonio Querubin To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: another input to IPv6 addressing architecture In-Reply-To: <20020829231727.E283F4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 30 Aug 2002 itojun@iijlab.net wrote: > 4. Suggested protocol change > > o In IPv4 address architecture document [Hinden, 1998] explicitly state > that IPv4 mapped address is for use within basic API [Gilligan, 1999] > , and basic API only. Forbid any other uses. You may recall someone (maybe it was you?) had suggested the issue of using 'multicast' IPv4 mapped addresses in the API be handled in a separate document rather than in the basic API. It sounds like the above suggestion would prevent that from happening at all if we ever came to some agreement on the finer details. > o Move any document that suggests the use of IPv4 mapped address on wire > to historic, due to security reasons. > > The above change will remove the threat due to the use of IPv4 mapped > address on wire. This sounds reasonable. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 03:39:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UAdxwf013675; Fri, 30 Aug 2002 03:39:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UAdxY2013674; Fri, 30 Aug 2002 03:39:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UAdrwf013667 for ; Fri, 30 Aug 2002 03:39:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UAe3uH014152 for ; Fri, 30 Aug 2002 03:40:03 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08214 for ; Fri, 30 Aug 2002 04:39:57 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g7UAbnG04592; Fri, 30 Aug 2002 06:37:50 -0400 Message-Id: <200208301037.g7UAbnG04592@cichlid.adsl.duke.edu> To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic In-Reply-To: Message from Pekka Savola of "Fri, 30 Aug 2002 09:18:40 +0300." Date: Fri, 30 Aug 2002 06:37:49 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola writes: > If ISP's assign /48 prefixes to homes, those will be trackable. RIR's > also have expressed a requirement to have contact information etc. for > every prefix in the WHOIS database. RIRs need to be able to verify that an ISP really does have all the customers they say they have. An ISP doesn't get more address space if its not using its existing address space properly. Detailed information such as contact information about individual /48 ownership does not need to be publically available; the recently-adopted RIR policies are clear about that. Indeed, there may be country-specific laws that apply that would make that a bad idea. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 04:10:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UBAjwf013719; Fri, 30 Aug 2002 04:10:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UBAiwl013718; Fri, 30 Aug 2002 04:10:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UBAcwf013711 for ; Fri, 30 Aug 2002 04:10:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UBAmJf014884 for ; Fri, 30 Aug 2002 04:10:48 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21083 for ; Fri, 30 Aug 2002 05:10:42 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7UBAXh27603; Fri, 30 Aug 2002 13:10:34 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA22675; Fri, 30 Aug 2002 13:10:34 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7UBAW6o037869; Fri, 30 Aug 2002 13:10:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208301110.g7UBAW6o037869@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: another input to IPv6 addressing architecture In-reply-to: Your message of Fri, 30 Aug 2002 08:17:27 +0900. <20020829231727.E283F4B22@coconut.itojun.org> Date: Fri, 30 Aug 2002 13:10:32 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 4. Suggested protocol change o In IPv4 address architecture document [Hinden, 1998] explicitly state that IPv4 mapped address is for use within basic API [Gilligan, 1999] , and basic API only. Forbid any other uses. => I don't like at all SIIT so I have no concern with this proposal. o Move any document that suggests the use of IPv4 mapped address on wire to historic, due to security reasons. => you are a bit hard: these mechanisms should simply use other injections of the IPv4 address space into the IPv6 address space (there are many ways to inject a 2^32 space into a 2^128 one :-). The above change will remove the threat due to the use of IPv4 mapped address on wire. => I agree this should be simpler so safer. Another way is to deprecate RFC2553 section 3.7, however, due to the wide deployment of applications that use IPv6 basic API, the option is not feasible. => I strongly object to this part of your proposal. IMHO IPv6 is NOT a new protocol, it is only a new version of the IP protocol. So the right target is to provide an "all version" API, as it is easy to inject IPv4 into IPv6, the section 3.7 is the right idea! Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 04:50:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UBoUwf013797; Fri, 30 Aug 2002 04:50:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UBoT8n013796; Fri, 30 Aug 2002 04:50:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UBoNwf013789 for ; Fri, 30 Aug 2002 04:50:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UBoXJf019695 for ; Fri, 30 Aug 2002 04:50:33 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19483 for ; Fri, 30 Aug 2002 05:50:27 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12092; Fri, 30 Aug 2002 07:48:54 -0400 (EDT) Message-Id: <200208301148.HAA12092@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-daley-ipv6-mcast-dad-00.txt Date: Fri, 30 Aug 2002 07:48:53 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery Author(s) : G. Daley, R. Nelson Filename : draft-daley-ipv6-mcast-dad-00.txt Pages : 12 Date : 2002-8-29 This draft describes a possible optimization to Duplicate Address Detection (DAD) which can be used to successfully terminate DAD early, based on the presence of listeners on the link-scope solicited nodes multicast address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-daley-ipv6-mcast-dad-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-daley-ipv6-mcast-dad-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-29142157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daley-ipv6-mcast-dad-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-daley-ipv6-mcast-dad-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-29142157.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 05:05:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UC5swf013858; Fri, 30 Aug 2002 05:05:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UC5ssK013857; Fri, 30 Aug 2002 05:05:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UC5lwf013847 for ; Fri, 30 Aug 2002 05:05:47 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27829 for ; Fri, 30 Aug 2002 05:05:57 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26331 for ; Fri, 30 Aug 2002 06:05:57 -0600 (MDT) Received: from kenawang ([147.11.233.15]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA28058; Fri, 30 Aug 2002 05:05:16 -0700 (PDT) Message-Id: <4.2.2.20020830080316.02caf630@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 30 Aug 2002 08:05:21 -0400 To: itojun@iijlab.net From: Margaret Wasserman Subject: Re: another input to IPv6 addressing architecture Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020829231727.E283F4B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, >o In IPv4 address architecture document [Hinden, 1998] explicitly state > that IPv4 mapped address is for use within basic API [Gilligan, 1999] > , and basic API only. Forbid any other uses. I don't have a problem with this concept. In fact, I thought that we had two ways to include an IPv4 address in an IPv6 address because one was meant to be used on the wire and the other was not. Was I confused? >o Move any document that suggests the use of IPv4 mapped address on wire > to historic, due to security reasons. Which documents would this include? SIIT? Any others? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 05:16:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UCGLwf013892; Fri, 30 Aug 2002 05:16:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UCGKJL013891; Fri, 30 Aug 2002 05:16:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UCGFwf013884 for ; Fri, 30 Aug 2002 05:16:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UCGQJf022854 for ; Fri, 30 Aug 2002 05:16:26 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23317 for ; Fri, 30 Aug 2002 05:16:20 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7UCG5W15664; Fri, 30 Aug 2002 15:16:05 +0300 Date: Fri, 30 Aug 2002 15:16:04 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: itojun@iijlab.net, Subject: Re: another input to IPv6 addressing architecture In-Reply-To: <4.2.2.20020830080316.02caf630@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 30 Aug 2002, Margaret Wasserman wrote: > >o In IPv4 address architecture document [Hinden, 1998] explicitly state > > that IPv4 mapped address is for use within basic API [Gilligan, 1999] > > , and basic API only. Forbid any other uses. > > I don't have a problem with this concept. In fact, I thought that we > had two ways to include an IPv4 address in an IPv6 address because one > was meant to be used on the wire and the other was not. Was I confused? You probably thought: 1) mapped address --> API 2) compatible address --> on the wire But 2) no longer holds and people only see "1)" as the only "standard way" to get to their goals. > >o Move any document that suggests the use of IPv4 mapped address on wire > > to historic, due to security reasons. > > Which documents would this include? SIIT? Only non-algorithmic portions of SIIT. (Or else NAT-PT should have to be rewritten to be independent). > Any others? The -00 nat64-nat46 draft. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 06:24:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UDOfwf013992; Fri, 30 Aug 2002 06:24:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UDOf40013991; Fri, 30 Aug 2002 06:24:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UDOZwf013984 for ; Fri, 30 Aug 2002 06:24:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16366 for ; Fri, 30 Aug 2002 06:24:46 -0700 (PDT) Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21109 for ; Fri, 30 Aug 2002 07:24:45 -0600 (MDT) Received: from repligate ([67.37.180.69]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020830132442.HETI18992.mailhost.chi1.ameritech.net@repligate>; Fri, 30 Aug 2002 08:24:42 -0500 Message-ID: <119e01c25028$b067c5e0$8c56fea9@repligate> From: "Jim Fleming" To: "Francis Dupont" , "Thomas Narten" Cc: "Pekka Savola" , "Steve Deering" , "Joe Baptista" , References: <200208300738.g7U7cn6o037339@givry.rennes.enst-bretagne.fr> Subject: Re: IPv6 Interview Questions and critic Date: Fri, 30 Aug 2002 08:25:19 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_119B_01C24FFE.C6C37160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_119B_01C24FFE.C6C37160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Francis Dupont" > > => the second IMHO. In fact the real problem (true anonymity) is > very hard to solve (and is not even IP-specific). > True anonymity is not hard to solve, if you start with an **architecture** that addresses it. By the way....IPv6 continues to crash... http://www.iht.com/articles/69229.html PARIS Europe's bold hopes for third-generation mobile-phone services have come crashing down to earth. By one estimate, perhaps half of the licenses that West European companies bought two years ago for fast networks will never be used - meaning $50 billion will have been spent for nothing." ================================ Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ------=_NextPart_000_119B_01C24FFE.C6C37160 Content-Type: image/gif; name="architech.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="architech.gif" R0lGODlh6wLHA/f/AAAAAAAAQAAAgAAA/wAgAAAgQAAggAAg/wBAAABAQABAgABA/wBgAABgQABg gABg/wCAAACAQACAgACA/wCgAACgQACggACg/wDAAADAQADAgADA/wD/AAD/QAD/gAD//yAAACAA QCAAgCAA/yAgACAgQCAggCAg/yBAACBAQCBAgCBA/yBgACBgQCBggCBg/yCAACCAQCCAgCCA/yCg ACCgQCCggCCg/yDAACDAQCDAgCDA/yD/ACD/QCD/gCD//0AAAEAAQEAAgEAA/0AgAEAgQEAggEAg /0BAAEBAQEBAgEBA/0BgAEBgQEBggEBg/0CAAECAQECAgECA/0CgAECgQECggECg/0DAAEDAQEDA gEDA/0D/AED/QED/gED//2AAAGAAQGAAgGAA/2AgAGAgQGAggGAg/2BAAGBAQGBAgGBA/2BgAGBg QGBggGBg/2CAAGCAQGCAgGCA/2CgAGCgQGCggGCg/2DAAGDAQGDAgGDA/2D/AGD/QGD/gGD//4AA AIAAQIAAgIAA/4AgAIAgQIAggIAg/4BAAIBAQIBAgIBA/4BgAIBgQIBggIBg/4CAAICAQICAgICA /4CgAICgQICggICg/4DAAIDAQIDAgIDA/4D/AID/QID/gID//6AAAKAAQKAAgKAA/6AgAKAgQKAg gKAg/6BAAKBAQKBAgKBA/6BgAKBgQKBggKBg/6CAAKCAQKCAgKCA/6CgAKCgQKCggKCg/6DAAKDA QKDAgKDA/6D/AKD/QKD/gKD//8AAAMAAQMAAgMAA/8AgAMAgQMAggMAg/8BAAMBAQMBAgMBA/8Bg AMBgQMBggMBg/8CAAMCAQMCAgMCA/8CgAMCgQMCggMCg/8DAAMDAQMDAgMDA/8D/AMD/QMD/gMD/ //8AAP8AQP8AgP8A//8gAP8gQP8ggP8g//9AAP9AQP9AgP9A//9gAP9gQP9ggP9g//+AAP+AQP+A gP+A//+gAP+gQP+ggP+g///AAP/AQP/AgP/A////AP//QP//gP///yH5BAEAAP8ALAAAAADrAscD QAj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypEmEAE6qXMmypcuX MGPKnEmzps2bHVNm1Imzp8+fQIMKHUq0qNGjA3leVNqSadKCTgVGXfoUqdWrWLNq3cq151SJX01O ZToWKoCzaKWiPZtwbVqCbtn+W9u1rt27ePOCTCn3INuwdQE/FEwyKlmUUCMehptYIWGrfcU+Xhi5 ZGW9mC2+nUuXr9rPb9NGDs1ZJ2nPpf9O1sw5aWjPqyfG9jgbcc3LZh03rspb6m7fjLfWnoka6fDM yJM75Bs37tznqZf2Pa6RenDl2Btaz96Uu/fvbVP+N/8Lna7m6TG3AwefXT379O/jJ2eu2m1r9+Fh uscvPyTu/gBqx1+ABEIk12Q8HTjegs3dtF+BMm1nnlq4mTchhQnCtVl0F7a1oWujMajUheNhaFaI JYJo34QkLkjZeTb9J2CMAwpV41EPQthddRt2SJl9P1bGIEMiCtnjkSh+1aBBQ6rI5GYsuqidXzo6 eNeNRuVYpVhbdrkRll6OBKaY8mkZ4JhUCgekk4p9mJ6bLol4XZhcjdikfmVWByGa+V1lYYriLRnd iaUViqRTUV4G6Jc4HnqnbGti6FyQclZUqZV75bnTnsTRiRefYjoqqIYJyjioiWz6BSebPvr45Kr+ tzEan5lDMechdIrZCGuhnuLZ668qSagpRqByZOup5KFZ7KbActnss2RC2xtrWQbaIGq7LjciVqZK K5tyUraYoouJTgflpdaa9lq3OHo7J7VF0TcktuwSue2nPwG2bK5T5tXhpJJGOuqakQYM8Kmpulqt u0zqWW2RsEVb5sGkFszSqCcqvNe+DGtVb8frUaVryC+2li7EFtPJsbErSwyyV4S+TJvDMlfZMo/z 1bwSqBq7S6usz9mKrcl/yhsorhT6tq7S5XV2c1ZPExt1hMYpOfW3al6N0886A6g1RR973bOBY9NW trbZdpn2wsR2rePXkLqNdJ1yE+kxzXX3Bzf+WHvb1XfbeffpJ96Bv/f3YId7mTjQZ97NbOGzcrv4 lpM/3jjUhEP+XeWOcc5pZp4H6zjgmrMXuqqlZ37l59yqnjq4KMcebOy012777bjnrixypzvbuuWv S9v727uDzvrgwAf/7PB7Fo8Z8y5D5rrynHZLHvWI7Xo96XpBL5L301rq8L2lAnkvcEsiaDDJxWX4 aqu6TZuh+3Ora75Pxybt2txbdx7+2TTJH7KKI7LnHU96ycNe9VDGPwUGjYFc89sBjTM9BPbpQMEp FW/MtcENug98H5GXnKhjmA72hn4oNOFuzqfBkKGQfg000MmcA0LRFaiGEQTXcpQnmhWtyGv+sfIh DWt4EiLmZHQFdKDhSijDJwWuQvzKzQ0n2K4EKlFtRlxir+jjvyyCBYnwuqLKvAiesOUpSfsjYxN/ xz0xupFvvFNjvmb4wzKCUXxv9A+vUBdDxclRijVTFB07Y7o7gi2PejQXB/uIxTgCy4yMEaIPC4k5 KyKybQxkpMF0p7vb/FFDZ1IPFNcISuNVso2X1FMmPQdJPtIIZ1s7XCux9xguomR70cNjKo11MvFo MoD6Mt4nSSadl3yQaSBaDxdh2J4dWo+A36vgLu11vh0m00GmmWYIAanNI05JdsXKYTeHNU7LlDM8 z/xlYsDpuyROkZS+y2bQSKVMQ4WvmOf+1GKzYnOYdC5mMPOsY2Gkabj7lAiX5Mynp4aJSRE6rX6D FM06HdpDTRpmQOLEnPXYF1GE2s2fQGGoQm3YPZPdiqIHnSjEIMrOTlnybook30R/xFIItkidOyri oVSlICPFFFW3NFW5FrUoak5KXOk76LmWWj4pbRJVAIyfv0w6wAfStJ+SrGgk9QUbCGbqpRpdaf3q 00NCbrWXZL3WTjC6s50izlWPCqpYB1kxp8o1Y0k62MCG+j6iuqlc7gxVETvaVadRjJgle8oQJ5nW h2Ipo61bJaEWK9GtrnSEIR0pyBiKUrVSVquM+qxqCIvTL4JVcg49Glv92VhoZlazC23+5rUm+TCu ljaKgW0UonCrP76llraC6+3ILlZPZLZwtyytimshiit5lke58lRXXzGIPuV+prnXTeErsfNX3u7R SrMVqDdR+bKymleAsYWnd9a2M8bBtr3hNevMTvve9dYXa6Gcny2hNCfpEi1pr0EsgSDLu4YlCzQu fK5/DxyxbIp0oN1bbmDuqzKCUjhMs7SMKGX54Avn8pAeVmKG49XhENfKwibO24iJsuIUlxfFLnZb i4cbY+oRuMZdm3FQdIxjaN24x7MqMTCBvDwYE7mMibPTafiXZCEfmb79sq9Un9swjiJNphmUGT8Z tuUnUxG/Xi5ka0erPqMCtUfvEq7+cG1JT8XajzBCU+ptw5wzKOOryvlD89Jc+KE+s7fCLSWboiq7 1DRfedDb+utoMvZNr9L5cuTVYXC/W03nIuy7l/YWep342OraxtB2s+amQPpoINo5a4eN8jkpaq05 pwm795FfHV9YPlC2ENZ/dvN5QVvqyJ3akPJLMKyte0IBY1nTrVarz3wp514nVJfODnLqeBzt1f26 2p9ycoS0je1QR7rbsONkqv0mbm6De9IgPrfPREptdfv62+5eKLvNHW9eXrveHvsbj9v9JXqr+8f4 tlGBTRlw4Ri54FQLs79TDHCEt/ffDsffwSN+K4rrZ+Gva3jEMd5jjud44vX2+KP+Rc5lkHdzWRh1 K6MvLa5Mv4+nSrYrUuu6155yNal5NZ9SY9pUFfn1qOsqi8U/nVsKozwnKhdQ2c42103OPFUIe7rL oX40nwtMr3zFa80RxdRXj5fIGh8nx0iucD0+Oewn99XQ49VOIKNdmxzG1HWUBOZ//k+oxc6y3q3M xBXuXcAahs/ZTQ73Ooe4mqKm2+DvnXYpe5mzjyf8NEk+TI9KcHORZ7yMaV5u2YE6ME1eq1fIGPPO 1+7zYnz7x33+gda7/vWwj73sZ/+B7q69oKynve53H3vb71L1Ois974fPe9/fHvO5J77yey/IyUue yatpfqhr+RvBS2r52H+98Y/+zx3hZz/72+8fN+1V5ekn3tXVhzaY0c9c86ua/dvcNjO5z13ikOa1 93w/9XFq9/Wr37TpN2VW1yS0E4DqBT9OZ3oKKChk8S9ZclHZxWohUlf740oVKCm29mZcdyQsFyXi R4Fzt4AieCkNGH4JFH0wVyQJSDHWAXxC521xUnT54Tz+93fvx2KDdl0mMi5JdUuUci5a11RAWIE8 +IHWRIMAmCZd9nWo14QQ9n/pFoVOCHht51uOpiycFD+dRUP0F00thYWdNIOkdSMvmFgxGEZomIRT GENh0YYC2IIjGIdyWIBDFiTXVGgRWGtUpSDXZFJDqIN7OBuLRFW8wm+WMof+iJiIGOM6+1d+XueI kNiCz9d/AIV6bhhckghtBLSJVwaJakdvhkh+M0JJUciJiZZmcDN/wDMclGiJbyiD3sVbrBiEpmeA XXiLyJd/MEhYt2OL5weF6lVFxnQsGCQ0AaVgzhUxuDhgxOhgsdZgSpOM8zRhpySFwLiM2JiNc6R5 azQ/+sOH/wU1QyNAdoKMx0gvCKaN3TeOe2hr0XiOTZOOkoZd9hOB2RUr3KiO+riP8Qdv/PiPABlN +RiQBFmQu3iNBpmQChmLNbiQz+aQ1keKsAiRuUiRCeeJVoaRMDOQFtkVndZqJoR4eKZXKlQWwQSS xdVfBghDItmJw7YYfXf+bO33cBrZivBHkxPZkfWnkxEJajbpdScZbO9ik8DHkwanQGSXU0R3g3kn lE6ZkWaYhkbZfQ6UlMT1bjmJYY3RYNHljEIyd/kXXcfId+YYUH/CNCUEjZ5WjH54TEzVlfZ0k2vI LCyJijN4VCo5bFSmiwyJW8lIXTCJl5EUkusjhk9INn6nQnppgUtZif44lQRnY1VZiltZmU1Id1LZ kJBpeJKJlA+pmZsZmupYlKJZmgVHmudRVHFlmqx5RagJjEQ5X3LZmha5hZU1cI/5YTM5lL64m/33 k6CziCg5jKlWVOAGl+F4PcoZjrHWnAymYHvphSrYYa+ZmQcJnL5ZfX/+tDhBKXe0OVCX1TQKyJfm xJGwZZXG9J2hZTXTGFVBRZ6HaZ0uhp4bqZ7fYliOBVRggx5ql5V51DO59ntCFYr6aDSz5SEIQqD+ eZCueYg5Z5yC5mcQWjEwt5/1AlcBepX+kTJt4p5r5aEpSHmfqYa0xCMPmjJ4eFdQB6BwInVRl3QU +i8kqGiAooJR2Zgs9ohsZ0BYKZ+QQ5+lo6CFQ0QYV52KN1gKCaQeKYwS6aMViaSoBXQnanOS5HMJ gy48aHMbmqThNKJ92aQ4+YA+JSpI5ShWSosuemYZqpG6gkYv14H8qZ/4aWYIKoRbB6LpaW+4l5sx ElHo1zdC2qCoRqH+b5U2MjqhnOdUNrqCgepe1uh4CxpAflobcqSkF2mfbPqLkOqk4DWd4ik1c4mP qcddBQOieLqhjdqTPvZ8xCUjB4ZpcQOfOUpBzPOVwUmlQ8WANGoo9UGovtoqwslGHWOk4OmpGihu oSqObSV6s8OnBGmpkSqAAheeFYo2wiM5YkoimTecguqs9Ac+qaqUF3Yca7pZrIpO8TiO0uWVaGmM aZSOz8mus/mkD7ipiMRh0Kqjjzqa2HpDqQiHnrRE2kas8Qau+QqaFpRxwEaiBdqvq0eNwYND54pw Bis3cxgnihiuOyqsnHqLFZtP7PZlGxutx/exq4abkIY83sp9Jlv+TiH7ThyLkNjYsmKHsqYWs/vK mgeLP0h4ZwO2sF9amjs7eroJsSmbsB3rkLYpX6MaaCTLpDersk+rhIWYolbFZr3lgHaoa+sUM30Y gA6mh8lFT0p2Vn06Zu66jZZJTKfaHWjbnCtLQTArtUlbMuSjSHnJZ2XbV69il7JWgjh6d8jFPriE ZjDjtPWprz2Xo4grs0f5s9VYt206bjeqsKRmoW3LsERKiJy2RSI7q3GLf49oadL4dzKZl2S3a6ol n2UYnWH5G60rlLErq7qRVbymOJ97YuZZoI21um8kQunCuZSTuwK3uwWpsTJ2sEt7m/YKtY67mcib Y8prUAcKikD+G4w6m7Fh+Dzl5rmNu5M4i7CH11FUSDnz9qOblhvWG7nPO67UOy7Lc77r1mi7Nlp2 xL45y3DkO6/rJb82gx/A22z06rz5a2LpS4S1MiaUa4XRS3P9lrl1eK/O5Gjx2b5Gh1ZMmy/RB0Ib 5bCSYU5ddbUI7JVDM8BU8raW149TO1KdxWwJnKn3tcFgN8HUWsEF/J1DO1Xu+721a1tdarzTZpYi fI8k7LqFUarl+ngSmsR1E2fVmys/FMBVeMNi5sPEg6nSajPC646W5amW1UVmybwCGbonJllme1JQ TMFqi8VUDFNedbnvCMZn7INfQ7CdgsIcxcPo1MIp7FKSMaX+HPqDgTyAwYo2iGp1KxehNGKIlfe+ jDWGKlW/hLi8fRymFtwuZqxrXuxmVzUvH7qAbQXIFYK3hBrILKqliVynbRh0BDOjiMarWAusP0WL Jqq9R8dOiPtbQxTJmDWgEkbGMBxZJwm4olVTV0XHa8zGwDytVixaByw+zmxQx6zCkktiupzBS8io QpRsxavM4mtw4dWbkZig4szLnkzNlyymqiVeo2ZTElg1oqqjl7jADUTPWax/bVzOlypbxdzAVKHH K6zP8XvN9tu/F9pKLERsi2nE/wOUhOlpe4mcvIlr9wjRpbvQqal0Obyk8SXGjprPfiTQhJtezsZx u/Wqy6n+WMa1rvDojG8i0mNlnhvdeDE204UHxJCBHr26R5Vmj58aYPwbSsp6zzjozdUcuEZtNvxm z6jKxNWa1EUbtFB9Mf471fF81Fa9MY6U1Vedzlyt1cH51ZKK01g8gnGErGK9zMma1v78i8zESjaN Y3bczWsd1/YnuiJZlxGc1l6N1Jz5kqQrbHqZ0Ck5rFsMYCWnPb/M1zCNboz9zPLIoM0FmAOogyVY NBaylYJJddljxYwt2Qw7j0C52S4Zc5Wtn8sG0LGl2p/Nv3YNspDMGsoollBp0YXNZHlMuyesxq2t r9+8pFJFXRb9QheoXX5YvoAWza8dwAfa244d2nqjqUj+2Xea2tYa7NvoZt0GOdfqqd2b89rzObFG 7d3969zQLdXm3W9bnd5T/NvsjU/c+97tfd7yLVc6BsFKvWH43dvcLZrkDSMV5yfgrVD9DZEDLnFs Ld4UeeDhi6kFvnG+zOAR5stG+eC99t+4KOFvo+DVpuHON7McXmr8UaZ2BSmG2qLlmqaF2qFLbIWL 3IjfGuLdasOpWXrCmaIw+tS+CqeLK6dJd8isUqOuvIGwTGk02uOELMi1uHhqnUr7kq/77UYfeWQW rrAaat49K9cyLmJ3Lbq3HYn+A5bjp4oqfc9WuTIensx9TdM7tjZOrZ2umKmIN7i7mZEwubZ1Xs+F bWn+7Ofmby6bM0zWXA6+F67DVL7lk7mn4S3abofoRWaEajLUz/3CdDvWv+fo+1RX3wd+0odkSz3I oRLlnF1SybfpxGeCv4vpj6Tppq58qF7fiecWre7qnX5JLni9JCUes37qtQ7rpCTru158ve6dSEvf jimFs5ioWdp0Qc09tmwxaV5jNq69wdyTyU7Iy76oyF257r2U177tDD26LMPU4C4YAFyof94U7Kmg /wHkAdvmoL6G5v7R9p3ur7h++wfjcnnr2L2SR3h+mXja1uXu0u1MGMjnRNUoF0g05QiIPAeO0zWl gNiBUjSBhYnhQ8mC0UjuoP1NG++6CQ/o8u7XNoj+iQG91v7OlLxoO7Y4bseaPuDuoLmjhdoc80la 8+H+wDNvmHQ1Z3BG8mEph4099P2u8vp+5VizqHwu8l+qX5WyN3727vspiizjtVFvQ0pv890u59BF gOhc7qqK3ip/7CPf75fo7SdPlVJf3A3o8A1vJG5v2ey58F572F3U8AFO9zSuxUwP9mZP1HmOvcYe ld/OSGcv7lh9v6G5s2RI9MB5+GCe+ET/lPAE+b6Inb6+kJiP9pMO+QGf9okdjw+E0ipNMG2W+aEl +gYa0aMfp7CqWQ/u0skSwmE7jYNTWHrm08L908qI+rLd+ou2YAuWQWTW7Du20iK8nK+6z2vu+87+ /7Cg//zSj2yCPv3Wj7vVf/3aT7wFv/1fhfpFqurej/JiHf7ZP/6Tb7dFb/u2Qd1wXn6Y6f4GNtEn TN+FD7opDxD/BAIQWLAgQYMJFS5UiPAgQ4gQHUakOLDiRYwZNW7k2NHjR5AhRY4kWTLkRJMIUS5c +TCiyoooHbb8N7MmS4sUacp0mbAlTIM2b7oUmnOoUaBHASRFanLjToY8cfoMerRqQ6pXHxbNKpKm U7BhxY4lW9bsWbBf0a5l29bt27Jf1cbEmnWl1J5Gey6NSnIuXMCBBQ8mDPhvYcRpEy9Ge9jnUr4Z IUN+PFmm5cuWMTqmy9izTs55Xw5UWbqz1qD+oXU+3XqQstWLk0uqlrg2KcHXr7vWJT0Rd2TdNnX3 hv2RNk68NYMrvxvZ4vCbQn07r1087PHPHrHzzt7d+3fwZ7dvXq7XN/fdw88TzTsdt9+RP13zhQmd OWrz7Ofvzol5fHWO1tNvQL32Gs04+MJTcEEGG9zMQQj7inBC0Sjs6D8LM9RwQw479PBDEBv0b0QS SzTxRBRTVHFFFlt08UUYY5RxRhprtPFGHHPUcUcee/TxRyCDxLDAEIs08kgkk1RyycYSZPJJKKOU ckoqMxzSuiqz1HJLLrv08kInvxRzTDLLNNPIK69EcKoKiTzzTTjjlDPJNAWDCr82QUpuTj7++/Tz LRaRrDOwO/NU809EE1WUrd9MxLLDQQ2T0FD+3kOvwD2pO3RRTt9kak3eCgXwUacaLZHUDSOFS1RU RZsr00r5+5C6UjdNbSxaO1UQKOB4tZRX5ST6lbTWbnNTMRSj+9HOMFfVU1auMI21q1wnrNata4Ul zFZd27LPK+2OvS7Yhij7NUdxm4yvMNVYhRW/dzXk9rq7wMu2W3zBTfbce2Nzbl7Jmk1MM/IInk+2 1AzuDeEIAfZUSIgjlnhiinkkl6X3Sus3pn+ZXTff7hz2U2SQ5bS0Nn7/K0/Sj0se2OWWYZYZuRSH Yli7jgkVeGZveZ7NZ59NZU42+hauMU/+23YGOq6lS226ZFMddbFgkleL+WnysGZwY62pFNq/+6we 1TNVu77UX00d9etahYWt9maN4MY4W7nZRWzEhsHmsuJTX77abJXV+xZhuBkmsbKE1ar7ZsLtY9zc XmmVG7Ny6Uu77qE3PpTrWunFtursQA9d6aaHfPzExA922z28Xxpc8MtZT73ymWCXfeHKvh169rE5 /o5rzgkVXecpy35azdNDg/xV23mfu7nmVZce9+d3d7560HLTPTZtKbTcwuAXHJ5s0nnePHrJML/+ 4HYpx556+K2PSv3Mod+pbfbbdc3suOX1unyZjY9/fhsgqBwkwMUYz2sSK6CSEDizBz7+q3gAfNL4 IpiSyW3vNNvS4GcuaD7x/e9vImQU+NwXP6Ox7nAJy13u3ra8+NFvbR9s4AyxRcKTdAmBNDzJ8iz3 L/QVDojBGaL9ppe/8MWNh2hTod7iwzYZ0i6K6cPfYJIYIBxKcEsRXOKFbEfEfmXwN/tD3/TEqDEF /q6M0hNiEdu2xha+L3EvlFwHWea0CY4wj3cUn+POSEfoBPJeJ1xf8gwooi+uEH7qS54T5Ug7FMoP iXb0GAXRZMmBrQhMdqshrkwYOyU2Knu3iyTvFHlGo0HSO2l0ICbvVj+wHaeLj+mkK0MGx1H+BXNV zOUP7TdIQtpLj60cpgdhSTlZQqr+lnhappgwNEtA2XJbx9RM1HYkzGVCs5mhm1EWD/m7i6UuZUdL F2O0WaVz0suPV0QaoChprUSx0pj7shk7adnO0RUwnbVS2B+b6MiwHbF+1dMeKK2kKHmSj24ZI04P mbk1rH1qVj4UWgzBmBn27SeShlsnLxu2qISaE1UMDahxBOQ/NZ5NpJOaaOwuOsrKXeyHhXxpHKcI Tk6FNIHUJFo9n3lSD9mzc0qcJhYh1dFf/uSNdVRcFVEp0PDs03vStCJPzVXPcTFJqL4Ty1ZBk9Vt gkiqqaIqs+g5NSaaaayuM+c7w8our/ZJpy+j5wbZNLK8cWitCN2rluZqGL61Lk7+fcVYUN/6zZgO 8K+HNSaE4hoyxorNhgEs64OA+qC7solVdyUsARFJp86iU3ihbSy4ulq0YA0LOP2JznNSK5dhybS1 Sinnl0i7vwrelpaPtVNn3SqlxU51k7qtqmOJi8FVcoa3uDoux5br2MpGtqgHbG5cnutcdTLquqna 7k6LKV3IGldXityaYGHW3RJ+F7yl/Sy+qisrCArXtOsNoXjdq8zSyTeH9K0vdfP13oeeV79a5C82 /XtfvR5vwIgtMHvLC14A986bEFVvgzl54MhGmKVZam5wLews+2b4kntbcLg+vMq8SlfDmRUtPCtM FkNa9HLOOx2Ng1hGjhpUxjb+JqUkc5wyHvPYPUIWZz9rKuMhHzHGmVPyjXXs4yf/2JRSbvKMq5xk JM/OyEUkskazbEYcHxnKViZWJfd74nximLErVilwS7xJNDu4jxAe8RbfbNQ4ky/Ea66zX+/Mmjzr Wc2HZTN89wjdFwfaxfxFLz7Bp8M/90/RRSq0A0VWaUdrNdIBm3SIMC2oS/eZw5vGbKdn1eBG15bU S+pwdE0N10A1EK3zFSukF33mVx/Qqj2V9a6vmmhE2/nWBCa2oZW2JxAHGNh0rdlY60WkVquoVaWu NYmHzWCjridaTNG2XdyGHm4PSD54erZVpCIdV0lr2tGUtrNDVWZlj67drjb+sJ+vbWLTdlvdJ/2U RK3Tb2kVZdwVUhy8WtOUq5x7nvf7dZozK5eohnOO67arYa390WXnmtl11aevUUvrU1882LjWeAjD eDLFSrxcHq8ZpW2NcZCvWs4TPAzK8RzvZgHY5n35dEpePvJi3zvd5kY4gfRtdFVb2poDHY8jkZ2b h7u23KxNuLernumAxVqtP9d1xsMLoNWWuXYGag/ZiU5xUC8dmUHXCldyRtuilz0/SHG72c+OoGrG suc/E3nXY07MigfQl4PfOZS6aE21bb3vIqJ3ybUrSmRWs6RAu2reIz95rrcY5iR3fCZ95DIgRWnW mhb6zTufYkbvHT7zNrz+zCV7+j2vN9UJZn0FXX8g2KOevrMna+1Jv3m25z6qqvc08fXF8I//HujY Fj6ieN/b+Pqe1beX8KRH/zA0Gd+szEN7gksPaI0jXm/aX1v2oXbw1ZAf6w4PfqDF7z71e6Xnz6fT aLSufL9zvtPvJ1j8HUpp//s7+yMavRM96tswUxsj7AlAkzI/xXuW+5u+75O08PO4pNub+WNABDSp jCHAy/utR5tATqtAYGK5D6K/XgLBWwKo+sOgz3M5JpI28Wg8PtOlCxQeFwQs6wIswtLAehtAjmMa r9s9luu+VcEOFPw/ohq+4uqq1gKqaPESx+A/yZvBIZQ9amKyveIcDWv+Du/zpBLqQAKBtye8LEGx rGZTFwFUNCrkteSqPiJsPwubwnCiKCPEN/1jw/fTwrXSlJJ7ldOjQ+kDwzVMvReEqzv8sMLbvRZJ OgXUFtDxsOYTtElcv2Zqw4azLO6JRBrML5JSt0T0rEpkMREbxPRLQyssxOJpxDBUljGsQ1e0xKdI wlHErpFhxa1AxUmSGmXJRBjrRMMyRXurxfwrE0xMvlhMIV88RioMRfDLQ9ESRgMkxi90piLkCelj xifUQszzuStMrgjUxvaJQPajxmoEwEDJRpXbLapoNxjBI1X8qJbDRuRbRJTRxZkzx5DztGtcR26s ipqDjUd0IWf0xnj+hK55bEd83MSFFEXrcikWnMWbmqTZCKbVMSI8tCIVfD1lmjd1jDzz6kXUWSJJ FKaEBEjuy4yjSScLwqXGYSo0Wh+ZlKT8eSQZcjqk+qdgEiSYBKSwWTI4C8Y0PDmBZLrLQ8mvuj6+ O0hdg6KwQz/7U8gg/MeVso1EMi8qmyNd0qCXxEitvEk7zEr5aaOMaiiaHMucXK5KG8iJs0eAlEqK eqNp68CpXEponKqT3A+QXMZrPBXT2ZSWfDLs4skeU6Us3KiCyhX6aSQucx3F/B5igSOxpJ6JxD2z QEFxNEq8qTzLI8D7ULvDkca7pMCOBESBJDymg0teLKwbgcfGwCX+x1yoylTGs7TIr6QaKZIipSJL FrrI3fTKsyTNy4wYfyQjzQy9vYScfgSr0ZTHzsCo5LS5gQxLlClHfYTBWgtI0AzJ4/PAAsSdKlSM b1zB40StmYrOWBRHv0Sx6xQ1oTyrzlROryqa6Bwj0ZTDETyq7YzL1mQr/izIpGnPc+RHiknBdyTK eSlJNdpPZNQXhgzN/hLQ5bskckQx7XTC8SQb70TNjZwfBo3PmWI8M8O9givK+Ym6/MxIJMxI79Iq wtvPXVlO8WRKbjpEiSxPE4zINwzQbQSWuKM6rPBRamk7hEM3IJ06n2pM6SCc3rxBGFO/0FOo+gTQ DQzKTonLY4L+E9rwQSdNxQztvMxkTvw0GciLz9fSUnNkwLCDuOosPpH8T7akUY4kUxsdEy61vVFT SKLgt7eULSKtj9HqkeakNgmN0AQs1GJkPlAD0jabLf6504NCVBEkVDxFyv7g04N7u6YAVIQaUFp8 Ukklqy8N1baasyW0F0iFPQUlVUR6oA6loiNM1VpcVVYNKhm0klutVc0bVF1dRQfsVTKhVWAFwF8d VtsCRmPVqwxMVmscVWblrmJ91mHkVWldVGKtVmGTU3UiJaAMMzIbM2711tqJMtgJsiubMnL91m5N 13DVsXVVV3EtS3BF1x6rsXP9skWKVy+b131913Ft13ot13v+zVd2Hdgxu5URVVRsBa1oXVg3c1aH tcqgkdVZRdaIFQ9nCyRSzKSLPcCN7VgNzUe7mzsOAlngU1h0/NRHZUkJQTZZBFWTTVQWPUPLDLe7 Gzt4EzjciidclKuejdmqpNYBTY+p2DaStZkq5ZMwxav7BFri0Van9aSmJdrAg5aIm9qovSGIzdpw wdqRsjoTNY1pUbirQ7r+8VquVUOh9dRXe8T1TFG4EzewPVqkLVtGrduPzcWvbNC0fdq1FVUiHTpM jcKw7ZalBdwZRNu+FUKoRSmWItu5uxOXpVgwQVDnK87IXNwL+1vNXZcLBRXh+EyVe7bpVMx+1dlu TL9N7Nz+JuRc1oXAhmQNkhLSpyvSIYU7yJVFZlTZ133ZpLW4CR0sWBpeyj3bDVXO3k0215VZwS3b 3D06RvU34VVcKczR5FXeMXXcSXlK7kVdkvVevB0s+pxSUXoYunxR++TdzhXWaqvaiFoWDKzT63XN 7J3ftCje07Lfza1f/a3Iie3f1uVfAJa//x1gPhJgA25A88Hf5mPfBPaWZX1gEW1cCdbBa63gGN1a DGauht1g67RSDw7ZCw7hr1teEn5I2zQuHT3hhJ1ZFp6sx6ua2XwiBs49Bz5h9Z3FAOnBGj5UDTbg FXPZSX1hY3tGIv5dOjtiy0TgB+7hSFVi381bD3Zi4D3+4hteXCqmWRa+4qzN4kqdYotl1Ve92DFO Vi4WUC+uoTRW2jAmxjV+qzc+kzMexTgWMYedY+GrY0bDVjwORBfUyRn20K30SS8STCoax8cUqlma Ij3OVhO+RIjhp8KkTMJ0Ic15HVDCH39FTENGIppiTICqZK0kqMiZ5EbOUwoOK9EBzKvEycZsqCha nDUSy02mSOeKGrR0V56UVzEj2KQKo2ftY61ZZUmeSQ8tqWRZndwUKFrWV0o+OYj8V5hCHCBC5o6C qq6EQybe4x8GHB6doUnOpVsOpV1KTMPkV3wNTk5OZEze5SZ9HkLuMpxzYetrY2/+Zjst417D0D+0 567+EaBTTmJ+rsBu/ucDhuJGtctcE+aIamElHp6AjriCHmaHfKW6YFPMgkKzRZrCy8Rfc1uYNKVc hM7p6hnHY2gF46bNFeI7hJ7i0GjdNNrC9WR8rTsT1a79bVt/pmh+3BnpnTiO1B2XJsUhK2poC2kz kjviSKYnJuhU3ibVi+imnmqdnuiGlkBV7el+tuqU/mIfxk6nfuRsQmVFxL+qfurxCizyGmKJRlhc bVW1TuGO42o0DVpo3ZX2wesQbNGxpmtP2dsonWfuctXZ02ecWUvAhl/Bvmq0vtI5+gDIjmzJnmzK rmzL/gDHkcJc9Z7NVj7LuGzQDu3Kzmyo3mmTeWz+0U7t0CZthL5M1FZt2KZs1u7rxs6p145t3MZs 021t12af3P7t2a4lWo3rblrpyfjt3A5u3mbOz0bu2FbuBCLuGBHrLi3iH/Tb5nZu1Ybu5TbIzNFu 2OZuiz5ZI0bZJV5Rwf7paSnp7Abv1d7t7h7o9nbvyxbv/UVvrFNvg9vmhLYr/HZEAF/s3jbLg45v uzRs6v5FAd/v5yRUlaE3ln49TTJB604vvjZw7x5vB/tvCu/wKP7wCg9q01s3/R46PdlKECbEUz1R U70ntjpxFt9XD2JJ7htxFU+frxroLkXS6qDDBe9vSi3vAAfy8D1vkgvl6uYkldRYvXbryNnZtCH+ w16JcViuZrOM8oAqKNzC8hzeMCSnUhBbcskR0/xG4lf08gR/cCkG8fH8pYtm3MqNpaO27xmXuCmH 8umQcrFdue4prGO28z0nFy7XJjefWzI33vOcc/jO8DL32xR/dLgdckvuzw9vZeg99ElXb27DygEG ZLvF9L1Nl0135QmfUxIXZHT58RDnHrbz8Zi2kTjCopMMNQMV9eeI3eQ9xrudUd98yqJVRjkn58Rb 9XrEkVXXZuG08VN3dFlP5hI34RI93LtBcLs+donkpUD2XGdP8kjvdqrD9Tx0dexVdnIP8mUvcPDj dG6nmhepWWAnXAu+5TzP5sgUnFsxGCMTdBX+cnEcR9jHJMNKOiU2l3elRA00wncdb3R093YhT3ZJ V7YSRXP+9moczPEtz/OLv6dB30U9j3W3llcn/9fHyWk7xXRxh/glXm96bvhI158ijngUNe/HJbrz uKzDG3hJbiOO+vhS/jF6d6Ixv81KryOC/9Sm61PXgkoevyNuGThKhflGjXBWR2upHxuof3lrX3N3 r3mkf+nx9j/etcFDuzmUK/u7w3knafqsN/G8hXo1p/q1B8W2N/ITl267587rvXu9l2ti4/CrR3lV D3wit3oVTXnAR3sMj9qql/jfdfs0D/fOfncaiXvkMl3lqk5fT/wdtHxvF0MwZ3bJT2FBFfz+dSf9 HN37E1TA1bJPR60PYyl9zfcifZc6hkI37kV8DkL9yHd4SI9937fj2g48jK4/6cx8U//8319djEK7 4dfiAOtB045e21cttxy+2q/DKXf9LM/X5D+t67cy83ytJbXyFsR4pA1/vl14ljfp7m9/tTVUmXd/ +WfsBJ9/+zfc6AeIfwIHEixo8CDChAoXMmzo8CHEiBInUqxo8SLGjBo3cuzo8SPIkCJHkowIQOPJ kipXsmzp8iXMmDJn0qxp8yZOgykx7szp8yfQoEKHEi1q9ChShz0tLk3q9CnUqFKnUq1qdWJTilmv cu3q9SvYsGLH/tsq0SzZtGqnAmjr9i3+3Lhy59Kta/cu3rx69/Lt6/cv4MCCBxMubFguyrWKF7Nl 7PixUsgC0UKkLPky5pWWM3MGu1nsZ4ahO5MurdU0atAI6xZkXXS0QtipZ9MeKDty2biVF6ZELLpt bOAJe+vGTdCtaKwHb1fd6rz1ao87mS9PXPs69tgge1dfOn0yb/A6y0InL767dvPQvZcHj3y47eM9 v+eOr36+/fPcz5sXrj/mc9UdF11H9GVEXXvZKagggulRdhJxxRH44H0J8gehgBRmhd+A43WoHoj5 9ZdfgO1xyCFNJVqo4mRw2fbWcBK26GJu/llYUYML6rhWjprtiB2LIoYoJIg2eigkex/+8qckUz86 mVqPT0q5kVkb3rjkkOkheSWTRJ42JZiXHTYmmWWaeSaaaaqJFnNWeslkkls2FGWUYdrpVJ1O5vnj ZkbqRKGcgS4ZZ3gH3nmoYnvuqKiOjCJFJ6KRkuWogDjCB1WPflKaXJacbvomj9Y92RRyMJIHHISo vhcfcS1iKV6Ep+4nX6o12upbqrlGxx19vKr6a4cRvleqcLquetGnwYqIIqizwqrkrCdyeZah/4Xo 7IjKkmgttmy+Kp2YokpqoLZEJfsQtniKJO2FXVY5aLv2kdutuJYOSO+18OZr4H6EengubM4mOTCX 6U7LKU+SKuxZdswiC2BN52pp0p/+GL5o8Yz5drkxuvUu/HFjIBcq8qXUtqYpyv7G+23H1ZL8srow Vyozx6EeuCbOOeu8M889+/wz0EELPTTRRRs9F81JK7000007/TTUUc8msdRVW321zQljvTXXXV8H qddhiz32Y2CTfTbaaV9lttptu/22UGzDPTfddbckt91567231n3z/TfggU/cpOCFGx443ncT+CbV hzv++FCJs8RikDc3Djnmmbfs90uUL05lzZqLPvpIkvs4c6eKOkw662GGdjlMpqvkOeoo+dk67lLm yhrsnXusOOqV5z681LpW3GlXspdE+5H6qqwvkv71TrzTqyKIMa0lO+gjXshzpTz+ScyveLL20Jvv /WK+vSYj9eX5anyxxhK7bcam0gj/8vVdXOv0wHPukvjgdDCNCYqAY6GRVhC4LlPhiIGk61eN+mUx 6+nveNYr1ancQ66Q1Gp/9enf5H4XwuB9Dn3NMyD6QBg+gO3pdtJRYfVg1ar49WeC+otWBmeYQ/dk q3QRpEsG1zUT8IVvNR0k4clu5y+VwQiGLwQQdVy4PCdirYXKAVWBPqgbVNVwTCybnQhHeEUBkrGA S7SKFGPXJyq6qn2O2R0QJ0imL+bPZTK5jZvMOL4yopGNJQxdivzoxiJ2T45pnJP0hhhGAG7uhGfk IwqjckifTEeQvLHkILMIxA/+drFBFLzjItXonUk+Uo+QfAomGxmzTHoFjkgzpCcTCUo7Yi6V6WNl 8ir4pyA6ECuyhBgtHWfLsuESjT98ZSeR9cvYhZJvwwxXMaWCPfQIS5kbZGQwBfdMzGwzmuXTTjWZ skzfZfNv3czMOb25HmK5iIsRtCYW6/g/c54tnerU4K+aCMvCxLOI5dSbPTkTUG/u7pj8y1gWZzlP gLptoLgsKGLcyUFF/lNsrjGh1yqJtHuCUi8GnaNCH0a2SY6OpBzlCES3aBmPBoWIT3No9WAKOHbe RZcnvGlOXLo0mVaNp3Oz0euSKNKb6JRmbTpW93hyrBmxr2IbWiq6oLocqfb+MqcAVF8SFRgxrNJK q6Tx6UJN1lNxAhWqXkUk++xX1a5O1aTWfKpbgVmguCbwU1KdK1jDqpaikiyWZVXisJbKQH3+VTZr daBdstpVtRqplxvdH2O5+thvnoWueLXcHS3bHGjq1aiWm49ZB9tYKSJ2k8EBbGGFBdrUOtWDbP0h ZF/LVNeeFZBGBApdNTvFrBGzojKjE1JrKlSEGpG1sI0RalerXNm+s7Wzhaz6HDvZj651gC96VJXs qduj5JVwnYUZcAsb1fixKbjiRS5cl+va57JXsdI9ZHU/2t7djAyV1o1bWLprr+/2lUrmHQ1XnUvb +B43tuttbnvjG2AEi3b+tOdl8F0L9r0J51IyfB0XSv9rEgLPV75onS6CQ1xa0jaVqe8llWlNHGEk ZlS/+v0Sfz/2YrVNc2x5nbFYh7rTk6IUbj7FMcV8KzIg29huMiWyKve7Yx57N28ORbJxdIxO/zE5 yDNNCpTn1MxbirHKSXbmozgrZW5SWZJV5XBxcYJmqx4unVlG2JjFLE9pymjNiiXqiqf4oDzvjcN8 nqiFt5wobNJZQidusEpHqejFanWjiF7gm2Pa5TcKmrenMzOuNFzgEWtUehd8cIFna+cxejnHgIbM hQ/ITEyrFtGPPfGt8nlg9p55wTG2CadT3MCUldipIN7wr1MkxEALmcv+5ETlpxHo59DKz3gdfnRW awtj7mp6sb5Ma2BXXGdpX9K4bAYXsW+915BiN7UPhna0DcxcTjt31PWlNqgH7OBOi/jP1m6ruQ+N ZXCjutLjJrdRai1YyWJ70fguOIrjbWU8VVvdA89uvvNMYHSHmLrdzFOkB6fkKVO0loVWrq5tRVx8 31vaE892wiHu7lUXWzUtt7Rc28yWhnc7Vuhdd4QVSF563/mw9gb4tCn9clx/Gc7CNhxY2T3eZc/b xKdNdtMPrPOVHzvOgx56xCyOQVMT/cpUUfrSV8psbjP6oheFLtnVjPVW+jvrVJUofXGbcZiPdO5/ 5Lqxrd5SrcO96HL+f3VGSw30hQtd3G5fbt+jbEyu2R3MTS683nGrS31iFKdfZ7zgB+/3fxte2IWs /Mb3XsXMx5xPbfe8Kw/a6sH0k6ijJz2hR3V6RX5+9YGx7bejlnGvUl3kuP45psCU6o7W1JBKxX3u X7rXbVu29xwEvn2nNHyIbZKLNhcn8ilZvLS8+uHKfqWDh6viQ6N81tJ03eyJn1jjKzP7km8a9JGd 6fN+/9zoBnuo3+n89ws//dTPLi9t13W1nrlIkgESIKuNn6eZnffFWkE9W7L5WvxFjp1MHzPV3sgl kPtFjnYN4Gvc3dpAXQQ+nQUBC81BGK+lHXfdiQX6joZ00fEh4Ar+4hcI/t67fc9/VRvFOZzAqRcE 7txmsaD/sVxyXF8DbSC15dQaqRmAfUUPKlqjFZz4RVsU8hpzYVektCAjYaDvHaEMYkr/bJcAtl/Q wR6pIYoWKg4XetEXztxuZdgb3owZbhjIpGEIrSGjNJ661dUYKsX+Od2pzSFlYdja0V7xgV4ZCpSt UVKw3Y0e/tYjah7hFWDtqcnXmFncnNUf0lhyTaAQFqL68c5vJJXsgeHaCNNIDaEjpl6i3eB91caR vVgk3pIn/pYqrlD2rVbnkZkpUpjXHY/V2GEmxaITOp4f9qH03eJDYSLD1E2mIOOCCOMgEaPLNdTz zSIYgaLi5dH++bDKaQ2i++gJM6pa2sBOLaKGNK6HAmqQqBFWOxUJicjaceFPo4wj91kUFZ0jL+5i ZMgRL91QIsUK/zCb7zXRP44TkNgj5wXh4rWUPl4dPyKMCY4IDfEKRcIWv+wQJ2GIRRoMLCokRDIc +QQfGGKjK55hNcYdInYGNaKam2lZwM3YQ56iNhIUSLrkT2gWNM5VouzkvtVkNLXkV/lkZflXZpnk xSzk4wmiUE5NshDlbZUOUh4jkKVj+zQlgzRiI17VIm7lokBl1S3lHGJlBVZY0vyYMrISWaKfL3rW +QFlMa1l/7WlLb5lRNpkL2ahWbrlAd5lUN4kW9LkWYaMX8b+JWDOpWDyJUkW5jLmJRruZV32ZeRl nlwmI12CF2FOpuBVpu5AJmbapWaWGmdeTZZNJRImX+iN5WFuTWmWBlrCZWMiG9q05ldlplia4WgG IzmypG2mJm6u5uvll2v2ZiL+pmNa1G4KFHGipGoeZ9jQJm+C5m3CXm6OVUpynGROJ+lV5/Zd5z4u Zmh6GXfqXnJiJ3hqJ2UCJ2mW53dGH2OqpXrqpnfK2SqFZ5WNJ9RAp3JKp29SZ3xap3DWJn8Wp386 Z+DNZ7idZ39u5392Z4BGZ3YuaHoaaNfop3m6p30yWSweDYf6hQ8haL8NKHMKIug0lF2xJ33+5HuS aO3U04n+gmhvRSiBsmiGkuaLPuh+yuiI0miNBuONNiOEKuiM8uiQttiH4uiF1id6Eine1d2RAmmO CumOMumUPuePFqOA6miTUmmVGumwIWl7KqmEcunmWemTYmmQYuiSkukGmqbrqeSaimiIaukksil8 eJSbEh2epqXopamYFqmd4hNyreSQdaFQWSVqpmiYwSah6hky5sgiwulpHt7nZaLOtegK7imj9mmU qumYKt4rJiI3EmEbluneRV3iJSq+nN+8HdSm8l+n/mmX4oYsoUgleWBGfou36Ae92Cr9XEmr0A97 2Gqu2pSeQqGrPJObXNPqSF6rctKr5uRwymmdXhG7aAz+s+CL2G2QwMiLlzBRnZFRr8gJwUirpjrk pdbYk/Hd1q0orCapivbohJSLilxrqHrksP6qbe0q9GAMt+qqs9peu77rHmGq9u1cRPEpwSrqDL5n t8KjtaxMsRZshWBJtv7qqBYsoRArxgZspXLqTc1LwLFrqs4qtUKepwJqoLJiwo7VucrrovppvMap nbLsreYppUZXjaksnaKsrG5poN5LXjSqjJHszppszzLGa7qrf8LX0TLNEd0WzoJjjEop0P7sB/Lm y3KdxJDKZm3t1Exr0oLqyd5KvHwHUoncwwltOJFZnxDtq+jinSVl9ixLWwGjoE5hB21iEIXH1NZg 1ab+LNKuj6GFo7c6D7Qg7uHG6kmC6r9iKxIFq7ga7uI+S6lSrcGKLePGLMwuLLnSK+VCLK6UCzrl k+k+LUwWV4NZLhVKLhSi3LC4T3Eg68O0U0T9beb67Mx+asNGLuiSrr32kPBy0+keE9x6T7lW7ucm LukOr7ZibhG6I+UlZJZabbWWJPPdhzuhLVAx78idCFjKn/Fu0ZI2oNzSbdzWrfrKSsLByUPCkXyF L9tVr+BeLYxOqvQVL/mG6f/R1PReIv1iraQGbQlKL+oqjc1GagAz7MhGK2X6rysZK9TCL/jhbqgq pQCbKpOa1/i+I/oOWffyxfrKbILW7/VSaeW4kPD+fCJOqTDg6m4JZzDZEvBvvI38embjoijn0iwN eyAnNozRHm/ZUqAD0+gNgzAQ51zJTspy2m8Pj2TbHPEpgi0G7y7PPrEEO2lCPusS63Dv8vATS7GM WfA6pVsX328BFjGLivHCsPHlUfE9DnHqYnENm2gSC+wZg6kVD24Yd6gKftztbfHQRuLSdi4dM+EB kXGPwTETy7HRHbJsgoYigw4DCvHY0iDTQvJVJfLLJLBBwvAX8+5PnTCUlOYkJ4bTWrL1Zm0msybJ 0hE6mnIdcuQgB64MzzHiGCrdnjIUewYvF6U3FqEt77ET040nF8tXcjILrvAL6/EOi7KP2dT0/rL+ DzshNceI3xqwqgzzM1+xDUvz/Khy+siyngSV7aoUN4eyN1vj0IpzTypzNBoWRt5uOjdwK48ewm6z O/MIOX/N9cwzOoOyPRtyPb3yPi8fPJeyoYiwQLMyQadiO19zFodgLMPhOZ9zQ6fxPa+nayBzo/Rz 6WIWq+zFCEOpCQ8wmA2yH3vl5IB02dQJM2Oqhd7yI9NTGnk0B7Z0V7I0FO20AjfoZ9a0xm2Hwlao QV9cHrrxTB6jZrgxHGKeljFyQm20bq4ULG+V7djgZWF1JiJnVJPYAZcoVQPoDCsh9jnkWaO1VoPb w5a0aXzGMedxWkp08MXRJ+c0HWIZXK+rGvn+EEdeZL9aXzXHcfT2XFjPtczZ9cCqNS5r6Y2xEPew rw2VnGRf9fwW9mvJNaPStX0ptmYPkdi10jU1R1JzZf1A683i02TnHTjV8pyBMTtX8Gdn1lDjsG3n NUN99fglazaO9fZJNZ5NFUDhEWcPdGt/7JlC8zd79mEH0gXTGCLJ3Fcj95c+dIVaXy0v9Ucg5C/2 MtL1o2nNNmw382xmrCs6dQ0X91uiN1kf9yG+tnJrsmUb4yij9J3u2UFDb1nLd+5KdzQD93gAOGLz d2OLjnofK8St5GE3t8NGMesOiXZ33PAcuCFSt1Dr92Y7+F9bZGD/dRuJUve6Ecg9JzhXJMX+vCMF 97Z1I3AObd3r8pD9rFCExyXfoh+qMrhqb/hdJ/c6V3FtX+Npb+91vc9qPzV/s3dDbmMQPw84STaO j3d/E5OA4ySBR+UdU/fezu40xfWGY6SKQzkTK/GT012VR/mUifm+uPZIJ/j6fXl8j9uUk3mZ/7jW qnmOiyLbHiIthzOP83Go3Hh+X/Kcm7mU027fJTBvC60ZI/r59pgav7Ghj7lJDzopBxqgD6udy8qi pxB523elr7IjLfmn4++kUbqfn3SAZ3rUCjemWzipvvkHRnQZG1Sid0ycl56p9/i+7Wk+61Cet7mi 0zq0Hp1vXyCJwcuts++gKmuuF/XBgrX+k+N5MPvtOrl6WMI6JSZVq7+3rWd6oja7ro8sr6s64XF5 oJ86oe+6oSN7eD/5qtvuuT86yaFdr43iT/PdW9X7vV0hU+MZVCLZuwdWtItWmmuzNGtdrUs4mFMg qrK7td/3pqfS5eAfIIZdxR8cyB2Vt6nuCdo7E/67cF66qP966h18sgfiwuOXrAc7NjM5erWs9um0 D2Z2A9YbWKtwrlWhTupsq4ogO01hF56dh+1gMXd2duP3tp/uu090whd4hhdjrz/4wCMTyTO3iUur zPN7/QG9V57cAs68xX3Y/Wha/flg2UtdDrrXUhNZlo/91MP8ndN6Y4n6ye+3p7Oqtqv+ozCz7bJL O1mxYVNHHO8tYOtqm+ED4dxK4J71+td3X9P9PNFH/r2LPc5wT3ZHdbVDsGNh1J4vO1HLeyh29HMn Pe/4vReK9ex0vOp+r+qHGuJXXHP53E37PM/d3KGaoMJJ/uRf+BOBUbKDVgdj9Beau6Mgas4W7rXo rwePtGEbb9NroKMHPtjXnPep1tM1Pu0mWK6RINrJFtFvWg/inBXCftHLoe+3e7TLfQhf9LYFP+WJ /HY7O4InVvJH8P4yP80DxD8AAwkWBCDQYEKFCw/+c/gQYkSJExtOtHgRY8SCEDdm1Njx40KPCBka fFhSYsmKF0GebEnSJMeEIWlSZBj+cqXDli9Hcuz5M6NKoUNnEj141KRCizk95kS6UelAhDh1HgUK lOnVk1q5dvWqcyrGhk6lFk2qEaZKgUutfnUr9m1cuXOxZqV7F29evSz39u2JNKhVs0nten1KMG3Z w2oLu22M1W9kvkTBylx8ea1PqYnHXj4rmetj0KNJlzZ9Gq9o1HI9i8QcVTXkwVABc66aOTXr1X7b wsVd9fXnrUZ/o42N+vhu5cuZN6eb3PnP3nCDi3yemDNi4tCl644+F/pK2uO1i88eNej3lOrZt3f/ vjj80HWxw+bOsjrt80X13qcov6vyyFOsIgENLMul1jab6kAE4fMPwAglnJAvCrX+8iyt4QizLqyr FsxvtplugzC9uEh8r8H60IIsJcoanM69Ey2ckcbvZARQwf9Y/CgwHbvbrj/vasQPRBjfqg0/kmy7 UTImh3wSSt6i/GtJwihEkq34hHRsyhaL1PIrBQdbUkInuzwTTQ/TpC5ELHHcT7i7mDQzuhT5u041 MY18cM0+/bzuz/+MWjDCPdejcysT+7QzTkXrwhBR0CK9kMrKlrIUUx7X86k7LjmldD4UA52szQ4L VTOvOafsiFGogDuxVQJv6oxQ+WolbaxE13oKrFszcwq3XLMCFjhdef3VVAc/tRSxBGUK9sNfCZ3U MWrZYxVOEXmyscpGwdtyRrv+wrs0NFnNNdXHFcs0rcBdkQ1W10RFdPddnKKtrF149c132XqZyhVf eeMdWDlrryW3003Vg/TO3BwdlV1zF0N3VF9THY5egPXlVNxdY1qWX41FZpZkdQNWd+T4hiU4Yohd ptI+Vy9++GVJJc7Q4peHYtm3kqX1WWCEWSZWyQQ7OxlalVGetjeQmv3taTBDzdbgmmlk2FtwDbN6 tFi35TrhSsHe2Dknqx57UaqVlVNrtJ/zumi3UZWb7ky5frqwxqJeFGv9HD6ybtYKvJnDnAPn+XCX zxbVOF6dbvfozSQvtlnJF++xVxdd+pbmxKVbecdnPVd49Irr/pfBwSd3NmP+1cNa3VCb0x1pWFjb Lh33snP/8/IHawOsLQfNw/h1wdwNXurTb9+d+d16b15K6KUvePnprW/yegufzz57VeXGu0K2ti/d cO6XK9/89DkH3G3UCYRp815HPFraYy1Pf/zS8sdV/f6x7/xuh0IStlgXPNfdD1n76xL6tNevVSnQ f9LzHtoUk7nW1QtqP2PQ8TKWvOtBcH2kqxEIIzi9CZYQhX0h4dQwd6UUvlCF1YPhDMO0QrFAiIHO syENmXdCHv5QcCvc25FyGJkiAhGJTZFhEpnooSNWS3+XG2ITqQgq9lURiyaa4m0sM6+FFe4xX8vi GMMWJjKesT87TJUa0Rj+QR+2EY6GYaOc5hhH873Rjnn8Sx3Bw0c9mnCJfxQkF/30xEHmEY+HVCTF 0GTIRbYxkY8UpCMnRElJjjGSl0SkH7WoyUtm0pNwtGShOBlK5QHQlHYcJY5Kmcr2BdKVWFylrVoZ S7CB0payrKUcc/lHXPayibP0HTARCUtiAlGYKNrlMQP1S2b+MJkxWuYz04ZKauZuUMThXTY5dE3u OdObdIsm9MYZzpqB05wUnOaTyplOiKHTnXdb55DaGU/eGdOeVqtnCIfnwC/mU4L4BKji6hhGB4rx NPsc6JngudBmFrREtyroPB3aNYFWtJAQ1dG9ulgnimLUiBddoMnKGEr+hV7RWCT1J3I+CtIYWrOZ JWJW5fA2raLtLWpuQuFJtVgr0MGvbC11aZBges+eYTClHANZpjTmv3Gp76lDDWBRCylTaHGUWP2s HwHdqLbYBRRIUp0qSs+5UX+mLGiYaipSoRo3L3mweceyyVfFWk2y6vMl2jEa69yqVfHYtIR6ktmj zDa79ghWr3UtK1UVy050sYquKhXNZFUao8fqR6iNDZ0ZNbsmN0EWroiLV1NDNrTRGotfG+MoXD+L 2c6+U6Sv5VNYadfFf62uOMJSmlJ5m1akhVYzmpOtUe9K0I8BSpTFi8narNpbpHVsqYZlqt2oW93g voqmwB3u1WILpZ/+UhOxzFXiaePXz9SqlbxJQy/QtHop2m43TQ1d1UbNG78OoVW16W3re+drUf7C d6SM5dtx20va3n6XrU7dz+YyK0IpoWREAPZsdx0bPjD5tbprFRr+vKpd3IU3shJuoIAnbOH8kje1 pV1v/3TKowY7j5HPerGIRbtZGrvwv2yTGjgLm+Mbc5fEP15YaEMcPsjha62oex3Q/HUygJ1XiXny sJAtG2Qq687GajLeu86r5Hwd96pJZhp3onplIBfXzJaNWWI5uy8mezmtTUOyk5+r5QGVJ80jpLAL 9bzfNhUZmziDTZ7P7CnYBgZ5ce7rTX1qU5ry9J5rFu8HBW0WQof+a8+VVMp0M0g2DA4vq879ZrcG e8dKW+nSfEZziTdsYE+7GsnLFXX3Ojxj5HgV0qnW8arje9RPv3nFSHW1rVsm6RZLcGKuybWuM23d +HaTzYmFHGCDnVOOLdu7jhZusT6sbW1ym9lDtvJix6vKDROyslM2nXQtBt1wY5nX77YRsYcp70K3 2d7KpCK2841cQ/f7sPTWN8Ar2WyCp3HfAjezfA/eJIUHvOGnGnfEHZ5witvK4BcXnMU1XuV4d7xr D7+WyIXMcJDTkZtq2WbKwXzy5pjc5SN/aMwbmXGaF4zk/L559D6+c1rO3OfetXnQW7ZNole450eX udGVfu+tNf3+Sjkn+cVhDvWESt3qI0561pmj86JzXeJbB7sOgT52jE/c7Knppr28Xq6WG+3taecf 2uV+IZ4ilDdb7OPUSz70uqN7NXqXY9tb9Pe//dvwvJRmDeudeHw/3vF71F5sCI/4yIvN8pc/99UQ PEK+i7XqXK+8Co/Nzs+DNPRQPz1xNZ9uK7Y+xrEcvb1T7/PV3xL26t7832//Ss3X3uW9P6XjgQ9y 4Qfu+MwsPtWlmnxgLj/izvec9G0JfYJTn3x1t/6VIexsl/517cH3O40F3+/ym3/8w529+rG/7/Q3 dv03jr87t1/X9sse/XSH7/2fT/v3Y5T/lO/d6q+iAvCZDFD+wfSvsxAQvHSNAAeKAa8pAmlNARVr AiXw0h7Qni7QmziQnP5vA99mzLqvhtBnW/COSMDPP1DQXrzkPs4PV2BQ9+APBOkP5VTQBXEo7jrK BQNEBvfoiTbtVexu/oawttJMA7NIim6QB6kCqPbKtkxwinaCBJ/QClUOCq0wB2uq0eZlVrqwJrAL zKzjcXzFA3uoBpXQokQQB1sQ3N7w0SZrCnOqDD+EDkeQVkZQC+dKW+4wD1WnDTPECK/QD8lCVnzt x5JQltZw71TwJsLwDrMwBfmwCQeRCvVQEsOPEs8D7oQwrwRESeqwBwexE8vnDAOtAgdpCdmwEhGN VkrRi0b+0QlJ8QkvMRAJUQgnUQzt0BSHCBRBURIt0Rc1scYCJJ8UsYpWsRFb0RULkRixyw2hURpx 8RZtkRZl0TayUBRzEO6w0Rqd8Gsm5RSFLhUniRGD6BZpBwVZEE62cAz9sBK/8RqDURBhke0MMQzv EaeGERNXSuxyCRndT1KQrQi7ambiKSCDae566AcfiVrGEekyr5eehwPZUZIe8hjTcBH1J/fK7SBt sBx9KaE60sQOL50SkonyByJdqWpWss/+8ZMCjySLUSOTKyT1SIFc8iLP8SRrUiBhjJYILBfrsSS3 6LYoq7lokoW0biBD8CaL6eUYZ0X0RrrohdPkZ2DyxoP+3A35RtIpYXInPepgNkUrX49oshJxusy+ BgfdVOy3RMYtZ6/ydBLTntLcDsujhPJjXnBpRAjKkorTQg0tteSnQM31eA4oEdInFbLxZDK6qjIp D6pfEEwtcyvYSrLJfGsGfbBOMtIu42iddsb7bOwvJ7O5/pJoOk+1QibJAPPXyIY1p0Y08fIrJRIg Y6on54YcFfMzbRI3j8kilXJdahPy+u/Qvq/XiPPpDpDcFkrh6JIpi3Mi9cmhHg46Vc02qw/3lLPm uHMpiSn5rvPsfhMkwdIhv0c8501nPNM8F6n9pg4+x6o8sxP/Dqcgt0Tg7pMnzQklUZFb+ms3Hawu ozP+KhWpPz9sLBnK6bKEQLET3lRxMXdnjqyzlCxJPzUlQB/UHHvT1GCR5bjpMBdo/hpSHYWI3hzx Qz/UH0EzQv0T11J0KDeTnrBN52j0Qv0NRlNUQKGyPWHIET8ASINUSIeUSIvUSD/AF5GvIR9x5GL0 hm70pbDrSKeUSos0SQ20RREU7qqUS6v0Smdy19KiS8fUSL8UQjl01LaUTNc0SM0UTPGzINhUTt1U JNGUAqVUTteUTt/03wwiT/VUotwzS7NPTf+0S/eUT5dTTA31UAMVS+2U0gqVUakUUROVhfx0Ur3U UQ/pQAkVTzN1SivVUnUTU0H1SEXVN+nTIwf0fGz+y1RDdVNHFd9K9VWJFFVblZ5UFfO+00ETc1Fr 1VZjVVaNUVKBtU2FVdxeklh79MK+TR/J0FllNExp1ViB9FaH1aqotVqv1VejsAo9dNMGJURXVVGX cgXH9bd8zYZ+tFqFlFuxVWi01Vjf9dZWVF0rhfLQFRGXlV9n8Cx9I1/tdSFfNEd5Ij1rs2BZbkc1 9FwFNl1NzHYq8F/LKGADVjhDClwTlkkvFl5NRmNBVF8dk2MHc7wsdjQjk1c3q2GVUsNa7UFJ9CM7 NnRg1iST9WRnp2J3NWKZdWJ1Fl99tkBxrjRlFmWjCLdoc2SvMqKAtlybVjf9VV9bFmeD6mM1lmj+ ibBqC5ZPHHZqj9BkpbXqlIw0f/YIk9YmGLQZs1ZHm6J2Ji9J2g1WxOUZxXLxCo9t1TZH1XH3Quhm JdNrmbZfnTbLkkM1zaps+xYz9zZxY3ZXF3fpMDRJGO9sIRfibLZoHTdMS0pxi5NwIXMqATdlXy9l v5Zlb7ZnSdNgEfc/c2sMNQ1DLUfZRAda0XYtvfDOUBQQIasPLRc7Zm04WTevGNd0N1czIVZXD3d0 G3d4get0w2bthMVJ3U5FXYOpcnGa7FB2/8q+KAa0+HAvyaItzRB8k+Uo6acz7VGp5pawFHY8hM16 hZd5ifdhXVY6Rdd+l9cdH1FcuRZiYxF6Y1H+cGEGGsWsdV03fA8YgbsXbp90d2Wx0RI4u2JPZHfx c9VXc38kcxKtFEM2y+LXe1Vuf81WhDm4KkmXIzkXugyGRKiSMM3QbR+YfGvXfCPYbsUne0WHi7gQ gguIjWoHdFS4fhNsCuHXhAc2dJ/2fj14gs215aS2ERW2QgwxeCfvtgAvDu8ruxa4GXG4G22Li3kx cnr4Hj+X9NaWXKQYp4hYeY04idt4jYt4P1MQt7DQiZcIzqI4Y0fY/3bRaVTXje2mjuGSScssceG4 KQMYiRNZieu1d6NMNOuYse74jGvt6MJrfv3t3AI51hhDkdPNkP8HkTv4gj8ZYwdPuIAYkf/+Vyik Vd5ALMEwuZMTaNtgGX8ZOXBvuYOLGG99ikvCCpVxOWB8TPx8GTHd+Ml2JlK4cl8JNoT9mIQxl1xr 2Vutln/PeJVfmW9j+ZhBeN4AmOyC2Jnv1n+j96UeOZwveI2d7JqTWX6bFW+fGZ49F3lLt1utiJvP OZ3n+VP+UFvUs4ZxTvHYlo5qWHwX8p5Z+XKjOanoWI31mY1jWZTf+I13OZ4Pipf12FfxsZorTpy5 8M74eHvPJRsFEXefGYYlyny7Lh87jVU1GqMLeaLfeaMXFqIVWpeX2dmaN5+nL6gE+oZDOqWL56cv C4HfkHL1lpAGWYgAqWalWbRYmH5DGZ3+JdqhodpzddqhPfV85NaKU5ppunqH+dirfXh8vfhsvzpy /7mU46qhbRqnkwerFfqPo7lz8zdhKxqfS6VUnnWXGZpqLYOvaDiG4wZ7uY0Xh3qwi9qJytqG+eqQ pZdwNoQf+zqE2ZmmBbSv8RqhwfayDcuqaTquEzpbM8g82muzH2ZCjZIKvziMu3CAwFh7uZgoR6mK S1QlZ5W0NcNvVRqfi9J+P/swQ/utIxp5Vzan31q4ofmopoO5WfqlheT42k4KfY9fm7u0dxtXT9s0 zRW57xWcp7q4+zWzZxqv9VqyUZqyK3ts5nK4jxOyvwSA0zubnpukjJuZo3Vnj9d4udv+cT87v9GQ 6E7Rss1Wp4F7u6V6p1fVvg38qTX7ajMwngu8u8mbwjv7NMV7wqP6wY0vwoM7w3s7bDt8RRlcaTdc 45K7vj/cL/VbtJPyiJB1xL1bZN2HyFr4FU3c0GhcynzYqJ3uxcX2qmUcmGu6xaWSpYR6wa7KY47s YEHvd/iZq/QKfADtTXL1uxO8yD3uyBFIMIxH2pbcWZq8+Z5cfhDEccr8sG1NqP4bwaGJzI/Hy+F8 yWZKgnFcoLncYzioy+c8aaCUqZnVzgM9UgFd0AudrSG1gOXZ0ME00S08aFl8OY/sgpA8Py0Tkl1P zO3P0hG3LNeTZHSL0i89jo+Yc67+GHpl2a2oWM+ve4PyXM7oh2btXMrznHiEZ4MkHXYXy9Qt6NRj valJ3TsMyNVbHXi0O2LinNqIvdU5CIsXHQhXHWSQR1m2rLAVByvNfM973djbXK5PeD1VOdpzGC7h x8ydvbbAfbRgfdxdi/8oqlPNHd67k9Djnd4paFDrHd+V9crznd+HD9L7HeCpE1IDnuBZdd8LHuHX bd4TnuEXFNgbHuKTc+EjnuK3duIrHuN5d8gznuMdfq47HuTD7t9DnuTP9+JLHuVBeeRTnuW98uT5 PdNNSfre3cRj3qS+595r/sFnPuc33OY9iecHHt5/XpOC/uXznehjkrpXHuKTPiz+d/R0a4nmfX7n dy/q18hMpr7qZwbIb2hpQ7Q0h1bD8iQ1qeOP7VvkV+rqp9XgnH7/iGplyn4rqQtG6t5HyjLuydi0 J6NxApuwhfEoh9AwD3uJeWbtcbTtW97BJxllANOgdgs2DccUAdk11Urs9eu70EowG9+3UJyWL8yT sf7zP77jxdH7NPj0U78y95lgIHlPCuyDUyxdNL+fFcYwN9jlQ1/t057bM970516ZyTI9Vp9kyZjv Sadn5Z7uD2wwC9O5PD+bM0z3o+vwS/zJ2rnbSf73kXL2hd/FJX+1Lnn3V9q0VGa1BNmxwe3R2MrX rUmZg5/VHexfGTv4Nz7kd8n+7QHin8CBBAsaPIgwocKFDBsCQPjwYMSBEwtWFFgRwEWLHAle/NjR 4MaGEkmaPIkypcqVLFu6fAkzpsyZK0fSvIkzp86dPHvWhAjUY1ChJkESpbjQps2US306fQo1qtSp VDFWvYo1q9atVodafKgx4caxYUWG7IpUZFilMZtyfQs3rty5R+navYt361K3Ckca/Tf2LGDBGdnC 5Js3seLFjL02fmwWsmTBlB16/Ys28+C6mxkitjw5tOjRWT+Tlmv6NFy+pptmJAyb8+fUfVXbvo37 cG7FtHdXbV2WYvDaaYtrxtxZs9i2vps7f54c+mrpc3vbtl6Suvbtj7Fzz+n+/fvN8KPJGxePPr1W 80WVk9QIH757lOxVsvcbdWJE6/t91pdc33/qDUggfU+RtxeAuiEHVX9MzUeTgN0xV+BP0T2Y3FoY 7edgZIh1aKGB/ek3H4hE/RfggWgFx2Jk2XWmX4xpybiicBS6BCKJM+pY44bHwdjjhR1J6Nh2KVaI 4YyDabhZWWABZpR8Ujr5WpNLAnmilU5myKFVT0Ip1IjC0fjklh6Z+aWYZfoopH0qYpkZWfHpGGVd HVbJYIgt8Sjnj9HlqGRXJroG4UzY9fkVoklJNCd/NyJ5UnwbgmUmUvJ5eWKXYEJ0KaaJclgYpTFq KOp5NX6ZZadl4gclpZPdnvlqpzjuhKdxVXKW5YsZBmklrnqyBNKgfhpmaXEOpmYieA/eKuiQlXlK XJKzQjqeUkRCNxxk19rKK7MQ8sltoLuueOS0sHLJ5rhwhtvrutlt+6xnsg37bLLxyqsbtfruuye/ 0ZorFbyRYnVoSC2mS6Od/0rbr78OP7wwv5LKJPCi6hW8nK6yNZogsI9CDDLEFTs8sr8YG3vUraxl 7HG+Ib9MMswRymxoeuXSjHOBJUucs8vf3dxz0D8L3TDRbqIHtNFKN7fzvk3r+zRqS09NddVWX411 1lpvzTV1AQEAOw== ------=_NextPart_000_119B_01C24FFE.C6C37160-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 06:43:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UDhiwf014049; Fri, 30 Aug 2002 06:43:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UDhiOv014048; Fri, 30 Aug 2002 06:43:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UDhcwf014041 for ; Fri, 30 Aug 2002 06:43:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UDhmuH013036 for ; Fri, 30 Aug 2002 06:43:48 -0700 (PDT) Received: from mg.hk5.outblaze.com (202-77-181-23.outblaze.com [202.77.181.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00039 for ; Fri, 30 Aug 2002 07:43:41 -0600 (MDT) Received: from ws2.hk3.outblaze.com (202-77-181-50.outblaze.com [202.77.181.50]) by mg.hk5.outblaze.com (8.11.2/8.11.2) with SMTP id g7UDhcp00737 for ; Fri, 30 Aug 2002 13:43:38 GMT Received: (qmail 18635 invoked by uid 1001); 30 Aug 2002 13:43:38 -0000 Message-ID: <20020830134338.18634.qmail@atozasia.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) Received: from [161.142.14.4] by ws2.hk3.outblaze.com with http for sinlk@atozasia.com; Fri, 30 Aug 2002 21:43:38 +0800 From: "sin lk" To: ipng@sunroof.eng.sun.com Date: Fri, 30 Aug 2002 21:43:38 +0800 Subject: IP Header Compression Suggestions X-Originating-Ip: 161.142.14.4 X-Originating-Server: ws2.hk3.outblaze.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We would like to give our comment regarding rfc2507 – IP Header compression to fulfill our requirement of our minor assignment. Please feel free to give any comment. Thank you very much. If you're interested, it is also available at the following URL: http://www.geocities.com/ipv6group/index.html Group 4 & 5 University Science Malaysia Suggestions On RFC2507 – IP Header Compression After reading the RFC2507 – IP Header Compression and other related RFC (RFC1144, RFC2508, RFC2509 and RFC3096), we would like to express our opinion on IP Header Compression. As a simple introduction, packet compression can be performed by taking advantages of the constant field, field change infrequently or field that its value can be predicted (For a complete list of these fields, please refer to RFC1144). >From our understanding, the way packet compression work is that, the sender will send a full header, which is an uncompressed packet with Context Identifier (CID). The information in the full header is used to create/refresh the context, which have the information to uncompressed compressed packet. Compressed packet can be decompressed using the context information that had been established, using the CID as the key. If CID can be found, the packet will be uncompressed. But if it can’t be found then it will either be stored for future processing (when full header arrive later) or be discarded. >From RFC2507, we can’t find any information that discusses on the number of contexts to be kept by the compressor. In situation where there are a lot of compressor and only one decompressor, there is a possibility that memory limitation limit the number of contexts that can be kept at a time. The issue is how to handle such a case if it happened. Below, we give our suggestion to overcome this problem. We suggest that we associate a time field to each context at the decompressor. From time to time, compressor will let decompressor knows that it is still using that context by updating it. This can be done either using a different type of packet or the information can be attached when packets are grouped together. Compressor will from time to time check the time associate with every context, and record down any contexts that are expired. The expired context can then be reclaimed, and use by others. In situation when there are a lot of compressors and there is not enough memory to keep the new context, the sender will have to send in original uncompress packets. Compressor can be notified either implicitly or explicitly. Decompressor can explicitly send a special packet to notify compressor, when decompressor receives the new full header. Decompressor can also just perform a discard on the full header if situation not allow it to send a packet to compressor. Compressor that f! ails to send compressed packet will then switch to normal packet and resend them. We would also like to give our suggestion on how to implement the system in a wide area network, which involves more than one hop. We suggest that at every decompressor, decompressor will mapped and every compressors’ CID to a unique CID and send them to the next node. The reason for mapping the CID is to make sure packet from different source has a unique CID. The same operation is performed from source until destination. If in the process, there is some node that unable to perform the compression, then the node before it will uncompressed them and send them as normal packet (uncompressed packet). -- __________________________________________________ Get FREE 50 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 08:24:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFOwwf014247; Fri, 30 Aug 2002 08:24:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UFOwGp014246; Fri, 30 Aug 2002 08:24:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFOpwf014238 for ; Fri, 30 Aug 2002 08:24:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22414 for ; Fri, 30 Aug 2002 08:25:01 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25345 for ; Fri, 30 Aug 2002 08:25:01 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B31ED4B23; Sat, 31 Aug 2002 00:24:57 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Fri, 30 Aug 2002 15:16:04 +0300. 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: another input to IPv6 addressing architecture From: itojun@iijlab.net Date: Sat, 31 Aug 2002 00:24:57 +0900 Message-Id: <20020830152457.B31ED4B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >o Move any document that suggests the use of IPv4 mapped address on wire >> > to historic, due to security reasons. >> Which documents would this include? SIIT? >Only non-algorithmic portions of SIIT. (Or else NAT-PT should have to be >rewritten to be independent). >> Any others? >The -00 nat64-nat46 draft. draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 08:50:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFo5wf014457; Fri, 30 Aug 2002 08:50:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UFo5Ps014456; Fri, 30 Aug 2002 08:50:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFnwwf014449 for ; Fri, 30 Aug 2002 08:49:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UFo9uH010687 for ; Fri, 30 Aug 2002 08:50:09 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10322 for ; Fri, 30 Aug 2002 08:50:03 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E93714B23; Sat, 31 Aug 2002 00:49:59 +0900 (JST) To: Francis Dupont Cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Fri, 30 Aug 2002 13:10:32 +0200. <200208301110.g7UBAW6o037869@givry.rennes.enst-bretagne.fr> 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: another input to IPv6 addressing architecture From: itojun@iijlab.net Date: Sat, 31 Aug 2002 00:49:59 +0900 Message-Id: <20020830155000.E93714B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> o Move any document that suggests the use of IPv4 mapped address on wire >> to historic, due to security reasons. >=> you are a bit hard: these mechanisms should simply use other >injections of the IPv4 address space into the IPv6 address space >(there are many ways to inject a 2^32 space into a 2^128 one :-). SIIT and NAT64 takes advantage of the "confusion" regarding to IPv4 mapped address, so they have no other choice (or they will require changes to nodes in SIIT/NAT64 cloud). >> Another way is to deprecate RFC2553 section 3.7, however, due to the >> wide deployment of applications that use IPv6 basic API, the option is >> not feasible. >=> I strongly object to this part of your proposal. IMHO IPv6 is NOT >a new protocol, it is only a new version of the IP protocol. So the >right target is to provide an "all version" API, as it is easy to inject >IPv4 into IPv6, the section 3.7 is the right idea! please be sure to read the whole draft. i disagree that RFC2460 section 3.7 is a good idea, as it adds a lot of complication into the kernel API (AF_INET setsockopt operations on AF_INET6 socket, multicast, complicated and unauditable tcp/udp/pcb layer). it seems right for shortterm porting, but it actually hurts people in long term. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 30 09:14:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UGEVwf014566; Fri, 30 Aug 2002 09:14:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UGEVKu014565; Fri, 30 Aug 2002 09:14:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UGEQwf014558 for ; Fri, 30 Aug 2002 09:14:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UGEauH017333 for ; Fri, 30 Aug 2002 09:14:36 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19735 for ; Fri, 30 Aug 2002 10:14:31 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 09:14:29 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Aug 2002 09:14:28 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 30 Aug 2002 09:14:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-daley-ipv6-mcast-dad-00.txt Date: Fri, 30 Aug 2002 09:14:29 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEE78@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-daley-ipv6-mcast-dad-00.txt thread-index: AcJQMOubh+xyFKl6SAOfN8XSJWcX0gADmbZw From: "Richard Draves" To: , Cc: X-OriginalArrivalTime: 30 Aug 2002 16:14:29.0131 (UTC) FILETIME=[51439DB0:01C25040] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7UGEQwf014559 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The way MLD works today, if you don't have a valid link-local address to use as the IP Source, you use the unspecified address instead. It sounds like (section 4.1) you want to change this? I assume so the router can unicast a response. I think this is a problem because until DAD completes for the link-local address it's really not right to accept packets sent to it. So your optimization can not apply to the link-local address, only subsequent addresses. You say only the first MLD Report may be a report-requesting-response. Don't you mean the first one for each solicited-node multicast address? Or even more accurately (since some implementations allow an interface to be "reset" to that DAD etc is redone), just strike this sentence and leave the requirement as only unsolicited reports may request a response? What is your intent for retransmitted reports - are they not supposed to request a response? Rich > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, August 30, 2002 4:49 AM > Cc: ipng@sunroof.eng.sun.com > Subject: I-D ACTION:draft-daley-ipv6-mcast-dad-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Duplicate Address Detection > Optimization using IPv6 > Multicast Listener Discovery > Author(s) : G. Daley, R. Nelson > Filename : draft-daley-ipv6-mcast-dad-00.txt > Pages : 12 > Date : 2002-8-29 > > This draft describes a possible optimization to Duplicate > Address Detection (DAD) which can be used to successfully > terminate DAD early, based on the presence of listeners on > the link-scope solicited nodes multicast address. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-> daley-ipv6-mcast-dad-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-daley-ipv6-mcast-dad-00.txt". > > A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-daley-ipv6-mcast-dad-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 31 01:39:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7V8dGwf016320; Sat, 31 Aug 2002 01:39:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7V8dGja016319; Sat, 31 Aug 2002 01:39:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7V8dBwf016312 for ; Sat, 31 Aug 2002 01:39:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7V8dMPG022235 for ; Sat, 31 Aug 2002 01:39:22 -0700 (PDT) Received: from intipen.icpg.edu.my ([202.186.197.168]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03977 for ; Sat, 31 Aug 2002 02:39:15 -0600 (MDT) Received: by intipen.icpg.edu.my with Internet Mail Service (5.5.2655.55) id ; Sat, 31 Aug 2002 16:40:28 +0800 Message-ID: From: Lim Min Min To: "'ipng@sunroof.eng.sun.com'" Subject: Comment on RFC 1981 - Path MTU Discovery for IPv6 Date: Sat, 31 Aug 2002 16:40:26 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Referring to item 5.3, we think that the timestamp value need not be set to "Reserved". This is because we can just use the timestamp and the current time to determine that the PMTU has expired. For example, before sending out a packet, the timer-based procedure should check if the PMTU to be used has expired based on the cached timestamp and the current time. If it has indeed expired, then no packets should be sent out using this PMTU. The PMTU value should be reset to the MTU value of the first hop and the PMTU discovery should be restarted. We think the "Reserved" value can be removed to make the process of detemining the stale PMTUs less complicated. We welcome suggestions and comments. Lim Min Min Universiti Sains Malaysia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 31 05:56:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VCumwf016628; Sat, 31 Aug 2002 05:56:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7VCulZd016627; Sat, 31 Aug 2002 05:56:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VCugwf016620 for ; Sat, 31 Aug 2002 05:56:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VCuruH006618 for ; Sat, 31 Aug 2002 05:56:53 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10027 for ; Sat, 31 Aug 2002 06:56:43 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7VCuZh09608; Sat, 31 Aug 2002 14:56:36 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA01739; Sat, 31 Aug 2002 14:56:35 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7VCuY6o043720; Sat, 31 Aug 2002 14:56:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208311256.g7VCuY6o043720@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: another input to IPv6 addressing architecture In-reply-to: Your message of Sat, 31 Aug 2002 00:49:59 +0900. <20020830155000.E93714B23@coconut.itojun.org> Date: Sat, 31 Aug 2002 14:56:34 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >> Another way is to deprecate RFC2553 section 3.7, however, due to the >> wide deployment of applications that use IPv6 basic API, the option is >> not feasible. >=> I strongly object to this part of your proposal. IMHO IPv6 is NOT >a new protocol, it is only a new version of the IP protocol. So the >right target is to provide an "all version" API, as it is easy to inject >IPv4 into IPv6, the section 3.7 is the right idea! please be sure to read the whole draft. => I read it when you posted it in the bugtraq list.. i disagree that RFC2460 section 3.7 is a good idea, => this is a matter of taste and obviously we deeply disagree. as it adds a lot of complication into the kernel API (AF_INET setsockopt operations on AF_INET6 socket, multicast, complicated and unauditable tcp/udp/pcb layer). => this is not so hard and one stack supporting the two versions is simpler than two different parallel stacks for each version. it seems right for shortterm porting, but it actually hurts people in long term. => my target is not easy short-term porting, it is more a long term and philosophical issue. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 31 08:07:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VF7wwf016837; Sat, 31 Aug 2002 08:07:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7VF7wml016836; Sat, 31 Aug 2002 08:07:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VF7jwf016821; Sat, 31 Aug 2002 08:07:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VF7pPG009070; Sat, 31 Aug 2002 08:07:51 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23180; Sat, 31 Aug 2002 09:07:41 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g7VF7bh12743; Sat, 31 Aug 2002 17:07:37 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA02224; Sat, 31 Aug 2002 17:07:37 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7VF7X6o044997; Sat, 31 Aug 2002 17:07:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208311507.g7VF7X6o044997@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Tue, 27 Aug 2002 12:33:34 +0300. <200208270933.MAA18566@burp.tkv.asdf.org> Date: Sat, 31 Aug 2002 17:07:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > >I'm going to ingore RFC 2710 on this point. I do not send MLD for link > >local multicast groups. > > then your device will have trouble operating on coming switches > that support MLD snooping, and it will be very difficult to > track the issue down (extraordinary support load to your colleagues). > i suggest you to follow RFC2710. => I strongly support Itojun! Please don't ignore standards just because NIBY. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 31 08:23:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VFNjwf016977; Sat, 31 Aug 2002 08:23:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7VFNjE0016976; Sat, 31 Aug 2002 08:23:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VFNdwf016969 for ; Sat, 31 Aug 2002 08:23:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VFNouH028806 for ; Sat, 31 Aug 2002 08:23:50 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04128 for ; Sat, 31 Aug 2002 09:23:44 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.184.113) by smtp2.libero.it (6.5.028) id 3D6B8C49001A8525; Sat, 31 Aug 2002 17:23:17 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 50126296E5; Fri, 30 Aug 2002 16:46:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 3DA4628F77; Fri, 30 Aug 2002 16:46:36 +0200 (CEST) Date: Fri, 30 Aug 2002 16:46:36 +0200 (CEST) From: Mauro Tortonesi To: Pekka Savola Cc: Steve Deering , Thomas Narten , Joe Baptista , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 30 Aug 2002, Pekka Savola wrote: > Whether RFC3041 is too complex mechanism for some of the needs is a > different thing though. I think "randomizing" your MAC address once and > for all (or every time your computer restarts or whatever) should be > enough for most. this bootstap randomization of the MAC address without RFC3041 network layer addresses does not solve the problem of untraceability for mobile hosts. maybe an eavesdropper (that could be anywhere along the communication path) would not be able to find out the real hardware address of the interface of your host, but he will be able to trace the movements of your host with a little effort. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it mauro.tortonesi@ing.unife.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 31 08:41:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VFf4wf017037; Sat, 31 Aug 2002 08:41:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7VFf4Ua017036; Sat, 31 Aug 2002 08:41:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VFexwf017029 for ; Sat, 31 Aug 2002 08:40:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VFfAuH000520 for ; Sat, 31 Aug 2002 08:41:10 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02989 for ; Sat, 31 Aug 2002 08:41:04 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g7VFecX28078; Sat, 31 Aug 2002 18:40:38 +0300 Date: Sat, 31 Aug 2002 18:40:38 +0300 (EEST) From: Pekka Savola To: Mauro Tortonesi cc: Steve Deering , Thomas Narten , Joe Baptista , Subject: Re: IPv6 Interview Questions and critic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 30 Aug 2002, Mauro Tortonesi wrote: > On Fri, 30 Aug 2002, Pekka Savola wrote: > > > Whether RFC3041 is too complex mechanism for some of the needs is a > > different thing though. I think "randomizing" your MAC address once and > > for all (or every time your computer restarts or whatever) should be > > enough for most. > > this bootstap randomization of the MAC address without RFC3041 network > layer addresses does not solve the problem of untraceability for mobile > hosts. RFC3041 is not meant to provide (full) untraceability, and if it is, it fails to do that. > maybe an eavesdropper (that could be anywhere along the > communication path) would not be able to find out the real hardware > address of the interface of your host, but he will be able to trace > the movements of your host with a little effort. This 'mobile node' case is one major one where RFC3041 may actually be useful and work to enable some form of untraceability. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 31 10:18:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VHIuwf017183; Sat, 31 Aug 2002 10:18:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7VHIueT017182; Sat, 31 Aug 2002 10:18:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VHIowf017175 for ; Sat, 31 Aug 2002 10:18:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VHJ2PG025095 for ; Sat, 31 Aug 2002 10:19:02 -0700 (PDT) Received: from petasus.png.intel.com ([210.187.61.73]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24443 for ; Sat, 31 Aug 2002 11:18:56 -0600 (MDT) Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.233.18]) by petasus.png.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.43 2002/08/30 20:06:11 dmccart Exp $) with SMTP id g7VHJQL29074 for ; Sat, 31 Aug 2002 17:19:26 GMT Received: from pgsmsx17.PNG.INTEL.COM ([172.30.233.17]) by pgsmsxvs01.png.intel.com (NAVGW 2.5.2.11) with SMTP id M2002090101213621355 ; Sun, 01 Sep 2002 01:21:36 +0800 Received: by pgsmsx17.png.intel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 1 Sep 2002 01:18:51 +0800 Message-ID: <8582A38FC37CD511BC850002A50A56280846B94B@KMSMSX101> From: "Mognesvari, Muniandy" To: "'Mauro Tortonesi'" , Pekka Savola Cc: Steve Deering , Thomas Narten , Joe Baptista , ipng@sunroof.eng.sun.com Subject: RE: IPv6 Interview Questions and critic Date: Sun, 1 Sep 2002 01:18:50 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Referring to the RFC3041, and based on the comments given below i think in order to protect a mobile network, we can use the these approaches ; Prevention and Detection. The prevention approach consists in reducing the risk of threats by insuring that users respect the rules of usage of the network services. A well known mechanism is authentication based on shared secrets. In this section, we propose one-way authentication protocol into which user anonymity and untraceability are embedded based on both the secret-key certificate and the algebraic structure of the error-correcting code. Through issuing the secret-key certificate to each mobile subscriber, the key management problem of the authentication server can be eliminated even though the symmetric-key encryption is employed. (I read this proposal from an article related to authentication for mobile network). Referring to section 2.4, I agree with your proposal of using the pseudo-random sequence of interface identifiers via an MD5 hash. RFC1948 suggests the use of source IP address, destination IP address, source port and destination port, plus an additional random secret key. This data should be hashed using a shortcut function to generate random and unique sequence numbers for every unique connection. Failing to account for this can lead to improper conclusions when analyzing TCP generators with respect to ISN predictability. However, my concern is that this could create packet overhead. Note: I'm a student who is still getting acquainted with IPV6. So would appreciate any feedback on my comments above. Thanks. Regards, M.Mognesvari -----Original Message----- From: Mauro Tortonesi [mailto:mauro@ferrara.linux.it] Sent: Friday, August 30, 2002 10:47 PM To: Pekka Savola Cc: Steve Deering; Thomas Narten; Joe Baptista; ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interview Questions and critic On Fri, 30 Aug 2002, Pekka Savola wrote: > Whether RFC3041 is too complex mechanism for some of the needs is a > different thing though. I think "randomizing" your MAC address once and > for all (or every time your computer restarts or whatever) should be > enough for most. this bootstap randomization of the MAC address without RFC3041 network layer addresses does not solve the problem of untraceability for mobile hosts. maybe an eavesdropper (that could be anywhere along the communication path) would not be able to find out the real hardware address of the interface of your host, but he will be able to trace the movements of your host with a little effort. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it mauro.tortonesi@ing.unife.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------